On 24/08/17 19:19, Ivan J. wrote:
> On Thu, 24 Aug 2017, Evilham wrote:
>
>> Devuan Notes Aug 23/14 2017 @20:30 UTC
>>
>> Pad is here. Please add notes prior to the meet:
>> https://pad.dyne.org/code/#/1/edit/P03NCxozgULLEWFiD+ii0w/7VmjTKxq8l5fWk43B6FvnvqX
>>
>> Other pads relevant to the meet:
>>
>> Current infrastructure:
>> https://pad.dyne.org/code/#/1/edit/usQoFADFDsJ9UAFbVm0H7A/FPGyscaoxWTAqqgscT1bw7VA
>>
>> Build system improvements:
>> https://pad.dyne.org/code/#/1/edit/nXiySd0FPHvG8pBgGgImxA/aJ87TdwIEWiIk96GZcFwypnb
>>
>> Present: Centurion, rrq, Evilham, golinux, dimitsos (briefly),
>> tremon (observer), blinkdog (observer), gnu_srs (observer)
>>
>> ## golinux
>> - Thanks to all the newcomers for joining us!
>> - Confusion between jessie-updates and
>> jessie-proposed-updates - needs clarification on d.o
>> - There are issues relating release names and their stability
>> (people get confused, sometimes install wrong things, etc.)
>> There are posts of about this on dev1galaxy and irc (golinux)
>> * We should make it somehow clearer, one option would be to add on
>> d.o a repository equivalence table / branch explanation / ...
>> - Devuan repository | Debian repository
>> Jessie 1.0 (stable) | Jessie (old stable)
>> ASCII (testing) | Stretch (stable)
>> Beowulf (unstable, coming soon) | Buster (testing)
>
> Ceres is "unstable" and should stay that way. Are we introducing something
> between testing and unstable and making buster that in-between?
We could add testing-next for beowulf, but personally I'm hesitant as
I'd rather we focused on getting ascii as stable before adding an extra
testing suite.
>
>> Ceres | sid
>> Experimental | Devuan-only packages
>> (that's not a release.
>> Jessie-proposed is also devuan
>> only packages)
>>
>> * jaromil . . . At the risk of volunteering Evilham without asking
>> first, I would like to suggest that you give him access to update
>> the website according to your current method. He and I work well
>> together. Then you will be relieved of that aggravation and the
>> website will benefit for having the most current information.
>> Seems like a win/win all around. (golinux) *
>> * I'd be ok with this; may look into replicating the pipeline
>> locally at some point before Wednesday, that way a chrooted
>> SFTP-only access to update the site would suffice (evilham) *
>>
>> - progress on rsyslog? KatolaZ was going to do further review.
>> What's the verdict?
>>
>> ## gnu_srs
>> - When will a repository for testing be created (i.e. Buster:Beowulf)
>> * I think when amprolla3 is finally in production (golinux)
>> - Time to build eudev for unstable, and eventually
>> ascii-proposed/ascii?
>
> I've pushed the new commits, and tagged the release. But we have to test
> this still, before pushing forward.
did jaromil generate the key for you?
>
>> * See notes above about releases. ascii is based on a STABLE release
>> even though it's not quite stable on devuan. (golinux)
>> - When will util-linux ever build so openrc can be installed without
>> privately built packages?
>> - What makes maemo so important to support with the Devuan
>> infrastructure, It's only for ancient Nokia N900 phones.
>
> That's where you're wrong. It's the whole point of porting. Maemo now
> (mostly) works on any machine and is not N900-specific.
>
>> How many of them are still out there?
>
> Way many ;)
>
>> * Here's a partial answer. There are other posts scattered here
>> and there with mor information: (golinux)
>>
>> https://lists.dyne.org/lurker/message/20170614.162030.49f3c95f.en.html
>> - KatolaZ: I know you are not present tonight. But, can you possibly
>> test your scorsh locally before requesting it to be used in the
>> infrastructure chain?
>
> Can you define a "local test"? Scorsh has test units and has been tested
> with local git repos.
>
>> * It would be nice to compare scorsh and a refactored releasebot in
>> action in a testing situation before making a decision. (golinux)
>
> Also keep in mind that scorsh solves the website as well. I don't think> releasebot does on its own. Gitlab used to have a pipeline for the
> website which was broken and never fixed when the server was migrated.
> Perhaps the admins can look into fixing that?
>We can create a job for this in jenkins - even it it's a non-standard
one. Ideally we should just build the website as standard deb anyway
(has the side benefit for making mirroring it easier too) - and either
hack the repo job to tell the webserver to install it or push the
content in alternative form to where-ever it needs to go. The problem
is the only ones that know how it's built are Hellekin and Jaromil...
>> * Pretty sure this has been the case already :). (evilham)
>> - Debian has the concept of Maintainers as well as Developers and
>> e.g. incoming.debian.org for uploaded packages.
>> * I think this translates to formalising Devuan's structure(evilham)
>> Comments and comparisons with Devuan infrastructure?
>> - I'd like to build an iso with the Devuan installer on it for test:
>> Any links? Or should I look at how Debian does this?
>> * look at this thread especially ozi's posts:
>> https://dev1galaxy.org/viewtopic.php?id=551
>> and also on dng mail list. Also chat with fsmithred. (golinux)
>> - Are the current access codes: ---:--b really too coarse grained?
>> If you can build a package for experimental why not for stable?
>> How do Debian solve this?
>> (tremon) for Debian, packages are only ever built for unstable or
>> stable-proposed-updates... packages then migrate by release manager
>> accord to testing or stable, respectively
>> (sherdlu) that is a delicious bit of information. Thanks.
>> (evilham) devuan's goal is to have something similar :).
>> In the mean time, we need to be able to trust some developers to
>> build stuff for unstable / testing, but only a few for stable.
>> - What about packages built for sid entering testing after 10 days,
>> as for Debian?
>> Good Idea, see above (evilham)
>>
>> ## tremon:
>> - Maybe something to consider would be to treat "Devuan Jessie" as an
>> LTS, and work on ascii to be parallel to debian testing,
>> that way we could save some development time and catch up with
>> debian quicker.
>> * one problem with that is that Buster has already been named as
>> Devuan Beowul, so we'd have to skip the ascii release entirely.
>> (golinux)
>> - dist-upgrade could be an issue; maybe as an exception we could
>> require users to perform a fresh install.
>> - (Sherdlu) not a good idea, IHMO. +1 (golinux)
>> The ability to upgrade, rather than re-install, is a very
>> attractive feature of Debian.
>> Especially for production systems, number-crunching servers, etc.
>> * no argument there, it is definitely valuable to have (tremon)
>> * Nice to see people's inputs here. So, as atractive as this could be,
>> for dev; probably not a good idea? (evilham)
>>
>> ## sherdlu
>> ### a constitution
>> * here's one by Hellekin:
>>
>> https://git.devuan.org/devuan/devuan-project/wikis/HellekinConstitutionDraft
>> * Here's the other one by nextime. Wasn't easy to find references but
>> finally success (golinux)
>> https://git.devuan.org/devuan/devuan-project/wikis/DevuanConstitution
>> (Actually it was right there in the wiki index rh column)
>> * And this document on decisional structure is informative.
>> https://git.devuan.org/devuan/devuan-project/wikis/DecisionalStructure
>> * jaromil - I have never seen the list of VUAs involved with Devuan.
>> Are they the owner members here?
>> https://git.devuan.org/devuan/devuan-repository-masters/settings/members
>> Many of them are unknown to me. At this point in our development, I
>> am not comfortable with the draft proposal presented in that
>> document giving so much decisional power to unknown individuals.
>> * Agree with this; on a related note: those accounts have currently
>> all build config / build permissions, some kind of permission
>> revocation policy is needed (evilham)
>>
>> ## Evilham
>> - In order to create better GL comments from ReleaseBot, we can use
>> this trick to get the build id of a queued job
>>
>> https://github.com/openstack/python-jenkins/blob/828eb92c481898e574f4729d030a7ea5b850a0d2/jenkins/__init__.py#L473
>> It does assume that that's the only job that gets queued between
>> calls, so maybe some check has to be added.
>>
>> ## fsmithred
>> - It's time to get some ascii isos out there. New people are showing
>> up at the forum wanting to install ascii and beyond.
>> Some have been especially disappointed when trying to upgrade to ceres
>> * Thanks for putting 32 bit one together for me. :) (golinux)
>> - Observation: If you upgrade to ascii, /lib is still /lib.
>> If you install ascii directly by debootstrap or live-sdk,
>> then /lib is just a symlink to /usr/lib.
>> This may or may not affect you. I got burned by it with
>> refractasnapshot. Need to add some /usr/lib/live/ dirs to the
>> excludes file.
>> (To complement the /lib/live/ lines that are already there.)
>>
>> ## CenturionDan
>> - wants people to file bug reports against devuan-releasebot - one for
>> each concise issue.
>> This should be the done for all of these infrastructure issues and
>> wishlist items.
>> - has been working on devuan-releasebot test suite with a view to
>> resolving the most complained about issues with it.
>
>
>
> _______________________________________________
> devuan-dev internal mailing list
> devuan-dev@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/devuan-dev
>
--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722