Bug#809705: general: let people use non-free software but opt-out of non-open software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: > Philippe Cerfon: > > On Sun, Jan 3, 2016 at 7:35 AM, Christian PERRIER > > wrote: > >> Discussing infrastructure changes like what you're proposing (which I > >> have no advice about) should usually be done through our mailing > >> lists, > > Which one would be the appropriate list? debian-project, or hopefully debian-devel. -project for talking about the idea, -devel for discussing an implementation. Having an implementation ready hugely improves chances of it being done. But of course probing the community to see if there are any protests (as you are doing now) is a good idea. > Your second item has been brought up before with different > focus/rationale/purpose. At least I remember there being an interest in > splitting "non-free" into "non-free/firmware" vs. various other non-free > sub components. > > Mind you, its primary goal was not to address "source vs. no-source", > but it is the closest related idea I could think of. Sadly, I don't > have a reference ready to backup my memory. Yes; I think the conclusion of that discussion was two things: 1. Different people want different splits. Using something like debtags may be more useful, so users can block their own tag selection. 2. The firmware category is special in that pretty much everyone needs it, so we may want to make that its own section the old way. This allows people to use their hardware without enabling any (other) non-free sections and without worrying about debtags filters (once implemented). Note that it was just my impression that there was consensus on this; I may be mistaken. Note also that nothing has happened (AFAIK) since that discussion. Someone implementing things would be very welcome as far as I'm concerned. > On your first item, I would have to agree with Christian. It is not > actionable and much less by Debian. At best we could stop packaging > such software or disabling such features, but both have their disadvantages: > > * Even if we stop shipping them, people will still download them. >Except your average user will probably be worse off because most of >them do not verify their downloads. I agree that not shipping things (that we are allowed to ship) is a bad idea most of the time (except if it's because nobody considers it a priority; giving upstream an incentive to release their software under a free license is good). The exception is software that actively hurts the user (malware, spyware). Which we can only block if we know about it, of course. > * If we disable the functionality, we would "cripple" the software to >many people. If this annoys people, we will end up in a situation >where people will advise /against/ using the Debian package because >it is "crippled", which leads to the situation above. Or we could >get badly unpopular with upstream (see the "Debian vs. Ruby" issue >from a couple of years ago). This is a valid concern, but it shouldn't always be the deciding factor. Many people (including me) use Debian because it easily allows installing a 100% free system with a huge choice of packages. If the choice is "move a thing to non-free, or keep it in main and disable the functionality", those people will lose the software completely if it's moved to non-free. Disabling functionality is work, and when it's done, it's done for this group. It leads to "crippled" packages and the complaints you mention, but the alternative is moving it to non-free, which leads to the software missing from Debian main entirely. Either option may be better, depending on the situation. Perhaps it's best to do both, like unrar does (AFAIK): package a "crippled" version in main, and the original version in non-free. But this is even more work, and the maintainer has to decide if it's worth their time. Personally, I don't care much for non-free, so I would choose between disabling the functionality and not packaging the software at all. But that doesn't mean everyone has to work that way; if others want to spend their time on non-free packages, I'm not stopping them. Thanks, Bas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWijfHAAoJEJzRfVgHwHE6J7gP/izcwZPCJ9YvtpDf9FNtDKmA 7Vop3e1wZD2h7G93FY/YvQkufkFQhW9KJp3cIZ2UkCDq6EBt5Of6xtoDEtSWmedV Hi4djop7nIXJxFnzB2/5wMYVLa+DIeRUUhtR8/HkQu2/GCbf1SIbOH3ZjH2SW0Kj BozkqzyQQkFv7t/GK9y34goW6l4oc0CF+vINlRV+iV886C0166Kim1rOBWM8Ctfq JrP9JcfwVBFIVzznK2+6E4/0bCLT1AeRORyfpwIW/QI0+3wmjoECdmA2PRrtTxgD vy1ZNEfAY+BxYIo4XJsSQpE4VTgtYMmnYDuP4IWx9NUlYKVA3jWwjdn4FSim5fRl BqWk9tdY4zmM62WGkqLexwSgeyx2Ozh+zh9Cf4TIVRK5OXmUK3E2VUCA9CvE87pw Dayw3F7ZJX0N5Tpal55DDcBEVHOFFmLgfqHHy80HEM1rgQnwbQE9Z0CrRckhDjIK jQkCaZynCSknB/5iG7eL1U4UiLySmrxNYqCbuU7T5gEY6SABghwCdcFyCwtRttXC Q/4H5bXDw7E/PszsSvaUDe39NsDS9xBDbpgSZ/OhylkhimhwUhtixWaNBCDzC9Tw SLgQaW8TYrAClRzKM+JRBSJM8hTX1R3+CsnS1wVy3em6BRohFO/I8uq+kZZ5007S HnieFjcna9ri4H0UxCwU
Bug#809804: ITP: python-pager -- terminal/console pager module in pure Python
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-pager Version : 3.3 Upstream Author : anatoly techtonik * URL : http://bitbucket.org/techtonik/python-pager * License : Expat Programming Lang: Python Description : terminal/console pager module in pure Python Pager is a Python module that pages output to the screen, reads keys and console dimensions without executing external utils. It was meant to be included in the Python standard library. This is a new OpenStack dependency for the Mesos project (ie: dcos-cli needs it).
Bug#809808: ITP: python-toml -- library for Tom's Obvious, Minimal Language
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-toml Version : 0.9.1 Upstream Author : Uiri Noyb * URL : https://github.com/uiri/toml * License : Expat Programming Lang: Python Description : library for Tom's Obvious, Minimal Language This package provides a Python module which parses and emits TOML. TOML aims to be a minimal configuration file format that's easy to read due to obvious semantics. TOML is designed to map unambiguously to a hash table. TOML should be easy to parse into data structures in a wide variety of languages. This is a dependency for python-docs CLI (ie: Datacenter Operating System), part of the Mesos system (yet another OpenStack component).
Re: support for merged /usr in Debian
On Sun, 03 Jan 2016 10:14:14 -0800, Russ Allbery wrote: >Note that mounting /usr early, something we *already do*, is separate from >actually merging /usr with /bin and /lib. Once you mount /usr early, it's >rather less important whether you actually merge the file systems. While >it does let you do some interesting things, I see it as more of a cleanup. How about being able to umount /usr in the running system for analysis or fixes? I do this once in a while. It is disruptive and can be used from a rescue system, granted, but I would miss that possibility. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On Sun, 3 Jan 2016 22:30:24 +0100, Eric Valette wrote: >System admins do like using absolute path >for security reasons... Please also notice that this is the only option for ExecStart in systemd units. Well played, Lennart. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On Sun, 3 Jan 2016 23:55:08 +0100, Eric Valette wrote: >cannot really accommodate the /etc/defaut/pkg >configurable options... This will get worse, btw, since the systemd community ponders removing the EnvironmentFile option since "all distributions are using it wrong", especially looking upon Debian, saying that system administrators and distributions need to be "educated" about how to use systemd. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On Sun, 3 Jan 2016 22:06:32 +0100, Florian Lohoff wrote: >From my 25 year Unix experience i dont like the usr merge. Agreed. > As you sum >up very nicely and i agree on is that Debian has given up on being >slim at this point. There is no such thing as a single user mode boot >with only the rootfs anymore. And it is a disadvantage of a distributed project like Debian that we have given up on this gradually without thinking about it. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Bug#809705: general: let people use non-free software but opt-out of non-open software
On 2016-01-03 07:35, Christian PERRIER wrote: Quoting Philippe Cerfon (philc...@gmail.com): Package: general Severity: wishlist Tags: security Hi. I think Debian has the following two problems (or rather its security conscious users) with respect to software that gets into the system: No idea whether what you're proposing is relevant or notbut there's something I'm deeply sure of : that won't be solved through a "general" bug report. Such vague bug reports are usually either quickly closedor just ignored by everybody in the project. Well, the messages sent to this bugreport land in debian-devel, which looks appropriate for this kind of discussions, IMHO. Be it a bugreport or a simple message sent to the list, it doesn't look very different. Once discussion happens and we have a clear idea on what is needed to do, we will be able to describe a concrete plan or, aternatively, close the bugreport because nothing is needed to do. The concrete plan could be several bugreports files where appropriate, blocking this one. We do already track discussions in bugreports (Tech-ctte issues for example), even if the initial request might be very vague or quite complicated. Regards, -- Mehdi
Re: support for merged /usr in Debian
On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery
wrote:
>I do understand why people working in the embedded space care about some
>unusual mount orderings, file system separations, and very light cores,
>and I hope that we can accomodate and support all of their use cases
>inside Debian. I think that's the most productive part of this thread.
We have already shown how "much" we care about the users of non-Linux
kernels in Debian ("not at all, they can happily go fishing").
I have no doubt that we're going to do the same thing to embedded
users if we can trade those users for a few seconds per year in
startup time.
And I fear that we're going to lose a few more important contributors
that way.
And we're all doing this to keep our upstreams and Ubuntu happy. Is it
worth this?
>But I don't get why people who are using non-embedded UNIX systems
>particularly care.
I, for example, am afraid of having to merge /usr in existing systems
during upgrades, causing repartitions to be necessary. I am afraid of
partition layout suddenly not fitting any more during an upgrade,
causing downtimes and customers considering to take the opportunity to
migrate to a really supported enterprise distribution.
And, I really don't want to have to adapt, test and verify scripts and
backup schemes to changed partition layout. This will be necessary for
new systems, and it is really a horror vision to have to do this for
existing systems during upgrades.
>If you've used UNIX for a long time, you've seen
>binaries in all sorts of bizarre and irritating locations. This is minor
>compared to the organizational differences between various commercial
>UNIXes back in the day.
I decided for Debian to get rid of this. Now we're planning to cause
this _inside_ Debian.
>> There is no such thing as a single user mode boot with only the rootfs
>> anymore.
>
>Yes, there is. The rootfs just includes /usr.
Which is, in my case, the case for a single-digit number of tiny VMs
in a park of a couple of hundred systems with separate /usr. The
majory of those systems hasn't been reinstalled or even repartitioned
in years. Please don't force me to do that during an upgrade.
>> PS: And i hate giving up on technical issues.
>
>That's the whole thing, though. Maintaining a meaningful /bin and /lib
>vs. /usr split is not primarily a technical issue. It's a coordination
>issue. The technical work for a single package is painful only because
>moving things is really painful. The problem is more that it affects
>thousands of packages maintained by numerous different maintainers who are
>never testing that configuration and may not even be aware that it exists.
And it affects hundreds of thousands of installed systems.
>Another word for "giving up" is "applying sane prioritization." We can't
>fix every wishlist bug. Is this one actually worth the effort?
So it is a wishlist bug to keep things as broken as they were always
been?
Greetings
Marc
--
-- !! No courtesy copies, please !! -
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On Sun, 3 Jan 2016 21:35:39 +0100, Christian Seiler wrote: >So that was the state in February of 2011, when the warning was added >to systemd and the systemd developers recommended the use of the >initrd: mounting /usr from a running system is broken. Either it is >already completely broken in some cases - and for all other cases where >it currently works it is broken maintenance-wise. Declaring something that was the normal use case five years ago as broken is a blatant sign of disrespect for users. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
Marc Haber writes: > On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery > wrote: >>But I don't get why people who are using non-embedded UNIX systems >>particularly care. > > I, for example, am afraid of having to merge /usr in existing systems > during upgrades, causing repartitions to be necessary. I am afraid of > partition layout suddenly not fitting any more during an upgrade, > causing downtimes and customers considering to take the opportunity to > migrate to a really supported enterprise distribution. Are you afraid of your /usr partition being too small to hold the additional binaries from /bin, /sbin and /lib? If that is the case, won't it also be too small for regular distribution upgrades? Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. > And, I really don't want to have to adapt, test and verify scripts and > backup schemes to changed partition layout. This will be necessary for > new systems, and it is really a horror vision to have to do this for > existing systems during upgrades. I wouldn't expect much changes to be needed for backups: if you excluded /bin, /sbin, /lib and /usr, then it would be enough to just exclude /usr in the future. If you included them, they will still be included. Ansgar
Re: support for merged /usr in Debian
On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote: >Anyway, if you think that the merged /usr scheme is about systemd then >you are automatically disqualified from taking part in this discussion >because you are not understanding the basic underlying issues. As friendly as always. -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
MBF Announcement: Transition libpng12 -> libpng16
Dear debian-devel, we are currently planning to start the transition of libpng. The transition bug can be found here: https://bugs.debian.org/650601. Out of the 463 rebuilt packages 117 FTBFS with the new libpng, however not every failure can be attributed to the library. Logs from the rebuild can be found here: http://libpng.sviech.de, as well as a scratchpad with a short analysis: https://titanpad.com/libpng16-transistion Out of those results, mass bug filings will be conducted: - Packages that fail to build with the new libpng - Packages that B-D on ancient libpng3-dev, libpng12-0-dev and (the soon-obsolete) libpng12-dev, asking to update their B-Ds to libpng-dev There are already bugs filed earlier against certain packages: https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libpng15-transition &user=libpng%40packages.debian.org Those bugs will be updated with the new usertag to avoid filing duplicate bugs. The bugs will be non-RC for the time being, when the transition starts the severity will be raised appropriately. The current plan is drafted as: 0. Assess situation (rebuild) -- done 1. Announce MBF (this mail) and execute it. (1a. I'll also try to patches and attach them to the bugs) 2. Nobuhiro to upload to libpng1.6 to unstable. (after "GO" from the release team) 3. Raise severity to RC 4. binNMU / NMUing packgages 5. fix remaining issues to finish transition 6. Remove libpng12 from unstable Those two MBFs are planned: 1. FTBFS 2. B-D on old dev package Templates: Subject: $PACKAGE: FTBFS with new libpng16 Severity: important User: lib...@packages.debian.org Usertags: libpng16-transition Dear maintainer of $PACKAGE, Currently we are preparing the transistion of libpng1.2 to libpng1.6. The transistion bug is #650601. A rebuilt of all packages depending on libpng-dev and libpng12-dev has been done. The result with buildlogs can be found here: https://libpng. sviech.de/ $PACKAGE FTBFS during this rebuild. The buildlog is available at https://libpng.sviech.de/$PACKAGE.build The Titanpad at https://titanpad.com/libpng16-transistion might gives y ou clues about what went wrong as well as contains some recipes/pointers how to fix them. Please try to make $PACKAGE compatible with libpng16 and then make sure to B-D on libpng-dev only, if the fix makes it possible to compile it against libdev12 and libdev16. If you can only make in a non-backward compatible way, please B-D on libpng16-dev. This bug will become RC as soon as the transistion starts. Best regards, -- tobi # Case 2: B-D not libpng-dev Subject: $PACKAGE: Please update dependency on libpng-dev Severity: important User: lib...@packages.debian.org Usertags: libpng16-transition Dear maintainer of $PACKAGES, Currently we are preparing the transistion of libpng1.2 to libpng1.6. The transistion bug is #650601. A rebuild of all packages depending on libpng-dev and libpng(3,12,12- 0)-dev has been done. The result with buildlogs can be found here: http://libpng.sviech.de/ $PACKAGE (build-)depends an versioned development package (libpng-??.dev), however it seems to build fine also with the new libpng-1.6. Therefore please update your (build-)depends to libpng-dev to help in the transition. This bug will become RC as soon as the transistion starts, as it is planned to remove libpng12. Thanks! -- tobiChristian T. Steigies hp2xx Debian QA Group mgp Debichem Team pymol Michael Banck pymol (U) Ansgar Burchardt xaos (U) Debian FlightGear Crew flightgear Debian Games Team xaos Kari Pahula crossfire-client Markus Wanner flightgear (U) Ove Kaaven flightgear (U) Adam Majer mrtg (U) Alan Bain xnecview Alastair McKinstry cdo emoslib ncl Alessio Treglia camorama (U) harvid (U) Alexander Reichle-Schmehl netpanzer (U) Alexander Wirt icinga (U) Andreas Barth netpbm-free Andreas Henriksson gdk-pixbuf (U) Andreas Metzler enblend-enfuse (U) hugin (U) libpano13 (U) Andreas Rönnquist allegro5 (U) Andrei Karas manaplus Android tools Maintainer android-platform-frameworks-base Ansgar Burchardt simutrans (U) Aurelien Jarno qemu (U) Axel Beckert dillo Balint Reczey kodi (U) Barry deFreese netpanzer (U) Barry deFreese clanlib (U) Bret Curtis openmw Carlo Segre libpgplot-perl (U) Chris Halls libreoffice (U) Chris Vanden Berghe metapixel Clint Adams simutrans (U) Clint Adams simutrans (U) Colin Tuckley libzia (U) Darren Salt libwebp (U) pngmeta David Martínez Moreno hhvm (U) David Paleino gambas3 (U) David Stone photoprint Debian Astronomy Maintainers astrometry.net Debian Astronomy Team yt Debian Electronics Team gerbv Debian Flash Team swfmill Debian FlightGear Crew flightgear Debian freesmartphone.org Team literki Debian Games Team allegro5 chocolate-doom clanlib colobot netpanze
Re: support for merged /usr in Debian
On Mon, 04 Jan 2016 12:01:46 +0100, Ansgar Burchardt wrote: >Marc Haber writes: >> On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery >> wrote: >>>But I don't get why people who are using non-embedded UNIX systems >>>particularly care. >> >> I, for example, am afraid of having to merge /usr in existing systems >> during upgrades, causing repartitions to be necessary. I am afraid of >> partition layout suddenly not fitting any more during an upgrade, >> causing downtimes and customers considering to take the opportunity to >> migrate to a really supported enterprise distribution. > >Are you afraid of your /usr partition being too small to hold the >additional binaries from /bin, /sbin and /lib? If that is the case, >won't it also be too small for regular distribution upgrades? I don't know yet. >Remember that / and /usr don't have to reside on the same partition with >the usrmerge proposal: they only have to be both available >post-initramfs. The initramfs already takes care to mount /usr (for the >systemd case as initscripts needs updates for sysvinit as was said >elsewhere). So no repartitioning should be required on upgrades. I'd like to have a positive confirmation that systemd upstream intends to continue supporting this scheme and that Debian will also. Otherwise, there is always the possiblity that systemd upstream will condemn our setup "broken" and goes out to "educate" us how to "properly" run a "modern" Linux system by removing support for things that have always worked in the past. >> And, I really don't want to have to adapt, test and verify scripts and >> backup schemes to changed partition layout. This will be necessary for >> new systems, and it is really a horror vision to have to do this for >> existing systems during upgrades. > >I wouldn't expect much changes to be needed for backups: if you excluded >/bin, /sbin, /lib and /usr, then it would be enough to just exclude /usr >in the future. If you included them, they will still be included. Think some backup system that backs up every file system by its own and runs with directives to stay on the file system. There is ample possibility to error out when a backed-up file system suddenly goes out of existence with an upgrade, or that some part of the file system is inadvertently excluded from the backup when the file system layout is severely "modernized" during a system upgrade. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: MBF Announcement: Transition libpng12 -> libpng16
* Tobias Frost , 2016-01-04, 12:02: Logs from the rebuild can be found here: http://libpng.sviech.de, as well as a scratchpad with a short analysis: https://titanpad.com/libpng16-transistion Plain-text version for people who don't enjoy running non-free JS code: https://titanpad.com/ep/pad/export/libpng16-transistion/latest Currently we are preparing the transistion of libpng1.2 to libpng1.6. s/transistion/transition/ (here and in other places) been done. The result with buildlogs can be found here: https://libpng. sviech.de/ URLs work better when they're not line-wrapped. :) The Titanpad at https://titanpad.com/libpng16-transistion might gives y ou clues about what went wrong as well as contains some s/gives/give/ s/y\nou/you/ -- Jakub Wilk
Re: Failed to stop defining RPATH in libncl
On 04/01/16 11:40, Andreas Tille wrote: Hi, I'm trying to package libncl[1] but I failed to fight the following lintian error: E: ncl-tools: binary-or-shlib-defines-rpath usr/bin/NCLconverter /usr/lib/x86_64-linux-gnu/ncl I deactivated my quilt patches and the override_dh_auto_configure since nothing really helped. Any hint would be welcome. Kind regards Andreas. [1] git://anonscm.debian.org/debian-med/libncl.git Hm... don't know the Debian docs that well, but Fedora has some info on [2]. Basically, you should be able to add something like that in a dh_ override. The debian GL seems to be in [3]; they look similar. --Cheers! -alec [2] https://fedoraproject.org/wiki/Packaging:Guidelines#Removing_Rpath [3] https://wiki.debian.org/RpathIssue
Re: Failed to stop defining RPATH in libncl
Hi Alec, please do not move the thread from debian-mentors to debian-devel. For those reading here and are interested to answer do this on debian-mentors where it belongs to. On Mon, Jan 04, 2016 at 12:37:59PM +0100, Alec Leamas wrote: > > > >Andreas. > > > >[1] git://anonscm.debian.org/debian-med/libncl.git > > > Hm... don't know the Debian docs that well, but Fedora has some info on [2]. > Basically, you should be able to add something like that in a dh_ override. > The debian GL seems to be in [3]; they look similar. Thanks for your attempt to help but these links are clear. I simply failed to implement a dh_override / patch since the means that were usually helpful failed and thus was asking for help. Kind regards Andreas. > [2] https://fedoraproject.org/wiki/Packaging:Guidelines#Removing_Rpath > [3] https://wiki.debian.org/RpathIssue -- http://fam-tille.de
Bug#694308: non-DFSG postscript embedded in fontforge
On Fri, 1 Jan 2016 14:07:46 +0100 Bastien ROUCARIES wrote: >>No, it will help me on the lintian to get not rebuilt at build time fonts... >> >>Best will be to add a timestamp but i think it destroy reproductible >>build step, so if timestamp could be >>overriden by an env variable (so it could be set to last changelog >>entry timestamp) and disable by a command line flags it will be good. Excuse me, but I didn't get it. What you would want to check with lintian? Could you explain it more a bit, please? # As you say, just adding timestamp will break reproducibility. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane
Re: MBF Announcement: Transition libpng12 -> libpng16
Le 4 janvier 2016 12:02:00 GMT+01:00, Tobias Frost a écrit : >Dear debian-devel, > >we are currently planning to start the transition of libpng. >The transition bug can be found here: >https://bugs.debian.org/650601. > >Out of the 463 rebuilt packages 117 FTBFS with the new libpng, however >not every failure can be attributed to the library. > >Logs from the rebuild can be found here: http://libpng.sviech.de, as >well as a scratchpad with a short analysis: >https://titanpad.com/libpng16-transistion > >Out of those results, mass bug filings will be conducted: >- Packages that fail to build with the new libpng >- Packages that B-D on ancient libpng3-dev, libpng12-0-dev and (the >soon-obsolete) libpng12-dev, asking to update their B-Ds to libpng-dev > >There are already bugs filed earlier against certain packages: >https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=libpng15-transition >&user=libpng%40packages.debian.org >Those bugs will be updated with the new usertag to avoid filing >duplicate bugs. > >The bugs will be non-RC for the time being, when the transition starts >the severity will be raised appropriately. > >The current plan is drafted as: > >0. Assess situation (rebuild) -- done >1. Announce MBF (this mail) and execute it. >(1a. I'll also try to patches and attach them to the bugs) >2. Nobuhiro to upload to libpng1.6 to unstable. (after "GO" from the >release team) >3. Raise severity to RC >4. binNMU / NMUing packgages >5. fix remaining issues to finish transition >6. Remove libpng12 from unstable > >Those two MBFs are planned: > >1. FTBFS >2. B-D on old dev package Add also bug to package using embeded libpng 1.6 like texlive ? > >Templates: > >Subject: $PACKAGE: FTBFS with new libpng16 >Severity: important >User: lib...@packages.debian.org >Usertags: libpng16-transition > >Dear maintainer of $PACKAGE, > >Currently we are preparing the transistion of libpng1.2 to libpng1.6. >The transistion bug is #650601. > >A rebuilt of all packages depending on libpng-dev and libpng12-dev has >been done. The result with buildlogs can be found here: https://libpng. >sviech.de/ > >$PACKAGE FTBFS during this rebuild. The buildlog is available at >https://libpng.sviech.de/$PACKAGE.build > >The Titanpad at https://titanpad.com/libpng16-transistion might gives y >ou clues about what went wrong as well as contains some >recipes/pointers how to fix them. > >Please try to make $PACKAGE compatible with libpng16 and then make sure >to B-D on libpng-dev only, if the fix makes it possible to compile it >against libdev12 and libdev16. If you can only make in a non-backward >compatible way, please B-D on libpng16-dev. > >This bug will become RC as soon as the transistion starts. > >Best regards, >-- >tobi > ># Case 2: B-D not libpng-dev > >Subject: $PACKAGE: Please update dependency on libpng-dev >Severity: important >User: lib...@packages.debian.org >Usertags: libpng16-transition > >Dear maintainer of $PACKAGES, > >Currently we are preparing the transistion of libpng1.2 to libpng1.6. >The transistion bug is #650601. > >A rebuild of all packages depending on libpng-dev and libpng(3,12,12- >0)-dev has been done. >The result with buildlogs can be found here: http://libpng.sviech.de/ > >$PACKAGE (build-)depends an versioned development package >(libpng-??.dev), however it seems to build fine also with the new >libpng-1.6. Therefore please update your (build-)depends to libpng-dev >to help in the transition. > >This bug will become RC as soon as the transistion starts, >as it is planned to remove libpng12. > >Thanks! > >-- >tobi -- Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.
Re: support for merged /usr in Debian
On 01/04/2016 11:41 AM, Marc Haber wrote:
> On Sun, 03 Jan 2016 13:28:14 -0800, Russ Allbery
> wrote:
>> I do understand why people working in the embedded space care about some
>> unusual mount orderings, file system separations, and very light cores,
>> and I hope that we can accomodate and support all of their use cases
>> inside Debian. I think that's the most productive part of this thread.
>
> We have already shown how "much" we care about the users of non-Linux
> kernels in Debian ("not at all, they can happily go fishing").
So why aren't you on the list of porters for either Hurd of kFreeBSD?
https://release.debian.org/stretch/arch_qualify.html
(Hover over the number of porters to get a list of names.)
The main concern for kFreeBSD w.r.t. Jessie was manpower. The kFreeBSD
porters have a right to complain about a lack of interest, but you
certainly don't.
You could also say the same (not caring about them) of HA users: Jessie
has no Pacemaker, because nobody cared about that during the Jessie
release cycle. It was completely broken at that point and thus removed
from the release. The current recommendation for HA users is to stick
with Wheezy for now. When more people realized that, people complained
that that sucked - but instead of just complaining and complaining and
complaining constantly, there are now (new) people working on the HA
stack for Debian, because they saw that there should be work put into
it - and I'm quite confident that Stretch will have a very well
supported HA stack again. (Shout out and thanks to the people working
on that btw!)
> I have no doubt that we're going to do the same thing to embedded
> users if we can trade those users for a few seconds per year in
> startup time.
Please don't warm up the tired old systemd discussions with cheap
polemics. It doesn't help your cause.
> And we're all doing this to keep our upstreams and Ubuntu happy.
Have you read *any* of the technical arguments in this thread?
(Btw. Ubuntu does NOT have UsrMerge. Ubuntu switched to systemd AFTER
Debian decided to use systemd as default.)
Btw. Is Debian there to mindlessly follow RedHat or Ubuntu? It would be
_very_ helpful if people could make up their mind on this, it's very
confusing to me...
> I, for example, am afraid of having to merge /usr in existing systems
> during upgrades, causing repartitions to be necessary. I am afraid of
> partition layout suddenly not fitting any more during an upgrade,
> causing downtimes and customers considering to take the opportunity to
> migrate to a really supported enterprise distribution.
Sorry, but this is bogus, because this is a problem you have on every
every upgrade. In the past I've already had to repartition systems
because / had become too small, because the amount of software required
to be there had grown (to support more storage solutions for mounting
/usr) and also the kernel modules had grown.
Statistics:
deboostrap of lenny (via archive.d.o) + kernel:
313 MiB in total, 99 MiB on /usr => 214 MiB on /
debootstrap of jessie + kernel:
618 MiB in total, 203 MiB on /usr => 415 MiB on /
And that's just ONE kernel, if you upgrade you usually have additional
kernels lying around. Plus I didn't install a lot of other utilities
that are present on many systems, this is really minimal.
So let's say you installed lenny and had 512 MiB for / (with separate
/usr) because you thought back then that it was more than enough (more
than double the installed size) - and upgrade to Jessie will either run
out of disk space or come very close to it. If you also separate out
/var the numbers game changes a bit, but the principle remains.
Also, the amount of space software requires on /usr is larger on
Jessie - so even if your / partition is large enough, /usr might
already be too small un upgrades.
I've also had the case multiple times where the space I allocated for
/boot wasn't enough: I remember that 15 years ago I used to allocate
32 MiB or so for /boot, and that was *plenty* enough for it (kernel
image around 1-2 MiB, initrd the same, so typically 10 MiB or so used
with ~ 2 kernels insetalled) - but that is simply not true anymore and
/boot (if you separate it) should now be probably sized to ~ 256 MiB
to accomodate current kernels and initrds... (Unless you compile your
kernel by yourself and tailor it to your hardware, then you can get
away with far less.) OTOH, 256 MiB for /boot is nothing if you look at
current storage sizes, so it's not like the current requirements are
inherently unreasonable.
I can also remember a time nearly twenty years ago when I copied the
entire source code of KDE onto three (maybe four) 1.44 MiB floppy
drives with tar. Good luck doing that with even minimalistic DEs
nowadays. ;-) (Good luck finding a floppy drive nowadays. ;-))
It's always been a fact that upgrades might require repartitioning, and
this has nothing to do with UsrMerge. UsrMerge might cause some people
to already repartition one Debian
Re: MBF Announcement: Transition libpng12 -> libpng16
Hi Sebastien, Am Montag, den 04.01.2016, 12:00 + schrieb Bastien Roucaries: > > > Add also bug to package using embeded libpng 1.6 like texlive ? Thanks for the hint, I frankly forgot to check for code copies. Yes, I guess the security team would be happy to drop embedded code copies or at upgrade also to a newer version. I guess I'll drop Norbert a line for now to make him aware of the libpng transistion... (CC'ed) -- tobi
Re: support for merged /usr in Debian
On 01/04/2016 12:15 PM, Marc Haber wrote: > On Mon, 04 Jan 2016 12:01:46 +0100, Ansgar Burchardt >> Remember that / and /usr don't have to reside on the same partition with >> the usrmerge proposal: they only have to be both available >> post-initramfs. The initramfs already takes care to mount /usr (for the >> systemd case as initscripts needs updates for sysvinit as was said >> elsewhere). So no repartitioning should be required on upgrades. > > I'd like to have a positive confirmation that systemd upstream intends > to continue supporting this scheme and that Debian will also. Separate partitions mounted in the initramfs? The whole reason for the UsrMerge is to make a separate /usr filesystem more interesting - see the things in the proposal itself and what I've reiterated in [1]. And the systemd developers are actively interested in things such as stateless systems or sharing /usr in containers etc. Also, just from a technical perspective: systemd is also designed to work in containers, where filesystems are often already pre-mounted to their respective locations. So systemd must already cope with the fact that when it's started some mounts may already be present. If you couple that with the idea that the initrd mounts /usr, then it is trivially true that /usr can be separate, as long as it's already mounted before systemd is executed. That will hold true even IF systemd developers decide to drop support for mounting /usr from a running system. I'm not saying that somebody couldn't break that scenario if they tried really hard, but from a technical perspective. Regards, Christian [1] https://lists.debian.org/debian-devel/2016/01/msg00106.html signature.asc Description: OpenPGP digital signature
Re: MBF Announcement: Transition libpng12 -> libpng16
Hi Tobias, > I guess I'll drop Norbert a line for now to make him aware > of the libpng transistion... (CC'ed) Oh, I would be more than happy to have libpng16 in unstable!!! I can rebuild texlive-bin at any time with system-libpng, just need a working copy. But first I need the other libs being rebuilt (freetype, poppler, libgs at least is my guess) Please send a bug report on src:texlive-bin, if possible. Thanks Norbert PREINING, Norbert http://www.preining.info JAIST, Japan TeX Live & Debian Developer GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
Re: MBF Announcement: Transition libpng12 -> libpng16
On 04/01/16 12:50, Tobias Frost wrote: > Am Montag, den 04.01.2016, 12:00 + schrieb Bastien Roucaries: >> Add also bug to package using embeded libpng 1.6 like texlive ? > > Thanks for the hint, I frankly forgot to check for code copies. https://lintian.debian.org/tags/embedded-library.html and https://anonscm.debian.org/viewvc/secure-testing/data/embedded-code-copies?view=co might be useful, although the latter seems to be outdated (it says libtk-img embeds libpng, which is no longer true). Is there a newer security team list somewhere? In addition to texlive: chromium and ice* might be able to move from their embedded copies to a newer system copy, or not, depending whether they've patched them. I think eagle contains forks of its various libraries, but I could be wrong. It probably needs adding to the embedded code copies list multiple times? syslinux (and the copy of it in d-i) runs at a level below Linux, so the system copy of libpng is not useful. If syslinux is parsing anything untrusted then you have much larger problems than libpng, so an outdated libpng is presumably not really a problem. xserver-xorg-video-nvidia* are presumably unfixable (proprietary binaries). S
Re: support for merged /usr in Debian
On 01/04/2016 11:44 AM, Marc Haber wrote: > On Sun, 3 Jan 2016 21:35:39 +0100, Christian Seiler > wrote: >> So that was the state in February of 2011, when the warning was added >> to systemd and the systemd developers recommended the use of the >> initrd: mounting /usr from a running system is broken. Either it is >> already completely broken in some cases - and for all other cases where >> it currently works it is broken maintenance-wise. > > Declaring something that was the normal use case five years ago as > broken is a blatant sign of disrespect for users. Ok, so when Wheezy came around, 5 years before that a normal use case for init scripts was to have a fixed start/stop priority that was used when calling update-rc.d - and in Wheezy (this was pre-systemd!) the update-rc.d implementation completely ignores the start/stop priorities and says it only does dependency-based boot now (it shows a warning if priorities are still specified). Is that also a blatant sign of disrespect for users? With your argumentation you could argue that ANY change is a blatant disrespect for users. I'm really curious: what's your solution? I've provided lots of arguments (which you completely ignored in my previous email) why the current state of things is broken. You can say "this sucks", but how does that help? Diagnosis: mounting /usr from / doesn't work properly - things constantly break and the past has shown that it is not possible to sanely (!) maintain that setup. You might not like that diagnosis, just as you'd probably not like a diagnosis of appendicitis (because then you'd need an operation), but the diagnosis hold regardless. Now what do do about it? You seem to be suggesting that people should try to maintain the current state of affairs regardless. There's ample evidence that that simply won't work. Any other ideas? Suggestion by other people: ok, so we still want to support a separate /usr partition, so what do we do now? Oh yes, we just mount it already in the initrd, because that already has support for mounting filesystems (such as the root filesystem). Now people can still have their separate partitions but we don't have to support the use case of mounting /usr from / anymore. Plus: if we do that, we get a exciting possibilities, because we can just put everything in /usr, which is what the UsrMerge is all about, so we can actually make lemonade from those lemons. Response: well, in some cases a full-blown initrd is not an option. I respond in this thread with providing a 300 LoC PoC for a minimalistic initrd that's *reall* small. I ask people who have been complaining here whether this would address their concerns. What do I get? Silence. The only responses I got are from people who aren't affected by this. So really, what would you suggest? How would you solve this issue? I have yet to read anything from the nay-sayers in this thread that is both constructive AND addresses the problems identified. Regards, Christian signature.asc Description: OpenPGP digital signature
Re: MBF Announcement: Transition libpng12 -> libpng16
Am 04.01.2016 um 14:06 schrieb Simon McVittie: > In addition to texlive: > > chromium and ice* might be able to move from their embedded copies to a > newer system copy, or not, depending whether they've patched them. Happily Icedove isn't using here a embedded version of libpng, that's a little bit surprising. :-) The configure check simply searches for two functions: > 3636 if test -z "$PNG_DIR" -o "$PNG_DIR" = no; then > 3637 MOZ_NATIVE_PNG= > 3638 else > 3639 AC_CHECK_LIB(png, png_get_valid, [MOZ_NATIVE_PNG=1 > MOZ_PNG_LIBS="-lpng"], > 3640 AC_MSG_ERROR([--with-system-png requested but no > working libpng found])) > 3641 AC_CHECK_LIB(png, png_get_acTL, , > 3642 AC_MSG_ERROR([--with-system-png won't work because the > system's libpng doesn't have APNG support])) > 3643 fi I guess that shouldn't provoke errors with the new libpng version. -- Regards Carsten Schoenert
Re: Re: support for merged /usr in Debian
Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. As explained elsewhere in this thread, using initramfs is still not mandatory in debian and I personally have more managed debian system installed without it than with it. And the fact that /usr break may require user interaction is not really handled by initramfs and may cause dangling sysmlink in / -- eric
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
Le 22/12/2015 00:38, Mehdi Dogguy a écrit : >> The change done in unison 2.48 to overcome this looks pretty big... I'm >> not sure I'll be able/willing to provide a unison2.40.102 any more. >> Moreover, this package was created to provide compatibility with >> previous Debian releases, but another change in OCaml 4.02 makes it >> incompatible anyway (both communicating unisons need to be compiled with >> the same version of OCaml in practice, which won't be the case any more >> when one side is Debian stable, and the other Debian testing). IMHO, >> that's a design flaw in Unison that cannot be easily fixed. >> > > A possible way out for stable (and old-stable) users could be to use 2.48 > from backports, when 2.48 will be packaged and migrated to testing. No, 2.48 from backports will be compiled with stable's version of OCaml (4.01.0) whereas 2.48 from testing will (eventually) be compiled with testing's version of OCaml (4.02.3), making both versions incompatible. Personally, what I do when dealing with inter-release synchronization involves using schroot... I heard of people copying binaries around, and others recompiling unison locally on one system. I don't know which solution is the best. The situation sucks. Cheers, -- Stéphane
Re: Bug#807019: tracking bin-num - broken unison due to binnmu upload
On 2016-01-04 17:24, Stéphane Glondu wrote: Le 22/12/2015 00:38, Mehdi Dogguy a écrit : The change done in unison 2.48 to overcome this looks pretty big... I'm not sure I'll be able/willing to provide a unison2.40.102 any more. Moreover, this package was created to provide compatibility with previous Debian releases, but another change in OCaml 4.02 makes it incompatible anyway (both communicating unisons need to be compiled with the same version of OCaml in practice, which won't be the case any more when one side is Debian stable, and the other Debian testing). IMHO, that's a design flaw in Unison that cannot be easily fixed. A possible way out for stable (and old-stable) users could be to use 2.48 from backports, when 2.48 will be packaged and migrated to testing. No, 2.48 from backports will be compiled with stable's version of OCaml (4.01.0) whereas 2.48 from testing will (eventually) be compiled with testing's version of OCaml (4.02.3), making both versions incompatible. Oh, my understanding was that newer versions of Unison were not bound on an OCaml version anymore and have had worked a synchronization format which will work well with any OCaml version. Sorry if this is not the case. Personally, what I do when dealing with inter-release synchronization involves using schroot... I heard of people copying binaries around, and others recompiling unison locally on one system. I don't know which solution is the best. The situation sucks. It is possible to backport OCaml 4.02.3 (and lablgtk2 :-/) and use that from backports to build a compatible version of Unison. I realize this is a lot of work though. Regards, -- Mehdi
Re: Re: support for merged /usr in Debian
Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. As explained elsewhere in this thread, using initramfs is still not mandatory in debian and I personally have more managed debian system installed without it than with it. And the fact that /usr break may require user interaction is not really handled by initramfsand may cause dangling sysmlink in / -- eric
Bug#809857: ITP: django-python3-ldap -- Django LDAP user authentication backend
Package: wnpp Severity: wishlist Owner: Michael Fladischer -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 * Package name: django-python3-ldap Version : 0.9.8 Upstream Author : Dave Hall * URL : https://github.com/etianen/django-python3-ldap * License : BSD-3-clause Programming Lang: Python Description : Django LDAP user authentication backend django-python3-ldap provides a Django LDAP user authentication backend for Python. It uses the pure Python ldap3 library for all LDAP related operations. This makes it easier to deploy instead of solutions that depend on the OpenLDAP library. . It provides the following features: * Authenticate users with an LDAP server. * Sync LDAP users with a local Django database. * Supports custom Django user models. -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCgAGBQJWir5fAAoJEGlMre9Rx7W2RZoP/0Hsu71JJnDCDCAzLfjfSFgs xQiojeCit/uDVJSP7i6ItaJhhaZFyqdD7M58/s47kOeGodYsJepoDh5P9xoi2+pe iC+ovEMCLUMSfTWViqqilZuAIfveVbdzBwy+QOD1tnYtL5/mEfvyHxtinIrRpIA4 BTrtQtPgJqy7Ow0BHdyTyU5Epz46Cmxa1lLLmPpr1DiQwd/QIQ6yxbgCdt51Itfq tjcPyeAw37I4QDGKefCfLkjv0ibTtYfKVFeKvTCqJZKtjsJ0j39FuOLoi4W8abZe GoUTXcH1X7d1bDKb8ZAbRZXNR9BukGLLU54JtJdkgvQPck0EcVfqxsyM28FjSdvS f+gcrnbCFYqNCu2D8rcnk5pdPZ9gHoWkWsa6IwfPPCnxqRUrhIebOA7Vq4rhRpAF bFAt3Wk2KMPK20roJNBgv2mi+q9FrSmd5INWLpGdPMq2dNI4774/YpK3nPWSRvHS mY6ocaIaCkzjG0woUR3UQKbPO+9oA5B3DDat6jBhi5zfK4aFcXgLyrygNmGWlZyV rA7/ZV99sdiwZteij49J7cvGgNwYPglgRVCal/afwGLSrayWOCZP3qzKsQAHtNwV Sri+SlmN12WNnZSUl3I0kmFvqy3ppISxulclguqHz5w9SbmStXRN7mPxcYBXAaxC dgKRVG+TjP9kczjfpXJc =/v0T -END PGP SIGNATURE-
Re: support for merged /usr in Debian
Am 04.01.2016 um 19:12 schrieb Eric Valette: >> Remember that / and /usr don't have to reside on the same partition with >> the usrmerge proposal: they only have to be both available >> post-initramfs. The initramfs already takes care to mount /usr (for the >> systemd case as initscripts needs updates for sysvinit as was said >> elsewhere). So no repartitioning should be required on upgrades. > As explained elsewhere in this thread, using initramfs is still not > mandatory in debian an initramfs is not mandatory as long as you don't have /usr on a separate partition. No initramfs + split /usr is not supported and has been broken for a while. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On 2016-01-04 12:03:07, Marc Haber wrote: > On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote: > >Anyway, if you think that the merged /usr scheme is about systemd then > >you are automatically disqualified from taking part in this discussion > >because you are not understanding the basic underlying issues. > > As friendly as always. Friendly? Maybe not. But correct? Yes. iustin
Bug#809923: ITP: nordlicht -- a C library that creates moodbars from video files
Package: wnpp Severity: wishlist Owner: "Peter Spiess-Knafl" * Package name: nordlicht Version : 0.4.2 Upstream Author : Sebastian Morr * URL : https://github.com/nordlicht/nordlicht * License : GPL-2+ Programming Lang: C Description : a C library that creates moodbars from video files The tool creates colorful video barcodes, which can be used for navigation within the video. nordlicht converts video files into colorful barcodes. It's heavily inspired by the "moviebarcode" tumblr. It takes the video's frames in regular intervals, scales them to 1px width, and appends them. The resulting barcodes can be integrated into video players for simplified navigation. There is no package yet in the archives which provides similar functionality. I haven't found a suitable maintainer group yet, therefore I plan to maintain it on my own for now. If anybody wants to take the package into a team, I am very happy about that.
Bug#809925: RFA: neotoma -- parser generator for Erlang
Package: wnpp Severity: normal Description-en: parser generator for Erlang Neotoma is a packrat parser-generator for Erlang for Parsing Expression Grammars (PEGs). It consists of a parsing-combinator library with memoization routines, a parser for PEGs, and a utility to generate parsers from PEGs. It is inspired by treetop, a Ruby library with similar aims, and parsec, the parser-combinator library for Haskell. . Features include: - Simple, declarative parsers generated from even simpler grammars. - Fully integrated, single-pass lexical and syntactic analysis (a feature of PEGs). - Packrat-style memoization, boasting parse-time bound linearly to the input size (at the expense of memory usage). - In-place semantic analysis/transformation, supporting single-pass end-to-end in some applications. - Erlang code-generation for the lexical/syntactic analysis piece, with the option of semantic analysis/transformation inline, or in a separate module. - Line/column number tracking for easy resolution of parsing errors. I'm no longer using this. If nobody picks it up within a reasonable time I'll ask to have it removed from the archive. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Bug#809705: general: let people use non-free software but opt-out of non-open software
On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: > Your second item has been brought up before with different > focus/rationale/purpose. At least I remember there being an interest > in splitting "non-free" into "non-free/firmware" vs. various other > non-free sub components. Another one that is worth mentioning here --- which I discussed in the context of non-free.org with Dafydd Harries and others --- is introducing a debtags facet to capture the reason why a package is in non-free. At least two hierarchies come to mind: 1) which point of DFSG is not respected, and 2) which one of the 4 freedoms are not granted. I've had on my TODO list proposing the relevant debtags facets since at least 2 years, but never found the time to actually do that. This is a very actionable item: it is enough to follow the procedure for proposing a new debtags. (Procedure that I cannot find right now, but IIRC it includes coming up with a list of tag names + a list of at least N packages, with N relatively low, that are already in the archive and that would carry each tag.) Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On 04/01/2016 20:43, Michael Biebl wrote: an initramfs is not mandatory as long as you don't have /usr on a separate partition. No initramfs + split /usr is not supported and has been broken for a while. Did you actually test it? It works for me TM on fairly simple setup... -- eric
Re: support for merged /usr in Debian
On 2016-01-04 23:41:40, Eric Valette wrote: > On 04/01/2016 20:43, Michael Biebl wrote: > > >an initramfs is not mandatory as long as you don't have /usr on a > >separate partition. > >No initramfs + split /usr is not supported and has been broken for a while. > > Did you actually test it? It works for me TM on fairly simple setup... That's the key point - "on a fairly simple setup". You don't know when it will break - at which point the setup becomes complex enough that some library actually needed lives in /usr instead of /, and you can't boot anymore without going into rescue/emergency mode. The whole point of UsrMerge is to _guarantee_ that booting works on _all_ setups, and to reduce the maintenance burden at the same time. regards, iustin signature.asc Description: PGP signature
Re: MBF Announcement: Transition libpng12 -> libpng16
Am Montag, den 04.01.2016, 12:02 +0100 schrieb Tobias Frost: For those want to test against libpng1.6: Note that the libpn16 package in experimental does NOT Provide libpng- dev at the moment. As I've hacked something together for my rebuild, you can grab the dsc here: https://libpng.sviech.de/libpng_package_used/libpng1.6_1.6.19-1.dsc -- tobi signature.asc Description: This is a digitally signed message part
Re: support for merged /usr in Debian
On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote: > Am 04.01.2016 um 19:12 schrieb Eric Valette: > >> Remember that / and /usr don't have to reside on the same partition with > >> the usrmerge proposal: they only have to be both available > >> post-initramfs. The initramfs already takes care to mount /usr (for the > >> systemd case as initscripts needs updates for sysvinit as was said > >> elsewhere). So no repartitioning should be required on upgrades. > > As explained elsewhere in this thread, using initramfs is still not > > mandatory in debian > > an initramfs is not mandatory as long as you don't have /usr on a > separate partition. > No initramfs + split /usr is not supported and has been broken for a while. I guess you meant "with systemd". It does works with any other init system. -- A tit a day keeps the vet away.
Re: support for merged /usr in Debian
Am 05.01.2016 um 01:17 schrieb Adam Borowski: > On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote: >> Am 04.01.2016 um 19:12 schrieb Eric Valette: Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. >>> As explained elsewhere in this thread, using initramfs is still not >>> mandatory in debian >> >> an initramfs is not mandatory as long as you don't have /usr on a >> separate partition. >> No initramfs + split /usr is not supported and has been broken for a while. > > I guess you meant "with systemd". Nice try, but no. Those issues are not specific to systemd. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop wrote: >On 2016-01-04 12:03:07, Marc Haber wrote: >> On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote: >> >Anyway, if you think that the merged /usr scheme is about systemd then >> >you are automatically disqualified from taking part in this discussion >> >because you are not understanding the basic underlying issues. >> >> As friendly as always. > >Friendly? Maybe not. But correct? Yes. Being right and unfriendly drives friends and users away. This attitude is doing harm to Debian. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: support for merged /usr in Debian
On 01/05/2016 01:17 AM, Adam Borowski wrote: > On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote: >> Am 04.01.2016 um 19:12 schrieb Eric Valette: Remember that / and /usr don't have to reside on the same partition with the usrmerge proposal: they only have to be both available post-initramfs. The initramfs already takes care to mount /usr (for the systemd case as initscripts needs updates for sysvinit as was said elsewhere). So no repartitioning should be required on upgrades. >>> As explained elsewhere in this thread, using initramfs is still not >>> mandatory in debian >> >> an initramfs is not mandatory as long as you don't have /usr on a >> separate partition. >> No initramfs + split /usr is not supported and has been broken for a while. > > I guess you meant "with systemd". It does works with any other init system. It also "works" with systemd (the same as with other init systems), you can just try it in a VM if you like. (Compile your own kernel, change your block device driver + your root filesystem driver from module to compiled-in, have a separate /usr partition and boot an otherwise default Jessie system with systemd - it will boot and mount /usr.) Which binary is run as PID 1 has never been the issue, both sysvinit and systemd support /usr not being mounted at the beginning. The problem is that a lot of other things (that have nothing to do with PID 1) might break (and even do, examples have been provided in this thread) - and the _only_ reason you associate that with systemd is that systemd developers chose to add a warning to systemd 5 years ago in order to put people on the right track if they experience some really weird problems in their systems (because breakage due to this can be *very* subtle). It's not supported in systemd only in the sense that the developers really don't want to have to spend time helping people debug problems with other software that in the end turn out to be because /usr wasn't available early enough. All this has been explained in this thread multiple times. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#809972: ITP: scrm -- A coalescent simulator for genome-scale sequences
Package: wnpp Severity: wishlist Owner: Kevin Murray * Package name: scrm Version : 1.6.1 Upstream Author : Paul R. Staab * URL : https://github.com/scrm/scrm * License : GPL Programming Lang: C++ Description : A coalescent simulator for genome-scale sequences scrm simulates the evolution of genetic sequences. It takes a neutral evolutionary model as input, and generates random sequences that evolved under the model. As coalescent simulator, it traces the ancestry of the sampled sequences backwards in time and is therefore extremely efficient. Compared to other coalescent simulators, it can simulate chromosome-scale sequences without a measurable reduction of genetic linkage between different sites. This package will be maintained by the Debian Med team.
Re: support for merged /usr in Debian
On 01/05/2016 01:34 AM, Marc Haber wrote: > On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop > wrote: >> On 2016-01-04 12:03:07, Marc Haber wrote: >>> On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote: Anyway, if you think that the merged /usr scheme is about systemd then you are automatically disqualified from taking part in this discussion because you are not understanding the basic underlying issues. >>> >>> As friendly as always. >> >> Friendly? Maybe not. But correct? Yes. > > Being right and unfriendly drives friends and users away. This > attitude is doing harm to Debian. Marco started this thread because he wanted to discuss a specific proposal - merging /bin, /lib and /sbin into /usr. He presupposed that people already knew that mounting /usr from / is broken. That assumption was apparently wrong, because the entire thread derailed into a discussion about that. Now you could certainly argue that the arguments that as to why mounting /usr from / being broken have not been made in enough detail so that not everybody was on the same page when the discussion started - and that people proposing things should take that into consideration. But _after_ this thread, where lots of people have patiently tried to explain the issues again and again, and even tried to find ways of constructively coming to a compromise - don't you think that repeating the same talking points again in this very same thread instead of actually responding to the issues presented, don't you think that that is far more harmful to Debian than a single comment borne out of frustration? Because the lack of actual responses to arguments and the apparent lack of interest in a constructive dialog gives the impression (whether it's true or not is irrelevant here) that some people participating in these discussions aren't honest actors, and that loss of trust is to me far more harmful to any community than somebody venting a bit of frustration. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#809705: general: let people use non-free software but opt-out of non-open software
Hey Niels On Mon, Jan 4, 2016 at 8:45 AM, Niels Thykier wrote: > Philippe Cerfon: > Your second item has been brought up before with different > focus/rationale/purpose. At least I remember there being an interest in > splitting "non-free" into "non-free/firmware" vs. various other non-free > sub components. Well, I think splitting of just the firmware sounds far less appealing. Actually in some cases having a non open firmware may not be *that* big security issues, e.g. when it's used to be loaded in some external device (something like ColorHug) and for many other firmwares there is simply no alternative (or e.g. one won't have networking). So while it would make of course to split of the non-open firmware packages as well, the whole effort seems to rather only make sense if really everything non-open is split off. > On your first item, I would have to agree with Christian. It is not > actionable and much less by Debian. At best we could stop packaging > such software or disabling such features, but both have their disadvantages: > > * Even if we stop shipping them, people will still download them. >Except your average user will probably be worse off because most of >them do not verify their downloads. > * If we disable the functionality, we would "cripple" the software to >many people. If this annoys people, we will end up in a situation >where people will advise /against/ using the Debian package because >it is "crippled", which leads to the situation above. Or we could >get badly unpopular with upstream (see the "Debian vs. Ruby" issue >from a couple of years ago). Removing the software is probably not going to work out, as one would loose such big things like FF (though when looking at certain parts of it, I wonder whether this woulnd't be quite good for security/privacy). So the only alternative seems to be to allow people to disable such functionalities. When I first stumbled over such packages, I was quite surprised that no one had seriously complained about that before, but looking deeper I found a number of tickets, but it seems these were usually not accepted or just ignored :-( The best thing would be if there was kind of a master-kill-switch, that allows people to say yes or no to externally downloaded software. Sincerely, Philippe
Bug#809705: general: let people use non-free software but opt-out of non-open software
Hey. On Mon, Jan 4, 2016 at 10:13 AM, Bas Wijnen wrote: > debian-project, or hopefully debian-devel. -project for talking about the > idea, -devel for discussing an implementation. Mehdi mentioned below that it would already land on debian-devel. So I'm not sure whether it makes sense to post it to debian-project as well, or whether people would get just annoyed because of cross-posting. > Having an implementation ready > hugely improves chances of it being done. The point is, at least for the 2nd part of my original mail, I wouldn't see much implementation work in kinds of code, or is there any? It would probably require some policy changes, the addition of a new suite (e.g. "non-open" or any better name), and identification of such non-free packages that would needed to be moved there. > Yes; I think the conclusion of that discussion was two things: > 1. Different people want different splits. Using something like debtags may > be >more useful, so users can block their own tag selection. At first I had thought one could simply add a package that conflicts any such packages for which there is no source code. But I think (and I'd believe that would apply to your debtags idea as well) that this is much less reliable, as it could be easily forgotten to be added. Having a separate suite for this has the appealing property that any software in it wouldn't even show up in the package management when it wasn't added in sources.list. > 2. The firmware category is special in that pretty much everyone needs it, so >we may want to make that its own section the old way. This allows people > to >use their hardware without enabling any (other) non-free sections and >without worrying about debtags filters (once implemented). But then I'd suggest to have something like e.g. "non-open/firmware", where it would again be easily clear for anyone: beware the code you're about to run is closed and may do anything. The installers could then for example ask: [ ] Do you want to enable non-open/closed-source software (Warning: this means ) and if this isn't selected there could be a: [ ] You're hardware XYZ was found to require non-open/closed-source firmware to work. Shall non-open firmware be enabled? > I agree that not shipping things (that we are allowed to ship) is a bad idea > most of the time (except if it's because nobody considers it a priority; > giving > upstream an incentive to release their software under a free license is good). > The exception is software that actively hurts the user (malware, spyware). > Which we can only block if we know about it, of course. I recently stumbled over several sites which try to sanitize firefox with several hidden settings in about:config. Seems per default it does all kinds of experiments, send telemetry data, transmits visited URLs to Google (couldn't really find out whether it does so for all Mozilla doesn't really document any of this properly) as well as hashsums of any downloaded file. Sounds quite like spyware. So the problem in the end is that we're in devil's circle. Some software vendors (as one sees: including open source software vendors) try to gain more and more power (e.g. shipping their own "package management", recording all kind of "telemetry" data and so on). The majority remains silent and that behavior gets more and more accepted until there is no way back. :-/ > This is a valid concern, but it shouldn't always be the deciding factor. Many > people (including me) use Debian because it easily allows installing a 100% > free system with a huge choice of packages. If the choice is "move a thing to > non-free, or keep it in main and disable the functionality", those people will > lose the software completely if it's moved to non-free. Well moving something to non-free or the non-open I've proposed should only happen when something really ships or downloads closed-source code. Not because something provides a plugin-system. It seems however quite worrisome, that there are more such big open source projects (Firefox, I think I once read about Chromium doing similar) that go to the dark side and install closed-source code. The distros accept this, and e.g. Debian is doing a good job in trying to prevent such rubbish, but since no one really shouts at these upstream guys such things will rather continue and get more and more difficult to be patched out. First one had OpenH264, on Windows Firefox users already get the Adobe DRM (surely no spyware) goodness. :-/ But it would of course be nice, if one could e.g. tell Debian's Firefox (Iceweasel): don't allow to download/use any add-ons that aren't part of Debian package. Or to tell josm, the same. Or Picard. In the end, I think these are really two distinct issues: - closed-source software in Debian, which I think could be best dealt wih a "non-open" suite (or e.g. "closed-source" or whatever people like best) - software that integrates automatic or manual downloading/instal
Bug#809983: ITP: node-getobject -- get.and.set.deep.objects.easily = true
Package: wnpp Severity: wishlist Owner: Jonathan Ulrich Horn X-Debbugs-CC: debian-devel@lists.debian.org * Package name: node-getobject Version : 0.1.0 Upstream Author : "Cowboy" Ben Alman (http://benalman.com/) * URL : https://github.com/cowboy/node-getobject * License : Expat Programming Lang: JavaScript Description : get.and.set.deep.objects.easily = true getobject allows you to easily get and set deep objects. It also allows you to check if deep objects exist. . Node.js is an event-based server-side JavaScript engine.
Re: support for merged /usr in Debian
On Jan 05 2016, Marc Haber wrote: > On Mon, 4 Jan 2016 22:21:06 +0100, Iustin Pop > wrote: >>On 2016-01-04 12:03:07, Marc Haber wrote: >>> On Sun, 3 Jan 2016 19:15:18 +0100, m...@linux.it (Marco d'Itri) wrote: >>> >Anyway, if you think that the merged /usr scheme is about systemd then >>> >you are automatically disqualified from taking part in this discussion >>> >because you are not understanding the basic underlying issues. >>> >>> As friendly as always. >> >> Friendly? Maybe not. But correct? Yes. > > Being right and unfriendly drives friends and users away. This > attitude is doing harm to Debian. This seems like an opportune moment to point out that you seem to be neither right nor friendly in this thread. Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.«
Bug#809986: ITP: mosquitto-auth-plugin -- Authentication plugin for Mosquitto with multiple back-ends
Package: wnpp Severity: wishlist Owner: Adam Majer * Package name: mosquitto-auth-plugin Version : 0.0.7 Upstream Author : Jan-Piet Mens * URL : https://github.com/jpmens/mosquitto-auth-plug * License : BSD Programming Lang: C Description : Authentication plugin for Mosquitto with multiple back-ends Authentication plugin for Mosquitto with multiple backends for MySQL, PostgreSQL, Redis, CDB, SQLite3 and LDAP
Bug#809705: general: let people use non-free software but opt-out of non-open software
Hi, Quoting Stefano Zacchiroli (2016-01-04 23:14:11) > On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: > > Your second item has been brought up before with different > > focus/rationale/purpose. At least I remember there being an interest > > in splitting "non-free" into "non-free/firmware" vs. various other > > non-free sub components. > > Another one that is worth mentioning here --- which I discussed in the > context of non-free.org with Dafydd Harries and others --- is > introducing a debtags facet to capture the reason why a package is in > non-free. At least two hierarchies come to mind: 1) which point of DFSG > is not respected, and 2) which one of the 4 freedoms are not granted. > > I've had on my TODO list proposing the relevant debtags facets since at > least 2 years, but never found the time to actually do that. This is a > very actionable item: it is enough to follow the procedure for proposing > a new debtags. (Procedure that I cannot find right now, but IIRC it > includes coming up with a list of tag names + a list of at least N > packages, with N relatively low, that are already in the archive and > that would carry each tag.) while I would welcome this sort of information being captured using debtags, this would not help me if I wanted to tell apt which packages are okay for me and which ones are not because apt cannot set pin priorities according to a package's debtags, right? Also, can the reason why something is in non-free not be captured by increased and a more structured use of DEP-5 (machine-readable debian/copyright)? Certainly I'd welcome support of apt for both: debtags *and* licenses in debian/copyright :) My own motivation to have better control over non-free is my package ldraw-parts which is released under the "Creative Commons Attribution Licence version 2.0" and thus non-free. I can imagine that more people than just me would find that license acceptable enough. Thanks! cheers, josch signature.asc Description: signature
Bug#809705: general: let people use non-free software but opt-out of non-open software
Hi, Quoting Jerome BENOIT (2016-01-05 08:25:47) > On 05/01/16 08:15, Johannes Schauer wrote: > > Hi, > > > > Quoting Stefano Zacchiroli (2016-01-04 23:14:11) > >> On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: > >>> Your second item has been brought up before with different > >>> focus/rationale/purpose. At least I remember there being an interest > >>> in splitting "non-free" into "non-free/firmware" vs. various other > >>> non-free sub components. > >> > >> Another one that is worth mentioning here --- which I discussed in the > >> context of non-free.org with Dafydd Harries and others --- is > >> introducing a debtags facet to capture the reason why a package is in > >> non-free. At least two hierarchies come to mind: 1) which point of DFSG > >> is not respected, and 2) which one of the 4 freedoms are not granted. > >> > >> I've had on my TODO list proposing the relevant debtags facets since at > >> least 2 years, but never found the time to actually do that. This is a > >> very actionable item: it is enough to follow the procedure for proposing > >> a new debtags. (Procedure that I cannot find right now, but IIRC it > >> includes coming up with a list of tag names + a list of at least N > >> packages, with N relatively low, that are already in the archive and > >> that would carry each tag.) > > > > while I would welcome this sort of information being captured using debtags, > > this would not help me if I wanted to tell apt which packages are okay for > > me > > and which ones are not because apt cannot set pin priorities according to a > > package's debtags, right? > > > > Also, can the reason why something is in non-free not be captured by > > increased > > and a more structured use of DEP-5 (machine-readable debian/copyright)? > > > > Certainly I'd welcome support of apt for both: debtags *and* licenses in > > debian/copyright :) > > > > My own motivation to have better control over non-free is my package > > ldraw-parts which is released under the "Creative Commons Attribution > > Licence > > version 2.0" and thus non-free. I can imagine that more people than just me > > would find that license acceptable enough. > > Are you suggesting some kind of scale ? no. I don't think it's possible to find a scale from "dfsg-free" to "non-free" which would work for everybody. Different people feel differently about what is acceptable for them. I am talking about adding the metadata about which license code is released under and/or which DFSG freedoms it violates as proposed by Stefano in a machine readable way: either debtags or DEP-5 and make either or both of them understood by apt pinning so that I can tell my system which software to allow and which to not allow. Thanks! cheers, josch signature.asc Description: signature
Bug#809705: general: let people use non-free software but opt-out of non-open software
On Tue, Jan 05, 2016 at 08:15:37AM +0100, Johannes Schauer wrote: > while I would welcome this sort of information being captured using debtags, > this would not help me if I wanted to tell apt which packages are okay for me > and which ones are not because apt cannot set pin priorities according to a > package's debtags, right? Right, but you need to start encoding the information in a machine parsable way somewhere. Once you've that, you can exploit the information, not before. > Also, can the reason why something is in non-free not be captured by > increased and a more structured use of DEP-5 (machine-readable > debian/copyright)? Policy §12.5 already requires to explain why a package is in non-free: Packages in the contrib or non-free archive areas should state in the copyright file that the package is not part of the Debian distribution and briefly explain why. and DEP-5 prescribes the Disclaimer field to that end. Unfortunately, no further (machine-readable) structure *within* the content of that field is prescribed by DEP-5. So, yes, we will need to improve that part of DEP-5 if we want to exploit information in there. I duly note that, out of the box, having the information in d/copyright won't help with APT pinning either. Cheers. -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: PGP signature
Bug#809705: general: let people use non-free software but opt-out of non-open software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 05/01/16 08:15, Johannes Schauer wrote: > Hi, > > Quoting Stefano Zacchiroli (2016-01-04 23:14:11) >> On Mon, Jan 04, 2016 at 07:45:37AM +, Niels Thykier wrote: >>> Your second item has been brought up before with different >>> focus/rationale/purpose. At least I remember there being an interest >>> in splitting "non-free" into "non-free/firmware" vs. various other >>> non-free sub components. >> >> Another one that is worth mentioning here --- which I discussed in the >> context of non-free.org with Dafydd Harries and others --- is >> introducing a debtags facet to capture the reason why a package is in >> non-free. At least two hierarchies come to mind: 1) which point of DFSG >> is not respected, and 2) which one of the 4 freedoms are not granted. >> >> I've had on my TODO list proposing the relevant debtags facets since at >> least 2 years, but never found the time to actually do that. This is a >> very actionable item: it is enough to follow the procedure for proposing >> a new debtags. (Procedure that I cannot find right now, but IIRC it >> includes coming up with a list of tag names + a list of at least N >> packages, with N relatively low, that are already in the archive and >> that would carry each tag.) > > while I would welcome this sort of information being captured using debtags, > this would not help me if I wanted to tell apt which packages are okay for me > and which ones are not because apt cannot set pin priorities according to a > package's debtags, right? > > Also, can the reason why something is in non-free not be captured by increased > and a more structured use of DEP-5 (machine-readable debian/copyright)? > > Certainly I'd welcome support of apt for both: debtags *and* licenses in > debian/copyright :) > > My own motivation to have better control over non-free is my package > ldraw-parts which is released under the "Creative Commons Attribution Licence > version 2.0" and thus non-free. I can imagine that more people than just me > would find that license acceptable enough. Are you suggesting some kind of scale ? Jerome > > Thanks! > > cheers, josch > -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWi2/7AAoJEIC/w4IMSybj5lMH/i9u8R5lhuhLmTubJ1REFNZg Pb+Cg6wNlBSIM/Za3lS5LzcePxZae/7g8ZLf6B/7VYHPPJQheczsX6YfRoa5as1C 47ArS6uR8sOdFOhvNOmR/hWKW2o9RE+3kLnlvz0I0qnc25ty7cP31w8G04W7yQCO +fM/4XcW3MI+wtZpwZFrupm1DCHUpVpcwHLdrWJ7Bn0wmwHOWW8N7DgV9RsnBETT FnMOAN+8f/DyOQviJPMuKRS2xDcbL0eFaaWrfdq909jdO7JJLHDsEdYYrmc5tHiH Ajdg04jmA8XoZVzE1JYgL0LL56Y8r50jDqsJ9p7p4tPJRoLAoeT6ObEVXJ3Whh8= =yNg4 -END PGP SIGNATURE-
Re: support for merged /usr in Debian
Hello all. On Tue, Jan 05, 2016 at 01:23:06AM +0100, Michael Biebl wrote: > Am 05.01.2016 um 01:17 schrieb Adam Borowski: > > On Mon, Jan 04, 2016 at 08:43:02PM +0100, Michael Biebl wrote: > >> Am 04.01.2016 um 19:12 schrieb Eric Valette: > Remember that / and /usr don't have to reside on the same partition with > the usrmerge proposal: they only have to be both available > post-initramfs. The initramfs already takes care to mount /usr (for the > systemd case as initscripts needs updates for sysvinit as was said > elsewhere). So no repartitioning should be required on upgrades. > >>> As explained elsewhere in this thread, using initramfs is still not > >>> mandatory in debian > >> > >> an initramfs is not mandatory as long as you don't have /usr on a > >> separate partition. > >> No initramfs + split /usr is not supported and has been broken for a while. > > > > I guess you meant "with systemd". > > Nice try, but no. Those issues are not specific to systemd. > Though systemd might be the only init system where developers are actually nice enough to actually give you the warning, while in sysvinit "with a big fat warning added"[1] has only come as far as being discussed but not yet implemented. Here's how another sysvinit maintainer summarized the situation[1]: "/usr as a separate partition *and* no initramfs to mount it early is [unfortunately] a really bad idea on jessie/sid, [...] (but warning the user of the problem is likely to be a good idea)." (Note: this was when jessie was testing and still not frozen.) Unfortunately I think this is one of the last times the sysvinit maintainers where heard from Ignorance really seems to be bliss. I wonder how long people on debian-devel can go on pretending like everything is fine with sysvinit while bullying others into doing the work to keep sysvinit on life-support via reluctant NMUs. One day you might wake up to find that those NMUs have stopped Regards, Andreas Henriksson [1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757083
