On 08/10/17 04:57, Ivan J. wrote:
> Dears,
>
> I'll use this opportunity to identify a few blockers I'm currently
> experiencing. Until all of these are solved/unblocked, I will be
> abstaining from doing any other work on Devuan as is. I am taking up the
> Devuan SDK as my main priority again and will not interfere with
> anything else that is happening.

Sounds like a rather childish response to me.
>
>
> * Releasebot:
> Dan has asked me for help on his releasebot thing, and upgrading it to
> the v4 gitlab API. I've provided him with a schematic and separated the
> gitlab code from actual releasebot functionality. It is up to him and
> anyone else who feels like it to complete it and make it running. I
> haven't finished it myself because I don't have enough insight on the
> plans.

Ivan, we discussed your initial approach on irc (pm)* and I was left
with the distinct impression you were going to continue on with the work
based on the ideas we discussed. (I've appended that conversation below
as a reminder). And besides you still haven't pushed it to a git repo
on git.devuan.org which makes it hard to get others involved.
>
>
> * Jenkins:
> The armhf and armel boards have been waiting on inclusion on the CI as
> build slaves. They have not been included yet. Both are preset and have
> jenkins and jenkins-debian-glue-buildenv-devuan installed. They also
> have the /etc/jenkins configuration from build0008.

I'm working on it. I'd rather you had given me a clean build without
anything installed, as you already alluded to the fact that build008 was
a mess with odd versions of things, and a whole bunch of cruft as well.
Can you just give me a clean image to start with?
>
> This task blocks building of rsyslog and basically everything else since
> qemus are too slow. But rsyslog is most important.
>
yup, but until we have a native arm64 we're still going to have that
issue as amr64 was the most problematic... If need be I can give my
expressobin setup another go. I've got a 32GB uSDcard for it now.
>
> * eudev:
> eudev has been hanging in the experimental repo for 5+ months as of
> today. No incentive was shown to include it in actual Devuan
> repositories.
>
I'm sure we agreed to push this forward more then once now, along with
the decision that you patch it to restore the old kernel based network
interface name scheme. I haven't heard whether you've done that or not yet.

> This task is important as people will bitch about seeing systemd-udevd
> in their process list if we don't replace udev with eudev in Ascii and
> the future.
Oh come on, that's not that much of an issue... but as I said we'd
agreed to it already, my understanding is you were working on that
package, so where are we actually at on it.
>
>
> * Antofox's MATE repositories:
> Nobody has shown any appreciation towards this effort and has talked
> about what has to be done to include this and enable Antofox to use our
> CI to build and/or provide packages officially for Devuan.
>
> This task is important for all desktop users as it provides yet another
> DE which in this case gives the feeling of old Gnome2, which some users
> will want. It only brings benefit to Devuan.
>
I'm sorry, I haven't looked at it yet. Has anybody else looked? I'm
fine with including it in principle, but somebody would need to review
the patches to get them in, and walk antofox through the process. I may
find some time this coming week to give it a look, but not promising
anything as I'm still buried in paying client work...
>
> * devuan/dists on pkgmaster:
> This task is a 5 minute job that has also been hanging for a while. The
> devuan/dists directory structure has to be pushed to pkgmaster in the
> same manner devuan/pool is pushed now.

I'm sure I responded asking for details on where to push it?

I'm also waiting for a response to the question about
packages.devuan.org dns records and how to ensure we don't break the
jessie installers, and that probably comes down to how the gpg key
verification works and how the new keys were added.>
> Completing this task will finalize the pkgmaster setup and Devuan will
> be able to provide mirrors.
>
Agreed, that would be good, and it shouldn't take long to sort this out.
>
> I'll be around for questions on any topic, but I refuse to do work until
> serious commitment starts being shown.
>
Now that seems to me to be a rather unhelpful approach, perhaps a more
positive tone would help encourage people to getting going.

Scolding contributors because you don't get instant gratification is
only going to turn them off and drive them away.

> Have a good one.
>
Indeed, I've had a somewhat less stressed weekend, so I've not been at
my desk much...

Cheers,
    Daniel

<qupte description="PM discussion on irc between Centurion_Dan and
parazyd about releasebot 27th Sept (NZDT - gmt+13hr)" >

12:44:56 AM - parazyd: hey
12:45:04 AM - parazyd: i can send you some of the code to see if you
like the approach
12:45:26 AM - Centurion-Dan2: is it on gitlab?
12:45:31 AM - parazyd: not finished since i don't want to lose time if
you disagree with things and the way i approached it, but you can read
it and see the general logic
12:45:38 AM - parazyd: no
12:45:50 AM - Centurion-Dan2: sure...
12:46:05 AM - parazyd: gitlab_pool.py: http://sprunge.us/CJGJ
12:46:12 AM - parazyd: releasebot.py: http://sprunge.us/NMWQ
12:46:23 AM - parazyd: config.py: http://sprunge.us/jbiZ
12:46:31 AM - parazyd: so gitlab_pool would be ran by cron
12:46:56 AM - parazyd: and if the authorization is right, it would call
the releasebot module to proceed with jenkins
12:49:20 AM - parazyd: with this, releasebot.py is reusable even without
gitlab per se
1:00:20 AM - Centurion-Dan2: the gitlab pool seems pretty tidy to me,
provides a pretty clear demarcation between releasebot core logic and
gitlab specific interface stuff - although I'd rather like to filter the
labels on that side rather then in the main releasebot code. I really
dislike the python config files and would much rather sticking with
configparser.
1:00:50 AM - Centurion-Dan2: also need to DRY up the jenkins api calls...
1:01:07 AM - Centurion-Dan2: (don't repeat yourself) ;-P
1:01:16 AM - parazyd: ok @ all
1:01:27 AM - parazyd: as said, not finished. just wanted to see if you
like it and if i can proceed
1:01:52 AM - parazyd: so with labels, you mean sorting them at the
gitlab side
1:02:05 AM - parazyd: makes sense
1:03:59 AM - parazyd: any other comments? i don't know if we have to
redefine the whole authorization part or to reimplement what's already there
1:04:18 AM - Centurion-Dan2: yeah, we can filter them against the job
type for a start.
1:14:03 AM - Centurion-Dan2: We'll need to reimplement what's there for
the most part.
1:15:54 AM - Centurion-Dan2: for authorization...
1:18:15 AM - parazyd: ok
1:19:53 AM - Centurion-Dan2: I don't think we can do much but accept and
use the permission levels that gitlab defines, unless you want to
provide a mapping to a releasebot specific ACL
1:21:14 AM - parazyd: iirc there were some new permissions in the new
gitlab?
1:26:01 AM - Centurion-Dan2: currently there are acl's for basic build
permissions, provided directly by the project and projects group ACL's.
1:26:01 AM - Centurion-Dan2: for job add/modify/delete, it requires
membership in a special project as does building -security suites and
also we could (but currently don't) restrict build of the stable &
testing suites that way too.
1:27:30 AM - parazyd: alright
1:28:02 AM - parazyd: is the "special project" a repository or a whole
thing, like 'devuan-packages'
1:28:27 AM - parazyd: maybe we should call that groups
1:30:08 AM - Centurion-Dan2: it's a normal git project, not a gitlab
group, but yeah I'd like to call it a "group" in releasebot config for
clarity.
1:30:39 AM - parazyd: yes that's what i meant
1:31:13 AM - parazyd: so it's the whole thing, right? not just a single repo
1:31:13 AM - parazyd: that confuses me when we talk about a 'project'
1:31:59 AM - Centurion-Dan2: it's a single repo
1:32:56 AM - Centurion-Dan2: devuan-masters or something like that, and
there also is devuan-security-team for the -security suites.
1:33:02 AM - parazyd: oh
1:33:17 AM - parazyd: alright then
1:34:11 AM - Centurion-Dan2: both are just single git repo's
1:34:20 AM - parazyd: i understood now, yes
1:36:39 AM - parazyd: ok then, i'll proceed with this a bit later
1:40:00 AM - Centurion-Dan2: probably easiest approach is to have a
config section for "gitlab project to group mappings" that define what
those mappings are. In the current releasebot config you'll see they
exist - "members_projectid: 108" in the jobs section from
example.config - 108 refers to the repo id in gitlab - which is probably
faster to look up.
1:40:33 AM - Centurion-Dan2: and more stable...
1:40:35 AM - parazyd: ack
</quote>

--
Daniel Reurich
Centurion Computer Technology (2005) Ltd.
021 797 722