Accepted rbldnsd 0.998b~pre1-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 27 Sep 2016 02:04:33 +0200 Source: rbldnsd Binary: rbldnsd Architecture: source i386 Version: 0.998b~pre1-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'I

Accepted binkd 1.0.5~pre5-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Dec 2016 14:32:37 +0100 Source: binkd Binary: binkd Architecture: source i386 Version: 1.0.5~pre5-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Can we kill net-tools, please?

ifconfig, route, etc... Recently the net-tools maintainer has forked the abandoned net-tools code base and started developing it again, after 15 years of stasis. As a design choice he has changed the output of most commands, hence breaking many scripts parsing their output. With this post I

Accepted ifmail 2.14tx8.10-23 (source i386 all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Dec 2016 04:40:59 +0100 Source: ifmail Binary: ifmail ifgate ifcico Architecture: source i386 all Version: 2.14tx8.10-23 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

Accepted kmod 23-2 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Dec 2016 03:42:54 +0100 Source: kmod Binary: kmod libkmod2 libkmod-dev libkmod2-udeb Architecture: source i386 Version: 23-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

Accepted netbase 5.4 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Dec 2016 02:56:39 +0100 Source: netbase Binary: netbase Architecture: source all Version: 5.4 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

compression support in kmod

Do we want it or not? And if we do, should we support gzip, XZ or both? From time to time some user requests enabling this feature, but since Debian kernels do not use it I am not sure that it is a good idea to add one or two library dependencies to kmod. -- ciao, Marco signature.asc

Accepted tcp-wrappers 7.6.q-26 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 26 Dec 2016 00:08:55 +0100 Source: tcp-wrappers Binary: tcpd libwrap0 libwrap0-dev Architecture: source i386 Version: 7.6.q-26 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

Accepted tin 1:2.4.1-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 25 Dec 2016 22:44:05 +0100 Source: tin Binary: tin Architecture: source i386 Version: 1:2.4.1-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted usrmerge 13 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 12 Dec 2016 05:23:20 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 13 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Bug#843073: dpkg-shlibdeps fix for merged /usr

On Nov 21, Guillem Jover wrote: > First I have to go over a list of queued pending items and then I'll > get to this during this week. I have not yet reviewed the patches (in > part because I didn't do much Debian stuff last week due to lack of > motivation after an

Re: Bug#843073: Debian Installer Stretch Alpha 8 release

On Nov 21, Guillem Jover wrote: > Oh, and forgot to mention, this issue has been known for over 8 > months, and now there's this need to be pushy and rush things, etc. > I certainly do not appreciate that. No, not really: it was not clear (e.g. I could never reproduce it)

Re: OpenSSL 1.1.0

On Nov 19, Simon Richter wrote: > My dream solution at this point would be to organize a week-long > hackfest somewhere where we move everything to GnuTLS if possible. I do not think that anybody has been considering GnuTLS as a credible replacement for a very long time. A few

Re: OpenSSL 1.1.0

On Nov 19, Stefan Fritsch wrote: > plugin messes with those internals. For example, for apache2 there is > gridsite > which uses mod_ssl private interfaces and a private copy of a header from the > apache2 sources to get access to the SSL context. Finding all such issues in

Re: OpenSSL 1.1.0

On Nov 16, Pau Garcia i Quiles wrote: > * Some obscure feature (e. g. BlaBla20) may be missing or be difficult > to support on a limited number of packages (e. g. apache2) ChaCha20 is hardly obscure: if it is to you then I fear that your opinion on this issue is not

Re: OpenSSL 1.1.0

On Nov 14, Lisandro Damián Nicanor Pérez Meyer wrote: > And yes, I would step back and switch libssl-dev to provide libssl1.0-dev and > have libssl1.1-dev around for anyone who can really do the switch. I would not: OpenSSL 1.0 does not support ChaCha20 so it would be a

Re: Debian Installer Stretch Alpha 8 release

On Nov 13, Helmut Grohne wrote: > Thus I think that debootstrap should revert to unmerged /usr until > dpkg-shlibdeps has been fixed. Fixing is non-trivial and likely requires > an archive rebuild on several architectures. Not really: dpkg-shlibdeps just needs to be fixed to

Re: Issues when building armhf packages in sid chroot with merged-usr

On Nov 10, Uwe Kleine-König wrote: > I tried to build the experimental linux package on an armhf machine > using sbuild. It failed (after 7 hours, sigh) with: This looks like #843073. -- ciao, Marco signature.asc Description: PGP signature

Re: Lots and lots of tiny node.js packages

On Nov 01, Ian Jackson wrote: > Can you explain why you don't aggregate these into bigger packages, > for use in Debian ? Because the node.js ecosystem is toxic and broken in encouraging relasing software which embeds very specific versions of lots of tiny

Accepted tin 1:2.4.0-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Mon, 31 Oct 2016 00:17:20 +0100 Source: tin Binary: tin Architecture: source i386 Version: 1:2.4.0-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted kmod 23-1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Tue, 27 Sep 2016 01:40:32 +0200 Source: kmod Binary: kmod libkmod2 libkmod-dev libkmod2-udeb Architecture: source i386 Version: 23-1 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

Accepted whois 5.2.13 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 30 Oct 2016 17:08:07 +0100 Source: whois Binary: whois Architecture: source i386 Version: 5.2.13 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Planned NMU of w3-recs would use much archive disk space

On Oct 27, "Thaddeus H. Black" wrote: > Unfortunately, without an NMU, this package would not be very > useful to stretch users. > > I'd do what I could to trim the size, but this NMU will be big > no matter what I do. > > Advice? Objections? What is the purpose of this

Re: Keysafe dynamic UID

On Oct 23, Guillem Jover wrote: > I think the solution here is pretty clear. The _-prefix is neutral, > short and used by other sytems. The Debian-prefix makes names way > long (used(?) to cause problems on display), is a Debianism that > seems wrong on non-Debian systems,

Re: When should we https our mirrors?

On Oct 17, Ian Campbell wrote: > Have we gotten to the point where we consider deb.d.o suitable for > production use? The web page still says Experimental (so I would assume I do not think that it is appropriate for general use, since at least one of the CDNs backing it lacks

Re: When should we https our mirrors?

On Oct 15, Dimitri John Ledkov wrote: > I believe the TLS overhead costs are negligible, especially if one This is not about the TLS overhead: the real issue is not being able to use sendfile(2). > uses ECC keys. The further privacy it buys one, is IMHO, well worth > the

Accepted usrmerge 12 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Thu, 29 Sep 2016 18:42:37 +0200 Source: usrmerge Binary: usrmerge Architecture: source all Version: 12 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Reupload package already in the NEW queue

On Sep 20, Thibaut Paumard wrote: > Since it is in the queue, I have been able to improve it. The > improvements add evenmore binary packages to this source package, so > the new version would need to go through NEW again in any case. I would just upload a new package by

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Sep 14, Felipe Sateler wrote: > I agree that merging /usr is a good thing to do. We should default to > that, and at some point force the merge somehow (via the usrmerge package? To be fair, I have implemented this as a switch only because I expected that somebody would

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Sep 15, Adam Borowski wrote: > I think it would be worthwhile to split up and move parts of /var as well. This is out of scope for this thread, so please let's discuss your proposals at a different time. -- ciao, Marco signature.asc Description: PGP signature

Re: Support for merged-/usr now in debootstrap; default for stretch?

On Sep 14, Ansgar Burchardt wrote: > One can also test installations using d-i.  The images from [1] already Just to be clear: merged-/usr can be tested on an existing system by installing the usrmerge package. -- ciao, Marco signature.asc Description: PGP signature

Re: lirc and new upstream release, can we update?

On Sep 14, Gianfranco Costamagna wrote: > I got a (back to january), a nice review with an "ETOOBUSY, come back on > june" or whatever > and now it is september and freeze is approaching... > I would like to avoid a new stable with the old libirman/lirc Please just

Re: lirc and new upstream release, can we update?

On Sep 11, Gianfranco Costamagna wrote: > 2) would it be possible to create a lirc-ng package and > conflict with the current one, so people can choose the best one for > them? No. > 3) NMU in unstable seems unfair and possibly a source of troubles for > such a complex

Re: Is missing SysV-init support a bug?

The fun thing is that if the original poster had just shipped an half-broken script nobody would have ever noticed, and in a couple of years it would have been another data point about the irrelevance of sysvinit nowadays. As long as the package builds, don't bother... :-) -- ciao, Marco

Re: Is missing SysV-init support a bug?

On Aug 26, Carsten Leonhardt wrote: > Considering the past conflicts on the topic of systemd, it should be > expected that there is a considerable user base that is staying with > sysvinit or another alternative. Barely noticeable:

Re: ifupdown2: debconf followup

On Aug 01, Guus Sliepen wrote: > The time spent writing such a hypothetical tool would then be better > spent keeping support for ifupdown in the installer for the non-Linux > platforms. I agree: if the Hurd/kFreeBSD porters will be able to keep sysvinit on life support then

Re: ifupdown2: debconf followup

On Aug 01, Lars Wirzenius wrote: > > Sorry, what I actually meant was "every non-toy Debian system". > we get that you have strong preferences. However, could you please > avoid inflammatory language when talking about anything that isn't > according to your preferences? Reasonable

Re: ifupdown2: debconf followup

On Aug 01, Adam Borowski wrote: > > We should also think hard about switching to a new default since > > currently many other major distributions are moving to NetworkManager > > and/or systemd-networkd (which nowadays is usable, works well for > > simpler use cases and

Re: ifupdown2: debconf followup

On Aug 01, Guus Sliepen wrote: > I see one big drawback of ifupdown2, and that is that it's written in > Python. Nothing wrong with that language, but it means it pulls in > dependencies which a minimal install currently doesn't require, which is > not so nice for people running

Re: Bug#830983: ITP: field -- extracts a list of fields from a file

On Jul 13, Trevor Bramwell wrote: > field it is a simpler version of: > > awk '{ print $5,$3,$1; }' Do we really need this trivial program which barely saves typing a few characters, especially in a standalone package? Also, what is wrong with cut(1)? -- ciao,

Re: Bug#830624: ITP: xplayer -- Simple media player based on GStreamer.

On Jul 09, Emilio Pozuelo Monfort wrote: > Do we really need yet another fork of GNOME? Probably not, but I suspect that this problem should be solved upstream... -- ciao, Marco signature.asc Description: PGP signature

Re: Replacing web assets with symlinks to packaged versions

On Jul 09, Enrico Zini wrote: > Could we have another LD_PRELOAD hack that replaced instances of > jquery.min.js to symlinks to libjs-jquery contents? Probably not, because some upstream maintainer will want to depend on a specific release of the library. -- ciao, Marco

Re: Installer of Debian Stable allows to use btrfs for /, does it mean it's mature enough to use safely?

On Jul 08, Russ Allbery wrote: > And of those two choices, I would lean heavily towards ext4. I have seen > repeated file system corruptions, kernel panics, and file systems that get > extremely slow after heavy usage for multiple months under XFS, and have > not seen any of

Re: howto avoid "apt-get update" going guru?

On Jul 06, Tollef Fog Heen wrote: > I personally recommend using deb.debian.org. I do not, since it does not have local nodes in my country. -- ciao, Marco signature.asc Description: PGP signature

Re: opinions of snappy packages

On Jun 22, Lars Wirzenius wrote: > Given that snapd therefore seems to be, in practice, only usable by > Canonical's server, shouldn't the package be in contrib instead of > main? No: this was discussed the first time ~15 years ago IIRC for ICQ clients, and I do not think that

Re: opinions of snappy packages

On Jun 19, Josh Triplett wrote: > of that overhead relates to following distribution-specific policies. The > prevalence of language-specific packaging ecosystems, such as npm and > Cargo, suggests a need not fully addressed by distribution packaging > formats. At least

Re: Genesis of the git.d.o/gitlab.d.o confusion (Was: Next steps for gitlab.debian)

On Jun 08, Luca Filipozzi wrote: > Let me rephrase, then: can we have a plan that addresses alioth / git / > gitolite / gitlab / stuff rather than standing up yet another SCM/PM tool > because it's shiny? Since usability is the main reason many people hate using alioth,

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

On Jun 06, Pirate Praveen wrote: > - setup gitlab.debian.net on jessie with my personal repo added. > - how do I add a machine? > - Do we have a preferred hosting provider? > - move to gitlab.debian.org after stretch release. Can we use gitlab.debian.org from the

Re: many tiny tiny node.js packages

On Jun 05, Jonathan Ulrich Horn wrote: > > I'm rather wondering > > how to deal with an ecosystem where it seems to be normal to release > > tiny tiny packages… > I ask myself more and more if it does make sense to have those tiny > packages in debian. Me too, also

Re: Detecting install vs upgrade in postinst

On Jun 05, Ben Hutchings wrote: > The postinst script for linux-image-* behaves differently on fresh > installation vs upgrade.  For a fresh installation, it updates the > default symlinks /vmlinuz and /initrd.img to point to the new kernel > and initramfs versions.  On

Re: Dropping upstart jobs (or not)

On Jun 04, Marc Haber wrote: > Another piece of diversity lost in the open source world. http://www.islinuxaboutchoice.com/ > systemd is winning the war. You are wrong: this war was won long ago:

Re: Bug#824884: netbase: should not recommend ifupdown

On May 22, "Iain R. Learmonth" wrote: > What is the upstream source for the /etc/services file? Do we just I am... > maintain that in Debian or are updates incorporated from IANA and > unofficial port numbers? I do not use the official IANA list because it is huge and full of

Re: Bug#824884: netbase: should not recommend ifupdown

Does anybody see a reason to NOT remove the recommends? On May 20, Ansgar Burchardt wrote: > netbase should not recommend ifupdown. Currently any package > depending on netbase will install ifupdown and a dhcp client if > recommends are installed, see [1]. > > As ifupdown

Re: Debian i386 architecture now requires a 686-class processor

On May 11, Russ Allbery wrote: > NEWS.Debian was the solution created for that problem, and it's not bad. > It can be a bit too verbose in a few cases, but it's almost always worth > reading carefully. It would help if more people opened bugs on packages with NEWS.Debian

Re: Time to reevaluate the cost of -fPIC?

On May 03, Josh Triplett wrote: > While this doesn't make PIC absolutely free, it does eliminate almost > all of the cost, to the point that it no longer seems worthwhile to > build without -fPIC. Apart from that, building *all* code with -fPIC > (including both programs

Re: Packaging of static libraries

On Apr 13, Ian Jackson wrote: > We in Debian are in a good position to defend our users from the > fallout from this problem. We could change our default compiler > options to favour safety, and provide more traditional semantics. Which would not solve any

Re: Remove clamav-unofficial-sigs

On Apr 05, Francois Gouget wrote: > clamav-unofficial-sigs is broken and not maintained anymore. So unless > something changes there is no point leaving it in the repository. I was discussing this yeasterday with Paul. While the current package has some issues I believe that it

Re: Debian package on Windows

On Mar 31, Stefano Zacchiroli wrote: > I think we should. It will help Windows users use less proprietary > software in their daily lives, and my very well work as a "gateway drug" > to 100% Free Software in the long run. Agreed. -- ciao, Marco signature.asc Description: PGP

Re: Bug#819500: general: Debian 8.3 CLI reboot using "init 6" shows username & password in plain text.

On Mar 30, Roger Shimizu wrote: > Not sure which to blame, but assign to systemd first, since it's Yes, we systemd maintainers really love this. -- ciao, Marco signature.asc Description: PGP signature

Re: -flto to become more of a routine - any change in opinion since 2011?

On Mar 29, Steffen Möller wrote: > Spending most of my Debian time with scientific packages, I see a gain > of speed on those routines as particularly rewarding. And this may also > be a feature that would attract many to our platform as an extra > advantage over the

Accepted whois 5.2.12 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 29 Mar 2016 05:33:10 +0200 Source: whois Binary: whois Architecture: source i386 Version: 5.2.12 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: a poll for Dgit workflows

On Mar 24, Ian Jackson wrote: > But I think that someone who knows how to use git should be able to > get the source code for a package in Debian, as a git branch, and > modify that source code, and share it, and so on, without needing to > deal with quilt, or

Re: a poll for Dgit workflows

On Mar 23, Ian Jackson wrote: > Obviously, for dgit to be useful, it has to define a standard > interchange format. That format has to be patches-applied because > otherwise naive users can't work with the source code properly. Having the alleged needs of naive

Re: a poll for Dgit workflows

On Mar 22, Barry Warsaw wrote: > Aside: I do like separating Debian deltas from upstream pristine source > because I find them easier to track as upstream changes. So I'm still a fan > of 3.0-quilt but I understand the problems involved, and I'm sure there's a > git-ier way of

Accepted usrmerge 11 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Tue, 15 Mar 2016 08:42:53 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 11 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted usrmerge 10 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 28 Feb 2016 02:02:03 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 10 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted debootstrap 1.0.78+nmu1 (source all) into unstable

n-b...@lists.debian.org> Changed-By: Marco d'Itri <m...@linux.it> Description: debootstrap - Bootstrap a basic Debian system debootstrap-udeb - Bootstrap the Debian system (udeb) Closes: 813232 Changes: debootstrap (1.0.78+nmu1) unstable; urgency=medium . * Non-maintainer upload. * Split s

Re: migrating to Debian gitlab (was: Re: GitLab B.V. to host free-software GitLab for Debian project)

On Feb 15, Pirate Praveen wrote: > More systemd troubles. > > While trying to move files that are created at runtime to /var, > I realized /var/run/gitlab won't persist across reboots. I have added This is not related to systemd, BTW. -- ciao, Marco signature.asc

Accepted xfsprogs 4.3.0+nmu1 (source amd64) into unstable

com> Changed-By: Marco d'Itri <m...@linux.it> Description: xfslibs-dev - XFS filesystem-specific static libraries and headers xfsprogs - Utilities for managing the XFS filesystem xfsprogs-udeb - A stripped-down version of xfsprogs, for debian-installer (udeb) Closes: 766811 Changes: xfs

Accepted usrmerge 9 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 10 Feb 2016 04:56:33 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 9 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Accepted musl 1.1.9-1.1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 06 Feb 2016 01:12:33 +0100 Source: musl Binary: musl musl-dev musl-tools Architecture: source i386 Version: 1.1.9-1.1 Distribution: unstable Urgency: medium Maintainer: Kevin Bortis <p...@bortis.ch> Changed-By: Marco d'I

cena italiana a FOSDEM

Ci vediamo per cena sabato? -- ciao, Marco signature.asc Description: PGP signature

Accepted davfs2 1.5.2-1.2 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sun, 24 Jan 2016 19:17:12 +0100 Source: davfs2 Binary: davfs2 Architecture: source i386 Version: 1.5.2-1.2 Distribution: unstable Urgency: medium Maintainer: Luciano Bello <luci...@debian.org> Changed-By: Marco d'Itri <m...

Accepted usrmerge 8 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Fri, 22 Jan 2016 07:07:50 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 8 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Having a single, good arc4random in Debian

On Jan 18, Steven Chamberlain wrote: > More background information follows. What do others think about going > in this direction; the Debian Security Team in particular? Thanks! The same issue was discussed recently for the MD5 functions. The first step is to create a

Re: Going ahead with non-free-firmware

On Jan 15, chrysn wrote: > Right now microcode does not fit in that middle ground from either 1) > (because no DMA to protect us) nor 2) (because things work without as > well). If, at some future point in time, CPUs do require microcode > updates, we might need to revisit this.

Accepted usrmerge 7 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 16 Jan 2016 03:51:37 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 7 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: Going ahead with non-free-firmware

On Jan 11, Paul Wise wrote: > FYI: there are people out there who are still angry at ESR/OSI for > hijacking the term "open source" to mean essentially the same thing as > "Free Software" instead of what they used it for; anything with > publicly released source code. Actually

Re: Going ahead with non-free-firmware

On Jan 09, Dominic Hargreaves wrote: > On Sat, Jan 09, 2016 at 11:51:08AM +0100, Ansgar Burchardt wrote: > > I think there was consensus to introduce the non-free-firmware section > > and move the non-free firmware blobs there. I'm wondering what we need > > to do next? > I

Re: Going ahead with non-free-firmware

On Jan 09, Matthias Klumpp wrote: > I wonder if we should widen the scope of a "non-free-firmware" > component a little, to "anything non-free you sometimes unfortunately > need to make your hardware usable". > This would mean having a "non-free-hardware" section instead,

Accepted inn2 2.6.0-2 (source amd64) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Format: 1.8 Date: Sun, 10 Jan 2016 03:43:00 +0100 Source: inn2 Binary: inn2 inn2-lfs inn2-inews inn2-dev Architecture: source amd64 Version: 2.6.0-2 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By:

md5(3bsd) (was: Re: support for merged /usr in Debian)

On Jan 08, Robert Edmonds wrote: > If it really does need to do MD5, maybe it could use the one in libbsd0 > instead of dragging in libgnutls-openssl27 and its dependencies. I did not notice this recent addition... Folks, there is *a lot* of software which embeds copies of

Accepted usrmerge 6 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Sat, 09 Jan 2016 04:33:13 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 6 Distribution: unstable Urgency: high Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...@linux.it>

Re: support for merged /usr in Debian

On Jan 08, Marc Haber wrote: > important functionality maked as "broken", "obsolete" and eventually > removed, just as the keyscript= feature of /etc/crypttab was lost a > year ago (noone cared). Let's be clear here: nobody cared enough to implement it. It was

Re: support for merged /usr in Debian

On Jan 08, Paul Wise wrote: > The idea was for those who don't want an initramfs or can't use an > initramfs (someone mentioned some Debian platforms can't) but still All platforms can use an initramfs. It has been said that some have[citation needed] crappy boot loaders that

Accepted xfsdump 3.1.6+nmu1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 07 Jan 2016 22:44:28 +0100 Source: xfsdump Binary: xfsdump Architecture: source i386 Version: 3.1.6+nmu1 Distribution: unstable Urgency: medium Maintainer: Nathan Scott <nath...@debian.org> Changed-By: Marco d'I

overlayfs (was: Re: support for merged /usr in Debian)

On Jan 06, Jonathan Dowland wrote: > Do you mean overlayfs? If so can you or anyone vouch for its quality? > I had been trying it as a docker storage back end and generally found > that it was not ready yet. Can you be more specific? I only use it to test new packages and it

Accepted davfs2 1.5.2-1.1 (source i386) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Wed, 06 Jan 2016 16:42:09 +0100 Source: davfs2 Binary: davfs2 Architecture: source i386 Version: 1.5.2-1.1 Distribution: unstable Urgency: medium Maintainer: Luciano Bello <luci...@debian.org> Changed-By: Marco d'Itri <m...

Re: vlan support en* or br*?

On Jan 06, Andreas Henriksson wrote: > (PS. Now if we could only replace net-tools with a similar wrapper > script and finally deprecate the ioctl based tools there as well. ;P) We should hunt down and fix the few packages still depending on net-tools (hello bind9!). --

Accepted usrmerge 5 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Thu, 07 Jan 2016 02:55:40 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 5 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

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

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

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

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

Accepted usrmerge 4 (source all) into unstable

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.8 Date: Mon, 04 Jan 2016 05:12:46 +0100 Source: usrmerge Binary: usrmerge Architecture: source all Version: 4 Distribution: unstable Urgency: medium Maintainer: Marco d'Itri <m...@linux.it> Changed-By: Marco d'Itri <m...

Re: support for merged /usr in Debian

On Jan 03, Eric Valette wrote: > The debian installer should first loudly warn that having a separated / and > /usr may break things in the future but not forbid it. With that in place, This is not true: you just need to use an initramfs. "I have always done this in a

Re: support for merged /usr in Debian

On Jan 03, Eric Valette wrote: > >This is not true: you just need to use an initramfs. > Ok, so it should warn that this setup will soon require to use an initramfs. It is the Debian default, there is no need to do this. > Same for your proposal : nothing really sound

Re: support for merged /usr in Debian

On Jan 03, Simon Richter wrote: > > "I have always done this in a different way" is not a valid use case, > > sorry. > "Compatibility" is a very valid use case. Debian is famous for backwards > compatibility and trouble-free upgrades. Requiring to use an initramfs in some

Re: support for merged /usr in Debian

On Jan 03, Andreas Henriksson wrote: > First, it would be nice to have a preinst check if the system has any > running services that uses ProtectSystem and offer a choice to stop > (and restart) them in case having them running is really a problem... I will think about this, I

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

<    1   2   3   4   5   6   7   8   9   10   >