:: Re: [devuan-dev] Devuan Notes for A…
Top Page
Delete this message
Reply to this message
Author: Ivan J.
Date:  
To: devuan developers internal list
Subject: Re: [devuan-dev] Devuan Notes for Aug 23/14 2017
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?

>     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.

>     * 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?

>     * 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.


--
~ parazyd
GnuPG: 03337671FDE75BB6A85EC91FB876CB44FA1B0274
GnuPG: https://parazyd.cf/FA1B0274.asc