Re: Bug#809705: general: let people use non-free software but opt-out of non-open software
]] Johannes Schauer > 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? That sounds possible to add. In the meantime, you could generate a preferences file for apt based on debtags. Not pretty, but once the data's there, it should be entirely doable. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: MBF Announcement: Transition libpng12 -> libpng16
On Mon, Jan 4, 2016 at 9:06 PM, Simon McVittie wrote: > 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? I would suggest using Debian codesearch to find more code copies. The embedded-code-copies file in the secure-testing repo is manually updated, so often gets out of date. https://wiki.debian.org/EmbeddedCodeCopies > 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. secure-testing e-c-c doesn't mention chromium and doesn't say if ice* use forks or embeds. > 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? https://security-tracker.debian.org/tracker/data/report > 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. It would be nice if this used artifacts built from src:libpng instead of embedding a copy of the code though. -- bye, pabs https://wiki.debian.org/PaulWise
Re: Bug#809705: general: let people use non-free software but opt-out of non-open software
On Tue, Jan 5, 2016 at 4:21 PM, Tollef Fog Heen wrote: > That sounds possible to add. In the meantime, you could generate a > preferences file for apt based on debtags. Not pretty, but once the > data's there, it should be entirely doable. Indeed, I'm doing something similar for installing security updates in unstable while running testing: https://bugs.debian.org/725934 -- bye, pabs https://wiki.debian.org/PaulWise
Bug#809705: general: let people use non-free software but opt-out of non-open software
Johannes Schauer writes: > 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. It might be worth looking at what FDroid have done with there antifeatures metainformation: https://f-droid.org/manual/fdroid.html#AntiFeatures -- Brian May
Bug#809993: ITP: ctop -- Command line / text based Linux Containers monitoring tool
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: ctop Version : 0.4.1 Upstream Author : Jean-Tiare Le Bigot * URL : https://github.com/yadutaf/ctop * License : Expat Programming Lang: Python Description : Command line / text based Linux Containers monitoring tool ctop will help you see what's going on at the container level. Basically, containers are a logical group of processes isolated using kernel's cgroups and namespaces. Recently, they have been made popular by Docker and they are also heavily used under the hood by systemd and a load of container tools like lxc, rocket, lmctfy and many others. . Under the hood, ctop will collect all metrics it can from cgroups in realtime and render them to instantly give you an overview of the global system health. . It currently collects metrics related to cpu, memory and block IO usage as well as metadata such as owning user (mostly for systemd based containers), uptime and attempts to guess the container managing technology behind. -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote: > And yet, it works, and it means that we don't have to try to harass a > thousand package maintainers into doing essentially untestable busy-work > to try to move things around between /usr, /bin, and /lib to support a > tiny handful of systems for which other approaches are available. The bin-or-sbin-binary-requires-usr-lib-library tag in adequate tests this. piuparts runs adequate for every single package in Debian. -- bye, pabs https://wiki.debian.org/PaulWise
Bug#809994: ITP: sen -- Terminal user interface for docker engine
Package: wnpp Severity: wishlist Owner: "ChangZhuo Chen (陳昌倬)" * Package name: sen Version : 0.2.2 Upstream Author : Tomas Tomecek * URL : https://github.com/TomasTomecek/sen * License : Expat Programming Lang: Python Description : Terminal user interface for docker engine sen is a terminal user interface for docker engine: . * it can interactively manage your containers and images: * manage? start, stop, restart, kill, delete,... * you are able to inspect containers and images * sen can fetch logs of containers and even stream logs real-time * all buffers support searching and filtering * sen receives real-time updates from docker when anything changes * e.g. if you create a container in another terminal, sen will pick it up * sen notifies you whenever something happens (and reports slow queries) * supports a lot of vim-like keybindings (j, k, gg, /, ...) * there is a special buffer which display detailed info about images * you can get interactive tree view of all images (equivalent of docker images --tree) -- ChangZhuo Chen (陳昌倬) Debian Developer (https://nm.debian.org/public/person/czchen) Key fingerprint = EC9F 905D 866D BE46 A896 C827 BE0C 9242 03F4 552D signature.asc Description: PGP signature
Bug#809996: ITP: python-dcos -- Datacenter Operating System (DCOS) CLI
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-dcos Version : 0.2.0 Upstream Author : Mesosphere, Inc. * URL : https://github.com/mesosphere/dcos-cli * License : Apache-2.0 Programming Lang: Python Description : Datacenter Operating System (DCOS) CLI The DCOS Command Line Interface (CLI) is a command line utility that provides a user-friendly yet powerful way to manage DCOS installations. You can use the Mesosphere DCOS command-line interface (CLI) to remotely manage your cluster, install software packages, and inspect the cluster state. With the DCOS CLI you can: * Find and install packages from DCOS Universe and Multiverse. * Uninstall DCOS services. * Administer the DCOS init process, Marathon. * Install and uninstall subcommands that extend and add functionality to the DCOS CLI. . After you install the CLI, you can use it through a bash shell on Unix/Linux systems or PowerShell on a Windows system. This is a new OpenStack dependency.
Re: support for merged /usr in Debian
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 02, Joerg Jaspert wrote:
> > No, /etc can be nicely ro. That is, /, /usr, /etc, ... can be. The log
> > storage and the user homes, as well as a tmp filesystem rw, rest ro.
> > Works nicely, I have 4 of such systems running.
>
> Just to be clear: on a merged /usr system nothing prevents you from
> having /home and /var on standalone file systems and keeping the root
> file system (eventually with /usr on it) read only.
/etc contains files which are modified during normal operation.
Ian.
Re: support for merged /usr in Debian
Simon Richter writes ("Re: support for merged /usr in Debian"):
> However, we do have a huge installation base outside of that. In most of
> my embedded systems projects, Debian has been the starting point for the
> customized installation, simply because before jessie, you could simply
> call "debootstrap --foreign" and get a working root filesystem, where
> all you need to add is a kernel that matches your hardware.
>
> This mechanism is already broken, and Debian's reputation has suffered
> for it. We can bootstrap an oldstable system and upgrade from there, but
> that is a cumbersome hack.
Can this be fixed ?
> Honestly, I am starting to believe that forking is a good choice, into a
> Debian that provides excellent supports for PCs, and an "universal
> operating system", because we obviously cannot have both in the same
> project.
The reason we are having trouble having both in the same project is
because some of the people who are trying to do what you describe as
"excellent supports for PCs" think that that is the only interesting
objective.
Ian.
Re: support for merged /usr in Debian
* Paul Wise , 2016-01-05, 17:49: And yet, it works, and it means that we don't have to try to harass a thousand package maintainers into doing essentially untestable busy-work to try to move things around between /usr, /bin, and /lib to support a tiny handful of systems for which other approaches are available. The bin-or-sbin-binary-requires-usr-lib-library tag in adequate tests this. piuparts runs adequate for every single package in Debian. https://piuparts.debian.org/sid/bin_or_sbin_binary_requires_usr_lib_library_inadequate_issue.html -- Jakub Wilk
Re: support for merged /usr in Debian
On Tue, 5 Jan 2016 12:49:25 +
Ian Jackson wrote:
> Simon Richter writes ("Re: support for merged /usr in Debian"):
> > However, we do have a huge installation base outside of that. In
> > most of my embedded systems projects, Debian has been the starting
> > point for the customized installation, simply because before
> > jessie, you could simply call "debootstrap --foreign" and get a
> > working root filesystem, where all you need to add is a kernel that
> > matches your hardware.
> >
> > This mechanism is already broken, and Debian's reputation has
> > suffered for it. We can bootstrap an oldstable system and upgrade
> > from there, but that is a cumbersome hack.
>
> Can this be fixed ?
I'm not sure what needs to be fixed. debootstrap --foreign + kernel
(+dtb) works just fine. It just depends on what gets enabled in the
kernel. There's some things to do if that is to be an NFS boot but
that's manageable too, depending on the kernel config. Debian kernels
don't have that config (and don't need it), but then if you've got a
Debian kernel, you have an initramfs which can be passed too.
Simon: where does this break for you?
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpNkU_PHHcL3.pgp
Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On Jan 05, Ian Jackson wrote: > /etc contains files which are modified during normal operation. Depending on the operation involved, we consider this to be a bug: https://wiki.debian.org/ReadonlyRoot -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
On Jan 05, Ian Jackson wrote: > The reason we are having trouble having both in the same project is > because some of the people who are trying to do what you describe as > "excellent supports for PCs" think that that is the only interesting > objective. I am not sure about who you are referring to, but I am quite interested in excellent Debian support for embedded devices, servers and containers, and a merged /usr scheme would be extremely useful for many of these use cases. -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 05, Ian Jackson wrote:
> > /etc contains files which are modified during normal operation.
>
> Depending on the operation involved, we consider this to be a bug:
> https://wiki.debian.org/ReadonlyRoot
Well, perhaps. My point is that currently there are real
configurations that work well with ro /usr but require rw /.
Abolishing the distinction between /usr and / will break systems that
have been set up that way.
I have to say that I'm rather confused and also dismayed by this
thread. There is an awful lot of aggressive language on both sides.
AFAICT the original posting in this thread is from someone who is
trying to make it easier and more automatic to try to produce Debian
installations which do not have a /usr vs / distinction.
There is, of course, nothing wrong with that.
What is causing all the heat is the suggestion that support might be
withdrawn for currently working configurations which _do_ have a /usr
vs / distinction, or which do mount /usr using / rather than
initramfs, or some such.
It seems to me that enough people want Debian to retain the
flexibility which is gained by the /usr vs / division, that we as a
project should continue to provide it.
That does not mean that every user has to have a separate /usr or that
/usr can't be mounted by the default initramfs. It does mean that
package maintainers need to continue to place files in / or /usr as
appropriate, respond approprately to reasonable bug reports, etc.
Ian.
Re: support for merged /usr in Debian
On Jan 05, Ian Jackson wrote: > > Depending on the operation involved, we consider this to be a bug: > > https://wiki.debian.org/ReadonlyRoot > > Well, perhaps. My point is that currently there are real > configurations that work well with ro /usr but require rw /. > > Abolishing the distinction between /usr and / will break systems that > have been set up that way. I think that you are a bit confused, because on a merged /usr system you can continue having a read only /usr and a read write /. If your goal is to have read only system binaries then a merged /usr system will be better for you, because then *all* system binaries will be on a read only filesystem. > What is causing all the heat is the suggestion that Part of the problem is that misinformed people keep suggesting that a merged /usr system is about all kind of things which is not or will break all kind of things that it will not, and then they get all worked up about their own misinformation. So I am quite tired of having to reply again and again to strawman arguments. > support might be withdrawn for > currently working configurations which _do_ have a /usr > vs / distinction, I do not think that this is being proposed. > or which do mount /usr using / rather than initramfs, or some such. And this has already not been supported for many years, even if it works in some cases, so it does not matter because it is hard to ask to keep support for an already unsupported configuration. And this would only matter if using a merged /usr were mandatory, which at this point has not been proposed anyway. > It seems to me that enough people want Debian to retain the > flexibility which is gained by the /usr vs / division, that we as a > project should continue to provide it. For all practical purposes a merged /usr system strongly improves the /usr vs / division. > That does not mean that every user has to have a separate /usr or that > /usr can't be mounted by the default initramfs. It does mean that > package maintainers need to continue to place files in / or /usr as > appropriate, respond approprately to reasonable bug reports, etc. As explained, we stopped doing this long ago since it is hard work with no significant benefits. -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
Marco d'Itri writes ("Re: support for merged /usr in Debian"):
> On Jan 05, Ian Jackson wrote:
> > or which do mount /usr using / rather than initramfs, or some such.
>
> And this has already not been supported for many years, even if it works
> in some cases, so it does not matter because it is hard to ask to keep
> support for an already unsupported configuration.
People who have been using a configuration for many years naturally
become upset when they are told that it has been `unsupported' for all
of this time and that, implicitly, changes are going to be made which
will break it.
It is this kind of apparent proposal to nonconsensually impose changes
which is generating upset.
> > That does not mean that every user has to have a separate /usr or that
> > /usr can't be mounted by the default initramfs. It does mean that
> > package maintainers need to continue to place files in / or /usr as
> > appropriate, respond approprately to reasonable bug reports, etc.
>
> As explained, we stopped doing this long ago since it is hard work with
> no significant benefits.
This seems to be mostly rhetoric rather than fact.
This thread contains a fair few assertions that certain configurations
are `broken' or `unsupported'; but these assertions sit alongside
reports from actual users that these configurations do work for them,
and expressions of the wish that they should continue to do so.
Ian.
Re: support for merged /usr in Debian
On 2016-01-05, Paul Wise wrote: > On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote: > >> And yet, it works, and it means that we don't have to try to harass a >> thousand package maintainers into doing essentially untestable busy-work >> to try to move things around between /usr, /bin, and /lib to support a >> tiny handful of systems for which other approaches are available. > > The bin-or-sbin-binary-requires-usr-lib-library tag in adequate tests this. > piuparts runs adequate for every single package in Debian. Does it also catch when for example a udev configuration file wants to run an executable living under /usr ? /Sune
Bug#810026: ITP: spineml-preflight -- Simulator independent initial processing for SpineML models
Package: wnpp Severity: wishlist Owner: Sebastian James * Package name: spineml-preflight Version : 0.1.0 Upstream Author : Seb James * URL : https://github.com/SpineML/SpineML_PreFlight * License : GPL Programming Lang: C++ Description : Simulator independent initial processing for SpineML models SpineML_PreFlight is part of the SpineML toolchain, which also includes SpineCreator, SpineML_2_BRAHMS and BRAHMS. This suite of tools allows computational neuroscientists to graphically create systems-level models of biological neural networks and then execute them on their own computers or on high performance computer systems. The SpineML toolchain has been developed at Sheffield University and is in use there by several groups involved in neuroscience and robotics research. This code takes a SpineML neural network model, which may have been created in the SpineCreator GUI, and "preflights" it ready for the simulator, which may be SpineML_2_BRAHMS. This is a dependency for SpineML_2_BRAHMS. I do require a sponsor for this package.
Re: support for merged /usr in Debian
On Jan 05, Ian Jackson wrote: > People who have been using a configuration for many years naturally > become upset when they are told that it has been `unsupported' for all > of this time and that, implicitly, changes are going to be made which > will break it. I think that your summary is correct, and I am quite sure that it would be a bad engineering practice to make technical decisions based on people's emotions. > It is this kind of apparent proposal to nonconsensually impose changes > which is generating upset. In 2004 people used to complain that udev was being imposed on them. Last year it was about systemd. And now: https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+sysvinit-core+udev&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1 > This thread contains a fair few assertions that certain configurations > are `broken' or `unsupported'; but these assertions sit alongside > reports from actual users that these configurations do work for them, > and expressions of the wish that they should continue to do so. There is a significant difference between concepts like: - something works for me - something works and: - I want something to be supported - the people actually working on something want to support it -- ciao, Marco signature.asc Description: PGP signature
Re: support for merged /usr in Debian
]] Paul Wise > On Mon, Jan 4, 2016 at 2:14 AM, Russ Allbery wrote: > > > And yet, it works, and it means that we don't have to try to harass a > > thousand package maintainers into doing essentially untestable busy-work > > to try to move things around between /usr, /bin, and /lib to support a > > tiny handful of systems for which other approaches are available. > > The bin-or-sbin-binary-requires-usr-lib-library tag in adequate tests this. > piuparts runs adequate for every single package in Debian. The check doesn't seem to be complete, it's not complaining about PAM modules needing libcurl or libkrb5 for instance. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: MBF Announcement: Transition libpng12 -> libpng16
Tobias Frost wrote: > 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 Hello, is there a reason why the experimental packages do not provide libpng-dev? It seems unnecessarily cumbersome to require maintainers to make and install a local rebuild of png (or use equivs) to test the transition. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: support for merged /usr in Debian
]] Ian Jackson > This thread contains a fair few assertions that certain configurations > are `broken' or `unsupported'; but these assertions sit alongside > reports from actual users that these configurations do work for them, > and expressions of the wish that they should continue to do so. A lot of this thread reminds me somewhat of the various people being very upset when gcc changes behaviour on something which is either undefined in the C standard or implementation defined. The other thing it reminds me of is https://xkcd.com/1172/ . Nearly any change we make has a risk of breaking something for somebody out there if our users have explored the enterity of what you can do with Debian and that has some reasonable chance of success. To counter this, we (collectively), need to do a couple of things: - Be reasonably clear about what you can expect will continue working and what configurations we actively care about even if they're not what we do by default. We care about, say, being able to run a self-compiled kernel, even if we don't require people to build their own kernel. However, we also require people to run a reasonably recent kernel, or thing won't work. Glibc has version requirements, apache uses epoll (something where we did have to wait a release to use it, because we wanted to support running a partially upgraded system). It's a two way street and both we as a project and our users need to be reasonable.[*] - When we change the expectations and the operating envelope, we need to communicate that. We also need to (whenever at all possible) provide a migration path. In some cases, we might be able to say «you can run with your old setup, but then you have to do those five steps for it to continue working». The 300loc initramfs elsethread is an example of this: You can have (almost) no initramfs and then you can continue with your /usr and / on separate partitions. Again, people need to be reasonable and constructive. Labelling initramfs as «evil» is not. What we can't do is to stop making changes because it might break configurations, especially configurations we don't know about. That's how this has «always» worked. We make changes, if it breaks something people use, you get bug reports and work it out from there. [*] «Reasonable» is hard to define, which is part of the reason we end up with those arguments. I don't have a good test for reasonableness outside of human judgement. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: support for merged /usr in Debian
Hi, On 05.01.2016 19:37, Marco d'Itri wrote: > There is a significant difference between concepts like: > - something works for me > - something works > and: > - I want something to be supported > - the people actually working on something want to support it What is the recourse for people who are not maintainers of the packages in question? Simon signature.asc Description: OpenPGP digital signature
Bug#810033: ITP: nvme-cli -- NVMe management command line interface
Package: wnpp Severity: wishlist Owner: Breno Leitao * Package name: nvme-cli Version : 0.2 Upstream Author : Stephen Bates * URL : https://github.com/linux-nvme/nvme-cli * License : GPL version 2 Programming Lang: C Description : NVMe management command line interface NVME is a specification for accessing solid-state drives (SSDs) attached through the PCI Express (PCIe) bus. "NVM" stands as an initialism for non-volatile memory, which is used in SSDs. nvme-cli is a set of userspace tools to handle NVME adapters on a server, such as performing serviceability functions to an nvme adapter, as adapter firmware update, device formatting, and diagnostics.
tiny-initrd (was: Re: support for merged /usr in Debian)
On 01/03/2016 09:35 PM, Christian Seiler wrote: > Well, just for the heck of it I wrote a braindead-simple initrd > implementation in just 300 LOC: > > https://gist.github.com/chris-se/e0fbc073fcbd9ac2d7ae > > [...] > > This is just a proof of concept, [...] Well, in case anyone's interested: https://github.com/chris-se/tiny-initrd If your kernel has the block device driver and the file system driver of your root and /usr file systems built in (NOT a standard Debian kernel), and you don't use UUID= but kernel device names (/dev/sda1 or similar) for the root= parameter with your boot loader and the /usr entry in /etc/fstab, you can use it as a drop-in replacement for the default initrd by just replacing the file in /boot. (You don't need to specify some additional parameter for the /usr mount, as the original PoC required.) The standard kernel parameters for the rootfs are also supported now (ro/rw, rootfstype=, rootdelay=, ...). (/usr doesn't have to be present, it will happily skip /usr if /etc/fstab or an entry for /usr doesn't exist.) Currently below 1000 LoC, initrd image size is around 10 KiB on amd64 unless you use glibc. (Then it's large.) Now properly packaged with Makefile (that can also generate the initrd image automatically), license (GPLv3+) and some basic documentation in form of a README. There are still some issues, please read the README before using it. Also, while it works for me[tm], there might be some bugs in there that I didn't find in my test setup. Usually a bug means a kernel panic, so you should keep an alternative way of booting around while testing it. I'll package that for Debian in the not too distant future. Regards, Christian signature.asc Description: OpenPGP digital signature
Re: MBF Announcement: Transition libpng12 -> libpng16
On Tue, Jan 05, 2016 at 08:04:53PM +0100, Andreas Metzler wrote: > Tobias Frost wrote: > > 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 [...] > is there a reason why the experimental packages do not provide > libpng-dev? It seems unnecessarily cumbersome to require maintainers to > make and install a local rebuild of png (or use equivs) to test the > transition. So that it will immediately fail when something eventually picks up the experimental packages (as experimental buildds right now do in some situations)? Thank you, please not. Been there, done that at the last round it was attempted, after which I reverted it back then. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662411#37. And I still see libpng12 refererences in some relevant pkg-config files, which most probably will then still fail when libpng16-dev gets picked up (unless it started to provide libpng12.pc, which I didn't check but doubt.) Regards, Rene
Re: MBF Announcement: Transition libpng12 -> libpng16
Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote: > So that it will immediately fail when something eventually picks > up the experimental packages (as experimental buildds right now do in some > situations)? ? No, experimental buildds only pick from experimental what is not available from sid. If something is available from sid, they will pick it up from there, even if experimental has a newer version. > Been there, done that at the last round it was attempted, after which > I reverted it back then. > > See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662411#37. This is a different thing: buildds install real packages, yes, and don't want to install virtual packages. But this is completely independent from sid vs unstable. Samuel
Re: MBF Announcement: Transition libpng12 -> libpng16
On Tue, Jan 05, 2016 at 09:50:58PM +0100, Samuel Thibault wrote: > Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote: > > So that it will immediately fail when something eventually picks > > up the experimental packages (as experimental buildds right now do in some > > situations)? > > ? No, experimental buildds only pick from experimental what is not > available from sid. If something is available from sid, they will pick > it up from there, even if experimental has a newer version. That is demonstrateable untrue since the resolver switch a few times ago. And yes, the respective people know and a fix is in the works. > This is a different thing: buildds install real packages, yes, and don't > want to install virtual packages. But this is completely independent > from sid vs unstable. OK, true, I misremembered. My bad. Regards, Rene
Re: MBF Announcement: Transition libpng12 -> libpng16
On Tue, Jan 05, 2016 at 09:58:03PM +0100, Rene Engelhard wrote: > On Tue, Jan 05, 2016 at 09:50:58PM +0100, Samuel Thibault wrote: > > Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote: > > > So that it will immediately fail when something eventually picks > > > up the experimental packages (as experimental buildds right now do in some > > > situations)? > > > > ? No, experimental buildds only pick from experimental what is not > > available from sid. If something is available from sid, they will pick > > it up from there, even if experimental has a newer version. > > That is demonstrateable untrue since the resolver switch a few times ago. See e.g. https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=1%3A5.1.0~alpha1-3&stamp=1446915107 firebird-dev in sid satifies the build-dep and still it was installed from experimental. (Also OpenJDK 8 was installed (LO only build-deps on default-jdk, which was and is 7 in sid, just 8 in experimental) (yes, I added a build-conflicts against firebird 3 later to work around that.) https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=hppa&ver=1%3A5.1.0~rc1-1&stamp=1450594629 libmdds-dev in unstable satifies the build-dep, still the experimental one was installed. (Build-Conflicts will be added in the next upload as a workaround.) Regards, Rene
Re: support for merged /usr in Debian
On Tue, Jan 05, 2016 at 03:55:51PM +, Ian Jackson wrote: > AFAICT the original posting in this thread is from someone who is > trying to make it easier and more automatic to try to produce Debian > installations which do not have a /usr vs / distinction. I think a lot of heat in this thread is due to people completely forgetting that is what this was about. > What is causing all the heat is the suggestion that support might be > withdrawn for currently working configurations which _do_ have a /usr > vs / distinction, or which do mount /usr using / rather than > initramfs, or some such. Which actually was never proposed. There were some "what if" type posts, but noone was mandating a merged /usr anywhere. > It seems to me that enough people want Debian to retain the > flexibility which is gained by the /usr vs / division, that we as a > project should continue to provide it. It would probably be a good idea to gather all of these use-cases and put them into the wiki under or linked to the usrmerge entry. I've seen a lot of "what about situation X" type emails in this thread with replies with "fixed with solution Y" or "not a /usr merge specific problem". Some of those would be useful to those people who have the same situation. It would also mean that any situation that hasn't got a solution is well-known. > That does not mean that every user has to have a separate /usr or that > /usr can't be mounted by the default initramfs. It does mean that > package maintainers need to continue to place files in / or /usr as > appropriate, respond approprately to reasonable bug reports, etc. So the idea would be, at this stage. 1) People who want a merged /usr install the usrmerge package 2) Package maintainers would still install in /usr/bin or /bin etc - Craig -- Craig Small (@smallsees) http://enc.com.au/ csmall at : enc.com.au Debian GNU/Linux http://www.debian.org/ csmall at : debian.org GPG fingerprint:5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5
Re: support for merged /usr in Debian
On Jan 05 2016, Ian Jackson wrote:
> Marco d'Itri writes ("Re: support for merged /usr in Debian"):
>> On Jan 05, Ian Jackson wrote:
>> > or which do mount /usr using / rather than initramfs, or some such.
>>
>> And this has already not been supported for many years, even if it works
>> in some cases, so it does not matter because it is hard to ask to keep
>> support for an already unsupported configuration.
>
> People who have been using a configuration for many years naturally
> become upset when they are told that it has been `unsupported' for all
> of this time
Well, yes, but this is just a fact. I don't think it makes sense to
avoid stating the fact because it makes some people upset - rather,
those people should try to avoid blaming the messenger.
> and that, implicitly, changes are going to be made which
> will break it.
I don't see this as being implied.
Best,
-Nikolaus
(No Cc on replies please, I'm reading the list)
--
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#810045: ITP: spinecreator -- A GUI for the creation and analysis of neural models using the SpineML format
Package: wnpp Severity: wishlist Owner: Sebastian James * Package name: spinecreator Version : 0.9.5 Upstream Author : Alex Cope * URL : https://github.com/SpineML/SpineCreator * License : GPL Programming Lang: C++ Description : A GUI for the creation and analysis of neural models using the SpineML format SpineCreator is a graphical editor for SpineML models with support for running model simulations. It features OpenGL visualisation of networks, simulator integration and graphical analysis tools. SpineML is an XML description format for neural network models, including firing rate models and various types of integrate and fire models. Most models which treat neural systems as a network of point neurons can be described in SpineML. Although SpineCreator on its own can create and modify SpineML models, it is always installed along with the SpineML_2_BRAHMS simulation engine so that it can execute models as well as modify and edit them. The target audience is the neuroscience community. I require a sponsor for this package, and the related packages (brahms, spineml-preflight and spineml-2-brahms).
Re: support for merged /usr in Debian
On 2016-01-04 11:30, Marc Haber wrote: 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. Similarly skeleton-based init scripts use the full path as well. It helps if you can stat() it. Which, I guess, you could by extension by using "which" and the like. On the other hand init scripts are supposed to be runable in "env -i". Now, what would the PATH be for systemd to use? My skeleton-based init scripts ship their own PATH (yay, duplication and decentral configuration). I can see how you would want to use EnvironmentFile for that. But then, why not simply override ExecStart? And even then I don't see the point. (One reply would be "to reuse the distro-provided commandline arguments", which is fair, but you are already redirecting the path to the binary from the default anyway and are not using the distro one.) You can continue to childishly blame Lennart for everything, but that might cause others to stop taking you seriously. Which isn't really what you deserve. Kind regards Philipp Kern
Re: support for merged /usr in Debian
On Tue, Jan 05, 2016 at 08:10:00PM +0100, Simon Richter wrote: > On 05.01.2016 19:37, Marco d'Itri wrote: > > > There is a significant difference between concepts like: > > - something works for me > > - something works > > > and: > > - I want something to be supported > > - the people actually working on something want to support it > > What is the recourse for people who are not maintainers of the packages > in question? Not much. For example, policykit-1 FTBFSes on non-systemd architectures (#798769) despite a patch being provided and multiple maintainer uploads since then. So even doing the work won't do any good if your aims are for whatever reason disliked by the maintainer. -- A tit a day keeps the vet away.
Re: MBF Announcement: Transition libpng12 -> libpng16
Rene Engelhard, on Tue 05 Jan 2016 22:15:31 +0100, wrote: > On Tue, Jan 05, 2016 at 09:58:03PM +0100, Rene Engelhard wrote: > > On Tue, Jan 05, 2016 at 09:50:58PM +0100, Samuel Thibault wrote: > > > Rene Engelhard, on Tue 05 Jan 2016 21:43:33 +0100, wrote: > > > > So that it will immediately fail when something eventually picks > > > > up the experimental packages (as experimental buildds right now do in > > > > some > > > > situations)? > > > > > > ? No, experimental buildds only pick from experimental what is not > > > available from sid. If something is available from sid, they will pick > > > it up from there, even if experimental has a newer version. > > > > That is demonstrateable untrue since the resolver switch a few times ago. > > See e.g. > > https://buildd.debian.org/status/fetch.php?pkg=libreoffice&arch=i386&ver=1%3A5.1.0~alpha1-3&stamp=1446915107 > > firebird-dev in sid satifies the build-dep and still it was installed from > experimental. Uh, I'm surprised, that's not what I thought was supposed to happen... Samuel
Re: support for merged /usr in Debian
On 01/06/2016 12:54 AM, Adam Borowski wrote: > On Tue, Jan 05, 2016 at 08:10:00PM +0100, Simon Richter wrote: >> On 05.01.2016 19:37, Marco d'Itri wrote: >> >>> There is a significant difference between concepts like: >>> - something works for me >>> - something works >> >>> and: >>> - I want something to be supported >>> - the people actually working on something want to support it >> >> What is the recourse for people who are not maintainers of the packages >> in question? > > Not much. For example, policykit-1 FTBFSes on non-systemd architectures > (#798769) despite a patch being provided and multiple maintainer uploads > since then. > > So even doing the work won't do any good if your aims are for whatever > reason disliked by the maintainer. It's sad to see that you don't assume good faith here. If you take a look at the list of bugs in the package, https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=policykit-1 you will see that there are quite a few other bugs open in the package, some also with severity important - and just from reading the subjects in that list it seems that a few of them also appear to have a large impact on some users. And if I look at the changelog, https://tracker.debian.org/media/packages/p/policykit-1/changelog-0.105-14 both uploads were not new upstream versions, but very selected bugfixes, where all the other still open bugs were also left unfixed. To me, this appears to be much more of a case of not enough time on the side of the maintainers rather than malice. I get it, it's very frustrating when a problem that affects you isn't fixed in a package, I myself have been on that very same end of that equation myself in different instances. But it's not like there isn't a recourse for this in Debian - if a maintainer just doesn't have enough time for your specific problem at that very moment, just announce that you're going to NMU the package in the BTS with the corresponding nmudiff, wait a bit and if there still isn't any reaction, upload the NMU to DELAYED/10. See https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu for further details. (NMUs can also be sponsored.) Doing that would actually fix your problem - and it'd be far lest frustrating for everybody than the insinuations you just made. Just saying... Regards, Christian signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
Nikolaus Rath writes ("Re: support for merged /usr in Debian"):
> On Jan 05 2016, Ian Jackson wrote:
> > People who have been using a configuration for many years naturally
> > become upset when they are told that it has been `unsupported' for all
> > of this time
>
> Well, yes, but this is just a fact. I don't think it makes sense to
> avoid stating the fact because it makes some people upset - rather,
> those people should try to avoid blaming the messenger.
Whether a configuration is `supported' is not a fact; it is a
political decision about how problems with it will be handled.
Ian.
Re: support for merged /usr in Debian
On 01/06/2016 12:54 AM, Adam Borowski wrote: > For example, policykit-1 FTBFSes on non-systemd architectures > (#798769) I'd also like to note that while you provided a patch, you didn't really provide much context for this - and left a lot of work to the maintainers when it comes to integrating that patch into the packaging. I did some digging and found that your bug was already fixed upstream (in fact, a backport of something from newer versions was the cause of the FTBFS, because the follow-up fixes were presumably overlooked). I've backported the two upstream patches that fix this (which amount to the same change that your patch does) and have added them with the proper metadata attached to them to the git packaging of the policykit package. I've attached the patch against the git packaging to your bugreport. In an ideal world, obviously just providing a patch should be more than sufficient, but if you have a package where the maintainers are obviously short on time, you're much more likely to get results if you put in a bit of extra effort and provide something they can simply apply to git (e.g. git am) without having to do all the additional work of figuring the things out that I've mentioned. And if there still is no reaction to that, NMU remains an option. Now you just need to add the proper changelog in addition to my diff. (I think it's really unfair for you to complain in the way you did, so I'm doing this to point out that you have not done all you could have done to get this fixed, because figuring out that it's fixed upstream, that it's probably better to backport the official upstream patches, adding all the appropriate metadata to the patches and putting them into the right position in the patch list to be consistent is a lot of work you didn't do and that the maintainers would have had to do had I not done it just now. Now of course I don't think it'd be reasonable to _expect_ this amount of work from everyone reporting bugs in packages - but if the maintainers of a package are short on time, doing this work for them will greatly help in getting things fixed, while bad-mouthing them on debian-devel definitely won't.) Regards, Christian (for reference) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798769 signature.asc Description: OpenPGP digital signature
Re: support for merged /usr in Debian
On Wed, Jan 6, 2016 at 2:42 AM, Tollef Fog Heen wrote: > The check doesn't seem to be complete, it's not complaining about PAM > modules needing libcurl or libkrb5 for instance. Could you file a bug? -- bye, pabs https://wiki.debian.org/PaulWise
Re: support for merged /usr in Debian
On Wed, Jan 6, 2016 at 2:27 AM, Sune Vuorela wrote: > Does it also catch when for example a udev configuration file wants to > run an executable living under /usr ? Doesn't look like it, could you file a bug? -- bye, pabs https://wiki.debian.org/PaulWise
vlan support en* or br*?
I checked vlan source http://anonscm.debian.org/cgit/collab-maint/vlan.git/ debian/network/if-pre-up.d/vlan, if-post-up.d/vlan … and not support en* or br* which are quite common nowadays. need to file a bug or just customize and use it myself? Thanks.
Re: vlan support en* or br*?
On Wed, 2016-01-06 at 12:46 +0900, Seyeong Kim wrote: > I checked vlan source http://anonscm.debian.org/cgit/collab-maint/vlan.git/ > > debian/network/if-pre-up.d/vlan, if-post-up.d/vlan … > > and not support en* or br* which are quite common nowadays. > > need to file a bug or just customize and use it myself? The vlan package is obsolete. You could perhaps replace it with something based on iproute. Ben. -- Ben Hutchings It is easier to write an incorrect program than to understand a correct one. signature.asc Description: This is a digitally signed message part
Re: support for merged /usr in Debian
On 01/06/2016 02:55 AM, Ian Jackson wrote:
> Nikolaus Rath writes ("Re: support for merged /usr in Debian"):
>> On Jan 05 2016, Ian Jackson wrote:
>>> People who have been using a configuration for many years naturally
>>> become upset when they are told that it has been `unsupported' for all
>>> of this time
>>
>> Well, yes, but this is just a fact. I don't think it makes sense to
>> avoid stating the fact because it makes some people upset - rather,
>> those people should try to avoid blaming the messenger.
>
> Whether a configuration is `supported' is not a fact; it is a
> political decision about how problems with it will be handled.
May I rephrase 'unsupported' a bit so it fits with your framing
of the issue?
"Ample evidence has shown that declaring continued support
for mounting /usr from / amounts to wishful thinking."
It's perfectly legitimate to lament that, but it doesn't make it
any less true.
Regards,
Christian
signature.asc
Description: OpenPGP digital signature
Bug#810061: ITP: python-django-environ -- utilize 12factor inspired environment variables for Django
Package: wnpp Severity: wishlist Owner: Brian May * Package name: python-django-environ Version : 0.4 Upstream Author : joke2k * URL : https://github.com/joke2k/django-environ/ * License : MIT Programming Lang: Python2 and Python3 Description : Simplified environment variables for Django Simplifies configuring key aspects of Django Applications through environment variables. I am hopeless with descriptions, any improvements to the above description welcome. This will be maintained as part of DPMT, and will be required for the next release of django-guardian.
Bug#809705: general: let people use non-free software but opt-out of non-open software
Stefano Zacchiroli wrote: >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. I'd still say that solving that via debtags isn't actually solving the issue (which doesn't mean that it would be nice to have it in Debtags as well). I guess not all software which is in Debian an makes use of apt repos understands debtags, so until that is fixed (which easily takes forever as new packages that do business with apt repos arrive), there would be still "holes" through which non-open software could hit a system. And, as said before, it's far easier to accidentally forget setting the "this is closed source" debtag, than to move it to the wrong suite, the later would probably at least be checked by the ftp-masters, right? And even *if* it would work out, that all closed-source packages have the right debtag set and no apt package installs them, these packages would still show up, in package listings, perhaps when doing apt-get source and so on. Johannes Schauer wrote: > 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. That sounds perhaps more like something for debtags, but this also doesn't have the security motivation as my proposal. You're package is likely less "worse" than non-free, while what I'd consider for "non-open" is "worse" than "non-free" (it's not even open). I'm not a Debian developer, does anyone here know or has some estimate, on what it would actually take in terms of effort to add another suite like the "non-open" (or "closed-source") I had proposed in the beginning? Are there any technical, organisational or other arguments against it? At least to me, though my knowledge may be too limited, it seemed like a proper solution to be able to have closed-source software in Debian repos in general, but also to be able to *completely* shut them out. And that seemed quite appealing, at least more than the debtags based approach. Thanks and best wishes, Philippe.
