:: Re: [devuan-dev] Devuan Notes for A…
Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Daniel Reurich
Fecha:  
A: devuan developers internal list, Ivan J.
Asunto: Re: [devuan-dev] Devuan Notes for Aug 23/14 2017
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