- crux-devel - lists.crux.nu

Meeting notes 2008-07-11
by Johannes Winkelmann 11 Jul '08

11 Jul '08

Hi there, I'm sorry for the delay, I was somewhat busy the last two days :-). Anyway, here are my notes from the last IRC meeting: - The new start time seems to be good; it has the advantage that those in europe are typically less tired when Lucas joins in Various Pkgfile things: - we define that they must be 7-bit ASCII for now; this was the de-facto standard already; we can always move to UTF-8 later - we discussed the "maintainer" vs. "arch maintainer" confusion a user might face; we believe that the proper solution is to document this properly; the original maintainer should stay in the Pkgfile, since changes in the port per se (bug fixes, security issues etc.) should go to him (preferably both to him and the arch maintainer) see http://git.die.net.au/cgit/crux/ports/core-x86_64/tree/gcc/Pkgfile Tree management: - Lucas wrote some scripts to simplify the maintenance of arch trees: http://nipul.die.net.au/sync_tools/ Please check them out and comment if you have time - For now, we'll consider x86 as the master tree; once x86_64 becomes official (hopefully either with 2.5 or 2.6), we'll allow "master ports" in either arch Handling outdated ports: - We have a new bug status "Work in progress" - We want to encourage users to use flyspray (either directly or via a to be written web interface) to report outdated bugs - if a maintainer doesn't change the new report to "Work in progress": a) security updates, critical bugs and broken urls should be looked at after three days b) other reports should be looked at at the casual meetings; in general, we should wait for at least one week - review: - for md5sum identical source=() changes, no ACK is needed - for the rest, another maintainer has to ack the change in in FS (maybe we'll have to take that to the mailing list as well) To those devs that we're at the meeting: please comment whether this sounds reasonable to you! Bug tracking: - we need to write a proper document on reporting bugs for outdated ports, as we've typically recommended to use direct mail so far - Lucas has written a very cool script to interface Flyspray. There are a couple of uses for that besides what he already suggested: - writing a simpler web interface to report outdated bugs - automating the review cycle, think: $ git-diff .|review-commit - > submits a patch to flyspray, maybe adding crux-devel to the list of addresses that get notified Finally, current open task: - move "Main" pages to "Wiki"; I guess we could do that next tuesday - write user _and_ developer docs on handling outdated ports; I'd suggest we wait with both to see whether there's any feedback from the other devs on the process I think this is about it :-) Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

1 0

Casual meeting reminder #3
by Johannes Winkelmann 08 Jul '08

08 Jul '08

Hi there, As every week, today's our casual irc meeting. There's a couple of items on http://crux.nu/Wiki/MeetingAgenda which we could talk about. As there have been no comments on this following my last mail, I suggest we start only at 20 CEST, and - as always - stay there till late at night :-) Looking forward to seeing you in #crux-devel Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

2 1

git-to-rsync missing file issues.
by Danny Rawlins 08 Jul '08

08 Jul '08

Hi this really needs to be fixed... Updating collection contrib file has vanished: "/crux-2.4/contrib/wmcalclock/wmCalClock-increase-delay.patch" (in ports) rsync: opendir "/crux-2.4/contrib/wmctrl" (in ports) failed: No such file or directory (2) rsync: opendir "/crux-2.4/contrib/wmdiscotux" (in ports) failed: No such file or directory (2) rsync: opendir "/crux-2.4/contrib/wmint" (in ports) failed: No such file or directory (2) rsync: opendir "/crux-2.4/contrib/wmlaptop" (in ports) failed: No such file or directory (2) [...] Isn't their a better way to do git to rsync? Cheers, Danny Rawlins <Romster>

1 0

Handling outdated ports
by Johannes Winkelmann 06 Jul '08

06 Jul '08

Hi there, There's been a some discussion on IRC about this, but I think it makes sense to discuss this here, and hopefully at one of the IRC meetings to come. One gripe users have with CRUX are outdated ports. Here's an idea on how to improve the current situation. this is meant as a starting point for a discussion, please comment and suggest alternative ideas! Also, please note that I'm still assuming that we want to keep the 1:1 relationship maintainer : port; alternatively, we could move to a group maintenance model similar to what we do with core, where everyone can update all ports. Anyway, here's the idea: 1. write some better guidelines for users on how to submit bug reports, i.e. to set the severity high if the download is broken etc. We should encourage the users to submit updated ports to flyspray. 2. go through all the "outdated ports" requests at the casual IRC meetings. We should have a way for maintainers to day "I'm working on this", or "I won't have the time soon, please 'causual meeting guys' look at it". I'd suggest that for trivial updates, it's okay to have another maintainer's acknowledge to commit the port; however we shouldn't ack changes of ports we didn't test. For major changes, I'd always commit it back to Flyspray and ask the original maintainer to comment, and the submitter to test. 3. for ports with non-working downloads, there should probably be a separate policy; I'd say every maintainer should be allowed to commit a Pkgfile with an updated URL if .md5sum isn't touched. However, we have to find a way to avoid duplicate work (i.e. by adding a note on flyspray, stating "I'm looking into that"). If there's a version bump needed, I'd again like to see some acknowledge step of that change. Since it take up to a week to the next IRC meeting, it might make sense to post these to the mailing list. There's a number of open points: - review methods for these changes - how long should one wait before touching other people's ports - will we maintainer accept that others update our ports? - will the users register a flyspray account to report outdated versions? Alternatively, we could use a separate tracking system for outdated ports Looking forward to hearing your comments. Best wishes, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

1 0

prtverify daily results
by crux＠crux.nu 04 Jul '08

04 Jul '08

Differences since last check: (no differences) Full report: http://crux.nu/files/prtverify.log

1 0

post commit hook
by Jose V Beneyto 04 Jul '08

04 Jul '08

Hi, First of all sorry for the previous mail, which I was sent accidentally. :) Well, I opened a thread in the contrib mailing list with the same topic, and seems that contributors are interested, but logically they want to known more about the code of certain hook scripts. I browse the gitweb looking for this code, and I found an older one used for subversion hooks: http://crux.nu/gitweb/?p=misc/scripts.git;a=blob;f=svn-notify.sh Maybe possible to import these hook scripts (and other useful ones) inside the script.git repository. Best regards, Jose V Beneyto

2 2

Maintainer line replacement script / Port removal policy
by Johannes Winkelmann 03 Jul '08

03 Jul '08

Hi there, I've started a script to replace maintainer lines with "unmaintained". This is mainly meant to mark ports as unmaintained when a maintainer leaves, however we could also automate the port removal and use it for regular port removal as well, such that a developer never manually removes a port, but just marks it as unmaintained, and some script which runs once per day picks them up, sends out a reminder after ~20 days (optionally with a special warning to maintainers of dependent ports), and removes it after 30 days (number of days chosen randomly). This would give other maintainers and users some time to pick a port up. The questions remains who should do security updates to these packages in the days before it's unmaintained. The script is here: http://jw.smts.ch/files/crux/set_unmaint Currently, it does not replace the maintainer but just prints an updated version (add -i to sed line to change this), and it's meant to be run like this: $ set_unmaint ~/crux/ports/core prt-get httpup ... Opinions, patches? Cheers, Johannes -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch

3 2

post commit hook
by Jose V Beneyto 03 Jul '08

03 Jul '08

1 0

prtverify daily results
by crux＠crux.nu 03 Jul '08

03 Jul '08

Differences since last check: (no differences) Full report: http://crux.nu/files/prtverify.log

1 0

Potentially broken source downloads
by crux＠crux.nu 03 Jul '08

03 Jul '08

Port: /home/crux/git-to-rsync-working-copy/crux-2.4/opt/libpcap Url: http://www.tcpdump.org/release/libpcap-0.9.8.tar.gz Reason: curl: (7) couldn't connect to host State: New Port: /home/crux/git-to-rsync-working-copy/crux-2.4/opt/tcpdump Url: http://www.tcpdump.org/release/tcpdump-3.9.8.tar.gz Reason: curl: (7) couldn't connect to host State: New Full report: http://crux.nu/files/check_urls.html

1 0