Re: Debian Buster release to partially drop non-systemd support
On Mon, Oct 15, 2018 at 9:51 PM Enzo Nicosia wrote: > Please, just tell us who we should contact (current/last > maintainer?) to start working on that. That's easy [1]. Thanks. [1] https://qa.debian.org/developer.php?login=pkg-sysvinit-de...@lists.alioth.debian.org -- Alessio Treglia | www.alessiotreglia.com Debian Developer | ales...@debian.org Ubuntu Core Developer| quadris...@ubuntu.com 0416 0004 A827 6E40 BB98 90FB E8A4 8AE5 311D 765A
Re: Debian Buster release to partially drop non-systemd support
On Tue, Oct 16, 2018 at 09:16:37AM +0800, Paul Wise wrote: > On Tue, Oct 16, 2018 at 12:18 AM Adam Borowski wrote: > > > The main problem with sysvinit is the lack of a git repository. > > There is an upstream git repository with commits up to September 2018: > > http://savannah.nongnu.org/projects/sysvinit > http://git.savannah.nongnu.org/cgit/sysvinit.git > Indeed. Sorry for the short presentation: another Devuan developer here (and Debian user/admin/tinkerer since 1998). I guess the bottom line of the discussion is: Devuan will keep supporting sysvinit. Now, it would obviously be better to have this support in Debian, so that all the Debian derivatives will automatically benefit of it. This seems like "just the right time" to do that. Please, just tell us who we should contact (current/last maintainer?) to start working on that. Otherwise, Devuan will keep supporting sysvinit nevertheless. Best Regards Enzo Nicosia -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature
Re: Debian Buster release to partially drop non-systemd support
On Tue, Oct 16, 2018 at 12:18 AM Adam Borowski wrote: > The main problem with sysvinit is the lack of a git repository. There is an upstream git repository with commits up to September 2018: http://savannah.nongnu.org/projects/sysvinit http://git.savannah.nongnu.org/cgit/sysvinit.git -- bye, pabs https://wiki.debian.org/PaulWise
Bug#911116: ITP: python-anyqt -- Qt4/Qt5 compatibility layer
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-anyqt * URL : https://github.com/ales-erjavec/anyqt * License : GPL Programming Lang: Python Description : Qt4/Qt5 compatibility layer About to appear on salsa.debian.org/python-team/modules/anyqt.
Bug#911115: ITP: xfce4-screensaver -- screen saver and locker that is integrated with the xfce4 desktop
Package: wnpp Severity: wishlist Owner: Jonathan Carter * Package name: xfce4-screensaver Version : 0.1.0 Upstream Author : Sean M. Davis URL : https://git.xfce.org/apps/xfce4-screensaver/ * License : GPL-2 / LGPL-2.1 / LGPL-2 Programming Lang: C Description : screen saver and locker that is integrated with the xfce4 desktop Xfce Screensaver is a screen saver and locker that aims to have simple, sane, secure defaults and be well integrated with the Xfce desktop. It is a port of MATE Screensaver, itself a port of GNOME Screensaver. It has been tightly integrated with the Xfce desktop, utilizing Xfce libraries and the Xfconf configuration backend. Features: * Integration with the Xfce Desktop per-monitor wallpaper * Locking down of configuration settings via Xfconf * DBUS interface to limited screensaver interaction * Full translation support into many languages * Shared styles with LightDM GTK+ Greeter * Support for XScreensaver screensavers * User switching See also: Initial release announcement on: https://bluesabre.org/2018/10/15/xfce-screensaver-0-1-0-released/
Bug#911111: ITP: python-louvain -- community graph analysis implementing Louvain method
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-louvain * URL : https://github.com/taynaud/python-louvain * License : BSD Programming Lang: Python Description : community graph analysis implementing Louvain method A dependency for the Orange machine learning suite. It is meant to arrive on salsa.debian.org/python-team/modules/python-louvain any time soonish.
Bug#911106: ITP: orange3 -- machine learning suite for python
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: orange3 Version : 3.0.15 * URL : https://orange.biolab.si * License : GPL Programming Lang: C, C++, Python Description : machine learning suite for python About to appear on https://salsa.debian.org/python-team/modules/orange3
Bug#911105: ITP: python-serverfiles -- accesses files on a HTTP server and stores them locally for reuse
Package: wnpp Severity: wishlist Owner: Steffen Moeller * Package name: python-serverfiles Version : 0.2.1 * URL : https://github.com/biolab/serverfiles * License : GPL Programming Lang: Python Description : accesses files on a HTTP server and stores them locally for reuse A small library that is requested by the Orange machine learning suite. I am about to upload it to https://salsa.debian.org/python-team/modules/python-serverfiles The naming "serverfiles" is obviously rather unfortunate. Hoping the prefix to render it tolerable.
Re: Debian Buster release to partially drop non-systemd support
On Mon, Oct 15, 2018 at 06:02:37PM +0200, Adam Borowski wrote: > On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote: > > I’ve volunteered to help out earlier in the thread, within constraints > > (but rather that than to see things go and break). > > The main problem with sysvinit is the lack of a git repository. There's a > massive amount of opportunities for drive-by contributions, but no way to > collaborate doing so. Seriously that's the main problem in your opinion? :/ -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
Re: Debian Buster release to partially drop non-systemd support
Adam Borowski, le lun. 15 oct. 2018 18:02:37 +0200, a ecrit: > On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote: > > Matthew Vernon wrote: > > >interest/effort in getting sysvinit (and related bits) in a better state > > >for buster, do drop me a line. > > > > I’ve volunteered to help out earlier in the thread, within constraints > > (but rather that than to see things go and break). > > The main problem with sysvinit is the lack of a git repository. I guess we could just move on and create a collab-maint one? Samuel
Re: Debian Buster release to partially drop non-systemd support
On Mon, 15 Oct 2018, Petter Reinholdtsen wrote: > Note, I can with authority, as the person introducing dependency based > boot and shutdown ordering in Debian, report that insserv were not > introduced for parallell boot, nor for boot speed. It was introduced to > correct broken boot and shutdown ordering using a system wide reordering > of every scripts at once. This was needed as it proved impossible to > get every package maintainer involved in a boot sequence reordering to […] Ah, okay, thanks for the explanation. > By all means, feel free to try to reintroduce the static sequence number > ordering again, if you believe it is a sensible way forward. I With this extra information, I do not believe that any more. > Just wanted to clear any misunderstanding about the use of insserv being > related to speed and running scripts in parallell. It is not true. > Insserv provided correct ordering, and a byproduct was that correct > ordering made it possible to run scripts in parallell for higher speed > using startpar. OK. I was using file-rc at the time those changes were introduced, so they hit me only much later when file-rc was no longer viable at all somehow, which is why I lacked that background info. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-235 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
Re: Debian Buster release to partially drop non-systemd support
[Thorsten Glaser] > Hmm. This does not answer the question, while it does point out one > package. I’d rather sysvinit not depend on insserv, it used to work > fine without that kind of added complexity, and AIUI, it was only > used for parallel boots Note, I can with authority, as the person introducing dependency based boot and shutdown ordering in Debian, report that insserv were not introduced for parallell boot, nor for boot speed. It was introduced to correct broken boot and shutdown ordering using a system wide reordering of every scripts at once. This was needed as it proved impossible to get every package maintainer involved in a boot sequence reordering to lift together in a finite amount of time, where the last one in a sequence had to change its number, before the second to last changed its number, and so on and so forth. There were lots of incorrect sequence numbers in the boot and shutdown sequence before we introduced dependency based boot ordering, and this was solved when we introduced dependency based boot ordering. By all means, feel free to try to reintroduce the static sequence number ordering again, if you believe it is a sensible way forward. I recommend to use the dependency information provided in the packages to verify you get it right. The /usr/share/insserv/check-initd-order script can be used to compare the sequence numbers with the dependencies, to detect any errors. After we introduced dependency based ordering, the sequence number that used to be passed to update-rc.d was made obsolete, and it is not really used any more. This means the number, if it is provided, can no longer be trusted. The 'start/stop' arguments for update-rc.d is no longer supposed and have not been supported for several years. There is no going back to static sequence numbers without changing around 1000 packages to add these sequence numbers back. I wish you luck motivating the maintainers to reinsert them. Personally I was a very happy when I did not have to pick a number between 00 and 99, and instead could just state relationships with other init scripts. Just wanted to clear any misunderstanding about the use of insserv being related to speed and running scripts in parallell. It is not true. Insserv provided correct ordering, and a byproduct was that correct ordering made it possible to run scripts in parallell for higher speed using startpar. -- Happy hacking Petter Reinholdtsen
Re: Debian Buster release to partially drop non-systemd support
Martin Steigerwald - 15.10.18, 17:56: > Anyway, I will make Devuan people aware of this discussion. Let's see > whether someone likes to cooperate. As Evilham also pointed out, Devuan people are aware of this discussion already: [devuan-dev] sysvinit in debian is under threat of being dropped for buster... https://lists.dyne.org/lurker/thread/ 20181015.095534.cb35153b.en.html#20181015.095534.cb35153b And actually there is interest to cooperate. Now, if people step over their own shadows… magic could happen. Thanks, -- Martin
Re: Debian Buster release to partially drop non-systemd support
Svante Signell, le lun. 15 oct. 2018 17:49:23 +0200, a ecrit: > On Mon, 2018-10-15 at 17:06 +0200, Samuel Thibault wrote: > > It's a matter of people subscribing to the > > pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there, > > I > > don't see why anything heavier would be needed. > > I thought alioth was no more, but maybe the mailing list remains? See https://alioth-lists.debian.net/ https://wiki.debian.org/Alioth/MailingListContinuation and https://alioth-lists.debian.net/cgi-bin/mailman/listinfo Samuel
Re: Bug#911090: libapt-pkg5.0: incompatible with apt/stretch
On Mon, Oct 15, 2018 at 05:12:10PM +0200, Andreas Beckmann wrote: > Package: libapt-pkg5.0 > Version: 1.7.0 > Severity: serious > > Hi, > > I just did a partial upgrade on a stretch+buster+sid development > system resulting in apt-get erroring out with > > apt-get: relocation error: /usr/lib/x86_64-linux-gnu/libapt-private.so.0.0: > symbol _ZN3URIcvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev > version APTPKG_5.0 not defined in file libapt-pkg.so.5.0 with link time > reference > > Looks like some Breaks may be needed ... So, I think this affects more than just apt. gcc 7 broke the ABI by adding a new mangling URI::operator std::__cxx11::basic_string, std::allocator >() and only linking to that. It seems that some new gcc version then got rid of the old one URI::operator std::__cxx11::basic_string, std::allocator >[abi:cxx11]() and now it's crashing. And that's a problem for _every_ library with operator string(), not just apt. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: Debian Buster release to partially drop non-systemd support
On Mon, Oct 15, 2018 at 04:18:57PM +0200, Thorsten Glaser wrote: > Matthew Vernon wrote: > > >I'm aware of some work ongoing at the moment to try and improve matters > >(currently looking at elongind, for example). If anyone's got some > > What’s elongind? elogind? Never heard of it… elogind is an isolated part extracted from systemd-logind, maintained by Void people, and in use by several other distributions (Gentoo, Devuan, etc). It is a drop-in replacement for interfaces exposed by libpam-systemd. I'm using it for several months myself, and intended to package it in Debian, but had a lack of tuits to do so. I just started a new job and I think I'll have a small but non-zero amount of tuits in the evenings, but havent't finished moving and can't comfortably run anything that needs reasonable VMs (got nothing but a Pinebook with me), so I can't be of much help -- but if anyone wants to start the work on elogind, I'll try to do what I can. > >interest/effort in getting sysvinit (and related bits) in a better state > >for buster, do drop me a line. > > I’ve volunteered to help out earlier in the thread, within constraints > (but rather that than to see things go and break). The main problem with sysvinit is the lack of a git repository. There's a massive amount of opportunities for drive-by contributions, but no way to collaborate doing so. Then, there are nice-looking new upstream releases of sysvinit (three in this year, after several years of dormancy), but that'd require some real testing. Unlike elogind, it could perhaps reasonably be tested remotely... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Re: Debian Buster release to partially drop non-systemd support
Ansgar Burchardt - 15.10.18, 16:03: > On Mon, 2018-10-15 at 14:20 +0100, Jonathan Dowland wrote: > > On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote: > > > I believe Andreas Henriksson is right, the packages are going to > > > be > > > removed unless someone with time and interest show up to take care > > > of > > > them. A good start would be to split initscripts off from the > > > sysvinit binary packages, to let them live separate lives. It > > > will be sad, but the proper way for Debian to handle unmaintained > > > packages in a sad state. > > > > Is it worth interested parties reaching out to the Devuan project > > regarding person-power for sysvinit maintenance? > > Please no. I don't think it would help Debian to have toxic people > maintain packages. > > (As an example, Devuan's infobot has fun facts like this one: > "<+infobot> 'sth is poettering' means it acts invasive, possessive, > destructive, and generally in an egocentric exacerbating negative way. > ``this cancer is extremely poettering'' [...]") Calling people "toxic" IMHO is quite similar to what Devuan's infobot displays: Both are attacks on persons. And both are not helpful. Anyway, I will make Devuan people aware of this discussion. Let's see whether someone likes to cooperate. -- Martin
Re: Debian packaging, dependency management and the C++ standards meeting
On 2018-10-03 22:43, Jussi Pakkanen wrote: Well, there are about three meetings per year, and I doubt the next meeting will be some soft of "definitive" (or will it?) It is the last meeting where things can be added to C++20 so I would call that definitive. The tooling group that will try to tackle packaging & similar issues have just barely stared, I doubt something will be prepared for C++20 that would be of concern to this topic. Again, not sure if there's need to "panic", though of course your initiative is really important!
Re: Debian Buster release to partially drop non-systemd support
On Mon, 2018-10-15 at 17:06 +0200, Samuel Thibault wrote: > > It's a matter of people subscribing to the > pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there, > I > don't see why anything heavier would be needed. I thought alioth was no more, but maybe the mailing list remains?
Re: Debian Buster release to partially drop non-systemd support
Evilham, le lun. 15 oct. 2018 16:27:25 +0200, a ecrit: > Where to now? > At devuan-dev, Adam Sampson has suggested that the debian-bsd and > debian-hurd communities are also very interested in keeping non-systemd > things working, Yes, but they aren't populated so much either, with already a lot of things in their plate. > which is why I'd hope this won't end up in non-systemd > support being dropped, but that this thread becomes the distress call > that the topic needed. > > If I had to guess, this requires some organisation first, and since it > may require cross-communities organisation it may be somewhat tricky. It's a matter of people subscribing to the pkg-sysvinit-de...@lists.alioth.debian.org list and discussing there, I don't see why anything heavier would be needed. Samuel
Re: Debian Buster release to partially drop non-systemd support
Dear debian-devel, Am 15/10/2018 um 15:20 schrieb Jonathan Dowland: > [ re-adding TG who requested CCs in an earlier message, but has not > set Mail-Followup-To:. You've probably missed half the conversation, > Thorsten… ] > > On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote: >> I believe Andreas Henriksson is right, the packages are going to be >> removed unless someone with time and interest show up to take care of >> them. A good start would be to split initscripts off from the sysvinit >> binary packages, to let them live separate lives. It will be sad, but >> the proper way for Debian to handle unmaintained packages in a sad >> state. > > Is it worth interested parties reaching out to the Devuan project > regarding person-power for sysvinit maintenance? As a derivative > distribution, I imagine their lives would become much harder if we did > drop sysvinit; they would have to pay the cost of maintaining the > sysvinit package themselves (which is what I am proposing they do now) > *as well* as a rapidly growing delta of sysvinit-support/initscripts in > lots of other packages, as they steadily rotted in Debian. it's my first time writing to this ML, which calls for a quick hello/intro and the FYI that I intended to send: The quick hello/intro: I go on the internet by Evilham and have been using Debian for ages. When it was time for me to give back to the community, systemd and Devuan were both already a thing, and things ended up bringing me to help Devuan first. The FYI: Devuan is not blind to this topic or reticent to contributing in Debian, the discussion is indeed taking place over at devuan-dev and, without having discussed it thoroughly yet, many are of the opinion that it *is* in everyone's best interest to keep the packages in Debian, and in a good state. https://lists.dyne.org/lurker/message/20181015.100838.2018520a.en.html At least personally speaking, there is interest in helping Debian from Devuan, as most of us see that there is big benefit in both distros. However, as you are aware, maintaining a distro is a lot of work (BTW: thank you all for your contribution to Debian), there have been priorities other than supervising state of packages in Debian. I don't think many were aware of the state of things and that this was the path these (very critical) packages were following in Debian. Where to now? At devuan-dev, Adam Sampson has suggested that the debian-bsd and debian-hurd communities are also very interested in keeping non-systemd things working, which is why I'd hope this won't end up in non-systemd support being dropped, but that this thread becomes the distress call that the topic needed. If I had to guess, this requires some organisation first, and since it may require cross-communities organisation it may be somewhat tricky. From Devuan's side, there is a weekly meeting happening on (UTC) Wednesday evening, where this will surely be a big topic. Just letting you know, things are moving (albeit somewhat late and slowly). Best regards, -- Evilham signature.asc Description: OpenPGP digital signature
Re: Debian Buster release to partially drop non-systemd support
On Mon, 15 Oct 2018, Jonathan Dowland wrote: > [ re-adding TG who requested CCs in an earlier message, but has not > set Mail-Followup-To:. You've probably missed half the conversation, > Thorsten… ] Thanks… will follow up on those I read up on in the web interface (why is there no NNTP interface like in GMane, where I could retrieve individual messages by Message-ID to easier reply to?) below. I think we can drop d-backports now, though? > Is it worth interested parties reaching out to the Devuan project > regarding person-power for sysvinit maintenance? As a derivative I’m not sure, but I’d rather not, as a general case, unless there’s one or more of theirs who’s willing to cooperate and able to keep quality. Devuan is… questionable, when one’s used to all of Debian. > distribution, I imagine their lives would become much harder if we did > drop sysvinit; they would have to pay the cost of maintaining the Several people have said they believe that to be the end of Devuan, and I concur, from what I’ve read. > sysvinit package themselves (which is what I am proposing they do now) > *as well* as a rapidly growing delta of sysvinit-support/initscripts in Indeed. > lots of other packages, as they steadily rotted in Debian. This takes distributed manpower. Maintainers do not use all packages. Bugs are spotted by people actually using them (though, if they can be reproduced easily, can then be tackled by others). My uses are probably not very normal, though… Adam Borowski wrote: >On Mon, Oct 15, 2018 at 08:46:31AM +0200, Laurent Bigonville wrote: >> Thorsten Glaser wrote: >> > On Sun, 14 Oct 2018, Andreas Henriksson wrote: >> > >> > > Please note that sysvinit dependencies still have open RC bugs which >> > > noone is caring for. >> > >> > Oof. How do I find them out? The BTS shows no RC bugs, not even >> > ones tagged as affects src:sysvinit, and the QA page >> > https://packages.qa.debian.org/s/sysvinit.html also doesn’t. >> insserv Hmm. This does not answer the question, while it does point out one package. I’d rather sysvinit not depend on insserv, it used to work fine without that kind of added complexity, and AIUI, it was only used for parallel boots (I have /etc/init.d/.legacy-bootordering on all systems so I don’t use that anyway), and boot speed fetishists have largely migrated to systemd (which *does* boot up rather fast, even if its shutdown procedures are…). Does anyone know any offhand reason to not drop the insserv integration? >> has 3 RC bugs (6 if you count duplicates) last upload is from 2016 >> by Martin (who is/was systemd maintainer) and is RFA since around that time >> as well. > >These RC bugs are on an experimental abandoned version; the one meant for >buster is ok. Can you please RM the experimental version and close those bugs, if that version is abandoned, since you seem to know more about this? What does “meant for buster is ok” mean? It’s a bug that needs action in sid? Matthew Vernon wrote: >I'm aware of some work ongoing at the moment to try and improve matters >(currently looking at elongind, for example). If anyone's got some What’s elongind? elogind? Never heard of it… >interest/effort in getting sysvinit (and related bits) in a better state >for buster, do drop me a line. I’ve volunteered to help out earlier in the thread, within constraints (but rather that than to see things go and break). Thanks, //mirabilos -- Yes, I hate users and I want them to suffer. -- Marco d'Itri on gmane.linux.debian.devel.general
Re: Debian Buster release to partially drop non-systemd support
On Mon, 2018-10-15 at 14:20 +0100, Jonathan Dowland wrote: > On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote: > > I believe Andreas Henriksson is right, the packages are going to be > > removed unless someone with time and interest show up to take care of > > them. A good start would be to split initscripts off from the sysvinit > > binary packages, to let them live separate lives. It will be sad, but > > the proper way for Debian to handle unmaintained packages in a sad > > state. > > Is it worth interested parties reaching out to the Devuan project > regarding person-power for sysvinit maintenance? Please no. I don't think it would help Debian to have toxic people maintain packages. (As an example, Devuan's infobot has fun facts like this one: "<+infobot> 'sth is poettering' means it acts invasive, possessive, destructive, and generally in an egocentric exacerbating negative way. ``this cancer is extremely poettering'' [...]") Ansgar
Re: Debian Buster release to partially drop non-systemd support
On Mon, Oct 15, 2018 at 02:20:03PM +0100, Jonathan Dowland wrote: > Is it worth interested parties reaching out to the Devuan project > regarding person-power for sysvinit maintenance? It's hard to discuss this with a straight face, but in any case even they admit they don't have any person-power: http://maemo.cloud-7.de/irclogs/freenode/_devuan-dev/_devuan-dev.2018-09-05.log.html -- WBR, wRAR signature.asc Description: PGP signature
Re: Debian Buster release to partially drop non-systemd support
[ re-adding TG who requested CCs in an earlier message, but has not set Mail-Followup-To:. You've probably missed half the conversation, Thorsten… ] On Mon, Oct 15, 2018 at 06:56:50AM +0200, Petter Reinholdtsen wrote: I believe Andreas Henriksson is right, the packages are going to be removed unless someone with time and interest show up to take care of them. A good start would be to split initscripts off from the sysvinit binary packages, to let them live separate lives. It will be sad, but the proper way for Debian to handle unmaintained packages in a sad state. Is it worth interested parties reaching out to the Devuan project regarding person-power for sysvinit maintenance? As a derivative distribution, I imagine their lives would become much harder if we did drop sysvinit; they would have to pay the cost of maintaining the sysvinit package themselves (which is what I am proposing they do now) *as well* as a rapidly growing delta of sysvinit-support/initscripts in lots of other packages, as they steadily rotted in Debian. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net ⠈⠳⣄ Please do not CC me, I am subscribed to debian-devel.
Re: Debian Buster release to partially drop non-systemd support
Holger Levsen writes: > On Sat, Oct 13, 2018 at 06:01:43AM +0100, Ben Hutchings wrote: >> > Has policy changed regarding support for multiple inits, or is it just that >> > no one is maintaining the shim and sysvinit-core? >> >> The latter. systemd-shim has been orphaned for over 2 years, and has >> RC bugs. sysvinit currently has two maintainers, but they've only >> ever made one upload (over a year ago). > > It seems that these facts are either largely ignored or unknown and I > wonder if some noise should be made so that interested people can pick > up the work now and not only complain later. I'm aware of some work ongoing at the moment to try and improve matters (currently looking at elongind, for example). If anyone's got some interest/effort in getting sysvinit (and related bits) in a better state for buster, do drop me a line. Regards, Matthew -- "At least you know where you are with Microsoft." "True. I just wish I'd brought a paddle." http://www.debian.org
Bug#911076: ITP: libdeflate -- fast, whole-buffer DEFLATE-based compression and decompression
Package: wnpp Severity: wishlist Owner: Debian Med team * Package name: libdeflate Version : 1.0 Upstream Author : Eric Biggers * URL : https://github.com/ebiggers/libdeflate * License : MIT Programming Lang: C Description : fast, whole-buffer DEFLATE-based compression and decompression The supported formats are: . DEFLATE (raw) zlib (a.k.a. DEFLATE with a zlib wrapper) gzip (a.k.a. DEFLATE with a gzip wrapper) libdeflate is heavily optimized. It is significantly faster than the zlib library, both for compression and decompression, and especially on x86 processors. In addition, libdeflate provides optional high compression modes that provide a better compression ratio than the zlib's "level 9". libdeflate is a recommended dependency of htslib and will be team-maintained by Debian Med
Re: Debian Buster release to partially drop non-systemd support
On Mon, Oct 15, 2018 at 08:46:31AM +0200, Laurent Bigonville wrote: > Thorsten Glaser wrote: > > > On Sun, 14 Oct 2018, Andreas Henriksson wrote: > > > > > Please note that sysvinit dependencies still have open RC bugs which > > > noone is caring for. > > > > Oof. How do I find them out? The BTS shows no RC bugs, not even > > ones tagged as affects src:sysvinit, and the QA page > > https://packages.qa.debian.org/s/sysvinit.html also doesn’t. > insserv has 3 RC bugs (6 if you count duplicates) last upload is from 2016 > by Martin (who is/was systemd maintainer) and is RFA since around that time > as well. These RC bugs are on an experimental abandoned version; the one meant for buster is ok. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ 10 people enter a bar: 1 who understands binary, ⢿⡄⠘⠷⠚⠋⠀ 1 who doesn't, D who prefer to write it as hex, ⠈⠳⣄ and 1 who narrowly avoided an off-by-one error.
Re: Bug#910446: NMU diff (substantive patches in git-format-patch form)
Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in
git-format-patch form)"):
> It's not that much trouble for me but rather sad that people spent time
> on (in this case) just tedious work while they could fix other stuff
> in the same time since the maintainer is already on it.
Ah. Well, then, thanks for your consideration.
I hope you are able to use most of what I did. I expect if you rebase
my series onto your master with a conflict strategy of just taking
master's version, you'll have most of it done.
As an aside, I looked for a way to *extend* rather than *specify* the
flake8 ignore list. I found that it is possible to fish the existing
list out of the relevant python module, but I didn't know how to write
such a programmatic thing in setup.cfg.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Bug#910446: NMU diff (substantive patches in git-format-patch form)
Hi,
On Sun, Oct 14, 2018 at 10:55:10PM +0100, Ian Jackson wrote:
> Guido Günther writes ("Re: Bug#910446: NMU diff (substantive patches in
> git-format-patch form)"):
> > On Sun, Oct 14, 2018 at 03:36:49PM +0100, Ian Jackson wrote:
> > > Hi. I fixed this bug, and some other FTBFS, and am about to upload
> > > the result. I'm doing this myself, right away, because this is an RC
> > > bug which has triggered the autoremover to want to remove dgit.
> > >
> > > Following the recommendation in dev ref 5.11.1, I have not use
> > > DELAYED; and because I doubt that actually uploading it now will cause
> > > you any difficulty. I hope that's OK.
> > >
> > > The patches I made are attached. You can also find this as a git
> > > branch, here:
> ...>
> > That's actually not what I prefer since I
>
> Sorry about that. But,
>
> I did look in the bug [1] before starting work, this lunchtime UK
> time, and there was no response there.
>
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910446
>
> I have just checked the bug again, and your message to it crossed with
> my decision to go ahead with the upload. The timestamp on the
> relevant .changes file shows that I did my formal build-for-upload at
> 14:28 UTC. I and evidently spent a few minutes getting my NMU diff
> email into shape and I sent that email at 14:36 and did the actual
> dgit push at 14:37.
>
> Your message to the bug was at 14:31 UTC. I confess didn't check the
> bug again in the 9 minutes between `dgit sbuild' and `dgit push'.
>
> To be honest, if you had said any time in the past week, in the bug,
> that you were intending to fix it I would have been quite happy to
> leave the work to you. But there was nothing from you in the bug and
> the upstream git server (which I was able to see via http, even if the
> git interface was giving me trouble) showed no recent activiy.
To be honest I saw that bug but forgot about it until I saw the
autoremoval mail. I then notified the BTS so reverse dependencies don't
need to worry.
> > - there's plenty of time until the autoremoval hits us
>
> I'm generally quite busy and I had time and headspace to do this
> technical work now. I wasn't confident that that would occur again in
> the next few weeks.
>
> I'm sorry to be told that I have engaged in "sub par interaction". I
> was trying to help. Can you explain to me what concrete problem my
> action has caused you ?
It's not that much trouble for me but rather sad that people spent time
on (in this case) just tedious work while they could fix other stuff
in the same time since the maintainer is already on it.
> I appreciate that being the recipient, several times a year, of
> autoremoval notifications (not just from gbp) is a hazard of sitting
> on top of a large dependency stack. But it would be nice to be able
> to at least fix these things oneself without being criticised.
>
> It would be really helpful if people would respond to RC bugs *before*
> their entire reverse dependency stack has received an `autoremoval'
> email.
Yept, that's totally true but I think the reverse holds as well: if
things are flagged check with the maintainer(s) how this happened
(in this case it was just an oversight). They might either be working on
a fix or might be happy about an NMU.
> I guess I can be criticised for not emailing the bug before starting
> work. Looking at my irc transcript it looks like I started at 12:00
> UTC or so. Of course once one has started on something like this it
> is very discouraging to be told to stop and throw one's work away -
> and I guess your message to the bug was prompted by the autoremoval
> mail which had been sent ovrnight, so an additional mail from me would
> have waited anyway. So probably in this case if I had emailed the bug
> at 12:00ish UTC it would have made no difference.
That's why I at least check with maintainers before starting work on
things. Even then it doesn't always help to avoid duplicated work (since
some times there's more than two parties involved) but most of the time
it does.
I should have used better words in my previous mail. Sorry if this came
over rougher than it meat to be.
Cheers,
-- Guido
Re: Debian Buster release to partially drop non-systemd support
Thorsten Glaser wrote: On Sun, 14 Oct 2018, Andreas Henriksson wrote: > Please note that sysvinit dependencies still have open RC bugs which > noone is caring for. Oof. How do I find them out? The BTS shows no RC bugs, not even ones tagged as affects src:sysvinit, and the QA page https://packages.qa.debian.org/s/sysvinit.html also doesn’t. insserv has 3 RC bugs (6 if you count duplicates) last upload is from 2016 by Martin (who is/was systemd maintainer) and is RFA since around that time as well.
