Re: proposal: Hybrid network stack for Trixie
Le lundi, 23 septembre 2024, 13.04:41 h CEST Lukas Märdian a écrit : > On 22.09.24 12:22, Chris Hofstaedtler wrote: > > * Lukas Märdian [240920 13:13]: > >> I've repeated the reasons why I think a hybrid stack using Netplan is a > >> feasible solution many times in previous threads, therefore I'd like to > >> refer to a list of frequently asked questions, instead of spreading more > >> reasons across more replies: https://wiki.debian.org/Netplan/FAQ > >> > >> # Why > >> The ifupdown package is a Debian only solution that is becoming a > >> maintenance burden. We've had plenty of discussions over the years and > >> consensus is that we want to get rid of it. > >> Some variations of Debian have already moved forward with choosing a > >> different stack, such as desktop/laptop installations (using > >> NetworkManager) and cloud images (using Netplan+systemd-networkd). Also, > >> ifupdown-ng exists as a modern re-implementation of the classic tooling, > >> that strives to become drop-in [compatible]. > > > > Thanks for providing the FAQ and this "Why" section, but it seems to > > leave open why we would want or need netplan as the default. As the > > FAQ shows, netplan is available as an optional package in many > > distros. The same is already true in Debian thanks to you. > > As described in the "Proposal" section and first answer of the FAQ, it's all > about consistency. > > There seems to be a tendency for moving towards a hybrid stack, using > sd-networkd and NetworkManager in different contexts/use-cases. But having > fragmented ways of doing network configuration provides bad UX, as it can > confuse users, who first need to understand what sortf of Debian they are > using, before looking for solutions. > > Netplan solves this and allows for providing common solution that work > across the system. > > The Netplan tooling around that, like "netplan status" or "netplan try" > to query/debug the network configuration or apply, but roll-back > configuration, in case it did not work out as expected, are only added > benefits. It sounds like having netplan be *available for install* solves that nicely if one cares about consistency across their fleet of Debian hosts; just make sure (via d-i preseed, cloud-init, etc) to install netplan when bootstrapping machines/VM/hosts, and you're good to go, right? I don't see any additional benefit by enforcing it on all installs by default, as has been eloquently explained already. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Firmwares (was Re: Bits from the DPL)
Le lundi, 1 avril 2024, 19.41:45 h CEST Andrey Rakhmatullin a écrit : > Why is updating the firmware packages not trivial? Is it because of > licensing issues? I always thought it's just copying a bunch of files from > the linux-firmware repo (but I also often wondered why is the package > often not up to date). My recollection, after getting some MRs merged in the firmware-nonfree package last cycle (oh, a year gone already), is that it's a mix of: * the maintainers in position to review, then merge the proposed changes are few, and have plenty on their hands; * firmware packages seem to have lower priority during the development cycle, in favour of larger updated shortly-before (or during) the freeze; * upstream and Debian (maintainers) are not in complete agreement on what can, or should be shipped in packages; from README.source: > Also, some of its contents are not clearly redistributable, and some are > obsolete for Debian's purposes. So almost every file addition needs a careful `git log` review to check for origin, updates, reasoning, version strings, etc. Unless there's tooling I have not found; it's tedious, error-prone (and not very interesting) work (although quite arguably necessary). * packaging is very smart, but peculiar (or at least, quite different to what I had been used to before I touched it). Despite good documentation, it's quite a steep intro for newcomers. All-in-all, I think it's an all-too-classical case of "we don't have enough humanpower for the job we set out to do". Add a team of motivated individuals to gain the confidence of the existing "already-plenty-on-their-plates maintainers", to then maintain the package on their own. Oh, wait… -- OdyX signature.asc Description: This is a digitally signed message part.
Re: xz backdoor
Le dimanche, 31 mars 2024, 21.23:10 h CEST Arto Jantunen a écrit : > Didier 'OdyX' Raboud writes: > > Le dimanche, 31 mars 2024, 14.37:08 h CEST Pierre-Elliott Bécue a écrit : > >> I would object against creating a PGP key on the HSM itself. Not having > >> the proper control on the key is room for disaster as soon as you lose > >> it or it dies. > > > > For subkeys, isn't that a benefit rather than a disadvantage? > > > > You lose the key, or it gets destroyed / unusable; good, you get a new > > subkey instead of reusing the existing one on a different HSM. > > For the authentication and signing subkeys this is indeed true. For the > encryption subkey significantly less so (as things encrypted against > that key then become impossible to decrypt). I was missing that perspective; thanks! -- OdyX
Re: xz backdoor
Le dimanche, 31 mars 2024, 14.37:08 h CEST Pierre-Elliott Bécue a écrit : > Hello, > > Iustin Pop wrote on 31/03/2024 at 13:13:27+0200: > > Option 2: Generate keys on the yubikey and have them never leave the > > secure enclave. That means having 2 yubikeys per developer, and ensuring > > you keep track of _two_ keys, but it does ensure there's a physical > > binding to the key. > > > > Are there other options? And which option is proposed? > > I would object against creating a PGP key on the HSM itself. Not having > the proper control on the key is room for disaster as soon as you lose > it or it dies. For subkeys, isn't that a benefit rather than a disadvantage? You lose the key, or it gets destroyed / unusable; good, you get a new subkey instead of reusing the existing one on a different HSM. -- OdyX
Bug#1060006: ITP: brpc -- Apache's brpc - Industrial-grade RPC framework
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: brpc Version : 1.7.0 Upstream Contact: d...@brpc.apache.org * URL : https://brpc.apache.org/ * License : Apache-2.0 Programming Lang: C++ Description : Industrial-grade RPC Apache bRPC is often used in high performance systems such as Search, Storage, Machine learning, Advertisement, Recommendation, etc (the short and long descriptions' are really bad; suggestions welcome! In the context of packaging typesense / https://github.com/typesense/typesense/, it looks like brpc is needed too, so here I come. The currently quite messy packaging is over at https://salsa.debian.org/typesense-team/brpc and I really welcome any help to make that a clean addition to Debian!
Bug#1058699: ITP: blupimania -- Blupimania - A mind boggling (brain twisting) game of logic
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud X-Debbugs-Cc: debian-devel@lists.debian.org Package name: blupimania Version : 1.6.2 Upstream Contact: Mathieu Schroeter URL : https://blupi.org/mania/ License : GPLv3 Programming Lang: C Description : Blupimania - A mind boggling (brain twisting) game of logic Blupi comes out of a hole holding on to a balloon. Unfortunately he let's it blow away. Blupi is lost, he turns to the left or the right and does various unpredictable things of his own. The object of the game is to help him find another balloon, so that he can move on to the next riddle. This 1994-1995 game, first released for Smaky's, was ported to DOS in 1996, then the source code was lost. It got found again on a CD-R in 2021, then ported to SDL, which now makes it available natively on GNU/Linux. That piece of history can now be made avaiable to Debian!
Bug#1037176: ITP: typesense -- Fast, typo-tolerant search engine
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud X-Debbugs-Cc: debian-devel@lists.debian.org Package name: typesense Version : 0.24.1 Upstream Contact: TypeSense team URL : https://typesense.org License : GPL-3 Programming Lang: C++ Typo-tolerant search engine optimized for instant search-as-you-type experiences and developer productivity. Push data to it and then allow users to search through this data via a search UI in a site or app. I plan to package this under https://salsa.debian.org/debian/typesense. If there's a matching packaging team, more than happy to move there!
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
Le mardi, 16 mai 2023, 17.06:38 h CEST Russ Allbery a écrit : > I don't know if anyone has written an ABI compliance test for binaries. > That sounds like something that would be in scope for the Linux Test > Project, though, and it's possible their existing tests do some of this. This has existed in a (now distant) past as the "Linux Distribution Checker", in the context of the Linux Standard Base, that Debian and Ubuntu stopped caring about in late 2015. I'm not aware of more recent efforts in that direction; but it's an understatement to say the landscape has changed quite a bit since: containers, sandbox environments (and others) have forever changed the way we think about distributing binary executable. LSB had that ambition, and failed. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Introducing Declarative Debian
Le dimanche, 2 avril 2023, 15.41:12 h CEST Micha Lenk a écrit : > I'm not quite sure I got the concept. Is this just (also) another way of > expressing things we currently express with virtual packages? > > For example: > * httpserver-is-apache > * imapserver-is-dovecot You need to think larger! * christoph-got-you-to-think-about-this-seriously * april-s-fool-is-less-and-less-fun-in-an-era-of-fakenews * I-genuinely-giggled-though -- OdyX signature.asc Description: This is a digitally signed message part.
Re: transitional packages? (was: Firmware GR result - what happens next?)
3 octobre 2022 11:11 "Santiago Ruano Rincón" a écrit: > El 02/10/22 a las 20:42, Michael Biebl escribió: >> Am 02.10.22 um 20:14 schrieb Luca Boccassi: >> On Sun, 2022-10-02 at 10:52 -0700, Russ Allbery wrote: >> In Bullseye we changed the name/syntax for the security repository, and >> for that a mention in the release notes was enough, no? Isn't this a >> very similar situation? >> >> The main difference is, that the renaming caused an error message by apt, so >> you knew something needed to be fixed. >> >> For this particular change, there will be no error. So yes, I have the same >> fear as Russ that this particular change might go unnoticed. > > Couldn't we handle this via transitional firware* non-free packages, > that depend on bookworm non-free-firmware packages? That would only work if we renamed all concerned binary packages, or if apt grew a "section/packagename" syntax (which would be bizarre).
Re: Automatic trimming of changelogs in binary packages
19 septembre 2022 23:19 "Bill Allombert" a écrit: > Le Tue, Sep 06, 2022 at 07:13:30AM +0200, Gioele Barabucci a écrit : > >> On 18/08/22 21:18, Gioele Barabucci wrote: >> Does anybody have objective objections against activating automatic >> changelog trimming in binary packages? >> >> Hi, >> >> a couple of weeks since the initial email (thanks everybody for the input), >> my reading is that there is now consensus in going ahead with the proposed >> automatic trimming of changelogs. > > Count me out. changelog embbed Debian history. The very first entries > are often very important. They can be important _in the source package_. I have yet to see binary packages for which having access to early debian/changelog entries matters at all. ( debian/NEWS is another story of course, and these are not affected).
Re: Idea: autopkgtest on big-endian for 'Architecture: all' packages to catch endian bugs
Le mardi, 2 août 2022, 18.00:40 h CEST Edward Betts a écrit : > I recently packaged a Python module called sqlite-fts4 written by Simon > Willison. The package is pure Python, so is 'Architecture: all', but it > fails on big-endian architectures. The test suite catches this failure. > > The bug was spotted by OpenSUSE because they tried to run the test suite on > s390x. They filed a bug which upstream has fixed. > > https://github.com/simonw/sqlite-fts4/issues/6 > > Simon has written some posts about this problem. > > https://til.simonwillison.net/python/struct-endianness > https://til.simonwillison.net/docker/emulate-s390x-with-qemu > > It would be nice if the Debian infrastructure could catch this class of bug. > > Building the sqlite-fts4 Debian package runs the test suite, and I've > configured it to run the tests via autopkgtest. If these tests are run at build-time, errors halt the build and that provides the largest coverage. It's also usually easier to iterate and test than autopkgtest. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Bug#1014908: ITP: gender-guesser -- Guess the gender from first name
Le samedi, 16 juillet 2022, 19.36:17 h CEST Adrian Bunk a écrit : > What tools did you use to generate this data? > > The irony is that your "fight" requires exactly the tools you want to > condemn, and data Debian should better not collect at all. It does not. The whole argument is "gender-guessing if prone to errors, if you want to know what gender a person identify themselves, ask them". signature.asc Description: This is a digitally signed message part.
Re: I'm orphan my packages and leave the project as maintainer
Le vendredi, 26 mars 2021, 16.01:14 h CET Timothy M Butterworth a écrit : > The FSF with out RMS would be like the Linux Foundations with out > Linus. I'm quite sure the Linux Foundation will work just fine without Linus Torvalds, and will one day have to. My hope is that the same goes for the FSF; either it can prove being a useful voice leading the Free Software movement without RMS, or it insists it can't merely exist without having RMS in the Board. In the latter, we should all diverge away (more than was already done) from the FSF and lead the Free Software movement without the FSF. -- OdyX
Bug#980200: ITP: pappl -- C-based framework/library for developing CUPS Printer Applications
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud X-Debbugs-Cc: debian-devel@lists.debian.org, debian-print...@lists.debian.org Package name: pappl Version : 1.0.1 Upstream Author : Michael R Sweet URL : hhttps://www.msweet.org/pappl License : Apache License Version 2.0 with an (optional) exception to allow linking against GPL2/LGPL2 software Programming Lang: C Description : C-based framework/library for developing CUPS Printer Applications PAPPL is a simple C-based framework/library for developing CUPS Printer Applications, which are the recommended replacement for printer drivers. It was specifically developed to support LPrint and a future Gutenprint Printer Application but is sufficiently general purpose to support any kind of printer or driver that can be used on desktops, servers, and in embedded environments. I'll be maintaining this under the Debian Printing Team umbrella. Current packaging is hosted at https://salsa.debian.org/printing-team/pappl/.
Re: On doing 3000 no-source-change source-only uploads in January 2021
Le jeudi, 31 décembre 2020, 13.50:30 h CET Holger Levsen a écrit : > hi, > > as described in Message-ID: <20201231124509.gb3...@layer-acht.org> > or > http://layer-acht.org/thinking/blog/20201231-no-source-change-source-upload > s/ I plan to do 3000 NMUs soon. Fantastic job, thanks a lot for doing it! -- OdyX signature.asc Description: This is a digitally signed message part.
Re: DAM Key and identity requirements
Le dimanche, 13 septembre 2020, 09.11:04 h CEST Enrico Zini (DAM) a écrit : > Hello everyone, > > world-wide changes due to COVID-19 prompted us to conduct a long-overdue > review of the GPG key requirements for people applying for Debian > Maintainer (DM) and Debian Developer (DD) membership status. Oah. Thanks for this much welcome change, along with this excellent explanation. \o/ -- OdyX signature.asc Description: This is a digitally signed message part.
Re: RFC: Final update of DEP-14 on naming of git packaging branches
Le samedi, 29 août 2020, 01.01:09 h CEST Raphael Hertzog a écrit : > Hello, > > following the recent discussions of June and of the last days, I'm > proposing the changes below to DEP-14. Basically it replaces debian/master > with debian/latest for all the reasons already discussed earlier. And > it says that debian/unstable is preferred over debian/sid. > > And it also marks the proposal as ACCEPTED given that it has gained > traction over the years and that we didn't feel the need to make > significant change to it. Thanks for this proposal. I can't help but feel overwhelmed by the upcoming change to main branches of "so many" repos to debian/latest, but I feel it's definitely worth it (and scriptable). Seconded. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Tagging in Salsa -> upload: status?
Le jeudi, 13 août 2020, 11.19:59 h CEST Christian Kastner a écrit : > Unless I'm grievously misremembering something, there was a discussion a > while ago about automatically generating a source package and uploading > it whenever a Debian release is (signed-)tagged in Salsa. > > If I did remember correctly: may I kindly inquire what the status on > that is? I think I was the one with that idea [0], and I threw around some code last winter, but I never really finished this; as I've stuck to using `dgit push- source` for now. The idea would be to have: a `dgit tag-source-for-upload`, which produces a tag with all the metadata needed by a knowledgeable tag consumer to reproduce a signed .dsc + a signed _source.changes. That knowledgeable tag consumer would run at the end of a salsa pipeline. But I am not at all perl fluent, and have stalled with a partial python-based proof-of-concept, sadly. -- OdyX [0] https://lists.debian.org/debian-devel/2019/10/msg00301.html
Re: 'No such file or directory' while building coreutils from source package
Le jeudi, 7 mai 2020, 21.59:56 h CEST Manuel Wagesreither a écrit : > Do I need to extract it? > https://www.debian.org/doc/manuals/maint-guide/build.en.html doesn't > mention anything like that. Also, it doesn't seem to change the outcome. The first part of the guide (Chapter 2. First steps) [0] explains a little better what different parts constitute a source package, and therefore a source directory. Another good resource is the Debian handbook; specifically it's chapter 5.3 "Structure of a Source Package" [1]. In short, you need to: - extract the upstream tarball - extract the Debian changes on top of the directory containing your upstream extracted source code (usually a .debian.tar.*). - apply the patches All this is doable by hand, but really, you should rely on Debian's tools: $ apt-get source coreutils … will download and extract the coreutils source package from the Debian repositories. And by extract, I mean that it will do nothing more than the 3 steps above. Regards, OdyX [0] https://www.debian.org/doc/manuals/maint-guide/first.en.html [1] https://www.debian.org/doc//manuals/debian-handbook/sect.source-package-structure.en.html signature.asc Description: This is a digitally signed message part.
Re: trends.debian.net updated
Le mardi, 14 avril 2020, 13.12:55 h CEST Wouter Verhelst a écrit : > > One could expect from maintainers that they check their packages for > > compliance regularly and that they document that. > > Perhaps, but it is *also* documented that an upload just to bump the > Standards-Version is severely frowned upon. If that is still true, we should change this: a "I checked, it still complies with the most recent Policy, had to do no other changes" upload should be considered just fine, as the highest cost was the maintainer's time, and it might well be saving a lot of other people's. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Le lundi, 30 mars 2020, 21.08:18 h CEST Russ Allbery a écrit : > Didier 'OdyX' Raboud writes: > > Yet one is a string, and the other one an image. If you edit the string > > before turning it into a QR code, you get a valid QR code (maybe > > encoding a broken, or misleading URL, but still valid QR code). If you > > edit the QR code directly, you _can_ get a valid QR code, but chances > > are that you are not getting what you want. We have a direct "string > > representation" → "binary artifact", quite like in compilation. > > Putting aside the issue of the embedded graphic, which is a separate > matter, this doesn't sound right to me. Surely the QR code is an > encoding of a string? If one can do a round-trip conversion into your > preferred format without loss, I'm having a hard time seeing how this is > not a preferred form of modification. It's a modifiable binary artifact, in that you can read it's content, and create a different version of itself from the same content, or an alteration of it. With (but even without) the image in their center, it takes quite some trial-and-error to get the _exact_same_ image. It's easy to get a functionally identical QR code; it's quite harder to get the exact same. It _can_ be a bi- directional lossless conversion; I'd argue that without upstream's build- parameters, it's not. Anyway, I am not really arguing that QR codes (even these) are not redistributable in Debian source or binary packages (I'm leaving this to the FTP masters). I am saying that with the tooling we have (qrencode is one of plenty), it is really easy to produce functionally-equivalent QR codes. And that I think that the cost of doing so (at build time) is really small with regards to the benefit we get in term of transparency (the URL from the QR code becomes searchable, the build process is clarified). Regards, OdyX signature.asc Description: This is a digitally signed message part.
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Le lundi, 30 mars 2020, 10.14:13 h CEST Raphael Hertzog a écrit : > On Mon, 30 Mar 2020, Didier 'OdyX' Raboud wrote: > > > How should package maintainers deal with QR codes ethically? > > > > Asking package maintainers to rebuild functionally-equivalent QR-codes > > during the build-process seems entirely reasonable to me. > > To me it looks like wasting my time. There are many pictures that are > not the preferred form of modification but we accept them as is when > there's no proof/evidence that some other source exist. > > And here there's no other source really, the source is the string > associated to the QR code. QR code and the string are two different > representation of the same underlying data. Yet one is a string, and the other one an image. If you edit the string before turning it into a QR code, you get a valid QR code (maybe encoding a broken, or misleading URL, but still valid QR code). If you edit the QR code directly, you _can_ get a valid QR code, but chances are that you are not getting what you want. We have a direct "string representation" → "binary artifact", quite like in compilation. That said. We don't _have_ to ship these in source or binary packages, and therefore getaway without re-building these. But if we are to ship them, building them at build-time from their source strings is a really modest price to pay; for the sake of "actually building binary artifacts from source". -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Overinterpretation of DFSG? QR code for receiving donation is non-free???
Hello Mo, Le lundi, 30 mars 2020, 07.54:23 h CEST Mo Zhou a écrit : > I think sometimes the DFSG has been over-interpreted. Here I'm talking about > the recent REJECTion of src:smartdns from our NEW queue, where QR code > pictures used for donation have been deemed DFSG non-free [1]. I'm not > satisfied with the explanation, and I think there is over-interpretation on > DFSG. > > I poked ftp-master about this problem: > >spwhitton: I'm quite confused about REJECTION of src:smartdns. Why > can the QR code pictures for software author to receive donations be > DFSG-nonfree? > > And I got the following explanations: > >lumin: IIRC that was not the only reason for REJECT. > Otherwise I would have PRODded. > >lumin: An image of a QR code wouldn't be the preferred form of > modification. They are usually generated from something. If the file it > was generated from isn't present and the tool to generate it isn't in > Debian, then it can't be shipped. Requiring preferred form of modification > is one area where Debian is often stricter than licenses due to DFSG. > > The pictures we're talking about are (…) > > Why are they non-free? They are non-free, because they cannot be rebuilt from their preferred form of modification. > Treating this files as non-free could lead to further problems. > > 1. If I stripped the donation codes from the source. > I believe such behaviour is **unethical**. It's allowed by GPL-3 licensing. Actually, we (Debian) require that this must be possible. But you can't be coerced into doing this (you can always opt to "not package for Debian"). > 2. If I decoded the QR code and replaced them with the underlying URLs. > There is no Chinese user who pay through URL instead of QR code. > > 3. If I stripped the donation codes but re-generated them during the > package build process. > "Oh damn, this QR code does not look like the original one and the > hashsum mismatches. Has the Debian developer forged the QR code to be > evil?" I mean there will be doubt if the distributed QR code is not > byte-to-byte equivalent to the one distributed by upstream author. We're _building_ source code towards binary artifacts all the time. Doing this (and being trusted to be doing it correctly) is one of the defining characteristics of being a "shipping-binaries" Linux distribution. The whole point of this exercise is that our build processes are auditable, and that eventual forgeries can be found, reported, and fixed. If you don't consider the result of your builds trustworthy, "we have a problem". > Is a QR code for donation really DFSG non-free? QR codes are artifacts in binary form, not in their preferred form of modification. By function, QR codes are vehicles of binary information, and can be easily reconstructed from said binary information without loss (of information). Frankly, simple lines like the following in debian/rules would do it: echo "http://donation-url.example.com/?vendor-id"; | qrencode -o qr.png > Is DFSG over-interpreted in this case? IANAFM, but I don't think so. > How should package maintainers deal with QR codes ethically? Asking package maintainers to rebuild functionally-equivalent QR-codes during the build-process seems entirely reasonable to me. -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#955126: ITP: libopenaptx -- Audio Processing Technology codec (aptX)
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud Package name: libopenaptx Version : 0.1.0 Upstream-Contact: Pali Rohár URL : https://github.com/pali/libopenaptx/ License : LGPL2.1+ Programming Lang: C Description : Audio Processing Technology codec (aptX) Support for aptX and aptX HD codec variants; they both operate on raw 24-bit signed stereo audio sample; at 6:1 fixed compress ratio for aptX; at 4:1 fixed compress ratio for aptX HD. This is mainly needed for Bluetooth headsets with aptX/aptX-HD support, and will be maintained in the debian/ salsa group.
Re: USB
Hello Kya, Le vendredi, 13 mars 2020, 15.00:10 h CET Kya Bailey a écrit : > Me and my family were cleaning a couch that we were getting rid of and I > found a USB so I checked it out and it had stuff with your logo in the > pictures and it has stuff like Copyright, changelog.Debain.gz, makefile and > others like that please contact me if you are interested in ownership the > USB The Debian project does not own nor sell USB sticks; so as far as the Debian project is concerned, this USB stick was likely lost (or hidden) by someone who had used it to install Debian. If at all possible, it is that someone that you might want to return the USB key to. That said, if you are interested in what the Debian project is, and does, I would encourage you to look at our homepage: https://debian.org/ and to try booting a Debian system by re-flashing a fresh Debian live image on this (or a different USB key): https://www.debian.org/CD/live/ For any questions regarding Debian, you could head to http://forums.debian.net/ the debian-u...@lists.debian.org mailing list. Thank you for enquiring about this USB key and Debian! -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Debian With Alternate Init Systems
Le samedi, 8 février 2020, 16.15:13 h CET Svante Signell a écrit : > On Sat, 2020-02-08 at 14:51 +0100, Samuel Thibault wrote: > > Sam Hartman, le sam. 08 févr. 2020 08:27:24 -0500, a ecrit: > > > It sounds like you were suggesting that people should leave as a way of > > > pressuring or punishing the project. > > Why not, if the project is heading in the wrong way according to their > conviction. Some people have already left Debian, as a result of the GR. The Debian project members voted for a project's position statement of the day, that resulted in option B winning [0]. You might dislike this result, but option B is the Debian project's current opinion on Init systems, multiple init systems, and the use of systemd facilities. Now with this Debian's position statement in mind, you can choose to help making (this) Debian better, or you can choose to put your energy in other projects that pursue goals more aligned with yours. That's not pushing you out, that's Debian saying "this is where we're going; are you going along?". > > I'd say do not try to fix it, we've been trying unsuccessfully within the > > Hurd community. > > Samuel, so you want me to stop working on Hurd? Nice, the first thing I'll > do is to shut down the Debian/GNU Hurd buildd mahler. Threats and emotional blackmail are not welcome in Debian. Please stop. (If you don't feel like maintaining an piece of infrastructure for the Debian project, by all means organize its replacement to free it from your hands. It's clearly your right. But don't use work you do for the project as argumentative lever; that's really not acceptable.) OdyX [0] https://www.debian.org/vote/2019/vote_002#textb signature.asc Description: This is a digitally signed message part.
Re: Heads up: persistent journal has been enabled in systemd
Le mercredi, 5 février 2020, 21.44:43 h CET Dmitry Smirnov a écrit : > On Wednesday, 5 February 2020 11:01:08 AM AEDT Scott Kitterman wrote: > > We just had a GR where the project voted it was just fine to systemd all > > the things, so this sort of thing is to be expected. > > Are you suggesting that voters fully understood the implications? Let me suggest (out of reading what they wrote in other parts of the thread), that I read Scott's message as a mix of despair and sarcasm. > Is this OK now to replace everything with systemd counterparts? > > I certainly voted with considerations for _init_ system. The vote was named "init systems and systemd". > If I recall correctly, no GR option suggested to "use as much systemd > components as possible" or I think the outcome of GR could have been > different... This was option "Choice 1: F: Focus on systemd". The option that won, "Choice 2: B: Systemd but we support exploring alternatives" [0] said: > Packages may use any systemd facility at the package maintainer's > discretion, provided that this is consistent with other Policy requirements > and the normal expectation that packages shouldn't depend on experimental or > unsupported (in Debian) features of other packages. Of course, it's ironic to read that under this project's opinion; "src:systemd may use any systemd facility at systemd maintainer's discretion". But, irony aside, we _did_ decide that we were to allow systemd facilities' usage, and moving ahead with journal's persistent storage seems to me very much inline with the project's latest GR-backed opinion. I'm not saying the project decided "journald should replace rsyslog" though. I'm saying that activating the persistent storage in journald feels very much inline with the project's expressed opinion. Also, it is orthogonal to whether we should be demoting rsyslog, or to what would happen to it upon upgrade. OdyX [0] https://www.debian.org/vote/2019/vote_002#textb
Re: Heads up: persistent journal has been enabled in systemd
Le mercredi, 5 février 2020, 07.01:44 h CET Scott Kitterman a écrit : > Not particularly useful IMO. In /var/log/mail.log I can see log entries > from all the programs configured to log to the mail facility. Unless I'm mistaken, exim4 logs nothing to /var/log/mail.log by default, only to /var/log/exim4/{mainlog,paniclog} -- OdyX
Re: Heads up: persistent journal has been enabled in systemd
Le samedi, 1 février 2020, 14.36:20 h CET Steve McIntyre a écrit : > Michael Biebl wrote: > >with today's upload of systemd 244.1-2 I finally enabled persistent > >journal by default [1]. It has been a long requested feature. > > > >The package will create a directory /var/log/journal on upgrades and new > >installs, which enables persistent journal in so called auto mode. > > Fine for new installations, but please *don't* do this for > upgrades. Those people with existing logging setups will be surprised > by this. I disagree. Please _do_ this for upgrades (it's great functionality!), but please do make sure that it is documented in NEWS.Debian (and release notes) so that it gets mentioned to host admins upon upgrade. -- OdyX signature.asc Description: This is a digitally signed message part.
Bug#950260: ITP: lprint -- lprint - A Label Printer Application
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud Package name: lprint Version : 1.0~b2 Upstream Author : Michael R Sweet URL : https://www.msweet.org/lprint/ License : Apache-2.0-with-GPL-LGPL-Exception Programming Lang: C Description : lprint - A Label Printer Application LPrint implements printing for a variety of common label and receipt printers connected via network or USB. Features include: . * A single executable handles spooling, status, and server functionality * Multiple printer support * Each printer implements an IPP Everywhere™ print service and is compatible with the driverless printing support in iOS, macOS, and Linux clients * Each printer can support options such as label modes, tear-off offsets, media tracking, media top offset, print darkness, resolution, roll selection, and speed * Each printer can print “raw”, Apple/PWG Raster, and/or PNG files * Each printer automatically recovers from out-of-media, power loss, and disconnected/bad cable issues This will be maintained by the Debian Printing Team.
Re: migration from cron.daily to systemd timers
Le mercredi, 8 janvier 2020, 16.33:28 h CET Daniel Leidert a écrit : > Am Mittwoch, den 08.01.2020, 15:36 +0100 schrieb Philipp Kern: > > I think there needs to be a sensible choice for *periodic jobs* that we > > should document as the default unless there is a reason to use something > > else. It does not need to be cron, though. > > Then go the appropriate way. Get a resolution if the Debian project is ok > with the new default (…) We _literally_ just passed a resolution [0] saying: > Packages may use any systemd facility at the package maintainer's > discretion, provided that this is consistent with other Policy requirements > (…) Policy says conffile changes must not be overriden; not that their meaning or semantics can never change. > If there is such a resolution: Change the default for new > installations and leave existing installations a choice. Philip's proposal at <87eewah0ws@hands.com> ( modify the shipped /etc/ default/spamassassin so that hosts with changes get a prompt; and others just start using the systemd timers) seems like a very nice strategy that seem to cover your needs. Cheers, OdyX [0] https://www.debian.org/vote/2019/vote_002#textb
Building Debian source packages reproducibly (was: Re: [RFC] Proposal for new source format)
Le mercredi, 23 octobre 2019, 15.49:11 h CET Theodore Y. Ts'o a écrit : > On Wed, Oct 23, 2019 at 11:18:24AM +1000, Russell Stuart wrote: > > On Tue, 2019-10-22 at 16:52 -0700, Russ Allbery wrote: > > > That seems excessively pessimistic. What about Git makes you think > > > it's impossible to create a reproducible source package? > > > > Has it been done? Given this point has been raised several times > > before if it hasn't been done by now I think it's reasonable to assume > > it's difficult, and thinking that it's so is not excessively > > pessimistic. > > Generating a reproducible source package given a particuar git commit > is trivial. All you have to do is use "git archive". For example: When talking about upstream projects, sure. But generating Debian source packages (.dsc and friends) from a `debian/master` (+ `pristine-tar`) reproducibly is not really, right? As far as I understand, `gbp buildpackage -S` is the closest we have, but so far, I fail to get it to give me the bit-by-bit identical unsigned .dsc that I'd like to get. What am I missing? (A little digresssion…) Where I'm coming from is that we were discussing the tag2upload problem at miniDebConf Vaumarcus. The heart of the problem is that FTP-Master are (currently) not going to accept .dscs built reproducibly by a (even trusted) service. tag2upload is built on the idea that a signed git tag is the only needed thing (`git tag -s`) to trigger an upload, and that is not going to fly currently. The solution that seemed obvious during the discussion [0] is to instead rely on a local tool to produce a git tag with significantly more metadata (such as .dsc signature, _source.changes signature); and reconstruct the a signed set of .dsc and _source.changes automatically (as last pipeline step in Gitlab CI), which are then acceptable by the archive. In other words, its "tag2upload", but with a reproducible way to: - build a source package on developer machine; - sign it locally; - create and push a special git tag Then, in a different environment (such as a GitLab CI pipeline step), given a special git tag and a repository; - build the exact unsigned same source package - unpack the special git tag; - apply the signatures to get the exact same signed source packages; - dput to the archive. The hard part is not the packing and unpacking of the special tag; that's mostly just strings massaging. But building the exact same source package in different environments is harder than I expected. Some caveats: - Q: if you built and signed the source package locally, why not uploading? A: Because you might want to only upload _after_ automated tests, and in an unsupervised manner. - Q: If one can fit pgp signatures in a git tag; why not inlining the complete .dsc and _source.changes? A: Indeed. You still need the debian.tar though. - Q: What about Dgit: in the .dsc, or buildinfo files? A: Currently optional; could just be left out for a prototype. Of course, all of this can only work if we can have, or make the ".git to .dsc" conversion reproducible; hence my query. All-in-all; would this be a welcome mechanism? OdyX [0] It probably was already considered. signature.asc Description: This is a digitally signed message part.
Re: Bug#888743: Debian vs Linux namespaces, NMU lsb-base
Le dimanche, 24 mars 2019, 09.42:12 h CET Geert Stappers a écrit : > What would be the harm to the Buster release > if lsb-base got NMU > with > https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=888743;filename=ini > t-functions.diff;msg=37 ? I have now uploaded src:lsb to experimental with Harald's patch. I'm not comfortable yet to target buster, I must say, nor do I really have time to test this extensively. Le dimanche, 24 mars 2019, 10.16:25 h CET Vincent Bernat a écrit : > Wouldn't it break chrooted processes? But mostly, as the whole pattern > is broken, it seems to be a low-effort solution. Vincent: what scenario did you have in mind? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: usrmerge -- plan B?
Le jeudi, 22 novembre 2018, 14.56:10 h CET Ian Jackson a écrit : > There is tradeoff here between risk of breakage, and reduction of > future work (as most clearly explained by Russ). The argument that is > being made is that the risk is low because of a lack of reports of > breakage. > > Others have observed that systems most likely to experience trouble > will not have been upgraded. For example, chiark was first installed > with Debian 0.93R5 in 1993. Obviously I haven't usrmerged it. No-one > sensible in my position would do so. Of course you do have backups. For the sake of the argument, would you consider trying an install of usrmerge on a restored backup VM somewhere? Maybe I'm overlooking something, but it seems that installing usrmerge on a production system is going to be a _much_ less demanding task proceeding with a stable upgrade. Cheers, OdyX
Re: usrmerge -- plan B?
Le jeudi, 22 novembre 2018, 00.17:54 h CET Michael Stone a écrit : > Then this needs to be a very explicit (and much better advertised) > decision, and it needs a much, much better implementation. You keep referring to usrmerge as buggy: > The current usrmerge package has no test mode, will bail with a partially- > converted system if it runs into problems, and has no way to revert the > process. Sorry to be blunt about this, but have you reported these? Sniping at (any) package without making the problems you see visible to others (through bugs) is not really helpful. > Pulling in usrmerge during an upgrade isn't going to cut it--we'd need some > kind of pre-upgrade check that tells people what they need to fix before we > break it. Designing this in a hurry less than two months before we start > freezing seems incredibly ambitious. usrmerge is in the archive for 3+ years now. What seems to be needed now is for a lot of us to actually _try_ it, find and report bugs, and get this through. Don't forget that a specificity of our bug report system is that the only measure of "it worked without issues" that we have is popcon; we only get a measure of how much things fail, not how good they work: https://qa.debian.org/popcon.php?package=usrmerge (Funnily enough, it seems to have had a recent spike…) Cheers, OdyX
Re: What can Debian do to provide complex applications to its users?
Le mardi, 27 février 2018, 14.13:41 h CET Didier 'OdyX' Raboud a écrit : > tl;dr: a new package format is needed, with a new non-suite-specific > repository is needed to bring the Debian added-value to these ecosystems. FTR, my current line of thought and understanding is that guix or nix do pretty much what is needed here, and it would be silly to start something from scratch. I plan to spend some brain time playing with guix and report back; I'm aware of: * https://bugs.debian.org/850644 for guix * https://bugs.debian.org/877019 for nix * Diane Trout's efforts 2 years ago on https://github.com/detrout/debian-guix Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: What can Debian do to provide complex applications to its users?
Le mardi, 27 février 2018, 15.14:02 h CET Simon McVittie a écrit : > Here is a different straw man, which I think might be similarly effective > and a lot less work: > > On Tue, 27 Feb 2018 at 14:13:41 +0100, Didier 'OdyX' Raboud wrote: > > As Debian, we > > are insisting that our releases ideally only contain a single version of a > > software, that we insist is made available at system-level. > > ... > > > In other words, vendorization is the tool that allows developers to get > > rid of distribution constraints and get on with their development through > > installing the dependencies from their ecosystem as they see fit > > (non-root), in the (eventually precise) version they need. > > I can't help wondering whether vendorizing dependencies (embedded code > copies) would be a better route for ecosystems like npm that we might > categorise as "aggressively modular" - package the app, but not the > dependencies, and treat the vendorized/embedded dependencies as part > of the app. Not embedding or duplicating libraries is already an ideal > that we have to compromise on for pragmatic reasons - browsers use > system libraries in testing/unstable but gradually make increasing use > of embedded code copies in stable[1], drifting further away from the > "no embedded code copies" ideal as time goes on and the latest browser > version becomes increasingly unbuildable against the increasingly old > libraries in stable. It's also how many Rust dependencies are already > managed, as far as I'm aware. Sure. That would just be a different use of these .vdebs where these would be embedded/repacked in the end application packages rather than installed globally and used from their installation paths. The added value that Debian can provide are source traceability, and trust mechanisms for package updates (although my proposal would most certainly weaken that) The issue I have with npm/pypi/you-name-it ecosystems is that I have to rely on _binary_ distribution made by non-Debian actors (with their own standards), to get dependencies for my applications. (I'm not saying their standards are necessarily bad; just that they often are not Debian's.) So I was talking about Debian providing a new source-to-binary_artifact pipeline, which I think is an area where there's something to be done, by Debian. Your proposal about embedding vendorized dependencies within applications (through embedded code copies or through Flatpak) is good, but I think the two proposals are orthogonal. The advantage of having Debian-provided version-specific dependencies is the centralization of the DFSG-freeness checking, of the copyright assignment, etc. (and of the security patching, but that's harder). I envision a hypothetical situation where instead of having embedded code copies of, say, jquery in various software, we had a centralized jquery source repository to which any arbitrary version (even patched) could be requested from. Need jQuery Core 2.2.3 ? We have it for your package, so please either: * depend on jquery_core_2.2.3.vdeb and add a symlink to /opt/vdebs/jquery-core/2.2.3; * build-depend on jquery-core_2.2.3.vdeb and add Built-Using: jquery-core_2.2.3 Need jQuery Core 3.3.1 with your specific patches? Add your patches to a branch, and get your jquery-core_3.3.1+g1231234.vdeb. That'd be a neat way to entirely eliminate code copies, and win metadata (which is currently fuzzy, at best) about these. > I'm just not sure that taking the rules we follow for C/C++ shared > libraries and applying them to every other language's ecosystem is either > feasible or desirable - nodejs libraries are not the same as C libraries, > and their tradeoffs are not the same tradeoffs. Yes. signature.asc Description: This is a digitally signed message part.
Re: What can Debian do to provide complex applications to its users?
Le mercredi, 28 février 2018, 06.06:54 h CET Sean Whitton a écrit : > > Furthermore, abandon the patch queue approach to Debian package > > management. We will not be able to maintain a big delta to any of > > these packages anyway. > > No, but we might often have reason to maintain a small delta. We patch > upstream source for all sorts of reasons; it is hard to believe it > wouldn't come up. It would not be reasonable to ship binary artifacts out of unpatcheable source, so I read Ian's point as getting rid of quilt in favour of git commits. signature.asc Description: This is a digitally signed message part.
Re: What can Debian do to provide complex applications to its users?
Le mardi, 27 février 2018, 14.48:48 h CET Ian Jackson a écrit : > I have some specific comments: > > Imagine > > * a new .vdeb format variant that: > > ** enables for multiple versions to be installed in parallel, where files > >are unpacked in a version-specific paths > > Instead, establish a formal convention about embedding the (stable > part of) the version number in the package name. This is important > so that it is possible to replace a specific "version" of one of these > packages with a modified package which is the "same version". Good point: not all versions are desirable; "majors" can be installed in parallel, "minors" are updates to the formers. But, assuming a new binary format, it feels really weak to abuse of the package name to embed a version. (The filename is a different question). What about (in control.tar's control): Package: simplejson Version-Unique: 3.13 Version: 3.13.2-1 > > ** forbids any kind of maintainer scripts > > ** is not bound to a specific suite > > ** is restricted to be arch:all (~ shipping interpreter scripts) > > These can be verified either the archive server as part of package > acceptance, or by apt as an annotation in the sources.list. Again, that's the main advantage I see from a new .*deb format: if these restrictions are part of the format, they can be checked and enforced at all steps in the process: dpkg-buildpackage would error out if there's a postinst, lintian would add an error, the server would block it and dpkg would not unpack the postinst, just because 'debian-binary' is 2.0-vdeb. > > ** (ideally) can be user-installed > > This one would require some thought. Do the target ecosystems support > transplantation of installed directory trees, without modification ? > > Perhaps the experience of other projects doing "prefixed" uses of dpkg > might be relevant. Eg > https://wiki.termux.com/wiki/FAQ#Is_Termux_a_complete_Linux_Environment.3F > (But the prefix there is baked into the .deb.) > > How is this going to work for build-dependencies ? If one says > "build-depends: npm-vdeb-foo", will the build system know to look in > $HOME as well as /usr ? user-installation embeds two different problems: prefixed unpack and non-root unpack. Given this is something orthogonal to the vdebs proposal (+ a hard problem), it's probably easier (for a start) to just leave that requirement off. > > * a repository of these .vdeb > > ** whose DFSG-freeness is checked > > ** which version set is known, and tracked > > ** that can provide new versions "on-demand" > > It is important to appreciate what we are *discarding* as too hard. Yes. > > How does that sound? > > Your proposal depends on continuous and almost-automatic > incorporation of upstream code. Our current source package workflows > are not suited to this. Yes. With Debian approval / whitelisting at various points in the lifetime of a "package: initial submission (as our NEW) and ideally at later points / versions. > OTOH we do not want to abandon the Debian source package format > completely because we have lots and lots of tools which understand it > well. Although I share the sentiment, I see value in finding a suitable model for the problem at hand, rather than massage our existing tools to fix the problem, "just because" they are our existing tools. I think we agree on that. > I would like to suggest a radical approach to the source code > management for your system: abandon source *packages* in favour of git > trees. Furthermore, abandon the patch queue approach to Debian > package management. We will not be able to maintain a big delta to > any of these packages anyway. > > So instead, we should have a Debian branch of each upstream git tree, > which we should "git merge". We will have to have a tool, for each > ecosystem, that converts the metadata provided in the upstream package > into the Debian format in debian/. The "update to new upstream" > process would be: >git fetch upstream >git merge upstream/master >npm-to-debian-autoconvert-update >git commit -s -a -m npm-to-debian-autoconvert-update debian > > Building should be done with "git clone" followed by > "dpkg-buildpackage -b" (or some suitable wrapper). That's pretty much what I had in mind, yes. I'm not even sure there's much need for a complete traditional debian/ directory: iff the .vdeb ecosystem does much less than normal .debs, we could aim for a single declarative .vspec (yes, I know what you're thinking) file for instance. Given we're tackling wide consistent (hmm) ecosystems, a set of fine tools and very minimal declarative packaging per-item could do it. Thanks for your inputs; I should probably find some time to put a refined version of these thoughts in a wiki page somewhere. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED
Le jeudi, 1 mars 2018, 07.29:15 h CET Pirate Praveen a écrit : > 2. CTTE should be able to overrule a delegate when there is a conflict > just like conflict between two debian developers. I don't think that's a power the Technical Committee (as a body, or as the current collection of its members) wants. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: What can Debian do to provide complex applications to its users?
Le jeudi, 1 mars 2018, 06.29:37 h CET Paul Wise a écrit : > On Tue, Feb 27, 2018 at 9:13 PM, Didier 'OdyX' Raboud wrote: > > Now, as a strawman proposition, here's what I fiddled with in my mind for > > some days now: > This reminds me a bit of Nix or Gentoo Prefix. Yes, only for the upper layers' only, on top of your good-old Debian, and "by Debian"™. Maybe what we need is a packaged nix and a standardized nix repository. > > ** is restricted to be arch:all (~ shipping interpreter scripts) > > Hmm, so this isn't going to cover all npm/pypi packages. It's not a roadmap, just a braindump :-) The packages that need compilation could still be provided as classical .debs for example. signature.asc Description: This is a digitally signed message part.
Re: What can Debian do to provide complex applications to its users?
Le mercredi, 28 février 2018, 06.04:27 h CET Sean Whitton a écrit : > On Tue, Feb 27 2018, Didier 'OdyX' Raboud wrote: > > ** is restricted to be arch:all (~ shipping interpreter scripts) > > There are compiled binary ecosystems that would benefit from your > proposal, such as Haskell, so could you say more about why you want this > restriction? Mostly out of wanting to (eventually) start small. It just reduces the problem surface. Arch:all packages can virtually be built anywhere, on any architecture, so vdebs wouldn't (really) need a buildd network; or at least not a multiple-architectures' buildd network. At first glance, it would also seem to vastly facilitate reproducibility, and reduces potential for executables' injection. In pretty much the same vein as dh-virtualenv, a possibility would be to do install-time build, through triggers for example. signature.asc Description: This is a digitally signed message part.
Re: What can Debian do to provide complex applications to its users?
Le mercredi, 28 février 2018, 04.57:50 h CET Russell Stuart a écrit : > On Tue, 2018-02-27 at 14:13 +0100, Didier 'OdyX' Raboud wrote: > > > - we could ship those applications not as .deb but as container > > > > > > and let them have their own lifecycle > > > > tl;dr: a new package format is needed, with a new non-suite-specific > > repository is needed to bring the Debian added-value to these > > ecosystems. > > To me 'container' is the right solution. For me, this is orthogonal. How your binaries or artifacts are orchestrated and isolated from eachothers doesn't have much to do with where they come from and how they're built. I'm not looking forward to having to maintain hierarchies of containers in which software is pulled from various different sources which don't have a shared agreement on what constitutes Free Software, sane security guidelines, etc. Ewww, wait… The hard problem is how to keep fostering and providing the four software freedoms, not (only) how to ship software. > (a grandiose and far fetched proposal) I don't disagree that smart containerization would make a better Debian. But not if we loose track of what binary gets installed from which source. Reproducibility and traceability are really important, and we should not throw them away for sake of more convenient software deployment. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: What can Debian do to provide complex applications to its users?
Le vendredi, 16 février 2018, 16.11:29 h CET Raphael Hertzog a écrit : > I don't have any definite answers although there are ideas to explore: > > - we could relax our requirements and have a way to document the > limitations of those packages (wrt our usual policies) > > - we could ship those applications not as .deb but as container > and let them have their own lifecycle tl;dr: a new package format is needed, with a new non-suite-specific repository is needed to bring the Debian added-value to these ecosystems. My current understanding of the problem is that there are two problems entangled with eachothers, for which Debian is currently not providing solutions * version spread * layer-specific expectations # Version spread Certain software will need to be available in multiple versions to satisfy reverse dependencies constraints, be it for convenience reasons ("the only version of that library my application has been tested with"), willingness to use the shiniest and latest, or any other reason. We have that problem already with jQuery and others, but it seems to be mostly contained thanks to reasonable back- and forward- compatibility. As Debian, we are insisting that our releases ideally only contain a single version of a software, that we insist is made available at system-level. The reasons for that are multiple, but the main one is the facilitated tracking and fixing of security issues, that we then only have to fix once, thereby protecting all its reverse dependencies. As has been mentioned with the example of Django, some software change too rapidly and too much for that single-version constraint to hold [0], and providing only one version is bound to not satisfy most reverse dependencies' needs; in other words, it's not going to be used. Another aspect of the version spread is that it limits the set of software we check DFSG-freeness of. There's an initial "seal-of-approval" from the FTP- Masters when going through NEW, but then it is currently left to the maintainer and the community to do this ongoing check. The cristallization towards the stable release will also encourage checking for eventual violations in only one version per software. # Layer-specific expectations Debian has long insisted that all software shipped in 'main' is constrained by the same standards (DFSG, Debian Policy, minimal code duplication, buildability, portability, maintainability over the course of a stable release cycle, etc), and gets the same support "in return" (security support, common bugtracker, etc). This is a very good model for "lower layers"; the plumbing (outside of new hardware support): I don't really care what version of CUPS I get, as long as I can print; I don't really care what minor version of Apache I get as long as it works, etc etc. On the other hand, when developing a application, with a rapidly-moving ecosystem, developer will insist on having the latest version of plenty of my direct dependencies, because working on whatever was released in Debian stable will just be a hassle more than a help. Also, the friction for them to fix a bug they have experienced in one of these dependencies is much lower than getting it fixed in Debian stable: given a responsive maintainer, one can get a new release with a pull request merged in a matter of days; and if that doesn't work, the tools allow to get a precise git hash for a given project. They can fix the bug, use the fixed version, and go on with my development. The point I'm trying to make, which I hope is obvious, is that the expectations upon software in different layers are vastly different: I want rock-solid kernel, libc and language interpreter, I want reasonably recent intermediate layers, but I want bleeding edge direct dependencies. Of course, fast-moving layers will not provide the same warranties as slow-moving layers. In a Debian-idealistic world, we could hold all layers up to the same standards, stabilize them up to a point where they can become part of stable, and all application developers would use Debian's set of libraries, from stable. Point is, that's not what is expected from Debian either: a Python application will only use Debian's python interpreter and virtualenv, all the rest will be taken from somewhere else than Debian, because it's way closer to how it'll be developped, and in many cases (just one missing library in stable), the only reasonable way to deploy said application. Then, instead of having only Debian as 'security' counterpart (getting the host to a secure state through a `apt upgrade`), the application developer now has to (do they?) care about the closer layer's security hirself. # Now, onto a solution In other words, vendorization is the tool that allows developers to get rid of distribution constraints and get on with their development through installing the dependencies from their ecosystem as they see fit (non-root), in the (eventually prec
Re: Extended Long Term Support for Wheezy
Le jeudi, 22 février 2018, 19.44:06 h CET Roberto C. Sánchez a écrit : > If we are going to start applying this sort of logic to naming, then > there are plenty of other places (e.g., where actual vulgarities are > used in package names, where abreviations and/or acronyms create words > that are or can be perceived as offensive, etc.). It's more prominent in suite names than in package descriptions though, as it will go in documentation, in apt sources' snippets, etc. Anyway, not a battle I'll fight; I fully trust the proponents to have heard that argument and make a sane suite name choice :-) Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Extended Long Term Support for Wheezy
Le mardi, 20 février 2018, 16.07:03 h CET Raphael Hertzog a écrit : > ("super long-term maintenance", SLTS in their jargon) A small point, but I haven't seen anyone mention it yet: I would not use the 'slts' acronym, basically anywhere, as it is very close to the 'sluts' smear word. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
CUPS GPL → Apache license change, how to proceed?
tl,dr; CUPS has moved from "GPL-2.0 with AOSDL exception" to "Apache-2.0"; how should the license incompatibilities be enforced? As you might have heard [lwn][cups-apache], Apple has changed the CUPS license away from a "GPL-2/LGPL-2 with exceptions" to plain Apache-2.0, effective in the 2.3 branch [23branch] and available from 2.3~b1 on [23b1]. Despite bold attempts from Fedora and Debian community members to try clarifying what issues this change causes and the incompatibilities it creates, Apple has, so far, unsurprisingly not changed CUPS' license. The principal issue, as I understand it, is that the Apache-2.0 license is incompatible with GPL-2 [apache-gpl2], although compatible with GPL-3 (therefore compatible with GPL-2+, and with LGPL through LGPL→GPL-3). See the lengthy explanation by Tom Callaway on Fedora's legal list [fedora-tom]. Further, it is my (current) understanding that having Apache-2.0 software (for instance, CUPS) in a dynamically-linked construct together with GPL-2-only software makes the result undistributable. This seems to be a situation which Debian needs to protect its users from. One way out, as outlined by Mike Sweet [system-library] as upstream author, is for Debian to consider that libcups/libcupsimage qualify as system-supplied libraries for the purposes of GPLv2. Having these two libraries in LSB could support that argument, but, using that argument, Debian could have gone away for the OpenSSL case long ago, and didn't. I made it clear to upstream [odyx- statement] that this was most certainly not going to happen. Some questions at this point (Some for FTP Masters, CC'ed): - Does Debian hold the view that Apache-2.0 and GPL-2.0-only dynamic linking is unacceptable for Debian main? In both directions? - Can CUPS link against GPL-2-only code? - Can GPL-2-only code link against CUPS? - Whose reponsibility is it to check for these incompatibilities, and make sure they are not shipped in Debian? Now, onto the ways forward. From a quick glance, the libraries CUPS links against don't seem to be an issue [CUPS-links-to], so let's focus on the libraries linked against CUPS' libraries (libcups2, libcupsmime1, libcupsppdc1, libcupsimage2, libcupscgi1). Using `build-rdeps`, it appears there are 5345 packages that (also indirectly) build-depend on these packages (attached). I am not going to review all these by hand. So, new questions: - What tools should I be using to identify which of these will be undistributable constructs? Aka: how, given a list of source packages, can I determine which are GPL-2-only in the codepaths that link against CUPS? - What fields could I / should I use in src:cups to enforce these? I was initially thinking of setting versionless Breaks: in each src:cups' library against the identified GPL-2-only culprits, then mass-filing bugs against these, promising to add version constraints when/if the licensing issue gets lifted. Does that sound like a good way forward? Many thanks in advance for your insights! Cheers, OdyX ( A build-ready package is available from CUPS' Vcs-Git, in branch debian/experimental [cups-deb], just `dch -v2.3~b3-1local0` before building ) [lwn] https://lwn.net/Articles/738531/ [cups-apache] https://lists.cups.org/pipermail/cups-devel/2017-November/ 017085.html [23branch] https://github.com/apple/cups/tree/master [23b1] https://github.com/apple/cups/releases/tag/v2.3b1 [apache-gpl2] https://www.apache.org/licenses/GPL-compatibility.html [fedora-tom] https://lists.fedoraproject.org/archives/list/ le...@lists.fedoraproject.org/message/NEQDL6V4RBRQTPI3YYBSZH5CTZG257F2/ [system-library] https://lists.cups.org/pipermail/cups-devel/2017-November/ 017095.html [odyx-statement] https://lists.cups.org/pipermail/cups-devel/2017-December/ 017097.html [cups-deb] https://salsa.debian.org/printing-team/cups/tree/debian/ experimental [CUPS-links-to] CUPS dynamically links against (excluding 'system libraries' such as libc, libgcc, libstdc++) - cups → libusb-1.0-0 (LGPL-2.1) - libcups2 → libavahi-client3 & libavahi-common3 (GPL-2+) - libcups2 → libc6 (GPL-2+) - libcups2 → libgnutls30 (LGPL-2.1+) - libcups2 → libgssapi-krb5-2 (MIT) - libcups2 → zlib1g (Zlib)0ad 2048-qt 389-admin-console 389-console 389-ds-console 3depict 3dldf 4pane 4ti2 a2ps aac-tactics abego-treelayout abgate abinit abiword ableton-link abntex aboot abx accerciser access-modifier-checker accessodf ace acedb ace-link ace-popup-menu acetoneiso ace-window acl2 aclock.app actiona activemq activemq-activeio activemq-protobuf actor-framework adacontrol ada-reference-manual adasockets addresses-for-gnustep adql adun.app advi adwaita-icon-theme adwaita-qt aegisub aeskulap aespipe aether aether-ant-tasks aewm afew affiche afterburner.fx afterstep agda agenda.app aggressive-indent-mode aghermann aiksaurus airlift-airline airlift-slice airport-utils aiscm aisleriot akonadi akonadi-cale
Re: Debian Stretch new user report (vs Linux Mint)
Le lundi, 4 décembre 2017, 23.18:21 h CET Philipp Kern a écrit : > On 04.12.2017 19:03, Holger Levsen wrote: > > On Mon, Dec 04, 2017 at 05:36:30PM +, Ian Jackson wrote: > >> Lars Wirzenius writes: > >>> Myself, I would prefer us to keep both the free-software-only ISO and > >>> the non-free ISO with firmware and other things needed to get typical > >>> modern hardware running, and improve the discoverability of the > >>> latter. I think we can do that without having to have a GR to change > >>> the Social Contract or the DFSG. > >> > >> Yes. > > > > yes, I also agree this would work and be better than the status-quo. > > however I'm inclined to believe doing this and adding a fourth repo, > > non-free-firmware (additionally to main, contrib and non-free) would > > be even better and also not need a GR. > > I like that this *finally* gets some traction. I have floated a GR > before but people seem to be reluctant to have yet another vote. It's a healthy discussion to be had, but we really should stop being scared by GRs. We had 3 in 2016 without much problems afterall. Instead of assuming a consensus from a debian-devel discussion, I certainly see value in both the wordsmithing happening during the discussion, and in the relative weighing of various slightly nuanced versions that comes as output from the vote. There's also value for the Debian project to be explicit when and if diverging from a longstanding tradition. We're discussing various different options here, and they don't all have the same symbolic weight: * making the current "embeds distributable non-free firmware" ISO image more visible; * splitting non-free in subsets; * adding a non-free-firmware area; * making the above ISO image the default image; * etc. To be honest, I don't think we are currently at a point in the discussion where we all feel the same consensus given the above (non-finite) set of options. Having an explicit vote will help better understanding where we stand as a project; also how we prioritise these. tl:dr; don't be afraid of a GR, just do it calmly :-) Cheers, OdyX
Re: Auto-update for sid? Auto-backport?
Le jeudi, 16 novembre 2017, 09.03:47 h CET Alexander Wirt a écrit : > On Wed, 15 Nov 2017, Didier 'OdyX' Raboud wrote: > > Le mercredi, 15 novembre 2017, 16.43:17 h CET Steffen Möller a écrit : > > > I would really like to see updates performed in some automated fashion. > > > > Debian updates are in fact different steps: > > * inclusion of upstream changes; > > * packaging updates; > > * .changes signing with a key in the Debian keyring; > > * dput of the .changes and associated files. > > Testing the package. Maybe the most important point. From my experience as > backports ftpmaster I could say that I am not very thrilled to see such > automatic upload repos. Oh, absolutely. But testing can have multiple forms, and we could imagine requiring autopkgtest before migrating stuff from this automatic suite to user-facing suites. Something along the lines of what Ubuntu AFAIK does with their pre-development release suite; a no-delay britney that checks suite coherency (migrations) and autopkgtests. OdyX
Re: Auto-update for sid? Auto-backport?
Le mercredi, 15 novembre 2017, 16.43:17 h CET Steffen Möller a écrit : > I would really like to see updates performed in some automated fashion. Debian updates are in fact different steps: * inclusion of upstream changes; * packaging updates; * .changes signing with a key in the Debian keyring; * dput of the .changes and associated files. The two first ones can (and often should) be automated, but a human check should happen at either of the two latter ones, most probably the signing one, as that where the uploading DD certifies the upload. People in various areas of Debian (as well as outside) have automated one or multiple of these steps, but with uploads outside of Debian suites: automated build from git heads, automated uploads to reprepro repositories, etc. But I'm not aware of unsupervised uploads to Debian. (At this point of the discussion, it seems to me that an unsupervised upload to Debian unstable is not a problem _per se_; a broken one would certainly be though.) > Maybe into a different section of Debian like sid-auto? The problem with > that obviously is the missing scrutiny by the human maintainer, so it > cannot go straight into sid. Or can it? An interesting infrastructure could provide a suite to which (unsigned ?) source packages could be sent for build. The output would be a build log and a _source.changes. As maintainer you'd be left with checking the build and `debsign -r` the .changes file that could then be auto-dput to Debian. Now that we have source only uploads, none of that would need to be on Debian infrastructure; the build would be there merely for guaranteeing that your package actually builds. > Maybe with an auto-created bug report against the package so it does not > auto-migrate into testing? I would not (ab)use bugs for something that should also be automated. Iff we're going to have automated uploads, then it should be somehow integrated in britney: massaging bugs for that purpose feels wrong. Cheers, OdyX
Bug#879214: ITP: planetblupi -- Planet Blupi - A delirious spell-binding game
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud Package name: planetblupi Version : 1.11.0 Upstream Author : Mathieu Schroeter, Daniel Roux, EPSITEC SA & Denis Dumoulin URL : http://blupi.org/ License : GPL-3+ Programming Lang: C++ Description : Planet Blupi - A delirious spell-binding game Planet Blupi is a strategy and adventure game. It subtly blends action with thought-provoking challenges. Behind the quiet and gentle facade, you'll enjoy a fascinating diversion full of surprises. This is another of the finally-freed games from Epsitec. The other one is Colobot (src:colobot), already in Debian. Its build-dependencies have reached NEW already. I will put it under the Debian Games Team umbrella.
Bug#879103: ITP: doctest -- Light and feature-rich C++ testing framework
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud Package name: doctest Version : 1.2.5 Upstream Author : Viktor Kirilov URL : https://github.com/onqtam/doctest License : MIT Programming Lang: C++ Description : Light and feature-rich C++ testing framework doctest is a light and feature-rich C++98 / C++11 single-header testing framework for unit tests and TDD. . It is inspired by the unittest {} functionality of the D programming language and Python's docstrings - tests can be considered a form of documentation and should be able to reside near the production code which they test. This isn't possible (or at least practical) with any other testing framework for C++. Justification: doctest is a B-D of argagg (ITP #878641) Package name: doctest-dev, as the package installs /usr/lib/doctest/doctest.h I welcome suggestions on the source or binary names, as well as packaging :)
Bug#878673: ITP: sdl-kitchensink -- FFmpeg and SDL2 based library for audio and video playback
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud Package name: sdl-kitchensink Version : 0.0.7 Upstream Author : Tuomas Virtanen URL : https://github.com/katajakasa/SDL_kitchensink License : MIT Programming Lang: C Description : FFmpeg and SDL2 based library for audio and video playback * Decoding video & audio via FFmpeg * Dumping video data on SDL_textures * Dumping audio data in the usual mono/stereo interleaved formats * Automatic audio and video conversion to SDL2 friendly formats * Synchronizing video & audio to clock * Seeking forwards and backwards * Bitmap & libass subtitle support. Justification : sdl-kitchensink is a build dependency of "Planet Blupi" (http://blupi.org) which I intend to package for Debian. Package names : libsdl-kitchensink0 libsdl-kitchensink-dev
Bug#878641: ITP: argagg -- Argument Aggregator - Simple C++11 command line argument parser
Package: wnpp Severity: wishlist Owner: Didier 'OdyX' Raboud Package name: argagg Version : 0.4.6 Upstream Author : Viet The Nguyen URL : https://github.com/vietjtnguyen/argagg License : MIT Programming Lang: C++ Description : Argument Aggregator - Simple C++11 command line argument parser This is yet another C++ command line argument/option parser. It was written as a simple and idiomatic alternative to other frameworks like getopt, Boost program options, TCLAP, and others. The goal is to achieve the majority of argument parsing needs in a simple manner with an easy to use API. It operates as a single pass over all arguments, recognizing flags prefixed by - (short) or -- (long) and aggregating them into easy to access structures with lots of convenience functions. It defers processing types until you access them, so the result structures end up just being pointers into the original command line argument C-strings. . argagg supports POSIX recommended argument syntax conventions. Justification : argagg is a build dependency of "Planet Blupi" (http://blupi.org) which I intend to package for Debian. Package names : argagg-dev & argagg-dev-doc
Re: changes to upload queue for security archive
Le lundi, 9 octobre 2017, 20.20:15 h CEST Simon McVittie a écrit : > For embargoed issues, is it better to upload via ssh and have the upload > briefly readable by other DDs, or to upload via ftp and have the upload > briefly readable by everyone on the network path between the DD and > security.upload.debian.org? It seems to me that the question embeds the answer. -- OdyX
Re: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing
Le jeudi, 5 octobre 2017, 13.29:16 h CEST Ian Jackson a écrit : > I have also heard of packages which do "apt-get source" in their rules > files. debian-installer-netboot-images does a similar thing, but it's more of a shell re-implementation of a trust chain check: http://sources.debian.net/src/debian-installer-netboot-images/ 20170615%2Bdeb9u1/get-images.sh/ (Patches welcome, of course) The reason for that (and #807168 documents this) is that: * d-i-n-i binary packages are arch:all packages with arch-specific content; because we want to ship any arch's netboot images on all architectures; and forcing the use of multiarch for that is overkill. * building these arch:all packages in an arch:any build (such as d-i's) is not supported and would be a heavy arm-twisting of our buildd infrastructure. tl;dr; It's certainly no good, but it's the best we have. > I think that both of these activities are reasonable things to do. > They don't violate the self-containedness of Debian. If they are > technically forbidden by policy then policy should be changed. Well. #807312 tracks a way to eventually do the above in a policy-compliant way: build arch:any packages containing netboot images and build d-i-n-i using multiarch Build-Depends. As for changing Policy; what matters is that we ultimately build things from known and DFSG-free _sources_, in a reproducible way. dpkg, apt and sbuilds are just (_FANTASTIC_) means to that end. So we either need better tooling than the above hideous shell, or massage everything into existing tooling. I prefer the "there's a RC bug to fix" situation over a "weaker policy", for now. Cheers, OdyX
Re: Debian Policy 4.0.1.0 released
For further reference, the full TC decision text is at: [0] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html Le dimanche, 6 août 2017, 11.40:26 h EDT Guillem Jover a écrit : > At this point I guess the decision to cope fairly with such subpar and > imposed policy that a maintainer that has a package shipping both a > desktop file and a menu file is either to: > > - ignore it, very sadly violating policy, :( at least until there's >a proper transition plan that does not leave users and WM/DE >maintainers in the cold, In September 2015 [0], the TC proposed a transition plan, in the form of points 3. & 4. : >3. We further resolve that "menu programs" should not depend on the >Debian Menu System and should instead rely on .desktop file >contents for constructing a list of applications to present to >the user. >4. We advise the maintainers of the 'menu' package to update that >package to reflect this increased focus on .desktop files by >modifying the 'menu' package to use .desktop files for the >source of menu information in addition to menu files. One "proper transition plan" has been proposed, and there was no visible result in almost two years; it's certainly sad that`xdg-menu` (from Arch, see [1]) has not been packaged; nor did our very own `menu` [2] receive enough love. The other recourse was (well, still is) a GR, which hasn't happened either. As I wrote back then [3] (and I haven't changed my mind) : > the burden of keeping the trad-menu relevant would be (IMHO correctly) put > on people who care about it, instead of leaving it on all package > maintainers through the Debian Policy. Also in [4]: > The "trad-menu" database will be preserved iff there is enough manpower > to make this happen: either through an automated desktop-to-menu > translation interface, or through a centralisation of that database. Le dimanche, 6 août 2017, 11.40:26 h EDT Guillem Jover a écrit : > - protest it, and still be policy compliant, by going the Solomonic >route and removing both files. That would be stupid, to be blunt. The next step is that this policy change is likely to find its way as a Lintian warning (or error). But we're still _very_ far from mass bug reports, without even talking about their severity (and several TC members indicated they were against 'serious' severity). OdyX [1] https://wiki.archlinux.org/index.php/xdg-menu [2] https://tracker.debian.org/pkg/menu [3] https://lists.debian.org/debian-ctte/2015/08/msg00076.html [4] https://lists.debian.org/debian-ctte/2015/08/msg00046.html [5] https://lists.debian.org/debian-ctte/2015/09/msg5.html signature.asc Description: This is a digitally signed message part.
Re: -all driver packages
Le lundi, 12 juin 2017, 23.26:01 h CEST Rebecca N. Palmer a écrit : > However, those involve Depends relationships (where an -all package is > needed to allow the option of only installing one) and/or multiple > depending/recommending packages and a changing set of providers (making > it desirable to be able to make such changes in one central place). > Hence, I agree that it wouldn't be worth it for *-microcode. The printer-driver-all package uses Recommends, but its source package also builds the printer-driver-all-enforce alternative package that has the same relations but as Depends. As britney only checks for Depends when verifying migration requirements, this setup makes sure that the printer-driver-all package only ever migrates if all its Recommends are satisfied. the -enforce alternative is not meant to be used by end-users. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Hello! How can I delete Debian from menu before Windows loading?
Le samedi, 27 mai 2017, 21.01:46 h CEST Александр Макаров a écrit : > Hello! > > I am thinking to use Debian, but later, because I have no time now. > > How can I delete Debian from menu before Windows loading? You need to uninstall win32-loader using its' uninstaller, which should be located in `C:\win32-loader\Uninstall.exe` Cheers, OdyX
Re: Is missing SysV-init support a bug?
Le lundi, 29 août 2016, 12.07:23 h CEST Dmitrii Kashin a écrit : > But I know a lot of them. And not only in Debian community. And they > don't agree that migrating will give them greater control over their > systems. This is not a popularity contest, in which we'd count points either way. We, as the Debian community, are discussing what we want to offer to our users, given our interests, capabilities, and manpower. Mobs don't produce patches. > If you want I'll ask them to write here too. Please don't. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Refresh the CUPS driver recommends (was: Re: Opt out style recommends)
Package: cups Version: 1.5.2-9 Le vendredi, 8 avril 2016, 10.31:17 Josh Triplett a écrit : > I'm not going to go through a full analysis here, but here's a *tiny* > subset of the output on my system, with some annotations: > > (…) > cups Recommends: printer-driver-gutenprint > > Why does cups recommend some printer drivers and only suggest others? > For instance, I have printer-driver-hpcups installed instead. This should indeed be changed. Reporting a bug to keep track. -- Cheers, OdyX
Re: Status of the src:lsb package
Le jeudi, 17 septembre 2015, 23.00:51 Michael Biebl a écrit : > Am 17.09.2015 um 14:56 schrieb Didier 'OdyX' Raboud: > > After the discussion [0] about these changes back in July (on both > > debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 > > to > > unstable, building no LSB compatibility packages anymore (besides > > lsb- release and lsb-base). As far as I could see, this didn't > > affect anything in unstable at the time (and that's how things > > should be). > So far I only stumbled upon one proprietary deb which has a Depends: > lsb, which will be broken by dropping the lsb compat packages. > It's the closed-source Epson printer driver [1]. It's a rather badly > maintained package (using alien), still wanted to mention it as a data > point. LSB-"compliant" (FSVO 'compliant') printing drivers are certainly a problem. That said, it's a problem that I'd rather tackle with re- packaging, upload to non-free, or any other more Debian-specific method. In this specific case, there's at least some part that comes in LGPL source form. The Debian Printing Team welcomes all interested parties :-) Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Status of the src:lsb package
Hi Nikolaus, Le jeudi, 17 septembre 2015, 09.27:56 Nikolaus Rath a écrit : > On Sep 17 2015, Didier 'OdyX' Raboud wrote: > > Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit : > >> I don't know about formal LSB compatibility, but there are several > >> proprietary applications that require nothing but the > >> /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So > >> it would be great if they could be preserved. > > > > FYI, this used to be in lsb-core, and is to be found in the package > > VCS history. > > > > I will not work towards this, but feel free to adopt the package and > > upload an updated version. > > I'm only a DM and having to search for a fresh sponsor for every > upload is very frustrating. Would you be generally available to > sponsor my uploads (ideallyl until you feel comfortable to give me > upload privileges)? Given that I'm (so far) convinced that _not_ providing the lsb packages at all is the correct thing to do for Debian, I'd prefer if another DD could sponsor any upload of src:lsb re-introducing these (and drop me from Uploaders). That said, as for the technical issue at hand, iff these symlinks [0] are useful to make Debian relevant for (some) non-free software out there, couldn't they be handled directly by libc6 on the various architectures ? src:eglibc maintainers: opinions ? Cheers, OdyX [0] http://anonscm.debian.org/cgit/collab-maint/lsb.git/tree/debian/lsb-core.postinst?id=96a2bf324aa67a68d30387804f18ccb5a7bb0d88 signature.asc Description: This is a digitally signed message part.
Re: Status of the src:lsb package
Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit : > I don't know about formal LSB compatibility, but there are several > proprietary applications that require nothing but the > /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So it > would be great if they could be preserved. FYI, this used to be in lsb-core, and is to be found in the package VCS history. I will not work towards this, but feel free to adopt the package and upload an updated version. Cheers, OdyX P.S. Please keep debian-lsb@ in the loop.
Status of the src:lsb package (was: Debian LSB compliance)
Hi all, It is time for an update about the lsb source package status, especially as a quite important change landed in testing. After the discussion [0] about these changes back in July (on both debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 to unstable, building no LSB compatibility packages anymore (besides lsb- release and lsb-base). As far as I could see, this didn't affect anything in unstable at the time (and that's how things should be). This change landed in stretch on September 14. and is de facto the "outright giving up" of LSB support for Debian, from stretch onwards. As mentionned in the NEWS.Debian entry, the lsb-base (init-functions) and lsb-release packages are still available, and are here to stay: lsb- release has 102 reverse-depends, and lsb-base has 800+ reverse-depends. But Debian's not throwing all of the LSB overboard: we're still firmly standing behind the FHS (version 2.3 through Debian Policy; although 3.0 was released in August this year) and our SysV init scripts mostly conform to LSB VIII.22.{2-8}. But don't get me wrong, this src:lsb upload is an explicit move away from the LSB. I will keep an eye on src:lsb, but really, I don't intend to invest much more time; so I'll happily hand over maintainership to anyone wanting to invest time in LSB 5.0 Debian support. Cheers, OdyX [0] https://lists.debian.org/4682310.7LIWdV4Lar@gyllingar signature.asc Description: This is a digitally signed message part.
Re: Security concerns with minified javascript code
Le mardi, 1 septembre 2015, 17.50:26 Vincent Bernat a écrit : > ❦ 1 septembre 2015 08:21 -0700, Nikolaus Rath : > >>> Couldn't we just use the non-minified versions in most situations? > >>> A > >> > >> Not for anything which has actual users over the network. > > > > Why? (Don't forget about gzip encoding). > > See: > https://mathiasbynens.be/demo/jquery-size What this tells us is that the size wins for the latest jquery version are the following : * gzip only -> 29.7% * zopfli only -> 28.1% * minifying + gzip -> 11.9% * minfying + zopfli -> 11.5% So, taking this jquery example, if minifying is too hard, we can still go below 30% of the total size by applying gzip only. That said… We should not forget that "minified+gzipped JS" is only a temporary state of things. The web ecosystem moved from "ship the full JS source to users" (which was way easier in terms of software freedom) to "miinified JS". We're at the point where we debate whether this "minified JS" is valid source for us (technically, it is valid JS code, but not the preferred form of modification). But the web ecosystem is moving towards WebAssembly [0,1], that will be "a portable, size- and load-time-efficient binary format" [2]. Where "minified JS" could be seen as source-code, WebAssembly will definitely not. If we accept the compromise to not run the compilation step from JS to "minified JS", will it be tenable to not run it either for _binaries_? Although I'm concerned by this, I don't doubt much that WebAssembly (or any other binary format for the web) _will_ be coming to the web, our upstreams, and will become their preferred way to ship frontend code to their users. We'll have to deal with that, and we should get ourselves ready for that. The current web compilation stack is arguably ugly, painful to maintain, and a big source of frustration, and I can therefore understand how maintainers end up not doing the compilation in the Debian package build; but really, if we don't do it now, what will happen with binary formats? I think we should take a strong move there and exercise (as well as justify to the outer world) our free software right to recompile the software that we ship to our users: this could mean to only merge & gzip JS files if minifying isn't realistic [3]. Not doing so _is_ going to hurt our ability to exercise our freedoms in the future, it's also making a disservice to our users. Cheers, OdyX [0] https://blog.mozilla.org/luke/2015/06/17/webassembly/ [1] https://github.com/WebAssembly [2] https://github.com/WebAssembly/design/blob/master/HighLevelGoals.md [3] Reducing to 29% instead of 12% might be the price of our freedom there…
Re: Debian LSB compliance
Le vendredi, 3 juillet 2015, 13.20:08 Mats Wichmann a écrit : > On 07/03/15 07:28, Didier 'OdyX' Raboud wrote: > > The crux of the issue is, I think, whether this whole game is worth > > the work: I am yet to hear about software distribution happening > > through LSB packages [4]. There are only _8_ applications by 6 > > companies on the LSB certified applications list [5], of which only > > one is against LSB >= 4. Amongst the distributions, RHEL 7.0 is > > LSB4.1, and Oracle 6, RHEL 6.0 and Ubuntu 9.04 are LSB 4. > > > > As a data point, I've just noticed that the Linux Foundation issued > > LSB 5.0 and FHS 3.0 [6] just yesterday. But that doesn't change the > > arguments, I think. > > The current distribution checker is actually quite easy to set up, > it's just a package to install and off you go, answer a few questions > through a web interface. Should you have the patience to fire off 10+ > hours of tests and then want to look at them. You would need that for > "compliance" which has never directly been a Debian goal, as you say. Fair enough, but then what? Let's assume we test 'stretch', our next stable release. Case a) Tests show that it is compliant so far, and by some magic trickery, this stays true until release day. In this case, we should apply for full certification, and use that as an "sales" argument. Case b) Tests show that it isn't: some problems might point to meaningful changes, but some others might not be fixable? We'd be non- compliant, and all that work would be a wasted effort. From what I understand (given the timescales), changing the LSB to be "whatever Debian as well as all other actors in the FLOSS world are _actually_ doing" is a painful, long and boring process, that the people involved in the LSB processes are only very slowly doing by themselves (no offense intended). The packages we currently have were built for LSB4.1, and the LSB5.0 just went out. Are there people out there interested in making the LSB relevant through certifying Debian 'stretch' for LSB5 [0]? Let's face it: given the current importance of Debian in the distributions' ecosystem, our decision with regards to becoming LSB5 certified (or not) could be decisive: if we commit to it, and establish efficient communication channels to push for LSB changes (eventually leading to a LSB5.1 == Debian strectch), then this /could/ make LSB5 somewhat more relevant than it ever was. If we don't, and instead outright "give up" on LSB support, then this might very well be a further nail in the LSB coffin. Given a) the work that certifying Debian would take; b) the interest in having Debian be certified (I am yet to see any of that interest); c) the marginal interest by application vendors for the LSB; … I'm leaning towards outright giving up. Of course, I could simply orphan src:lsb and be done with it, but I feel we'd be much better off with a src:lsb package that either does, or doesn't at all provide LSB5 certification: the middle ground that we've stayed in is helping neither Debian or LSB. So, are there any volunteers to make Debian LSB-certified? I'm likely to work on src:lsb during DebConf, so please make yourself known before then! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Debian LSB compliance (was: Re: Standard-producing bodies and Debian)
Hi Gunnar, just jumping on one specific point, sorry to hijack the thread… (Reply-To set to debian-lsb, please followup there…) tl;dr: proposal to shrink src:lsb to only produce lsb-base and lsb- release Le jeudi, 2 juillet 2015, 09.15:12 Gunnar Wolf a écrit : > But then I realized I was lying. > > Debian does take care to implement several standards (i.e. following a > LSB-compliant POSIX system This is only true to a certain extent: we do [0] care about a certain level of compatibility with LSB around initscripts and the existence of a lsb_release binary [1]. Debian has (ab)used the src:lsb package to host more and more common code over the years (see your /lib/lsb/init- functions{,.d/} and all of lsb-base): "left info blocks", all the log_{daemon,progress,end,action_msg shell functions, etc. (Sadly enough, there's even a code difference between the Ubuntu and Debian versions of pidofproc. /o\ ) But… the largest part of the LSB specification is about API compatibility: all the lsb-{base,core,cxx,desktop,graphics,languages,multimedia,printing,security} packages _try_ to make sure that the correct packages are present, but there is (as far as I know) nobody on the Debian side actually _checking_ that all symbols are actually present, or that they stay present. At the time of LSB4.1, for x86, we were talking about 1493 components, 1672 libs, 38491 commands, 30176 classes and 716202 interfaces [2]. (There's of course also the FHS, that we modify with our own exceptions anyway, but it is part of the LSB.) We're also not checking this because the LSB compatibility of Debian releases has never been a topic and I don't see anyone asking a library maintainer to stay at an older version and/or maintain a patch series to keep this compatibility [2]. By the way, the only organism that I know is regularly checking Debian's LSB compatibility, is the Linux Foundation [3]. They haven't tried Jessie yet apparently. (There _exists_ a Distribution Checker, but last I looked, it was an intense headache to setup.) The crux of the issue is, I think, whether this whole game is worth the work: I am yet to hear about software distribution happening through LSB packages [4]. There are only _8_ applications by 6 companies on the LSB certified applications list [5], of which only one is against LSB >= 4. Amongst the distributions, RHEL 7.0 is LSB4.1, and Oracle 6, RHEL 6.0 and Ubuntu 9.04 are LSB 4. As a data point, I've just noticed that the Linux Foundation issued LSB 5.0 and FHS 3.0 [6] just yesterday. But that doesn't change the arguments, I think. I've held an LSB BoF last year at DebConf [7], and discussed src:lsb with various people back then, and what I took back was "roughly noone cares". Since then, the package just floated in the limbo down my TODO list. Now, given all this, I'm considering the following (and seeking advice and/or support): * accepting that LSB certification is not a goal for us, and give up explicitely, * therefore truncating the src:lsb package to the only things that are still obligatory: lsb-base & lsb-release. Opinions? Thanks in advance, and sorry for the quite long mail! Cheers, OdyX [0] Mostly _did_, when SysVinit was the de-facto standard… [1] Which is currently broken for sid users, as I just noticed now when writing this email. [2] The package descriptions contain: > The intent of this package is to provide a best current practice way > of installing and running LSB packages on Debian GNU/Linux. Its > presence does not imply that Debian fully complies > with the Linux Standard Base, and should not be construed as a > statement that Debian is LSB-compliant. [3] http://www.linuxbase.org/navigator/browse/distr.php?cmd=list-byid&Did=476 [4] There are some OpenPrinting driver packages, but that shouldn't matter for all FLOSS drivers. [5] https://www.linuxbase.org/lsb-cert/productdir.php?by_lsb [6] http://www.linuxfoundation.org/collaborate/workgroups/lsb/lsb-50 [7] DebConf14 BoF: https://summit.debconf.org/debconf14/meeting/104/lsb-for-debian-bof/ and debconf14/bof/LSB on gobby.debian.org signature.asc Description: This is a digitally signed message part.
Bug#787889: general: USB keyboard stops working after a few seconds due to USB suspend
Le vendredi, 5 juin 2015, 17.19:46 Jesse Hallett a écrit : > Attempted to use USB keyboard in, in Xorg and in virtual TTY. > (…) > There appeared to be no input from the keyboard. After disconnecting > and reconnecting the keyboard it functioned; but after a period of > seconds it consistently stopped working until it was disconnected and > reconnected again. > (…) > > * Is there a workaround? > > I am able to work around the issue by overriding USB power management > for the keyboard device: > > cat on | sudo tee /sys/bus/usb/devices/3-1.2.2/power/level Do you have laptop-mode-tools installed ? This smells very much like https://bugs.debian.org/671405 and friends. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3583846.QuONxlSbeV@gyllingar
Re: Bits from the dpkg project: 1.17.x series, general news
Le dimanche, 19 avril 2015, 10.25:11 Cyril Brulebois a écrit : > Thanks so much for all the hard (and not only technical) work, > Raphaël! Indeed, thank you buxy! OdyX signature.asc Description: This is a digitally signed message part.
Re: how to remove libsystemd0 from a live-running debian desktop system
Le lundi, 16 février 2015, 13.38:01 Adam Borowski a écrit : > Second, all but one (upower) of affected packages can be recompiled to > drop the dependency. If you bothered to read lists you're subscribed > to, you would probably know of my set of deinfected packages at: > deb http://angband.pl/debian nosystemd > deb-src http://angband.pl/debian nosystemd > which are included for example in Trios. After such a recompilation, > you can have a systemd-free system with no functionality loss -- in > fact, it does solve some regressions compared to systemd-using hacks > like -shim. Given a common interface (such as 'nosystemd' in DEB_BUILD_OPTIONS), I, for one, would most probably include (whishlist-level) patches reducing this repetitive work to needing to set up automatic buildds setting the correct options. I'm mostly happy with systemd, but unhappy when people go monkey-patch a lot of packages when scalable and maintainable solutions could make everyone's life easier. Sure, including patches for build-time toggling of systemd support slightly increases the maintenance, but now that we have VCS'es everywhere, I tend to think it's mostly a one-time work. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2118253.4PMAVtGAYT@gyllingar
Bug#773356: ITP: ippusbxd -- Daemon for IPP-over-USB printer support
Package: wnpp Severity: wishlist Owner: "Didier 'OdyX' Raboud" Package name: ippusbxd Version : 1.21.2 Upstream Author : Daniel Dressler URL : https://github.com/daniel-dressler/ippusbxd License : Apache-2 Programming Lang: C Description : Daemon for IPP USB printer support ippusbxd is a userland driver for USB devices supporting the IPP USB specification. It enables these USB printers to be seen as regular network IPP printers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141217112933.26725.87.reportbug@gyllingar
Re: Please respect Freeze Policy
Le jeudi, 4 décembre 2014, 07.46:25 Bart Martens a écrit : > On Wed, Dec 03, 2014 at 10:42:54AM +0100, Didier 'OdyX' Raboud wrote: > > Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit : > > > Would it be OK to abuse experimental for new upstreams during > > > freeze? > > > > during freezes, where unstable should only have changes targeted at > > testing (and therefore, currently, at jessie). > > I don't read that in the freeze policy. Do you? It's indeed not mentioned there, although the following paragraph is of interest: > If the version in unstable has significant changes that cannot be > reversed or stuck behind other packages that are not acceptable, > please contact the release team (i.e. file a bug) for doing your > upload to testing-proposed-updates. However, please remember that > stricter rules apply to testing-proposed-updates (see here for the > rules.) The November Bits from the release team [0] have a different phrasing too : > Uploads to unstable > > Since many updates (hopefully, the vast majority) will be via > unstable, changes there can be disruptive if they would be unsuitable > for Jessie. > Please be mindful of this, particularly if you maintain a library or > key package. My understanding of the situation is that the Release Team considers unstable to be the ante-chamber of testing, and that they expect it to only contain changes suitable for inclusion in the next stable release. The problem with new upstream releases in unstable during the freeze is not these uploads /per se/, but with what they "inflict" on related packages and on testing. As others have mentioned in this thread: * RC bugs discovered in the testing version of the package ? ↳ Needs to go through t-p-u * Package is used in Build-Depends of other packages ? ↳ Other packages need to go through t-p-u So, of course, the heart of the problem is the insufficient usage of t- p-u by users, leading to /de facto/ uploads straight to testing. But this isn't easily solved: we already have three major suites and documenting all the additional partial suites in ways that make users _want_ to use these (and report bugs they see) isn't easy. Many of us developers are users of unstable: having this suite as close to testing as possible (especially during freezes) is _good_ for the quality of our stable releases. I'd encourage the RT to push even more for an 'unstable' suite dedicated to the release process. Development can perfectly "continue" in experimental. Cheers, OdyX [0] https://lists.debian.org/debian-devel-announce/2014/11/msg3.html signature.asc Description: This is a digitally signed message part.
Re: Please respect Freeze Policy
(Moving to debian-devel, please followup there) Le mercredi, 3 décembre 2014, 10.20:32 W. Martin Borgert a écrit : > Would it be OK to abuse experimental for new upstreams during > freeze? It is not the purpose of experimental to contain such > packages, of course. But it might be a less harmful form of > civil disobedience. > > (Nothing private in my part of the message.) (Snipping others' parts, and moving to -devel) Given the (current) small exposure of testing-proposed-updates (aka the repository has very few users, therefore the packages there get very few testing), unstable is supposed to stay the anti-chamber of testing, mostly at all times: whatever you upload to unstable should be aimed at the next stable release. None of this changes during freezes, where unstable should only have changes targeted at testing (and therefore, currently, at jessie).Using experimental for new upstream versions is not at all an abuse; it's exactly the suite one should be targeting for these changes! Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2460101.JeghnMkdZR@gyllingar
Re: Using USB serial device with a cdc-acm driver
Le mardi, 2 décembre 2014, 13.02:49 Matthias Urlichs a écrit : > Dmitriy Fitisov: > > > lsof /dev/ttyACM0 > > > > That I also tried last week. Nothing is open. > > The next target of interest would be udev. > Which rules fire, and do they start anything? In particular, do you have usb-modeswitch installed and running? OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3112008.5Q5dKWHIPJ@gyllingar
Bug#769907: general: non-sysvinit init systems are made of fail
Le jeudi, 20 novembre 2014, 12.06:45 Sam Hartman a écrit : > >>>>> "Didier" == Didier 'OdyX' Raboud writes: > Didier> Systems cross-craded from Ubuntu to Debian are absolutely > Didier> not supported, and I wouldn't be surprised if some of the > Didier> issues you're seeing are in some way related to this. > > I've seen both these issues on pure Debian systems. > > And I do consider both of them likely to be significant problems on > upgrades from wheezy. > I've been burned by both of the identified issues on multiple systems. Fair enough, and thanks for pointing this out. I also apologize to Michal for having jumped too rapidly to conclusions. Steve's suggestions stands though: separated and actionable bugs for these two issues filed on the corresponding packages are way more helpful than a general "non-sysvinit init systems are made of fail". Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3920626.IYNqfL8Hhi@gyllingar
Bug#769907: general: non-sysvinit init systems are made of fail
Le mercredi, 19 novembre 2014, 09.34:22 Michal Suchanek a écrit : > On 19 November 2014 08:02, Didier 'OdyX' Raboud wrote: > > Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit : > >> I had Ubuntu base system on this particular PC some years ago and I > >> noticed this issue and spent a few minutes trying to figure out > >> where that value is stored. I did not figure it out and since the > >> upgrade to Debian base system is not supposed to handle this > >> situation it is technically not a bug in Debian. It's only a > >> cosmetic issue so I left it at that. > > > > Systems cross-craded from Ubuntu to Debian are absolutely not > > supported, and I wouldn't be surprised if some of the issues you're > > seeing are in some way related to this. > > Sure, it's always user error when something fails. I didn't write that. > Systems upgraded from Ubuntu are not supported That should be obvious, yes. > systems upgraded from Debian are not supported, nor are systems > freshly bootstrapped and booted inside qemu. Because all these fail. This depends on your definition of "fail" (which was quite vague in this "general" bug-report). These two use-cases don't "fail" for me here. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5076940.tJqDfecBa5@gyllingar
Bug#769907: general: non-sysvinit init systems are made of fail
Le mercredi, 19 novembre 2014, 00.00:48 Michal Suchanek a écrit : > On 18 November 2014 18:57, Jordi Mallach wrote: > > El dl 17 de 11 de 2014 a les 15:41 +0100, en/na Michal Suchanek va > > escriure: > >> -- System Information: > >> Distributor ID: Ubuntu > >> Description: Ubuntu GNU/Linux testing (jessie) > > It's a cosmetic issue ;-). > > I had Ubuntu base system on this particular PC some years ago and I > noticed this issue and spent a few minutes trying to figure out where > that value is stored. I did not figure it out and since the upgrade to > Debian base system is not supposed to handle this situation it is > technically not a bug in Debian. It's only a cosmetic issue so I left > it at that. Systems cross-craded from Ubuntu to Debian are absolutely not supported, and I wouldn't be surprised if some of the issues you're seeing are in some way related to this. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/30809294.EYYie8BeKM@gyllingar
Re: piece of mind (Re: Moderated posts?)
Le mardi, 14 octobre 2014, 01.13:48 Wookey a écrit : > I'm just pointing out that interested people, who are moderately > well-involved, really did miss that a GR was attempted. For the record, I don't disagree; I'm just saying that the GR call was on the right list and that I think that the project's documented expectation is that those interested in GR calls should have been following -vote, as documented on our website: https://lists.debian.org/2644371.u0TgOhpbrd@gyllingar Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3544854.5pQuf1ujCs@gyllingar
Re: piece of mind (Re: Moderated posts?)
Le lundi, 13 octobre 2014, 12.23:00 Miles Fidelman a écrit : > Didier 'OdyX' Raboud wrote: > > I really don't buy the argument that "the GR proposal was too quiet > > to be noticed by 6+ people". > > Actually - I'd contest that, for four reasons: > > - as I've previously noted - the major impacts of systemd are being > (going to be) felt by sysadmins and upstream developers - who don't > necessarily follow debian-devel all that closely -- or have input Mind you, most if not all of the CTTE are both sysadmins and upstream developers, and I'd go as far as saying that most of DDs are either too. > - the actual GR call for vote was buried on debian-vote - immediately > jumped on regarding wording and procedural discussions Yes, and? There was a proposal on -vote, which could have been followed by seconds, totally ignoring the side-discussions. Don't expect launching a GR about a) overriding a Debian body; b) the default init system to be a quiet ride. > - actual discussion of the GR on -devel was completely swamped by all > the other discussion of systemd My feeling is that the swamping happened because some people disagreeing with the CTTE vote vented a lot of frustration through whining and complaining instead of focusing their energy to formulate a concrete proposal for a GR. We're talking about finding _6_ seconds, so I'd only buy this argument if the threshold was 50 (or so) and we'd have only found a dozen seconds. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2605439.lZGhNDzrLW@gyllingar
Re: piece of mind (Re: Moderated posts?)
I really don't buy the argument that "the GR proposal was too quiet to be noticed by 6+ people". I mean: the proposition happened to be in the middle of the post-TC decision wave, on the mailing lists where it belonged. The people who cared about the whole "default init for Debian" question _were_ following and contributing to these various lists. I'm therefore claiming that the people who missed the GR proposal were not sufficiently interested (otherwise they would've been subscribed to either -vote or -project, where these proposals belong). I'm also thankful that the proposer limited his proposal to these lists (I'd have considered a spread of the call over -devel, -user or other lists an abuse). Le lundi, 13 octobre 2014, 16.15:02 Ian Jackson a écrit : > If four other DDs send me and Matthew Vernon private email to say that > they would support a GR on this subject, I will restart this > conversation on -project. Doing this now despite the fact that the GR didn't reach its 6 seconds, 7 months ago, will lead to an incredibly bigger waste of time, just when we're about to freeze testing. The GR train passed… Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/17667995.ybzVghadep@gyllingar
Re: Trimming priority:standard
Le mardi, 16 septembre 2014, 23.17:51 Joerg Jaspert a écrit : > On 13698 March 1977, Didier Raboud wrote: > >> > One thought... there will probably be trademark concerns with > >> > "unix".[1] So we might have to choose a name for the tasksel task > >> > to be someting like "unix-like". > >> > >> Or we could just call it "standard system". > > > > Could we make sure the full "vim" is in that then? I miss it on > > every > > new installation and I'm quite sure that's not uncommon. > > ONLY if we put emacs there too (…) Apparently I just need to learn to use the 'nocompatible' option for vim, sorry for the noise. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3592821.OyjbmjOk0H@gyllingar
Re: Trimming priority:standard
Le vendredi, 12 septembre 2014, 13.55:53 Joey Hess a écrit : > Theodore Ts'o wrote: > > One thought... there will probably be trademark concerns with > > "unix".[1] So we might have to choose a name for the tasksel task > > to be someting like "unix-like". > > Or we could just call it "standard system". Could we make sure the full "vim" is in that then? I miss it on every new installation and I'm quite sure that's not uncommon. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/3087012.x4OgC7KCFP@gyllingar
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le jeudi, 31 juillet 2014, 22.19:28 Pau Garcia i Quiles a écrit : > How is it better to have libav, which does a lot less security > bugfixing, in? Our security team has to prepare the libav updates over the lifetime of wheezy anyway. Introducing ffmpeg in jessie (with or without dropping libav) means (at least) duplicating that work. OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5354151.iF7zqzrZRY@gyllingar
Re: sysvinit is still here, and here to stay for jessie (was Re: systemd is here to stay, get over it now)
That will be my last contribution to this pointless discussion. Le jeudi, 3 juillet 2014, 16.59:25 Thorsten Glaser a écrit : > > or without systemd btw). Given that the technical committee has made > > a decision which stayed unchallenged (so far), I've now come to > > think that > No, there just has not been any challenge that met the form and > other requirements… and I am at a bit of loss at what to do here. > > Besides, it’s not that the TC made a decision. Rather, the TC was > split, and the chairman threw in his weight. Sorry, but this is plain wrong (and you know it); the TC followed its decision-making process (outlined in the project's constitution [0,1]) which led to what is now a TC decision. The detail of the votes doesn't change the outcome. Quoting [2]: > The committee decided that the default init system for Linux > architectures in jessie should be systemd. There are no possible "weak" or "strong" decisions; the outcome of a TC or GR decision is either "resolution accepted" or "further discussion". Giving importance to the "winning majority" is your choice but doesn't change the decision itself. > This is absolutely not what I’d call a project(!) decision. I was careful enough to not say it was a project decision, mind you. That said, our technical decision body took a decision that stayed unchallenged (so far); this fact makes it a /de facto/ project decision. > > Can we get over this now and start making Jessie the most awesome > > stable release we've ever prepared together? > > To do that, it MUST work without systemd, if alone for upgrade > scenarios. That's wrong: as far as the default init is concerned, it only MUST work without systemd-as-init until the first post-dist-upgrade reboot. I don't think any work outside of that scope should be imposed on the package maintainers [3]. > And alone the fact that the systemd issue *continuously* pops up > shows you that it is nowhere even near solved. I don't think that's true. From my (most-certainly) biased point of view, the issue continues to pop up because some very vocal systemd opponents keep vocally insisting that other fellow project volunteers ensure that their pet use-cases keep working with a non-default init system (or even without a specific non-init package). As far as I am concerned, I'm putting my energy to make sure my packages (and my setup) work as good as possible with the _default_ init that was picked for jessie. The rest is best-effort. > Furthermore, the TC(-chairman) decision only was on the default > init system for the Linux ports of jessie. Please stop spreading the FUD that the default init decision was a TC- chairman decision. This is plain wrong, as our constitution outlines. > This means that > • installing jessie with other init systems > • switching between init systems > • default init system for kFreeBSD ports > • default init system for Hurd port > • which non-default init systems are there? > are still on the table. Sure. They are on the "we want Debian Jessie to work with other inits than the default" persons' table, they have no reason to be on everyone's. As mentioned above: if you want this to work, make sure it does, propose patches, test scenarios, etc. Pushing for a package conflicting with systemd is not helping any of this. > (Due to Debian’s requirements for sane upgrades, running a jessie > system that was upgraded from an older release with sysvinit MUST be > fully supported, anyway.) Wrong, see above. > I’m a bit torn between throwing it all (which is a bad idea ofc), > writing a GR myself (which is also a bad idea due to my lack of > language skills), packaging BSD init for my own repo, joining the > (currently unheard) runit-as-init crowd… Frankly, if voting on a default init GR would ensure we'd finally stop these bikeshed discussions (after few other weeks of mudslinging), by all means, go for it. That said, as far as I remember, the latest GR proposal [4] on this subject failed to gather the mandatory K seconds though. For me, this indicates that not even K=5 DDs were interested in having that discussion. We currently need half a percent of DDs to trigger a GR and it has not happened; could we get over this now? OdyX [0] https://www.debian.org/devel/constitution [1] Which you agreed to. [2] https://www.debian.org/devel/tech-ctte [3] It doesn't mean they should not accept patches for adaptations for other init systems though. [4] https://lists.debian.org/debian-vote/2014/03/msg0.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1627463.lsrZH6mOqL@gyllingar
systemd is here to stay, get over it now (was: Re: Pinning vs. conflicting)
Folks, Le jeudi, 3 juillet 2014, 14.20:24 Juliusz Chroboczek a écrit : > Isn't the proper solution to add blacklisting support to dpkg, then? The proper solution is to stop trying to hide ourselves from to the fact that some sort of systemd interfaces have been made unavoidable in modern desktop environments (fact which is rightfully reflected in our dependencies tree). Many of the interfaces of systemd are here to stay and will make their way through our stack (like it or not); fact is they already made it quite far in at least Gnome and KDE. As developers of Debian (which this list is about afterall), our proper solution is not to forbid systemd on our various systems while hoping that "not too many things" will end up depending on its interfaces and that our "working setup for so long that I can't even remember" will magically keep working while the underlying stack keeps evolving (with or without systemd btw). Given that the technical committee has made a decision which stayed unchallenged (so far), I've now come to think that this behavior (and its flaming counterpart) is actively hurting the project. The proper solution is to fix (or help fix) all use-cases that became broken with the arrival of systemd and/or make sure that the dependencies tree allows the systemd shim to be installed and working, as well as making sure this shim stays relevant and a working and transparent replacement to systemd itself. We are collectively developing an operating system, not only assembling a set of packages for our own benefit. Our priority is our users and they rightfully expect a rocking Jessie release, which will happen with systemd as default init system. Will we make this happen or will we just end up having gone through an endless bikeshedding discussion about a package that forbids the installation of the default init system!? Can we get over this now and start making Jessie the most awesome stable release we've ever prepared together? Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: MATE 1.8 has now fully arrived in Debian
Le vendredi, 27 juin 2014, 23.02:51 Thomas Goirand a écrit : > On 06/27/2014 06:31 PM, Michael Englehorn wrote: > > Wouldn't glibc then fall into the list of things you don't like as a > > "required framework"? By that logic, all libraries must be > > hot-swappable with no additional effort by the end-user. That's > > just not realistic. > > > > -Michael > > Are you aware that we're switching away from eglibc? Just saying... Are you aware that we never had both glibc and eglibc simultaneously available in a suite? Just saying… OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2568562.DDxbkL30vz@gyllingar
Re: systemd-fsck?
Le mardi, 13 mai 2014, 17.21:45 Thorsten Glaser a écrit : > Didier 'OdyX' Raboud dixit: > >Le mardi, 13 mai 2014, 16.25:31 Thorsten Glaser a écrit : > >> On Mon, 12 May 2014, Tollef Fog Heen wrote: > >> > Are you aware that Joss isn't a systemd maintainer? (He's one of > >> > the GNOME maintainers.) > >> > >> There’s not really a line between them, you know. (But it was > > > >On top of your first sentence being factually wrong (check the > >maintainer fields of the respective packages), I really think your > > I *know* that the people listed as maintainers of the respective > Debian packages, (…) Please don't quote private mails in public. Also, don't evade the criticism on on your unacceptable words and retract your statement. TIA, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2755547.vUKYPZ7X3A@gyllingar
Re: Bug #702005: Where can i get more attention on this?
Le jeudi, 8 mai 2014, 13.05:52 Ian Jackson a écrit : > Unfortunately, Luis's mail domain is hosted at Hotmail which hates > chiark: Pot calling the kettle black: chiark hates a lot of servers out there when it's "Irritated"… OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1915138.zsAfhk3TAZ@gyllingar
Re: gnutls28 transition
Le dimanche, 4 mai 2014, 02.14:17 peter green a écrit : > Personally I'd add a (build-)depends on the relicensed gmp in the next > gnutls28 upload. That way packages can (build-)depend on the new > gnutls and be assured of getting a GPLv2 compatible version. For cups, as it doesn't build-depend on libgmp directly, I added the inverse relationship: # libgmp-dev is not GPL-2 compatible before it's 6 release, which makes # it also GPL-2+ Build-Conflicts: libgmp-dev (<< 2:6) Dimitri John Ledkov wrote: > Should we start transition to gnutls28 by default, for all packages > that are compatible? Yes, please. Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2156746.eBzsy0u8Yc@gyllingar
Bluez5 and KDE (was: Re: Bits from the systemd + GNOME sprint)
Hi Jordi, and thanks for this interesting report! One point I'd like to see discussed is the Bluez5 transition: Le vendredi, 2 mai 2014, 01.26:15 Jordi Mallach a écrit : > We finally discussed how to tackle Bluez5. Bluez 4 is the current > release available in Debian, which is dead upstream and deprecated > since late 2012. GNOME 3.12 only supports Bluez 5, while the rest of > Bluez users in Debian (including KDE, Xfce and other environments) > haven't been ported yet to Bluez 5. For what is worth, the KDE Bluetooth stack (Bluedevil) has a new upstream version that supports Bluez5: 2.0~rc1. It's mostly an upload away and I might help the Qt-KDE Team out by just "doing it" soon… It works fine here at least. > Both releases are not parallel > installable, so we concluded that a potential solution could be to > upload Bluez 5 as “bluez5”, and let it conflict with ”bluez” > [BLUEZ5BTS]. Desktops would then recommend their supported release > instead of depending on it, which would allow for parallel > installation of different desktop environments, while respecting the > bluez conflict. Given that Bluez4 is already deprecated for a year (and will be for two at freeze time), I'd rather be leaning towards moving to Bluez5 as soon as possible to "force" the various environments to migrate (but I'm not a Bluez maintainer)… Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Bits from the Security Team
Hi, Le lundi, 17 mars 2014, 10.33:32 Holger Levsen a écrit : > I think you've missed one significant benefit here: (I believe) for > quite many people by now it's a showstoper to join a team which is > using subversion for it's workflow. git-svn usage is a manpage away: once you've learned `git svn rebase` and `git svn dcommit`, you're basically with pure git. > I would certainly *not* join the security team while you're using > subversion. (And I doubt I'm alone here.) That's quite ironic from a DebConf chair's mouth. :-P Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7470528.AlHlBr3Krs@gyllingar
Re: jquery debate with upstream
Le mercredi, 12 mars 2014, 12.58:51 Ian Jackson a écrit : > Didier 'OdyX' Raboud writes ("Re: jquery debate with upstream"): > > I disagree: I don't think it's tolerable to ship a .exe freeware [0] > > in a source package in main, just because it happens to be > > redistributable; in my reading, considering that the "source > > package" _is_ a component of the Debian system, doing so violates > > at least SC§1 and DFSG§2. I don't think there should be a > > standards' difference between our source and binary packages. > > I have a completely different approach to the DFSG. The DFSG is not > carefully drafted document and it doesn't stand up to detailed > legalistic interpretation. Rather, it is a statement of aims and > values. My intent was not to draw a legalistic line, I was merely explaining what my (current) interpretation of these aims and values are with regards to shipping non-free binaries in source packages in main. > That purpose is to improve the freedom of software users (and to an > extent developers) by providing an operating system which they can > (individually and collectively) examine, modify and share. > > If an interpretation of the DFSG suggests that we should be doing work > which does not further those objectives, then I think that > interpretation is a misreading. SC§1 states that we want Debian to remain 100% free; the common interpretation of that is that one can download anything from Debian main and only get DFSG-free material; I think our sources are held to the same expectation. In fact, we _are_ shipping source and binary packages in the exact same way through our mirrors network. Now, granted, making Debian 100% free is not improving the freedom of software users if they don't use these non-free parts (and having them in the source packages only is certainly a blocker), but I strongly feel that weakening our promise to only address binary packages for the sake of practicability is certainly not worth the practical benefit. > No-one has come up with any practical benefit from the repacking of > source tarballs to remove nonfree files. There's no practical benefit, granted, but doing so is a service to our users and a continued statement that we hold ourselves to high standards with regards to software freedom. > The requirement to be sure that these nonfree files aren't unwittingly > relied on by our build processes could be easily achieved by removing > them in clean targets, filtering in dpkg-source, or whatever. I think that, given proper tools, the explicit work of making sure that some non-free files are not used in the build process is equivalent to making sure they are not present in the source package. > If we are worried that users might be misled about the status of these > files, filtering them out in dpkg-source would suffice. That would protect sources.debian.net from publishing these indeed. I still disagree it's sufficient though. > The result would be that the only people who saw them would be people > who are using our archive as a convenient location to fetch the > upstream tarball. I would argue that everyone's freedom is served, > rather than hindered, by having those people come to us for that (as > it is in a similar way for the nonfree archive sections). … besides main is not the non-free archive section. At the risk of repeating myself: I value our promise that Debian will remain 100% free and I want that promise to include our source archives because access to sourcecode is what free software is all about. I'd be saddened by a decision to exempt the source archives from that freeness requirement. Cheers, OdyX P.S. There's no need to CC me, as I can't CC you in return and am subscribed to the list… signature.asc Description: This is a digitally signed message part.
Re: jquery debate with upstream
Le mardi, 11 mars 2014, 19.02:55 Ian Jackson a écrit : > Thomas Goirand writes ("Re: jquery debate with upstream"): > > In one of my package, I had openssl.dll in the source tarball (it > > was of course removed later on). > > > > Would you consider it ok as well to have it in a source package, as > > long as it's not used during the build? And what about a windows > > .exe? Is it different from having a minified .js that is also not > > in use? > Yes, I think all of these things are tolerable, so long as the files > are in fact redistributable (which depending on the licence they might > not be). I disagree: I don't think it's tolerable to ship a .exe freeware [0] in a source package in main, just because it happens to be redistributable; in my reading, considering that the "source package" _is_ a component of the Debian system, doing so violates at least SC§1 and DFSG§2. I don't think there should be a standards' difference between our source and binary packages. That said, the "minified .js" case is slightly different iff it can be proved that it can be recreated from DFSG-free sources, which should then really be actually done in the build phase. Now, if the problem is that "stripping out non-free stuff from upstream archives is boring work", then that's the thing to solve using smart tools rather than bending our standards. Cheers, OdyX [0] And that's without speaking of actively harmful executables… signature.asc Description: This is a digitally signed message part.
Re: Bits from the Security Team
Le lundi, 10 mars 2014, 22.00:09 Christoph Biedl a écrit : > > The problem is that there is no policy in place to make us support > > oldstable-to-testing upgrades. If there's interest, that'd need to > > be decided with a more firm policy than "encourage maintainers". > > Would you have preferred to read something "putting the burden onto > the maintainers"? Re-reading my statement again after hitting the send button made me admit that I didn't express what I intended to… I was trying to say that there is no policy currently in place to ensure that skip-upgrades actually work, and at least one maintainer has already started to cleanup pre-wheezy stuff from his packages [0]. People "encouraging maintainers not to gratuitously break skip-upgrades" on debian-devel is by far not equivalent to a Release Team decision on bug severity for a failure to skip-upgrade for example. Cheers, OdyX [0] I'd be surprised to be the only one, who knows. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/7312246.zXeI0qdFfj@gyllingar
Re: Bits from the Security Team
Le lundi, 10 mars 2014, 13.52:59 Ian Jackson a écrit : > Paul Wise writes ("Re: Bits from the Security Team"): > > Debian doesn't support skipping releases right now and I expect if > > we > > support releases for a longer amount of time that won't change. > > But, in practice, skip upgrades often work anyway. I'd encourage > maintainers not to gratuitously break them. For example, aggressively > removing compatibility code is a bad idea. (It's bad for our > downstreams too). I, for one, have been routinely dropping transitional binary packages that were in the latest stable; they were needed to migrate from (the releases which are now) oldstable to stable but are only archive noise now. Delaying that cleanup for an additional stable release cycle really feels like unnecessary delay, during which we pretend to maintain code that hardly anyone tests. The problem is that there is no policy in place to make us support oldstable-to-testing upgrades. If there's interest, that'd need to be decided with a more firm policy than "encourage maintainers". Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/69734414.qmXaMjuj1O@gyllingar
Re: Bits from keyring-maint: Pushing keyring updates. Let us bury your old 1024D key!
Le mercredi, 5 mars 2014, 10.47:07 Paul Wise a écrit : > On Wed, Mar 5, 2014 at 1:55 AM, Xavier Roche wrote: > > I have a rather silly question: would a mail (signed with this key) > > request to the DDs who already signed the initial key (and checked > > the identity) to sign the replacement key considered unreasonable ? > Considering that the initial keys are now considered weak, I expect > that it would be reasonable for people to not trust a key transition > statement where the only available trust anchor is the old weak key. Well, the project currently considers these old keys to be trustworthy enough to let the people who control them to upload any packages on the archive (modulo these keys are in the uploading keyring). If we trust that the people behind the keys haven't changed, we should let them use easy ways to stronger keys. On the other hand, if we think the keys have been compromised, then we should really drop the upload rights! Cheers, OdyX -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1698122.Pbb9aiM70E@gyllingar
Re: default init on non-Linux platforms
Le jeudi, 20 février 2014, 22.28:56 Thomas Goirand a écrit : > On 02/20/2014 09:02 PM, Tom H wrote: > > What features does sysvinit+openrc have that > > sysvinit+sysv-rc+insserv doesn't have? > > Just to name a few: > - getting rid of the ugly LSB headers They might be ugly, but they encode the dependency tree; by what are they replaced in OpenRC? > - cgroup supports to kill processes On non-Linux ports ? -- OdyX signature.asc Description: This is a digitally signed message part.
Re: default init on non-Linux platforms
Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit : > On 02/18/2014 11:10 PM, Jonathan Dowland wrote: > > On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote: > >> Once I consider OpenRC ready for it, would it be ok to just replace > >> sysv-rc by OpenRC, and transform sysv-rc into a transitional > >> package? > >> What is the opinion of other DDs? Is there anyone which would like > >> to > >> keep the old featureless sysv-rc? > > > > What problem does that solve? > > In this way, we'd have only 2 init systems to take care of, and we > could start replacing init.d scripts by OpenRC runscripts *IF* > there's a systemd service file. Yes. And three different daemon-starting syntaxes to manage the Wheezy- to-Jessie upgrades. Again, for Jessie, I don't think it's reasonable to change the default init _and_ replace the common baseline. I, for one, am not going to replace my awkward-but-working sysvinit scripts by anything but systemd/upstart unit files and that is doomed to happen in jessie+1 [0]. Cheers, OdyX [0] Can we haz a release name? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2536787.IXIK3uYTH8@gyllingar