Re: Current and upcoming toolchain changes for jessie
* Matthias Klose: glibc's version bump to 2.17 should be mostly uneventful, with the exception of a few more compiler warnings and errors, and the long overdue removal of gets() from the API. FTBFS bugs for the above have already been filed, and patches submitted for many of the new build failures. fd_set fortification might introduce some run-time failures. Upstream is discussing a patch which allows to selectively disable that part of source fortification, see fix wrong program abort on __FD_ELT here: http://sourceware.org/ml/libc-alpha/2013-05/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87bo8m80q9@mid.deneb.enyo.de
Re: Current and upcoming toolchain changes for jessie
* Roger Leigh: On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: The decision when to make GCC 4.8 the default for other architectures is left to the Debian port maintainers. This makes using C++11 and other features only in 4.8 rather difficult. C++11 hasn't got a stable API yet (implying mass rebuilds on compiler updates). Do we really want to encourage its use at this point? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/877gja80m8@mid.deneb.enyo.de
Re: /srv (was /export)
2013/5/8 Thorsten Glaser t...@debian.org: Игорь Пашев pashev.igor at gmail.com writes: What about moving default location for applications to /export ? *NO*! Maybe not /export, but /srv, which already exists, the idea is separating system data and application data. (Actually, I do not like /export, because of /etc and tab completion ;-) And probably /export is wrong place for this :-/ [1] We do not need *more* such non-Unixy, FLOS, nōnsense! I seem to understand you’re coming from Solaris here, which has a history of doing weird things like that…? Please, no. I know how weird Solaris is, no need to tell me :-) But referring to true-UNIX also does not make any sense. [1] http://lists.linux-foundation.org/pipermail/fhs-discuss/2011-May/000158.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8zknircpf1l1dvtmbge-rg1pdgt3slrbjfjx2tkm2k...@mail.gmail.com
Re: /export (was Re: jessie release goals)
2013/5/8 Peter Samuelson pe...@p12n.org: Wrong list, please bring this up instead on fhs-discuss. (If that still exists - it looks a bit stale - but anyway, debian-devel is not for FHS discussion.) I'd like to have an open discussion. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8z8mjonp88vmvm1_xuqwtjawu53gkdeertuwefjv8e...@mail.gmail.com
Re: /export (was Re: jessie release goals)
On 05/08/2013 01:54 AM, Игорь Пашев wrote: Currently /var/lib contains data for system utilities (dpkg, apt, aptitute) and for user application like databases. What about moving default location for applications to /export ? Think about modern fs like btrfs and zfs: One may want to create a snapshot of the entire system, user data should not get into such a snapshot, but, of course, /usr along with dpkg database - should. Again, the idea is to move all user data away from /var/lib How about moving /etc into /home? How about moving /home into /usr? How about deleting all the HDD content, and switching to vfat by default? Or getting rid of unix rights (too complicated?)? Seriously, please stop... My filesystem is ok the way it is, I don't want it to change so much that absolutely every package will be impacted. For the above, it's fixed by having a separate partition for /var/lib (which I often do). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518a0405.2070...@debian.org
Re: /export (was Re: jessie release goals)
2013/5/8 Thomas Goirand z...@debian.org: How about moving /home into /usr? I proposed exactly an opposite thing for databases :-) If do not like /usr/home, you might not like to have your data under /var/lib ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALL-Q8ypHeC=aqnsvfwwqbya7ohk6zu5zh4ye0efsv4dyc8...@mail.gmail.com
Re: /export (was Re: jessie release goals)
Le mercredi 08 mai 2013 à 11:59 +0400, Игорь Пашев a écrit : I proposed exactly an opposite thing for databases :-) If do not like /usr/home, you might not like to have your data under /var/lib ;-) The FHS has the perfect place for such data: /srv. I agree we should move the data there, but there is no reason to invent a new place. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368000694.4717.3.camel@tomoyo
Re: /export (was Re: jessie release goals)
On Wed, May 08, 2013 at 03:51:33PM +0800, Thomas Goirand wrote: How about moving /etc into /home? How about moving /home into /usr? Note that / was moved to /usr and /usr to /home just for HDD size reasons [1]. [1]: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508081132.ga30...@belkar.wrar.name
Re: epoch fix?
Le mercredi 08 mai 2013 à 05:04 +, Bart Martens a écrit : Michael Biebl wrote : The usage of really (...) that you don't have to fix all r-deps to include the the epoch in the Build-Depends. Why would adding an epoch cause the need for adding the epoch in the build-dependent packages ? Because otherwise these build-dependent packages will not bring the version they actually need? You know, what build-dependencies are for. -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368000988.4717.4.camel@tomoyo
Re: /export (was Re: jessie release goals)
2013/5/8 Josselin Mouette j...@debian.org: The FHS has the perfect place for such data: /srv. I agree we should move the data there, but there is no reason to invent a new place. Yeah. /export was my typo ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8wu-tv86ab_2i1gham3m+t1jjvmso3-+c4c37_fccx...@mail.gmail.com
Re: /export (was Re: jessie release goals)
2013/5/8 Andrey Rahmatullin w...@wrar.name: On Wed, May 08, 2013 at 03:51:33PM +0800, Thomas Goirand wrote: How about moving /etc into /home? How about moving /home into /usr? Note that / was moved to /usr and /usr to /home just for HDD size reasons [1]. [1]: http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Separating system and user data now make sense for other reasons. but still makes sense: compression, encryption, mirroring, easy system reinstall, etc. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8xjun1vxkdsmj3u4c9fowvjmbqvnzselr56sfhrzvr...@mail.gmail.com
Re: epoch fix?
Bart Martens bartm at debian.org writes: Michael Biebl wrote : The usage of really (...) that you don't have to fix all r-deps to include the the epoch in the Build-Depends. Why would adding an epoch cause the need for adding the epoch in the build-dependent packages ? Interestingly enough, I was just thinking about writing a message that said something to the point of, using “really” for a once-off botched upload would be okay. Then I considered versioning on the r-deps. Now imagine the following: • foo 1.0-1 uploaded • bar 1.0-1 uploaded, depends on foo-dev (= 1.0) • foo 1.1-1 uploaded • bar 1.1-1 uploaded, depends on foo-dev (= 1.1) • foo 1.1-1really1.0-1 uploaded That’s a massive “oops” in both cases. Funnily enough, using the epoch will, yes, force an update of all r-deps, BUT it’s the only sane way for the r-deps because otherwise the saga continues: • bar 1.1-2 uploaded, depends on foo-dev (= 1.1), foo-dev ( 1.1-1really1.0-1~) | foo-dev (= 1.1-2~) • foo 1.1-2 uploaded • foo 1.1-2really1.1-1 uploaded……… For r-deps it’s much clearer if you use epochs. It’ll disallow some versions, but it’s easier to see what’s really depended on. Also, once a r-dep includes the “really” it gets visually uglier too. (It’s bad enough we have build-depends with Ubuntu version numbers in them, but I can understand that too.) I agree with that. I think version ordering should be preserved forever. This is also an interesting point, yes. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130508t101613-...@post.gmane.org
Re: epoch fix?
Kurt Roeckx kurt at roeckx.be writes: Not sure what a clean way of escaping the colon would be. apt already saves it with %3a in /var/cache/apt/archives/ %2a IIRC… but I consider this a bug personally and think apt should construct the filenames for the cache the same way the original official .deb building process does. Also, the percent sign is not usually handled well in filenames on “other OSes” either. bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/loom.20130508t102506...@post.gmane.org
Re: epoch fix?
Le mercredi 08 mai 2013 à 08:23 +, Thorsten Glaser a écrit : Now imagine the following: • foo 1.0-1 uploaded • bar 1.0-1 uploaded, depends on foo-dev (= 1.0) • foo 1.1-1 uploaded • bar 1.1-1 uploaded, depends on foo-dev (= 1.1) • foo 1.1-1really1.0-1 uploaded That’s a massive “oops” in both cases. Indeed, thanks for showing epochs don’t bring anything useful here. Funnily enough, using the epoch will, yes, force an update of all r-deps, BUT it’s the only sane way for the r-deps because otherwise the saga continues: • bar 1.1-2 uploaded, depends on foo-dev (= 1.1), foo-dev ( 1.1-1really1.0-1~) | foo-dev (= 1.1-2~) WTF? Just bar 1.1-2 depends foo-dev (= 1.1-2~) • foo 1.1-2 uploaded • foo 1.1-2really1.1-1 uploaded……… Yeah sure, because in this case the foo maintainer is too stupid to remember his lesson, and does the same mistake *again* 2 days later. How about talking about real cases instead of completely made-up stuff that doesn’t have any relevance? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1368002093.4717.8.camel@tomoyo
Re: jessie release goals
On 7 May 2013 05:38, Stephen Kitt sk...@debian.org wrote: Hi Wookey, On Tue, 7 May 2013 03:04:50 +0100, Wookey woo...@wookware.org wrote: (just a decision to leave arch-independent headers in /usr/include and move arch-dependent headers to /usr/include/triplet). Doesn't this limit us to cross-compiling only across Debian architectures? If we go for a full /usr/include/triplet split (in the same way as for libraries) we could support cross-compiling to anything with the same structure - I'm thinking MinGW-w64 here of course, but I imagine it would apply to other targets too, some of which are supported in Debian already using the /usr/triplet/include directories. I for one believe that MinGW-w64 should become partial architectures on debian (both 32 and 64bit variants... and arm?! =) ). Partial as it would use linux kernel + wine for runtime. Having mingw as an arch will greatly make it easier to provide an up-to-date archive of deb package that one would reasonably would want to cross-compile against. And with some luck and NSIS magic create .exe installers to redistributed compiled packages to Windows. I am patiently waiting for bug #606825 dpkg: Please add mingw to ostable and triplettable. To be fixed. As well there is interest in developing i686/x86_64-w64-mingw32 [1] port. And doko has also informally voiced support for such a triplet name at last debconf. [1] Yes, exactly these i686/x86_64-w64-mingw32 and not other proposed combinations. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUi86xmNG=wwdqkx8b++vn2g5a3cwyzrvrywojoubz6...@mail.gmail.com
Re: Switching packages to non-awaiting triggers
Hi Guillem, On Tue, 07 May 2013, Guillem Jover wrote: Examples of this are man pages (#707129) or info documents (#707133), others could be menu, desktop or dictionary triggers, but that depends on how the triggering packages make use of them. I'd be glad if people who know any package registering triggers could mention if they think those could be switched. Reporting bugs afterwards or even handling the switch directly for those would be much appreciated. :) When I implemented those -noawait variants, I contacted various maintainers about their usage of the trigger. Only a handful answered that they had to keep the current directive: fontconfig gconf gdk-pixbuf glib2.0 iceape octave3.2 wims (and even in some of those, the concerns are purely theoric at it's unlikely to break installation of packages depending on trigger-awaited packages but could lead to run-time failures for users starting the application) Many answered that they could use -noawait: ccache cracklib2 desktop-file-utils (delay in mime database update, that's all) gap ghc6 (only for compilation in postinst) gnome-icon-theme gnome-menus grace guile-1.8 hicolor-icon-theme ibid lintian man-db menu nevow ntfs-3g nvidia-graphics-drivers pdl php5 postgresql-common protoaculous python-support (will go away anyway) resolvconf rkhunter rygel texinfo unhide unhide.rb xpdf yorick And all the others didn't respond. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508083700.gb15...@x230-buxy.home.ouaza.com
Re: Switching default dpkg-deb compressor to xz
Hi, On Tue, 07 May 2013, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ [...] currently?). Otherwise I'll be doing the change with the dpkg 1.17.0 upload. I agree that we have such a consensus. There was a time where d-i was not ready, but nowadays udeb are compressed with xz and busybox's xz is used in that context. Please go ahead with this change (unless some other valid concerns are raised that is). Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508084643.gc15...@x230-buxy.home.ouaza.com
Re: epoch fix?
On 05/08/2013 11:27 AM, Adam Borowski wrote: On Wed, May 08, 2013 at 09:46:02AM +0800, Thomas Goirand wrote: What I think should be fixed is the fact that it doesn't appear in the filename. I never understood why they don't. Did I miss something? Having a colon in CD/DVD images is likely to cause problems, with the chance of breakage reaching 100% if there's Windows nearby. Not sure what a clean way of escaping the colon would be. We don't *have* to use a semi-colon on the file names, if that char is a problem. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518a15d6.8010...@debian.org
Re: Switching default dpkg-deb compressor to xz
On 8 May 2013 01:46, Raphael Hertzog hert...@debian.org wrote: Hi, On Tue, 07 May 2013, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ [...] currently?). Otherwise I'll be doing the change with the dpkg 1.17.0 upload. I agree that we have such a consensus. There was a time where d-i was not ready, but nowadays udeb are compressed with xz and busybox's xz is used in that context. Please go ahead with this change (unless some other valid concerns are raised that is). A while back I have raised a proposal on debian-devel, to include a facility to opt-out of compressing packages. As a DEB_BUILD_OPTIONS for example or via some other mechanism. Personally I have seen a great build-time reduction, whilst doing test builds (or slow builds on arm panda board / qemu), or whist doing a noopt nostrip builds as all of these builds are usually local and one may just one to have the package simply sooner. I have spotted an independent implementation in an ubuntu's pkg-kde-tools (not sure if it's in debian one as well, at least it's not in the experimental upload) that defaults to xz, yet honours DEB_NO_XZ and DEB_NO_COMPRESSION environmental variables to disable such compression. Thinking more generically than last time around, would it be ok to propose ability to set / override dpkg-deb compression options via DEB_BUILD_OPTIONS? It would greatly simply rebuilding with no compression / alternative algos and settings. In particular it will ease to identify packages that do _not_ benefit from additional compression and/or perform better under non-default compression setting. I'm thinking of infamous openclipart, the one that has all images pre-compressed and a couple dozen of other similar packages. Should I open a bug and propose a change to debian-policy? Or do we need to bikeshed more about this? Last time around there was no significant arguments to not have such a facility. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANBHLUjmD9Cf07Lm_WnioQnhJgAFUn_cOGqYGa6t-Ct5J=b...@mail.gmail.com
Re: Switching default dpkg-deb compressor to xz
Hi, On 05/07/2013 21:49, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ [0] http://lists.debian.org/debian-devel/2012/08/msg00822.html Do you plan to switch the default compression for source packages to xz as well? Ansgar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518a1833.9050...@debian.org
Re: epoch fix?
On Wed, May 08, 2013 at 08:26:13AM +, Thorsten Glaser wrote: Kurt Roeckx kurt at roeckx.be writes: Not sure what a clean way of escaping the colon would be. apt already saves it with %3a in /var/cache/apt/archives/ %2a IIRC… but I consider this a bug personally and think apt should construct the filenames for the cache the same way the original official .deb building process does. Also, the percent sign is not usually handled well in filenames on “other OSes” either. Could you give a list of filesystems and/or operating systems on which the percent sign is not allowed, or causes problems, in filenames? FAT, for example, is expected to allow % in filenames (https://en.wikipedia.org/wiki/8.3_filename#Directory_table). -- http://www.cafepress.com/trunktees -- geeky funny T-shirts http://gtdfh.branchable.com/ -- GTD for hackers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508092854.gg4...@mavolio.codethink.co.uk
Re: Switching packages to non-awaiting triggers
On Wed, May 8, 2013 at 10:37:00 +0200, Raphael Hertzog wrote: python-support (will go away anyway) Seems fairly unlikely that it will, actually, with 758 reverse build deps in sid as far as I can tell. Cheers, Julien signature.asc Description: Digital signature
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Fri, May 03, 2013 at 04:38:40PM +0200, Josselin Mouette wrote: Le vendredi 03 mai 2013 à 09:18 +0800, Chow Loong Jin a écrit : While we're at it, can we also have source-only uploads? Uploading potentially huge binary packages that just go to /dev/null seems like a pointless waste of bandwidth to me, and the only for argument I've heard (which I don't buy) is so that we know maintainers have test-built their packages. There is a solution to both the upload bandwidth problem and the the problem that buildd binaries are untested, but I???m afraid it implies changes to dak. This means configuring dak to accepting only two types of uploads: - source-only uploads They are pushed to the buildds, and the produced binaries (including arch:all) are put in a staging area (much like incoming.d.o). These binaries can be downloaded, but the .changes cannot (to forbid skipping the second step). - binary-changes-only uploads, without binaries The developer uploads a sole .changes referencing the set of binaries he has downloaded (and tested, although it is hard to force that step). Anything referencing binaries not built on the buildds is ditched. This way, you ensure that the actual binaries ending up in the archive have been tested, which is neither the case with just source-only uploads (no binaries tested) nor with ditched-binary uploads (the binary might be built in a different environment). Cheers, Firstly: We already know we can't trust all maintainers to build binaries in a clean chroot. Nor can we trust them to test binaries they upload. What makes you think maintainers will not simply blindly create changes files for buildd build binaries and upload them? Secondly: Maintainers will only test binaries for their own arch. Most archs won't get this extra test step so most uploaded debs will still remain untested. Overall it seems like that extra step will just create extra work for the maintainer at a time (hours, days, weeks after the upload) not of his choosing with little benefit to the user. Those maintainers that do properly test stuff will test the packages before doing the source only upload. And I have enough confidence in the autobuilders to produce working debs from a well tested source. It's not 100% but close enough. The rest will be cought in unstable quickly enough. Those maintainers that skip or even circumvent testing will always do so. And I would rather have buildd build debs there than whatever those maintainer manage to hack together to produce a deb. I've seen uploads with debs where the source had a make error in debian/rules. There is no way that source package could ever have produced the uploaded deb. At least those kind of errors would be eliminated. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508095359.GD13185@frosties
Re: epoch fix?
On Wed, May 08, 2013 at 10:28:54AM +0100, Lars Wirzenius wrote:
On Wed, May 08, 2013 at 08:26:13AM +, Thorsten Glaser wrote:
Kurt Roeckx kurt at roeckx.be writes:
Not sure what a clean way of escaping the colon would be.
apt already saves it with %3a in /var/cache/apt/archives/
%2a IIRC… but I consider this a bug personally and think apt
should construct the filenames for the cache the same way
the original official .deb building process does.
Also, the percent sign is not usually handled well in filenames
on “other OSes” either.
Could you give a list of filesystems and/or operating systems on which
the percent sign is not allowed, or causes problems, in filenames?
FAT, for example, is expected to allow % in filenames
(https://en.wikipedia.org/wiki/8.3_filename#Directory_table).
A test case (in a directory you can see via http://angband.pl/tmp/):
for x in : %3A %3a; do echo $x foo${x}bar;done
echo ok baz%3Aquux
Let's try to access a file with % :
wget -q -O- http://angband.pl/tmp/foo%3Abar
:
-- should be %3A !
But, perhaps Apache tests both? Let's see:
wget http://angband.pl/tmp/baz%3Aquux
--2013-05-08 11:45:22-- http://angband.pl/tmp/baz%3Aquux
Resolving angband.pl (angband.pl)... 2a03:9300:10::8, 89.206.35.136
Connecting to angband.pl (angband.pl)|2a03:9300:10::8|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-05-08 11:45:22 ERROR 404: Not Found.
Nope.
And serving .deb files via http isn't exactly a fringe use case...
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130508095548.ga29...@angband.pl
Re: Current and upcoming toolchain changes for jessie
On Wed, May 08, 2013 at 08:08:31AM +0200, Florian Weimer wrote: * Roger Leigh: On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: The decision when to make GCC 4.8 the default for other architectures is left to the Debian port maintainers. This makes using C++11 and other features only in 4.8 rather difficult. C++11 hasn't got a stable API yet (implying mass rebuilds on compiler updates). Do we really want to encourage its use at this point? While the C++11 API isn't completed in its entirety, a large proportion of it is complete, and as far as I am aware, the API for those parts is stable and there should be no issues at all with using these. For example: std::shared_ptr, std::unique_ptr, std::tuple in the standard library, and language features such as decltype, nullptr, range-based for loops etc. Other parts /are/ broken, such as std::regex; I'm a little surprised this is even present given its broken state, and the number of GCC bug reports relating to it reflect that! I don't see a problem with using a functional subset of it. I don't think that Debian is really in a position to influence whether or not upstreams use particular features of an ISO standard! They /are/ present and functional; they /will/ be used; any API/ABI issues (if any) will just need to be dealt with--it's part of libstdc++ already. I've moved schroot's development branch to use a conservative subset of C++11 supported by GCC 4.7 and greater, so that I can support its use in stable as well as testing and unstable. The compiler support for C++11 isn't an issue--it's present and working. Having a different version of GCC on different architectures definitely *is* a problem-- if an architecture can't have GCC 4.8 as the default, then maybe we shouldn't be considering it as a release architecture; and the same applies to binutils and the rest of the toolchain. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508095657.gn21...@codelibre.net
Re: jessie release goals
On Wed, 8 May 2013 03:57:20 +0100, Wookey woo...@wookware.org wrote:
+++ Wookey [2013-05-07 22:31 +0100]:
[right. 3rd attempt at getting this email to make sense. reposting the
whole thing this time, hopefully with no remaining howlers]
+++ Stephen Kitt [2013-05-07 14:38 +0200]:
Hi Wookey,
On Tue, 7 May 2013 03:04:50 +0100, Wookey woo...@wookware.org wrote:
(just a decision to leave arch-independent headers in /usr/include and
move arch-dependent headers to /usr/include/triplet).
Doesn't this limit us to cross-compiling only across Debian
architectures? If we go for a full /usr/include/triplet split (in the
same way as for libraries)
Libraries are always different for different architectures. Only a
fairly small subset of headers is, so you could say we are doing
exactly the same thing for both libaries and headers:
arch-indep stuff goes in /usr/{lib,include}
arch-dependent stuff goes in /usr/{lib,include}/triplet
But your point is taken. This is worthy of discussion to check we
have at least vague consensus
The tradeoff is:
1) (Move _all_ headers to /usr/include/triplet)
* Much duplication of installed headers
* Only one system include dir, which fits current build-system
expectations
* Incorrect builds fail faster than with (2) since there's nothing
in /usr/include
2) (Move only arch-dependent headers to /usr/include/triplet)
* No duplication of headers
* Two system include dirs, which may confuse/break some builds
* Relatively little change from status quo
* Confused builds may seem to build correctly using the wrong headers (not
an issue with the base Debian use-case but bear with me...)
In both cases things which manage to explictly look only in '/usr/include'
may fail to build, (certainly in case 1, possibly in case 2). I have
no idea how much of a problem this would be in practice.
'2)', above, has been reasonably well tested in Ubuntu raring, and telling
the compiler to look in both dirs for system headers by default works
well, but there could be issues, e.g. if giving a path to a subdir
of a system header(?).
I'd be interested to hear of problems building against multiarched
-dev packages with moved headers. Are there any significant ones?
Not that I know of...
But my main point is that all this assumes a level of uniformity in the
target architectures. So if we're building packages for Debian or Ubuntu,
just for different ABIs (mostly different hardware), everything works fine.
Throw non-Debian architectures (which could be partial architectures) into the
mix and things change drastically.
Let me explain where I'm coming from... With MinGW-w64, we have a set of
compilers, headers and libraries which allow building software targeting
native Windows, without Cygwin or much in the way of wrappers at all. This is
definitely non-POSIX and not much like Debian; but I imagine similar problems
crop up when targeting a different libc. Despite the differences, and thanks
to a lot of work by upstream developers, a lot of the libraries in Debian
build fine when targeting Windows, and most of the time the only change
required is to pass the correct target triplet to the configure script. This
makes it sorely tempting to add mingw (i386, amd64 and arm as Dmitrijs
mentions) as partial architectures in Debian and use all the existing
packaging as much as possible to provide at least -dev packages and DLLs for
as many libraries as possible; this would greatly simplify the lives of
people working on building stuff for Windows (currently they basically have
to produce Makefiles which build all their dependencies - and then you end up
with things like the Firefox source packages which include all their
dependencies on all platforms).
The big issue which crops up then isn't so much the directory structure's
impact on the build process, but rather its impact on the packaging process.
If the target directory structure depends on whether we're building for a
full Debian architecture or for a partial architecture or just some
cross-compiler target, that means ad-hoc changes in the packaging for the
various cases and that much more friction (see for example
http://bugs.debian.org/671437 - although in zlib's case packaging changes are
necessary to build for Windows).
I know (2) is well-tested, and it reduces duplication drastically. Does this
outweigh being able to use multiarch and Debian's existing packaging work as
a generic means of supporting cross-compilers?
we could support cross-compiling to anything with the same
structure - I'm thinking MinGW-w64 here of course, but I imagine it would
apply to other targets too, some of which are supported in Debian already
using the /usr/triplet/include directories.
The header-layout issue is independent of the need for dpkg-architecture to
know about an arch to use multiarch mechanisms for cross-building to it. But
that's very easy to do (An easy way to add arches in
Re: Switching packages to non-awaiting triggers
* Raphael Hertzog hert...@debian.org, 2013-05-08, 10:37: python-support (will go away anyway) #629154 (don't pay attention to the current bug subject) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508100149.ga4...@jwilk.net
Re: Switching default dpkg-deb compressor to xz
On Wed, May 08, 2013 at 11:17:39AM +0200, Ansgar Burchardt wrote: Hi, On 05/07/2013 21:49, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ [0] http://lists.debian.org/debian-devel/2012/08/msg00822.html Do you plan to switch the default compression for source packages to xz as well? Would be great -- as opposed to ancient xz-less systems that can be an issue for debootstrap, source packages are always safe. If you backport to a version of Debian that old, you're deep in recursive backport land anyway and having one more tool to backport isn't a hurdle. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508100313.ga29...@angband.pl
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Fri, May 03, 2013 at 07:11:35PM +0200, Bernhard R. Link wrote: * Holger Levsen hol...@layer-acht.org [130502 12:28]: People do this all the time: upload packages built against local packages, experimental or even on Ubuntu to Debian sid. /me shivers. This hurts. There is no reason not to rebuild in sane environments. Can we please fix this for the next release?! I'm not sure the cure is not worse than the problem. Apart from the big problem of making it even easier for people to upload trash without testing it (both wasting buildd resources and lettings users install broken packages which any trivial testing would have catched, from which I've seen far too many), reducing the buildability of packages is a cruical problem for freedom. Having to upload binary debs is not preventing that. If we step towards rebuilding everything in a highly artifical environment, it should be made clear that a package having missing build-conflicts or any other bug preventing it from being built on a real system should still be important bugs afterwards. Once we drop that and only give people the right to modify the software we distribute but no longer the possiblity to do so on their own, the Free we are so proud on gets mood. How does always building in a clean chroot impact the freedom in any way? The build tools are free and any user can set up their own clean chroot to build the source. So even if Build-Conflicts were to bit-rot completly I don't see how that affects freedom in any way. Also build systems tend to degrade quite heavily over time and get more and more specific. In some years we might not be able to switch to some other builder tools as too many packages depend on the specifics of the ones we currently have. I don't see how that can be true. We have been using sbuild for ages and we have pbuilder and other alternatives working just as well. I don't see any degradation and reliance on sbuild hapening so far. And mainatiners will still be expected to build and test their packages at home, which tend to not to use sbuild. So I think the fear that sources will rely on specific sbuild behaviour is unfounded. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508100438.GE13185@frosties
Re: epoch fix?
On Wed, May 08, 2013 at 11:55:48AM +0200, Adam Borowski wrote:
A test case (in a directory you can see via http://angband.pl/tmp/):
for x in : %3A %3a; do echo $x foo${x}bar;done
echo ok baz%3Aquux
Let's try to access a file with % :
wget -q -O- http://angband.pl/tmp/foo%3Abar
:
-- should be %3A !
But, perhaps Apache tests both? Let's see:
wget http://angband.pl/tmp/baz%3Aquux
--2013-05-08 11:45:22-- http://angband.pl/tmp/baz%3Aquux
Resolving angband.pl (angband.pl)... 2a03:9300:10::8, 89.206.35.136
Connecting to angband.pl (angband.pl)|2a03:9300:10::8|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2013-05-08 11:45:22 ERROR 404: Not Found.
Nope.
And serving .deb files via http isn't exactly a fringe use case...
URL encoding is well-known and works quite well. It does not interfere
with percent signs in filenames at all. On your server, the name of the
file on disk is foo%3Abar: the sequence of letters is 'f', 'o', 'o',
'%', '3', 'A', 'b', a', 'r'. When used in a URL, this gets encoded as
foo%253Abar. When the HTTP server receives the URL, it decodes it
and gets back foo%3Abar.
The wget example you gave did not URL encode the filename. This meant
that the HTTP server decodes the un-encoded filename. That's a bug
in your URL construction.
The correct URL to give wget is http://angband.pl/tmp/foo%253Abar
and indeed that is the URL that Apache gives you when you click
the file in the directory listing, or use Copy Link Location in
Firefox's popup menu.
For more information, see https://en.wikipedia.org/wiki/URL_encoding
or the relevant RFCs linked from that.
--
http://www.cafepress.com/trunktees -- geeky funny T-shirts
http://gtdfh.branchable.com/ -- GTD for hackers
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130508100821.gh4...@mavolio.codethink.co.uk
Re: New version of libselinux makes libpcre3 pseudo-essential
On Tue, May 07, 2013 at 07:49:37PM +0400, Игорь Пашев wrote: Does it matter? If libselinux depends on libpcre3, libpcre3 will be pulled. I believed all libraries are optional. Please re-read the policy, especially 2.5: | Packages must not depend on packages with lower priority values | (excluding build-time dependencies). Bastian -- Deflector shields just came on, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508095615.gb10...@waldi.eu.org
kann sich jemand erklären warum beide Festplatten auf dem selben Sector einen Fehler haben?
Hallo Debian Freunde,
kann sich jemand erklären was genau lost interrupt (Status 0x50)
bedeutet bzw. wo ich mich schlau lesen kann im Internet steht viel aber
eine Erklärung was die einzelnen Logmeldungen überhaupt bedeuten habe
ich nicht gefunden.
Nun meine Fragen evtl. kann jemand diese beantworten oder einen Hinweis
geben wo ich diese Info nachlesen kann:
Was bedeutet der Status 0x50 beim lost Interrupt 1. Zeile wie kommt
dieser zu Stande?
Wie groß sind die Metadaten eines Linux Software RAID 1?
Was für Daten könnten auf dem Sector 25141733 liegen? Sind es die
Metadaten vom RAID oder schon vom LVM?
Hardware Info:
2 baugleiche Server, mit jeweils baugleichen Festplatten und mit FAI
baugleich installiert.
Als OS wird Debian Linux Version 6.0.7 mit dem Xen Kernel verwendet.
uname -r
2.6.32-5-xen-amd64
DRBD und LVM für den XEN-Gäste.
Auf allen 4 Festplatten habe ich in den vergangenen Tagen die gleiche
Fehlermeldung beobachtet, es ist jedesmal der selbe Sector. Die 3 von 4
Festplatten sind neuen Austauschfestplatten welche seit dem WoEn verbaut
wurden. Es ist zwar möglich das die Festplatten defekt sind aber sehr
unwahrscheinlich weil es jedes mal der selbe Sektor ist. Die S-ATA Kabel
sind auch ausgewechselt worden.
grep I/O error /var/log/*
/var/log/kern.log:May 5 22:58:33 lxhs110a kernel: [156062.572522]
end_request: I/O error, dev sdb, sector 25141733
/var/log/kern.log:May 5 22:58:33 lxhs110a kernel: [156062.636004]
end_request: I/O error, dev sda, sector 25141733
/var/log/kern.log:May 7 03:14:18 lxhs110a kernel: [257807.626851]
end_request: I/O error, dev sdb, sector 25141733
/var/log/kern.log:May 7 19:39:58 lxhs110a kernel: [316947.560831]
end_request: I/O error, dev sdb, sector 25141733
/var/log/syslog.1:May 7 19:39:58 lxhs110a kernel: [316947.560831]
end_request: I/O error, dev sdb, sector 25141733
grep I/O error /var/log/*
/var/log/kern.log:May 7 19:15:12 lxhs110b kernel: [315435.580027]
end_request: I/O error, dev sda, sector 25141733
/var/log/kern.log:May 7 19:15:12 lxhs110b kernel: [315435.588144]
end_request: I/O error, dev sdb, sector 25141733
Nun frage ich mich was auf diesem Sector 25141733, liegt? Die 4.
Partition beginnt mit dem Sector 25141725, und wird für /dev/md2 als
RAID1 verwendet. Möglich das hier noch Metadaten vom RAID liegen. Das
Device /dev/md2 wird als PV für das LVM verwendet.
*
*Der Angeblich defekte Sector 25141733 liegt also sehr zu beginn der 4.
Partition.
fdisk -lu /dev/sdb
Disk /dev/sdb: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0003f32f
Device Boot Start End Blocks Id System
/dev/sdb1 * 6310474379 5237158+ fd Linux raid
autodetect
/dev/sdb21047438018860309 4192965 82 Linux swap / Solaris
/dev/sdb31886031025141724 3140707+ fd Linux raid
autodetect
*/dev/sdb425141725 1465144064 720001170 fd Linux raid
autodetect*
Der Komplette Auszug aus dem Logfile lautet:
May 5 22:58:32 lxhs110a kernel: [156061.812045] ata2: lost interrupt
(Status 0x50)
May 5 22:58:32 lxhs110a kernel: [156061.812061] ata2: exception Emask
0x10 SAct 0x0 SErr 0x4405 action 0xf
May 5 22:58:32 lxhs110a kernel: [156061.812105] ata2: SError: {
PHYRdyChg CommWake DevExch }
May 5 22:58:32 lxhs110a kernel: [156061.812145] ata2: hard resetting link
May 5 22:58:32 lxhs110a kernel: [156061.812154] ata1: lost interrupt
(Status 0x50)
May 5 22:58:32 lxhs110a kernel: [156061.812164] ata1: exception Emask
0x10 SAct 0x0 SErr 0x4405 action 0xf
May 5 22:58:32 lxhs110a kernel: [156061.812203] ata1: SError: {
PHYRdyChg CommWake DevExch }
May 5 22:58:32 lxhs110a kernel: [156061.812241] ata1: hard resetting link
May 5 22:58:33 lxhs110a kernel: [156062.536048] ata2: SATA link up 1.5
Gbps (SStatus 113 SControl 300)
May 5 22:58:33 lxhs110a kernel: [156062.536203] ata1: SATA link up 1.5
Gbps (SStatus 113 SControl 300)
May 5 22:58:33 lxhs110a kernel: [156062.561071] ata2.00: configured for
UDMA/133
May 5 22:58:33 lxhs110a kernel: [156062.561097] ata2: EH complete
May 5 22:58:33 lxhs110a kernel: [156062.568968] ata1.00: configured for
UDMA/133
May 5 22:58:33 lxhs110a kernel: [156062.568978] ata1: EH complete
May 5 22:58:33 lxhs110a kernel: [156062.572522] *end_request: I/O
error, dev sdb, sector 25141733*
May 5 22:58:33 lxhs110a kernel: [156062.572569] md: super_written gets
error=-5, uptodate=0
May 5 22:58:33 lxhs110a kernel: [156062.572574] raid1: Disk failure on
sdb4, disabling device.
May 5 22:58:33 lxhs110a kernel: [156062.572576] raid1: Operation
continuing on 1 devices.
May 5 22:58:33 lxhs110a kernel: [156062.636004] *end_request: I/O
error, dev sda, sector 25141733*
May 5 22:58:33 lxhs110a kernel:
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 01:06:41AM +0200, Marco d'Itri wrote: On May 07, Marc Haber mh+debian-de...@zugschlus.de wrote: What about merging / and /usr ? So we really want to explicitly not offer an upgade path from wheezy to jessie? This causes no major issues on upgrades, Fedora did it. Fedora updates are different. (And so are Ubuntu updates, if one considers that it's possible to provide fixup scripts to update-manager pre-upgrade.) As long as we're supporting upgrades through plain apt, that's going to be hard. Especially if you have non-distro packages installed that need to be migrated as well, with the tracking information updated. Kind regards Philipp Kern signature.asc Description: Digital signature
Setting up package vs triggers
=== BEFORE = $ sudo apt-get install dbus Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: dbus-x11 The following NEW packages will be installed: dbus 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/378 kB of archives. After this operation, 796 kB of additional disk space will be used. Selecting previously unselected package dbus. (Reading database ... 73608 files and directories currently installed.) Unpacking dbus (from .../dbus_1.6.2-2+dyson1_illumos-amd64.deb) ... Processing triggers for manifest-import ... svccfg: Loaded 1 smf(5) service descriptions Processing triggers for man-db ... Setting up dbus (1.6.2-2+dyson1) ... DBUS service faled to start: maintenance17:24:17 svc:/system/dbus:default Because it is started just after manifest import, before dbus is configured (/etc/dbus-1/system.conf does not exist I guess) == AFTER == after adding /etc/apt/apt.conf.d/triggers [1]: DPkg::NoTriggers true; PackageManager::Configure smart; DPkg::ConfigurePending true; DPkg::TriggersPending true; $ sudo apt-get install dbus Reading package lists... Done Building dependency tree Reading state information... Done Suggested packages: dbus-x11 The following NEW packages will be installed: dbus 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/378 kB of archives. After this operation, 796 kB of additional disk space will be used. Selecting previously unselected package dbus. (Reading database ... 73608 files and directories currently installed.) Unpacking dbus (from .../dbus_1.6.2-2+dyson1_illumos-amd64.deb) ... Processing triggers for man-db ... Setting up dbus (1.6.2-2+dyson1) ... Processing triggers for manifest-import ... svccfg: Loaded 1 smf(5) service descriptions manifest-import is triggerred after dbus is configured, and dbus service succesfully starts Could anyone explain what is going on? :-) Why man-db is still triggerred before configureing dbus? [1] http://raphaelhertzog.com/2011/05/30/trying-to-make-dpkg-triggers-more-useful-and-less-painful/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CALL-Q8zCsKkiuSq=e5bp4iku5wcb6mrhsonqrcaoe78ganz...@mail.gmail.com
Re: epoch fix?
On Tue, May 07, 2013 at 05:22:25PM -0500, Peter Samuelson wrote: [Matt Zagrabelny] I've grepped the d-d list, but didn't find any threads regarding fixing epochs in package versions. This does come up occasionally. I was unaware of this thing and I'm sure I'm overlooking something, so can someone give a simple example of actual problems introduced by using epochs? Other than it looks ugly, some filesystems don't like : and % and people write their own algorithms to compare version numbers, which have already been mentioned. Is this documented in the wiki or somewhere else? Berto -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508101954.ga24...@igalia.com
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
On Sun, May 05, 2013 at 12:18:44AM +0100, Wookey wrote: The harder question is how/when to do that QA. The time to do QA is now and always. Otherwise it just collects and becomes too much. I resisted making the suggestion of doing it by default on all builds as that seemed a step too far, although I see someone else did :-). In fact, given the significant overhead of build-dep installation, build-twice would actually be quite a small overhead for many smaller packages (and only needs to be done on one fast arch, not all of them). It would clearly be annoying for builds that are large/slow anyway, which implies some kind of exception list, which was kind of the point where I decided this wasn't going to fly. If one arch tests it that should be enough for 99% of cases. So limiting it to fast archs should be fine. This could even be done dynamically. Use --build-twice only if there are less than X source in needs-build. In times of stress and on slower archs the option would be droped automatically. From time to time archive wide rebuilds are done. Those could certainly do --build-twice if buildds don't. MfG Goswin -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508102045.GF13185@frosties
Re: /export (was Re: jessie release goals)
On Tue, May 07, 2013 at 10:18:25PM +, Thorsten Glaser wrote: I always rm -rf /media after a fresh install, where T F did that come from. Funny you say that, given that the canonical reference document we use even provides an explanation for why it was created. If you'd said /srv, I'd sort of understand it. But you said /sys (why not /proc?), /run, /lib, /emul and /lib64. The latter is bound to exist due to architectural conventions involving the linker. /emul is simply cruft and disappeared completely. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: epoch fix?
[Alberto Garcia] I was unaware of this thing and I'm sure I'm overlooking something, so can someone give a simple example of actual problems introduced by using epochs? One real problem is that epochs make it easier to introduce human error in specifying reverse runtime and build deps. E.g.: # in stable Package: libfoo-dev Version: 1:1.4.1-1 # in unstable Package: libfoo-dev Version: 1:1.5.5-2 # in unstable Package: bar Build-Depends: libfoo-dev (= 1.5) The 'bar' maintainer intended to require the unstable version of libfoo-dev, but in fact the dependency is satisfied from stable as well. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508103011.gc13...@p12n.org
Re: New version of libselinux makes libpcre3 pseudo-essential
2013/5/8 Bastian Blank wa...@debian.org: On Tue, May 07, 2013 at 07:49:37PM +0400, Игорь Пашев wrote: Does it matter? If libselinux depends on libpcre3, libpcre3 will be pulled. I believed all libraries are optional. Please re-read the policy, especially 2.5: | Packages must not depend on packages with lower priority values | (excluding build-time dependencies). Will it change anything except non-linux systems will get libpcre3 by default, while do not need it? Maybe make libselinux optional? ;-) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/call-q8zf56jjpuqqxt8qvqueccrj-8dp7bofi-dyjohrgur...@mail.gmail.com
Re: Switching default dpkg-deb compressor to xz
On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote: If there's people who are still worried about that, I'd ask them to file bugs on the base packages to make them pass -Zgz explicitly to dpkg-deb (I'll do that for dpkg.deb in any case), and I can wait for the base system to be switched, but those packages could always be changed on their next upload, or even a fatal lintian error created so that ftp-master can reject those (I don't think there's one currently?). Otherwise I'll be doing the change with the dpkg 1.17.0 upload. The problem with that check was that it's hard to determine what's in the base set as that's defined by the essential packages plus their (transitive) dependencies. So it'd need to be either a static list or something more clever that looks at the target suite. (And even then another binary might suddenly be depended on which is not xz-compressed.) That only matters iff we care about the base system needing to be gz-compressed. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
* Goswin von Brederlow goswin-...@web.de, 2013-05-08, 11:53:
We already know we can't trust all maintainers to build binaries in a
clean chroot. Nor can we trust them to test binaries they upload. What
makes you think maintainers will not simply blindly create changes
files for buildd build binaries and upload them?
There's a huge difference between being negligent and actively trying to
bypass the archive software policies.
We can('t) trust X to do A doesn't usually imply We can('t) trust X
to do B. No, really, it doesn't.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130508104725.ga4...@jwilk.net
Re: epoch fix?
On Wed, May 08, 2013 at 05:30:11AM -0500, Peter Samuelson wrote: One real problem is that epochs make it easier to introduce human error in specifying reverse runtime and build deps. E.g.: # in stable Package: libfoo-dev Version: 1:1.4.1-1 # in unstable Package: libfoo-dev Version: 1:1.5.5-2 # in unstable Package: bar Build-Depends: libfoo-dev (= 1.5) The 'bar' maintainer intended to require the unstable version of libfoo-dev, but in fact the dependency is satisfied from stable as well. No real damage done. If it is built against 1:1.4 it will either not work or be rejected. Also one must not build stuff for unstable against stable anyway. Please show a real-world example where this breaks, not only may produce slightly undesired results. Bastian -- Another dream that failed. There's nothing sadder. -- Kirk, This side of Paradise, stardate 3417.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508110525.ga12...@waldi.eu.org
Re: Switching default dpkg-deb compressor to xz
Hi! On Wed, 2013-05-08 at 12:03:13 +0200, Adam Borowski wrote: On Wed, May 08, 2013 at 11:17:39AM +0200, Ansgar Burchardt wrote: On 05/07/2013 21:49, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ [0] http://lists.debian.org/debian-devel/2012/08/msg00822.html Do you plan to switch the default compression for source packages to xz as well? I've not proposed this for now, because I don't think we've discussed it previously. But I'm happy to do the switch for V2+ formats (not for V1) at the same time (or during the dpkg 1.17.x cycle) if there's also consensus for it. Would be great -- as opposed to ancient xz-less systems that can be an issue for debootstrap, source packages are always safe. If you backport to a version of Debian that old, you're deep in recursive backport land anyway and having one more tool to backport isn't a hurdle. Right. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508112133.ga7...@gaara.hadrons.org
Re: epoch fix?
On Tue, May 07, 2013 at 05:13:25PM -0500, Matt Zagrabelny wrote: Use the mechanism of really: % apt-cache policy libglib2.0-dev libglib2.0-dev: Installed: 2.33.12+really2.32.4-5 Candidate: 2.33.12+really2.32.4-5 So is this a 2.33.12 or 2.32.4? Sorry, this is neither readable nor does it sort into the correct location in any way. Bastian -- Sometimes a man will tell his bartender things he'll never tell his doctor. -- Dr. Phillip Boyce, The Menagerie (The Cage), stardate unknown. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508110627.gb12...@waldi.eu.org
Re: Switching default dpkg-deb compressor to xz
On Wed, 2013-05-08 at 12:38:47 +0200, Philipp Kern wrote: On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote: If there's people who are still worried about that, I'd ask them to file bugs on the base packages to make them pass -Zgz explicitly to dpkg-deb (I'll do that for dpkg.deb in any case), and I can wait for the base system to be switched, but those packages could always be changed on their next upload, or even a fatal lintian error created so that ftp-master can reject those (I don't think there's one currently?). Otherwise I'll be doing the change with the dpkg 1.17.0 upload. The problem with that check was that it's hard to determine what's in the base set as that's defined by the essential packages plus their (transitive) dependencies. So it'd need to be either a static list or something more clever that looks at the target suite. (And even then another binary might suddenly be depended on which is not xz-compressed.) In theory, as long as the Priority fields are kept up-to-date in the archive, then that should be a matter of just checking if a packages is required or important, which also implies the lintian check would not be much useful as the .deb Priority does not need to match the one in the archive. That does not solve the additional dependencies, but usually adding to the base system implies a discussion on debian-devel, or automated sanity checks could be performed from time to time. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508113102.gb7...@gaara.hadrons.org
Re: epoch fix?
On Wed, May 08, 2013 at 11:08:21AM +0100, Lars Wirzenius wrote: On Wed, May 08, 2013 at 11:55:48AM +0200, Adam Borowski wrote: wget -q -O- http://angband.pl/tmp/foo%3Abar : -- should be %3A ! And serving .deb files via http isn't exactly a fringe use case... URL encoding is well-known and works quite well. It does not interfere with percent signs in filenames at all. On your server, the name of the file on disk is foo%3Abar: the sequence of letters is 'f', 'o', 'o', '%', '3', 'A', 'b', a', 'r'. When used in a URL, this gets encoded as foo%253Abar. When the HTTP server receives the URL, it decodes it and gets back foo%3Abar. The wget example you gave did not URL encode the filename. This meant that the HTTP server decodes the un-encoded filename. That's a bug in your URL construction. I seriously doubt even a quarter of our tools bothers with this kind of encoding. All other characters in deb file names don't require any special handling. The correct URL to give wget is http://angband.pl/tmp/foo%253Abar and indeed that is the URL that Apache gives you when you click the file in the directory listing, or use Copy Link Location in Firefox's popup menu. I'd say this discrepancy is a good reason to avoid fancy characters in file names whenever possible. Even something Unicode would be safer. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508122917.gb29...@angband.pl
Re: Merging / and /usr (was: jessie release goals)
On 05/07/2013 11:41 AM, Paul Tagliamonte wrote: On Tue, May 07, 2013 at 05:36:41PM +0200, Marco d'Itri wrote: On May 07, Paul Tagliamonte paul...@debian.org wrote: No please. We are good about making sure they each mean something important, and there's no good reason. Not really nowadays: more and more things needed at boot time are in /usr and there are no plans to fix them. We also support setups that might need this split due to low storage, such as arm devices. everything in /usr actually means that supporting these devices is much easier. Not when you have a 500 meg internal storage that the firmware boots off of, and using a multi-gig CF card to store the mega-awesome-app you're using it for. This seems to point to what I think may be a key question in the ongoing/recurring '/usr'-related discussions, which I don't think I've seen addressed in the iterations I've seen. If it has been addressed well, please point me to past iterations which have so addressed it, rather than rehashing the whole thing here just for my benefit. The question, expressed in a number of different ways to provide a type of clarity by triangulation, is: Why does /usr exist in the first place? Why was it created, way back in the day? What is its purpose, what is it for? My understanding, to the extent that I've had one, has always been that - to oversimplify it a bit - / is for installs of things which are system-essential, and /usr is for installs of things which are not. The definition of system-essential can be debated, but again, my understanding of it has been that it incorporates A: boot-essential (things required for boot) plus B: emergency tools (things you want to try to guarantee will be available in an emergency, things-are-broken-and-we-have-to-fix-them scenario, such as might leave you needing to rely on single-user mode). The real-world scenario is obviously far more complicated than that - dragging in definitions for what goes in /etc and /var and /home, and further defining a distinction between /usr and /usr/local, and so forth. But the basic concept seems simple enough as far as it goes. Now, the next question is: does that distinction, that defining purpose for the existence of /usr, still make sense in the modern world? Almost everyone boots via an initrd nowadays AFAIK, which would seem to more or less negate the advantages of keeping boot-essential things separate that way - but almost still isn't everyone, and I don't know whether we want to explicitly step away from support for non-initrd boot configurations. The emergency tools side of it I'm less clear on. It's relatively unimportant for cases where you have physical access to the system in the emergency scenario, assuming you can take the machine down long enough to boot into a rescue environment on removable storage (LiveCD or USB drive, et cetera), but there may not be any analogous alternate fallback for cases where you only have remote access to a machine, or where taking the machine down that way may not be an option. There's also the question of what scenarios this could actually help in, which may be limited enough to make the entire thing negligible. If the distinction does still make sense (which I personally think is probably the case, though I don't have arguments to back it up at present), then installing something system-essential under /usr is Doing It Wrong, and we should not only not do it ourselves but push back against upstream efforts to do it. If the distinction does not still make sense, then we should explicitly decide to reject it, and under that scenario moving to merge /usr with / (in either direction) seems like a very sensible thing to do. -- The Wanderer Warning: Simply because I argue an issue does not mean I agree with any side of it. Every time you let somebody set a limit they start moving it. - LiveJournal user antonia_tiger -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/518a4f2c.8070...@fastmail.fm
Re: kann sich jemand erklären warum beide Festplatten auf dem selben Sector einen Fehler haben?
Hi! Ich glaube, du hast dich in der Mailingliste vertan, debian-devel ist für die (englischsprachige) Diskussion zur Entwicklung der Debian-Distribution. Die Frage kannst du besser unter http://lists.debian.org/debian-user-german/ stellen, oder in einem Forum. Viel Erfolg! MfG Matthias @list: I asked the poster to try another mailinglist, as d-devel is for Debian development discussion in English. -- Debian Developer | Freedesktop-Developer KDE-Developer| GNOME-Contributor -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKNHny8niKEaYtz7bZjoqV9sSDqL96bvOe�sgz51qhrvw...@mail.gmail.com
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 09:12:12AM -0400, The Wanderer wrote: The question, expressed in a number of different ways to provide a type of clarity by triangulation, is: Why does /usr exist in the first place? Why was it created, way back in the day? What is its purpose, what is it for? Histerical raisins. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Now, the next question is: does that distinction, that defining purpose for the existence of /usr, still make sense in the modern world? Of course no. -- WBR, wRAR signature.asc Description: Digital signature
Re: Bug#565308: Will we see MariaDB in Jessie?
On 2013-05-06 13:17:47, Patrick Matthäi wrote: But why should it _replace_ MySQL, why not providing it as an alternative MySQL'ish server? As others mentionned: Oracle. More precisely, because Oracle has a rather rude security policy of not divulging security issues directly and publishing a whole new release (as opposed to a patch) when security issues are published. That regression alone should be indication enough that Oracle doesn't care about us, if we needed any reminder. We did it for Libreoffice, let's push it a little further. A. -- Information is not knowledge Knowledge is not wisdom Wisdom is not truth - Frank Zappa pgpHoIulGYDfQ.pgp Description: PGP signature
Re: epoch fix?
+++ Jonathan Nieder [2013-05-07 16:14 -0700]: It makes sense for Debian, too. Epochs were invented to handle changes to the version numbering *scheme*. They work well for that. This is true. It would be good advice somewhere to sugest that if using a date-based packaging scheme, to prefix it with 0. i.e 0.20130215 I packaged something a while back that had no scheme so used a date string: 20110812 as this was suggested somewhere. Now they have done a release and called it 0.6, I realise that 20110812 (20 million) is a lot bigger than 0.6, or indeed any other likely version number. epoch time :-( Not a big deal but could so easily have been avoided. Now I just need to find that original packaging advice and add this little gem of knowledge. The really trick works better for temporary decreases in version number, and the conspicuousness is actually a good thing imho. Hope that helps, It does, thank you. I had not properly understood the above before. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508142551.gm2...@stoneboat.aleph1.co.uk
Re: Merging / and /usr (was: jessie release goals)
On May 08, The Wanderer wande...@fastmail.fm wrote: The emergency tools side of it I'm less clear on. It's relatively apt-get install grml-rescueboot Which is way safer than relying on / working. -- ciao, Marco signature.asc Description: Digital signature
Re: epoch fix?
Hi Wookey, Wookey woo...@wookware.org writes: +++ Jonathan Nieder [2013-05-07 16:14 -0700]: It makes sense for Debian, too. Epochs were invented to handle changes to the version numbering *scheme*. They work well for that. This is true. It would be good advice somewhere to sugest that if using a date-based packaging scheme, to prefix it with 0. i.e 0.20130215 I note that that date-based version even with a 0. prefix still fails to work with the subsequent 0.6 from your example. ~ (tilde) with it's magic negative sort order, does work however: 0~20130215 Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/ |-| HANDS.COM Ltd.http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND pgpN8KdE6aonN.pgp Description: PGP signature
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote:
Fedora updates are different. (And so are Ubuntu updates, if one considers
that it's possible to provide fixup scripts to update-manager pre-upgrade.)
As long as we're supporting upgrades through plain apt, that's going to
be hard. Especially if you have non-distro packages installed that need
to be migrated as well, with the tracking information updated.
Maybe the issue here shouldn't be changing the default. After all there
is a quite vocal opposition to such a step. I fail to see consensus in
the recent mails without even contributing a personal opinion here.
So really what does it take to e.g. move /bin and stuff to /usr? Did
anyone try that? Where is that documented? What problems did occur?
### Analysis
I didn't do too much research on previous research, but just tried it.
As far as I understood from the discussion, the idea is to move
/{lib,lib64,bin,sbin} to the corresponding /usr location and turn them
into symbolic links. That doesn't sound too hard to do in a chroot. So
what goes wrong when doing this?
First of all there is /bin/touch and /usr/bin/touch from coreutils. The
latter is a symbolic link to the former. Same issue for /bin/which. So
before doing this merge, coreutils would have to change in some way.
Looking further there are things like less, acl, and cryptsetup all of
which provide similar symbolic links.
Are there real issues? Like actual files conflicting? This can
probably be answered using project-b, but I currently have no access to
that one, so I just used the database backing dedup.debian.net. Some
clever SQL needed here... [15 minutes later]
SELECT a.filename, a.package, (SELECT b.package FROM content AS b WHERE
b.filename = . || substr(a.filename, 6)) FROM content AS a WHERE
substr(a.filename, 0, 7) = ./usr/ AND (SELECT c.id FROM content AS c
WHERE c.filename = . || substr(a.filename, 6)) IS NOT NULL;
You were interested in the actual data? Quite short:
./usr/bin/openvt|console-tools|kbd
./usr/bin/dumpkeys|console-tools|kbd
./usr/bin/unicode_start|console-tools|kbd
./usr/bin/chvt|console-tools|kbd
./usr/bin/kbd_mode|console-tools|kbd
./usr/bin/setfont|kbd-compat|kbd
./usr/bin/git-ftp|git-ftp|git-ftp
./usr/sbin/syslogd|inetutils-syslogd|sysklogd
./usr/sbin/mkfs.lustre|lustre-utils|lustre-utils
Now console-tools and kbd are in conflict, so we don't care about that
one. git-ftp should be deduplicated the others likely need some deeper
look. All in all this looks fixable for a /usr merge.
So back to practical problems. How does apt cope with this situation?
Installing a random package (e.g. debsums) just works.
Talking about debsums. Did we break it? No debsums --all --silent is
happy.
### Conclusion
My conclusion for now is that just using a merged /usr in this way
appears to be possible. So instead of asking should Debian do the /usr
merge, may I propose the question should Debian support the /usr
merge?
This actually makes up a possible release goal, because it is measurable
(just set up a system with merged /usr and see what breaks) and it
affects a number of packages (those compatibility symbolic links will
have to go). In addition this will likely require a change in the policy
(turning /bin/foo /usr/bin/foo file conflicts into a policy violation)
and it will need the work done by Roger Leigh (and others?) to support
mounting /usr in the initramfs.
I suggest to defer a decision on merging /usr by default until after the
release of jessie. The dependency based boot has similarly taken a
release for preparing the feature and then releasing it.
For those interested in my opinion: I don't consider myself a proponent
of the /usr merge, because the current way of doing things works for me.
On the other hand I do not see why Debian should not support that setup
if the cost is not too high and those interested are doing the work.
Helmut
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130508153213.ga2...@alf.mars
Debian 7
Debian developers have allot to learn still in 2013 the documentation is flawed from the very first line. http://www.debian.org/releases/stable/installmanual Debian wheezy -- Installation Guide What is Debian wheezy? I only downloaded 'Debian 7'. wheezy is a nick name? where is it defined from the point of download? I cannot see it. I am guessing it is a nick name, but how many other people will know this? i am downloading debian 7 now. even if it is the best operating system in the world, it will not gain populatiry because documentating does not exist in customer eyes. also, why still using mailing list? this is the 2013. Mailing list is like living in 1993. spam bots love mail-list. mozilla bugzilla system is good chat system. the user e-mail address is hidden, and there is the login system. no one wants hundreds of e-mail's in inbox. or spam. i like open source projects and i hope the best for debian, but developers must come with real times
Bug#707255: ITP: parsley -- pattern-matching language based on OMeta and Python
Package: wnpp Severity: wishlist Owner: Jérémy Bobbio lu...@debian.org * Package name: parsley Version : 1.1 Upstream Author : Allen Short washor...@gmail.com * URL : https://launchpad.net/parsley * License : Expat Programming Lang: Python Description : pattern-matching language based on OMeta and Python Parsley is a parsing library for people who find parsers scary or annoying. It uses the PEG algorithm, so each expression in the grammar rules works like a Python expression. In particular, alternatives are evaluated in order, unlike table-driven parsers such as yacc, bison or PLY. Parsley is an implementation of OMeta, an object-oriented pattern-matching language developed by Alessandro Warth http://tinlizzie.org/ometa/. -- Jérémy Bobbio.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
wheezy postmortem re rc bugfixing
It is good to have it released now, but I think we are all (mostly?) agreed that wheezy took longer to release than we would have liked. In particular, the RC bug count didn't drop quickly enough. Firstly, I want to say that I don't think this was anyone's fault. So I don't want to lay any blame. I think we should consider, though, how we can try to do better next time. For me the key problem is this: we are lacking a useful workflow for fixing RC bugs (well, many of them, anyway). Easy RC bugs tend to get fixed early in the freeze or even beforehand. But as the freeze continues, what are left are hard bugs. I don't think we necessarily have a lack of effort. I know that many people were _trying_ to improve the situation with RC bugs. But it's difficult. One ends up picking bugs more or less at random and then reading them. One will then naturally discover that the bug is difficult somehow - after all, if were easy it would probably have been fixed already. Unless one is already surrounded by enthusiastic and authoritative experts with a lot of spare time and (where needed) the right authority, one can end up blocked and discouraged. So I would like to suggest that we should have a thread where we: * Try to identify the main ways in which bugs can be hard (which might be technical, political, or a mixture) * Try to think of workflows which might overcome these problems * In particular, try to think of workflows and/or support tools which might be able to connect the people with the skills and/or authority to solve the problem, with the bug - and help motivate those people to do the work needed to unblock the bug. * Consider other ways in which our RC-bug-fixing efforts can be improved, especially during the latter part of the freeze. I have deliberately avoided suggesting any answers to these questions myself in this article. But I may do so later. Also we should try to treat this discussion as a kind of semi-brainstorm: if someone makes what seems like a poor suggestion, try to improve on it or post a better one yourself, rather than merely criticising theirs. That will help keep the discussion open and avoid it getting hung up on specific disagreements (which is of course a think that mailing list conversations have a tendency to to). Thanks, Ian. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20874.29810.191974.559...@chiark.greenend.org.uk
Re: epoch fix?
]] Philip Hands ~ (tilde) with it's magic negative sort order, does work however: 0~20130215 0~something is pretty magic and sometimes confuses tools, though, since it's a positive version number that's less than zero. (I know the import stuff in Launchpad got confused back in the days, but that's probably been fixed since, but I would not be surprised to see other tools be confused about such versions.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2fvxx4gb9@rahvafeir.err.no
Re: Debian 7
On Thu, May 09, 2013 at 01:49:56AM +1030, Mikael Livchenko wrote: Debian developers have allot to learn still in 2013 the documentation is flawed from the very first line. http://www.debian.org/releases/stable/installmanual Debian wheezy -- Installation Guide What is Debian wheezy? I only downloaded 'Debian 7'. wheezy is a nick name? where is it defined from the point of download? I cannot see it. I am guessing it is a nick name, but how many other people will know this? Wheezy. It's obvious, isn't it? It comes between Squeeze and Jessie. /sarcasm Wheezy is a brand. It's not really any different than Snow Leopard or XP. Do you expect people to care that one is 10.6.8 and the other 5.1.2600? i am downloading debian 7 now. even if it is the best operating system in the world, it will not gain populatiry because documentating does not exist in customer eyes. also, why still using mailing list? this is the 2013. Mailing list is like living in 1993. spam bots love mail-list. mozilla bugzilla system is good chat system. the user e-mail address is hidden, and there is the login system. no one wants hundreds of e-mail's in inbox. or spam. Actually, I DO want hundreds of email's [sic] in [my] inbox. I DON'T want to have to remember *another* login, have to visit *another* webpage to read messages. The beauty of a mailing list is that the messages are delivered to you. Filtering messages into folders isn't really that hard (whether you do it server- or client-side). And, please, don't impugn debian's spam filter. Do you know how many spam messages it blocks each day? i like open source projects and i hope the best for debian, but developers must come with real times signature.asc Description: Digital signature
Re: Switching default dpkg-deb compressor to xz
Hi, On Wed, May 08, 2013 at 11:17:39AM +0200, Ansgar Burchardt wrote: On 05/07/2013 21:49, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ [0] http://lists.debian.org/debian-devel/2012/08/msg00822.html Do you plan to switch the default compression for source packages to xz as well? You mean for debian.tar? I would assume most debian.tars are not so big that it would make a big difference and be worth the hassle, but dunno. Michael -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508155757.ga6...@nighthawk.chemicalconnection.dyndns.org
Re: epoch fix?
* Tollef Fog Heen tfh...@err.no, 2013-05-08, 17:55: ~ (tilde) with it's magic negative sort order, does work however: 0~20130215 0~something is pretty magic and sometimes confuses tools, though, since it's a positive version number that's less than zero. Define positive version number. We have hundreds of packages with such versions in the archive, and I haven't seen it exploding because of it. (Although personally I use 0+ prefix in similar cases.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508160221.ga5...@jwilk.net
Bug#707256: ITP: txsocksx -- SOCKS{4,4a,5} endpoints for Twisted
Package: wnpp
Severity: wishlist
Owner: Jérémy Bobbio lu...@debian.org
* Package name: txsocksx
Version : 0.0.2
Upstream Author : Arturo Filastò a...@fuffa.org
* URL : https://github.com/hellais/txsocksx
* License : BSD-2-clause
Programming Lang: Python
Description : SOCKS{4,4a,5} endpoints for Twisted
SOCKS is an Internet protocol that routes network packets between a client and
server through a proxy server.
This library implements endpoints for SOCKS versions 4, 4a and 5 for the
Twisted Python framework.
--
Jérémy Bobbio.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
signature.asc
Description: Digital signature
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 05:32:13PM +0200, Helmut Grohne wrote: So really what does it take to e.g. move /bin and stuff to /usr? Did anyone try that? Where is that documented? What problems did occur? http://fedoraproject.org/wiki/Features/UsrMove -- WBR, wRAR -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508160918.ga19...@belkar.wrar.name
Re: Debian 7
Mikael Livchenko, le Thu 09 May 2013 01:49:56 +1030, a écrit : no one wants hundreds of e-mail's in inbox. I do want that instead of hundreds of bugzillas to have to subscribe to and browse one by one. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508161117.gi8...@type.youpi.perso.aquilenet.fr
Debian 7 review
I think Debian 7 is better than ubuntu 12. if debian can make documents like ubuntu, ubuntu will end. great job on Debian 7 it has made my night well! thanks!
Re: wheezy postmortem re rc bugfixing
On Wed, 8 May 2013 16:51:14 +0100 Ian Jackson ijack...@chiark.greenend.org.uk wrote: So I would like to suggest that we should have a thread where we: I suspect a wiki page will be needed at some point... * Try to identify the main ways in which bugs can be hard (which might be technical, political, or a mixture) These are the issues which discouraged me from working on particular RC bugs during this release and the one before it. * Hard to reproduce - uncommon packages, specialised setups, specific hardware or hardware configurations, intermittent issues. * Un- / under maintained packages not yet orphaned. IMHO we should be much more aggressive with such packages - strict time limits for all RC-buggy leaf packages, regardless of the uncertainties of popcon, leading to at least automatic removal from testing. Warning bugs against reverse dependencies of non-leaf packages warning of problems. (We have this now in the PTS for WNPP issues, an extension to RC bugs in dependencies could also be really useful.) * Disagreements between submitter maintainer / fixer * Architecture-specific bugs for less common ports - maybe be more aggressive here also on which architectures are deemed fit for release on the basis of the occurrence and likely delays caused by such bugs. * Non-standard packaging or build system or packages using methods known to make NMU's difficult. * Languages other than C, C++, perl, shell or python, reducing the possible number of people who can get a full overview of the package. * Lapsed release goals (like building sanely twice in a row, not just in a clean chroot but during a typical NMU process too, so that test changes can be easily and quickly reverted and the package rebuilt.) Particularly important for packages which take a long time to build or have esoteric / uncommon build-dependencies. * Poor quality documentation within the package, especially for build-system idiosyncrasies and internal API/ABI requirements. Simple things like a comment in each source code file saying what the code in that file is meant to achieve. foo.c - wraps the bar interface in the foo class etc. Other steps to take as preventative measures: * More QA runs through the archive prior to freeze to catch things like embedded libraries or binaries without sources or licence irregularities, FTBFS and piuparts errors. The actual decision of the freeze date could be made to be reliant on a % clean report from such runs. * Make it a *MUST* that all transitions, no matter how small, are checked with the release team starting from as soon as the freeze is announced (not just after it starts) such that uploads which start a transition could be pushed into DELAYED or REJECTed automatically. (Not easy to implement this one, I know.) * Try to think of workflows which might overcome these problems debian/rules must be a makefile, only specific packages can be allowed to not use debhelper, toolchain packages to be frozen earlier than the rest of the archive... I think the Debian PPA approach could also ease the process substantially - we could, for example, require that all uploads during a freeze which do not fix RC bugs must go into a Debian PPA. This reduces the need for t-p-u builds and should help the slow isolation of desired changes from packaging fluff. * In particular, try to think of workflows and/or support tools which might be able to connect the people with the skills and/or authority to solve the problem, with the bug - and help motivate those people to do the work needed to unblock the bug. That sounds like a requirement for tags and a search interface allied with rc-alert or similar. BSP's could also make use of such tags, possibly via an interface akin to the reverse of dd-list. Maybe the debtags information could be used to feed data into UDD relating to the likely experience of the maintainers based on the implemented-in and works-with tags of the packages which they maintain? Then a BSP can just feed the names into the search and get a list of likely bug numbers. The data would also help identify tags which have poor coverage and high proportions of bugs. * Consider other ways in which our RC-bug-fixing efforts can be improved, especially during the latter part of the freeze. I have deliberately avoided suggesting any answers to these questions myself in this article. But I may do so later. Also we should try to treat this discussion as a kind of semi-brainstorm: if someone makes what seems like a poor suggestion, try to improve on it or post a better one yourself, rather than merely criticising theirs. That will help keep the discussion open and avoid it getting hung up on specific disagreements (which is of course a think that mailing list conversations have a tendency to to). -- Neil Williams = http://www.linux.codehelp.co.uk/ pgp678phNWTJP.pgp Description: PGP signature
Re: Bug#565308: Will we see MariaDB in Jessie?
On 2013-05-08 06:42, anarcat wrote: On 2013-05-06 13:17:47, Patrick Matthäi wrote: But why should it _replace_ MySQL, why not providing it as an alternative MySQL'ish server? As others mentionned: Oracle. More precisely, because Oracle has a rather rude security policy of not divulging security issues directly and publishing a whole new release (as opposed to a patch) when security issues are published. That regression alone should be indication enough that Oracle doesn't care about us, if we needed any reminder. We did it for Libreoffice, let's push it a little further. I have to say that actually the ship the whole release paradigm has, thus far, resulted in a single reported regression [1]. This regression was basically I have something really old and busted that depended on a really broken behavior.. Forgive me if I do not sympathize with the user who was not maintaining their software even a little bit (read the bug for details). It is the only mitigating factor in this whole freak show... we can simply ship what Oracle puts out, and at least have a modicum of confidence that it will not cause users too much pain. I would not say that Oracle doesn't care about Debian MySQL users. I would say that Oracle doesn't care about anybody who is not showing them the money. MySQL has enough momentum without Wikipedia, Debian, and Fedora using it. They can keep selling it to enterprise customers for years, and their policies will keep them in the green while MySQL slowly fades into obscurity in the open source world. I don't want to detract from the work that a few of their employees (like Norvald Ryeng) are doing to maintain relevance, but it seems clear to me that these are not long term strategic efforts, but rather tactics to control the out-flow of open source users. Also, it is not just the security policy that has open source users wanting off the crazy train, it is also the contributor agreement. Code from MariaDB can't go into MySQL because the coders for MariaDB are not going to assign copyright/grant license/whatever it is that the Oracle CA requires. So, for instance, when MariaDB fixes a blatant security problem, and publishes the fix, tests, and explanations of it, the Oracle MySQL team is pretty much screwed. They can't really look at the patches, lest they be charged with violating the license by simply copying/pasting using their minds. And they cannot even *talk* about whether or not it is fixed until well after it is fixed. But we can all see the code, so *WE* can talk about it. And when they fix it *wrong*, and those tests which they cannot use show that, we can point and laugh at them. Oracle's policy is completely nuts from the perspective of open source. I suspect they'll milk MySQL for more cash than any pure open source effort would even dream of. The question we're left with is how best to keep serving Debian users. At the moment, and I believe for the next release cycle, we should consider being the ones who protect our users while they decide for themselves, and one way to do that is to make it easy to have both. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=660206 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/0a473532e37c1088a0da68b63cc7a...@secure.spamaps.org
Re: Switching default dpkg-deb compressor to xz
On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ What about the compression level? xz -6 is pretty heavy and not needed for 99% of the packages. -3 or even -2 or -1 are sufficient. Bastian -- Youth doesn't excuse everything. -- Dr. Janice Lester (in Kirk's body), Turnabout Intruder, stardate 5928.5. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508161436.ga14...@waldi.eu.org
Re: Switching default dpkg-deb compressor to xz
Raphael Hertzog wrote: I agree that we have such a consensus. Not for packages installed by debootstrap. There was a time where d-i was not ready, but nowadays udeb are compressed with xz and busybox's xz is used in that context. That's not relevant. -- see shy jo signature.asc Description: Digital signature
Re: wheezy postmortem re rc bugfixing
On Thu, May 9, 2013 at 12:28 AM, Neil Williams wrote: (We have this now in the PTS for WNPP issues, an extension to RC bugs in dependencies could also be really useful.) Thanks for the idea, I'll pursue implementing this with QA infrastructure folks. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6EyEAm6+WNNyVez=w4blh640+-hbb5pfa0l9m36wdy...@mail.gmail.com
Re: Switching default dpkg-deb compressor to xz
On Wed, 08 May 2013, Michael Banck wrote: Do you plan to switch the default compression for source packages to xz as well? You mean for debian.tar? This and 3.0 (native) source packages. Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508164000.ga18...@x230-buxy.home.ouaza.com
Re: Merging / and /usr (was: jessie release goals)
On Wed, May 08, 2013 at 05:32:13PM +0200, Helmut Grohne wrote: On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote: Fedora updates are different. (And so are Ubuntu updates, if one considers that it's possible to provide fixup scripts to update-manager pre-upgrade.) As long as we're supporting upgrades through plain apt, that's going to be hard. Especially if you have non-distro packages installed that need to be migrated as well, with the tracking information updated. Maybe the issue here shouldn't be changing the default. After all there is a quite vocal opposition to such a step. I fail to see consensus in the recent mails without even contributing a personal opinion here. So really what does it take to e.g. move /bin and stuff to /usr? Did anyone try that? Where is that documented? What problems did occur? It takes initramfs support for correctly mounting /usr from the initramfs. Until we have that, all the should/shouldn't, do it by default, etc. discussions are pointless. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
DPA instead of PPA
Hi, On Dienstag, 7. Mai 2013, Thorsten Glaser wrote: I think you may have misunderstood the Debian PPA proposal. It will not be like the Ubuntu PPA system where anyone can upload a package to Call it DPA then? Debianprojectmember Personal Archive I actually really like this idea! (Though I suggest Debian Personal Archive.) It's really different from what people know as PPAs. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: epoch fix?
On Wed, May 08, 2013 at 10:16:28AM +0200, Josselin Mouette wrote: Le mercredi 08 mai 2013 à 05:04 +, Bart Martens a écrit : Michael Biebl wrote : The usage of really (...) that you don't have to fix all r-deps to include the the epoch in the Build-Depends. Why would adding an epoch cause the need for adding the epoch in the build-dependent packages ? Because otherwise these build-dependent packages will not bring the version they actually need? You know, what build-dependencies are for. I know what build-dependencies are for, thank you. :-) The question is why epoch would need more updating of Build-Depends than with the really approach. I'm missing Michael Biebl's point. Regards, Bart Martens -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508173302.gb7...@master.debian.org
Re: New version of libselinux makes libpcre3 pseudo-essential
On Wed, 8 May 2013 11:56:15 +0200, Bastian Blank wa...@debian.org wrote: Please re-read the policy, especially 2.5: | Packages must not depend on packages with lower priority values | (excluding build-time dependencies). IIRC that policy paragraph is from the times where our CD build software didn't follow dependencies when choosing packages for images. Afaik, they have been following dependencies for a decade now, so this policy paragraph could be removed. 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ua8nh-0004yl...@swivel.zugschlus.de
Re: Merging / and /usr (was: jessie release goals)
On Wed, 8 May 2013 01:06:41 +0200, m...@linux.it (Marco d'Itri) wrote: On May 07, Marc Haber mh+debian-de...@zugschlus.de wrote: What about merging / and /usr ? So we really want to explicitly not offer an upgade path from wheezy to jessie? This causes no major issues on upgrades, Fedora did it. How would that be done for a 200 MB filesystem holding /, no extra /boot partition, and a multi-gigabyte /usr beyond the 2T barrier? This setup works fine with wheezy. 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ua8pt-0004z1...@swivel.zugschlus.de
Re: Merging / and /usr (was: jessie release goals)
On Wed, 8 May 2013 17:32:13 +0200, Helmut Grohne hel...@subdivi.de wrote: On Wed, May 08, 2013 at 12:19:25PM +0200, Philipp Kern wrote: Fedora updates are different. (And so are Ubuntu updates, if one considers that it's possible to provide fixup scripts to update-manager pre-upgrade.) As long as we're supporting upgrades through plain apt, that's going to be hard. Especially if you have non-distro packages installed that need to be migrated as well, with the tracking information updated. Maybe the issue here shouldn't be changing the default. After all there is a quite vocal opposition to such a step. I fail to see consensus in the recent mails without even contributing a personal opinion here. So really what does it take to e.g. move /bin and stuff to /usr? Did anyone try that? Where is that documented? What problems did occur? If we force a much bigger /, the chance of a broken / filesystem increases. If / is fine, one has a chance to fix the system without booting to rescue. So, a small / both decreases the probability of a boot failure and makes fixing breakage easier. If we change our software so that the system never gets beyond initrd stage if mount /usr fails, we increase the change of breaking boot because _two_ filesystems need to be fine and mounted before we leave initrd. Both changes are bad from a robustness point of view. Keeping the root fs small was a good idea 20 years ago, and it still is. 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1ua8sq-0004zd...@swivel.zugschlus.de
Re: Debian 7
On Wed, May 08, 2013 at 04:56:00PM +0100, Darac Marjal wrote: On Thu, May 09, 2013 at 01:49:56AM +1030, Mikael Livchenko wrote: Debian developers have allot to learn still in 2013 the documentation is flawed from the very first line. http://www.debian.org/releases/stable/installmanual Debian wheezy -- Installation Guide What is Debian wheezy? I only downloaded 'Debian 7'. wheezy is a nick name? where is it defined from the point of download? I cannot see it. I am guessing it is a nick name, but how many other people will know this? Wheezy. It's obvious, isn't it? It comes between Squeeze and Jessie. /sarcasm Wheezy is a brand. [...] No, it really isn't. Everything on the front page of www.debian.org refers to 'Debian 7.0' (with 'wheezy' as a secondary identifier in one place). All our formal documentation should identify stable releases by number and then optionally by codename. For the testing suite (i.e. pre- release), using the codename alone is more appropriate. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508181909.ga6...@decadent.org.uk
idea: generalized soft dependencies
Somewhat crazy idea, but let's see.
---
The problem
---
Subjectiveness of Recommends. Debian policy declares Recommends as
strong but not absolute dependency. Maintainers have different
subjective opinions of what belongs to Recommends/Depends/Suggests. Some
put a lot of extra stuff to Recommends. Because of that, and also for
historial reasons (Recommends were not installed by default for a lot of
time) many switch off installing Recommends globally. Some users and
developers even publicly advertise doing that to keep the system
cleaner. This in turn makes harder for maintainers to do 'Depends -
Recommends' moves.
The idea
tl;dr:
Soft-Depends: a {90%}, b (= 1.2) {20%}, c (= 4) {99%}, c (= 6) {70%}
Soft-Depends: iceweasel {50%,tag:desktop}, curl {95%,if_not_installed:wget}
Soft-Depends: debdelta {10%,text:to enable automatic delta downloading}
The idea is to (eventually) replace Recommends and Suggests with new one
field Soft-Depends (Weak-Depends, whatever), which would have the
scalable ability to express when this relation is expected to be
satisfied. The maintainer could use one or more standardized
expressions, most important of which would be the percent of
installations as guessed by mainainer.
Package managers can implement various actions and thresholds to
(better) satisfy different kind of users. Package managers would ignore
expressions it doesn't recognize/understand. System administrators could
finely adjust the package manager of choice, for example:
Some embedded system:
- 80%: display/suggest;
Some minimal system:
- 95%: enable by default;
- 75%: ask interactively;
- 50%: display/suggest;
- 25%,tag:server: ask interactively;
Default:
- 90%: enable by default;
- 40%: display/suggest;
Newbie system with enough disk space:
- 33%: enable by default;
- 5%,text: ask interactively;
Transition period could be 2-3 releases.
'Suggests: x' can be converted to/treated as 'Soft-Depends: x {10%}' and
'Recommends: y' -- 'Soft-Depends: y {90%}'.
Numbers/tags are quite arbitrary -- to give the picture.
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130508185154.GA4105@debian-w500.Elisa
Re: Debian 7
On 08/05/13 17:19, Mikael Livchenko wrote: also, why still using mailing list? this is the 2013. Mailing list is like living in 1993. spam bots love mail-list. mozilla bugzilla system is good chat system. the user e-mail address is hidden, and there is the login system. no one wants hundreds of e-mail's in inbox. or spam. i like open source projects and i hope the best for debian, but developers must come with real times Maybe you should fix your spamfilter -- outlook ? signature.asc Description: OpenPGP digital signature
Re: /export (was Re: jessie release goals)
Hi, On 08.05.2013 10:11, Josselin Mouette wrote: Le mercredi 08 mai 2013 à 11:59 +0400, Игорь Пашев a écrit : I proposed exactly an opposite thing for databases :-) If do not like /usr/home, you might not like to have your data under /var/lib ;-) The FHS has the perfect place for such data: /srv. I agree we should move the data there, but there is no reason to invent a new place. Sadly not. While I agree that /var/lib is the wrong location and /srv is more correct, we cannot use /srv as a distribution, while every site user is allowed to use /srv for that. That's the purpose of /srv, after all. However, we, as distribution are not allowed by means of FHS to assume any directory layout, or sub-directory structure below /srv (Therefore, no program should rely on a specific subdirectory structure of /srv existing or data necessarily being stored in /srv. However /srv should always exist on FHS compliant systems and should be used as the default location for such data) [1]. If you find some better directory than /var/lib (or, similarly, for /var/www) let me know. See also [2]. I'm still seeking one. [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM [2] 4f8a1567.80...@debian.org // https://lists.debian.org/debian-devel/2012/04/msg00301.html -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Debian 7
On Wed, May 08, 2013 at 07:19:09PM +0100, Ben Hutchings wrote: On Wed, May 08, 2013 at 04:56:00PM +0100, Darac Marjal wrote: Wheezy. It's obvious, isn't it? It comes between Squeeze and Jessie. /sarcasm Wheezy is a brand. [...] No, it really isn't. Everything on the front page of www.debian.org refers to 'Debian 7.0' (with 'wheezy' as a secondary identifier in one place). Which causes confusion. I had to look it up when someone mentioned Debian 6.0 yesterday, and I haven't ran debootstrap just once or ten times... The number seems to be never used outside the front page and few pieces of docs no one reads. I guess a good part of us doesn't know the numbers either. It's akin to knowing that 2000 XP Vista 7 -- these do have underlying real monotonic version numbers, too: https://en.wikipedia.org/wiki/Windows_NT#Releases yet no one uses them either. -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508205550.ga8...@angband.pl
Re: Switching default dpkg-deb compressor to xz
On Wed, May 08, 2013 at 06:14:36PM +0200, Bastian Blank wrote: On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ What about the compression level? xz -6 is pretty heavy and not needed for 99% of the packages. -3 or even -2 or -1 are sufficient. As my and Hideki's repacks of the archive show, special-casing small packages is a waste of time: gains are hardly below linear for any packages big enough to take longer than fork()ing the compressor. Quoting some data from 2011, all with xz -6: ] * A repack of the whole archive (amd64+all main, ~40GB) took close to three ] hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz). ] ] Does someone have an estimate how many core-hours would an archive rebuild ] on such a machine take? Folks on IRC quoted numbers like 340, 240 on a ] very fast box, more like 1500 -- too divergent for my liking. The ] first number, 340, would mean switching to xz exclusively would increase ] average build time by ~5%. ] ] * armel Cortex-A8 600MHz does xz consistently 12.1 times slower than one ] core of the above box (on a big compressible and a big uncompressible ] file), that's ~2.6 times slower per-MHz. ] ] Glancing at build logs of a few randomly chosen packages, I see armel ] builds taking respectively 16.9, 13.1, 18.8 and 15.1 times longer. Not ] sure what are the actual speeds of buildds, but it looks like armel would ] be affected by less than the above 5%. I'd thus suggest using the default, -6, everywhere other than perhaps openclipart (already compressed) and the likes. xz folks chose this value for a reason :) -- ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508211359.gb8...@angband.pl
Bug#707297: ITP: node-readdirp -- Recursive version of Node.js's fs.readdir
Package: wnpp Severity: wishlist Owner: Mike Gabriel mike.gabr...@das-netzwerkteam.de * Package name: node-readdirp Version : 0.2.4 Upstream Author : Thorsten Lorenz thlor...@gmx.de * URL : https://github.com/thlorenz/readdirp * License : MIT Programming Lang: Javascript Description : Recursive version of Node.js's fs.readdir Recursive version of fs.readdir. Exposes a stream api. . Although the stream API is recommended, readdirp also exposes a callback based API. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508211450.13200.34970.report...@minobo.das-netzwerkteam.de
Re: epoch fix?
Am 08.05.2013 19:33, schrieb Bart Martens: On Wed, May 08, 2013 at 10:16:28AM +0200, Josselin Mouette wrote: Le mercredi 08 mai 2013 à 05:04 +, Bart Martens a écrit : Michael Biebl wrote : The usage of really (...) that you don't have to fix all r-deps to include the the epoch in the Build-Depends. Why would adding an epoch cause the need for adding the epoch in the build-dependent packages ? Because otherwise these build-dependent packages will not bring the version they actually need? You know, what build-dependencies are for. I know what build-dependencies are for, thank you. :-) The question is why epoch would need more updating of Build-Depends than with the really approach. I'm missing Michael Biebl's point. *sigh* Is that really that hard to understand? -- 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
Bug#707302: ITP: ejs.js -- Embedded JavaScript templates (Node.js / Client)
Package: wnpp Severity: wishlist Owner: Mike Gabriel sunwea...@debian.org * Package name: ejs.js Version : 0.8.4 Upstream Author : TJ Holowaychuk t...@vision-media.ca * URL : https://github.com/visionmedia/ejs * License : MIT Programming Lang: Javascript Description : Embedded JavaScript templates (Node.js / Client) Features of EJS: . - Complies with the Express view system - Static caching of intermediate JavaScript - Unbuffered code for conditionals etc % code % - Escapes html by default with %= code % - Unescaped buffering with %- code % - Supports tag customization - Filter support for designer-friendly templates - Includes - Client-side support - Newline slurping with % code -% or % -% or %= code -% or %- code -% -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508214300.24292.58582.report...@minobo.das-netzwerkteam.de
Re: jessie release goals
Christoph Anton Mitterer wrote: 2) No more packages that bypass the package management system and secure apt: a) There are still several (typically non-free) packages which download stuff from the web, install or at least un-tar it somwhere without checking any integrity information that would be hardcoded in that package. There's nothing stopping you filing a release critical bug against any package that does this. I do it whenever I notice something doing that. It's a security hole, plain and simple, and while in the broader world curl http://insecure.example.org/ | sh is distressingly common, there's no reason to allow such things in Debian. (Last I checked, flashplugin-nonfree verified the integrity of its downloads in a secure way.) -- see shy jo signature.asc Description: Digital signature
Re: Current and upcoming toolchain changes for jessie
* Roger Leigh: On Wed, May 08, 2013 at 08:08:31AM +0200, Florian Weimer wrote: * Roger Leigh: On Tue, May 07, 2013 at 03:25:29PM +0200, Matthias Klose wrote: The decision when to make GCC 4.8 the default for other architectures is left to the Debian port maintainers. This makes using C++11 and other features only in 4.8 rather difficult. C++11 hasn't got a stable API yet (implying mass rebuilds on compiler updates). Do we really want to encourage its use at this point? While the C++11 API isn't completed in its entirety, a large proportion of it is complete, and as far as I am aware, the API for those parts is stable and there should be no issues at all with using these. I mistyped, I meant ABI. I'm deeply sorry about that, it mangles my statement quite badly. AFAIK, this is the major reason why the C++11 support is still marked as experimental. For example: std::shared_ptr, std::unique_ptr, std::tuple in the standard library, and language features such as decltype, nullptr, range-based for loops etc. std::string, std::list and probably std::shared_ptr will have to change ABI at some point. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5bpt9bx@mid.deneb.enyo.de
Re: epoch fix?
* Michael Biebl bi...@debian.org, 2013-05-08, 23:39: Why would adding an epoch cause the need for adding the epoch in the build-dependent packages ? Because otherwise these build-dependent packages will not bring the version they actually need? You know, what build-dependencies are for. I know what build-dependencies are for, thank you. :-) The question is why epoch would need more updating of Build-Depends than with the really approach. I'm missing Michael Biebl's point. *sigh* Is that really that hard to understand? Sorry, but this is not helpful. Let me try to explain where the difference lies. Consider the following sequences of uploads: foo_4 foo_5 foo_1:4 foo_1:6 bar_4 bar_5 bar_5really4 bar_6 Two kind of bugs in (build-)dependencies on these packages could happen: 1) foo (= 5) doesn't guarantee you that you get upstream version 5 or later. You need to use foo (= 1:5). Similarly, bar (= 5) doesn't guarantee you that you get correct upstream version. You need to use bar (= 6) or something. No big difference here. 2) foo (= 6) doesn't guarantee you that you get upstream version 6 or later. You need to use foo (= 1:6). Such mistake couldn't possibly happen with the epoch approach. bar (= 6) does the right thing. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508222506.gc...@jwilk.net
Re: jessie release goals
* Joey Hess jo...@debian.org, 2013-05-08, 17:53: (Last I checked, flashplugin-nonfree verified the integrity of its downloads in a secure way.) Last I checked, flashplugin-nonfree was unauditable. It downloaded a script from people.d.o and the ran it. We may never know what the script did. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508224258.gd...@jwilk.net
Re: wheezy postmortem re rc bugfixing
How about a slush? A few projects have this period where changes are not completely forbidden, but slightly restricted. For example, we could have a period where new upstream releases (yes, with huge diffstats) would be accepted if they fix a RC bug. In fact, I am of the opinion that we should relax the requirements that the release team systematically review every diff posted during the freeze, especially if the freeze is going to last almost a year... That always seemed to me to be an insane amount of work. And yes, I know that we have a progression of exceptions for the freeze already, I just feel that we could add an extra window... But maybe that's just me. :) A. -- We will create a civilization of the Mind in Cyberspace. May it be more humane and fair than the world your governments have made before. - John Perry Barlow pgpxS6_0I2gW7.pgp Description: PGP signature
Re: Switching default dpkg-deb compressor to xz
On Wed, May 08, 2013 at 11:13:59PM +0200, Adam Borowski wrote: On Wed, May 08, 2013 at 06:14:36PM +0200, Bastian Blank wrote: On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ What about the compression level? xz -6 is pretty heavy and not needed for 99% of the packages. -3 or even -2 or -1 are sufficient. As my and Hideki's repacks of the archive show, special-casing small packages is a waste of time: gains are hardly below linear for any packages big enough to take longer than fork()ing the compressor. dpkg-deb does not fork the xz: | $ objdump -x /usr/bin/dpkg-deb | grep liblzma | NEEDED liblzma.so.5 Quoting some data from 2011, all with xz -6: ] * A repack of the whole archive (amd64+all main, ~40GB) took close to three ] hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz). This doesn't add up to the numbers I have from real life packages. linux-image-*-amd64-dbg, compressed size 250MiB, takes 20-30 minutes to compress on an 61xx Opteron. I'd thus suggest using the default, -6, everywhere other than perhaps openclipart (already compressed) and the likes. xz folks chose this value for a reason :) What is the advantage of -6 over -1? How much better is it? How much less time does it need? How much memory does it need? Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, Errand of Mercy, stardate 3198.9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508224224.gb19...@waldi.eu.org
Re: jessie release goals
On Wed, 2013-05-08 at 17:53 -0400, Joey Hess wrote: There's nothing stopping you filing a release critical bug against any package that does this. I do it whenever I notice something doing that. Obviously :) The thing is just... we need a way (at least at a social level) to prevent this from happen in the first place... Not sure it it's already forbidden by the policy, but on the other hand, I doubt every developer always knows all parts of the policy by hard. Perhaps one should have a Security Guidlines for Packaging or so :) Cheers, Chris. smime.p7s Description: S/MIME cryptographic signature
Re: wheezy postmortem re rc bugfixing
Le Wed, May 08, 2013 at 06:48:01PM -0400, anarcat a écrit : In fact, I am of the opinion that we should relax the requirements that the release team systematically review every diff posted during the freeze, especially if the freeze is going to last almost a year... That always seemed to me to be an insane amount of work. I agree. For a large number of packages if not all, we should allow the package maintainers to manually migrate their packages to Testing during the Freeze, within boundaries set on debian-devel-announce by the release team. It looks like DAK is growing a set of nice commands, and that developers will be familiar with them by using PPAs, so let's use them for that purpose as well ! Like any other service (BTS, uploads to Unstable, ...), repeated abuse can be solved by blocking the access, and in the worst case scenario, an expulsion procedure. The goal is nevertheless to save time to everybody, and to make the released stable version more exciting by including more upstream fixes and improvements. Looking at http://bugs.debian.org/release-critical, it takes only a few monthes to find hundreds of new RC bugs in stable releases. I think that we should focus on regressions rather than RC bugs. New upstream releases in simple packages tend to solve problems in the core parts of the packages, and may introduce new parts that are not fully tested. It is to our benefit and the benefit of our users to incorporate in Stable new upstream releases that fix bugs in existing tools, even if they introduce new tools that are not as well tested, because on the other hand these new tools do not have a user base as large as the older ones. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130508232658.ga30...@falafel.plessy.net
Re: Switching default dpkg-deb compressor to xz
On Thu, 2013-05-09 at 00:42 +0200, Bastian Blank wrote: On Wed, May 08, 2013 at 11:13:59PM +0200, Adam Borowski wrote: On Wed, May 08, 2013 at 06:14:36PM +0200, Bastian Blank wrote: On Tue, May 07, 2013 at 09:49:03PM +0200, Guillem Jover wrote: As mentioned some months ago [0], I'm planning to switch dpkg-deb default compressor from gzip to xz, as there seemed to be consensus that was the way to go, and given the amount of already manually switched packages, or packaging helpers. :/ What about the compression level? xz -6 is pretty heavy and not needed for 99% of the packages. -3 or even -2 or -1 are sufficient. As my and Hideki's repacks of the archive show, special-casing small packages is a waste of time: gains are hardly below linear for any packages big enough to take longer than fork()ing the compressor. dpkg-deb does not fork the xz: | $ objdump -x /usr/bin/dpkg-deb | grep liblzma | NEEDED liblzma.so.5 Quoting some data from 2011, all with xz -6: ] * A repack of the whole archive (amd64+all main, ~40GB) took close to three ] hours on a 6xPhenomII 2.8GHz box (ar p|gzip/bzip2 -d|xz). This doesn't add up to the numbers I have from real life packages. linux-image-*-amd64-dbg, compressed size 250MiB, takes 20-30 minutes to compress on an 61xx Opteron. [...] Yes, it takes about as long as the compilation (depending on number of cores) because compression is not parallelised. It still seems worthwhile when the debug info is so large, but I would like to see dpkg use a parallelised xz compressor when the parallel option is present in DEB_BUILD_OPTIONS. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Debian 7
Darac == Darac Marjal mailingl...@darac.org.uk writes: Darac On Thu, May 09, 2013 at 01:49:56AM +1030, Mikael Livchenko wrote: http://www.debian.org/releases/stable/installmanual Debian wheezy -- Installation Guide What is Debian wheezy? I only downloaded 'Debian 7'. Darac Wheezy is a brand. It's not really any different than Snow Darac Leopard or XP. Do you expect people to care that one is Darac 10.6.8 and the other 5.1.2600? Mikael makes a good point even if the tone in the rest of his email was totally uncalled for (and, IMHO, plain wrong - mailing lists rule, dude!). Debian does not need to follow the stupidity that Apple and Microsoft have blessed us with. Call it Wheezy. Or call it Debian 7.0. Or even Debian 7.0/Wheezy. But not two different names, both seemingly randomly used in different parts of the same documentation chain, for the same stable release. It brings no value to anyone who is not intimately familiar with the development process (i.e. users). I've used and evangalized Debian for over 15 years now, and I believe this is the one complaint that never seems to go away! Though that only goes to show what an awesome distribution it is :-) Cheers (and congratulations to y'all on releasing Wheezy)! Shyamal -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehdh2clj@dallas.rhythmnetworks.com
Re: Merging / and /usr (was: jessie release goals)
On May 08, Marc Haber mh+debian-de...@zugschlus.de wrote:
If we force a much bigger /, the chance of a broken / filesystem
increases. If / is fine, one has a chance to fix the system without
booting to rescue. So, a small / both decreases the probability of a
boot failure and makes fixing breakage easier.
If we change our software so that the system never gets beyond initrd
stage if mount /usr fails, we increase the change of breaking boot
because _two_ filesystems need to be fine and mounted before we leave
initrd.
This is not relevant for what we are talking about because /usr *will*
be required be available to boot the system no matter where the files
currently in /{bin,sbin,lib} will end up.
If your goal is to have the smallest and least accessed file system
available for recovery then I recommend that you create a 200-250 MB
/boot and install grml-rescueboot.
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: Merging / and /usr (was: jessie release goals)
On May 08, Marc Haber mh+debian-de...@zugschlus.de wrote:
How would that be done for a 200 MB filesystem holding /, no extra
/boot partition, and a multi-gigabyte /usr beyond the 2T barrier?
Let's assume that at this point there are no files in /{bin,sbin,lib}
which have the same name of a file in /usr/{bin,sbin,lib} but are not
a symlink to them (which I suspect is something that we want anyway).
For each $file in /{bin,sbin,lib}:
if $file is a symlink to /usr/.../$file
do nothing
else
cp -a $file to /usr/...
ln -sf ../usr/.../$file $file
When /{bin,sbin,lib} only contain symlinks then they can be quickly
renamed, replaced by a symlink to /usr/$dir and finally safely deleted.
There is a tiny race here, but I am sure that there are much worse
ones while doing a dist-upgrade.
And now you have space in /boot for a 150 MB grml-small rescue image!
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: Debian 7
Wheezy user here!! The best Debian thus far! Will not trust my machine to any other! On Wed, May 8, 2013 at 8:58 PM, Shyamal Prasad shya...@member.fsf.orgwrote: Darac == Darac Marjal mailingl...@darac.org.uk writes: Darac On Thu, May 09, 2013 at 01:49:56AM +1030, Mikael Livchenko wrote: http://www.debian.org/releases/stable/installmanual Debian wheezy -- Installation Guide What is Debian wheezy? I only downloaded 'Debian 7'. Darac Wheezy is a brand. It's not really any different than Snow Darac Leopard or XP. Do you expect people to care that one is Darac 10.6.8 and the other 5.1.2600? Mikael makes a good point even if the tone in the rest of his email was totally uncalled for (and, IMHO, plain wrong - mailing lists rule, dude!). Debian does not need to follow the stupidity that Apple and Microsoft have blessed us with. Call it Wheezy. Or call it Debian 7.0. Or even Debian 7.0/Wheezy. But not two different names, both seemingly randomly used in different parts of the same documentation chain, for the same stable release. It brings no value to anyone who is not intimately familiar with the development process (i.e. users). I've used and evangalized Debian for over 15 years now, and I believe this is the one complaint that never seems to go away! Though that only goes to show what an awesome distribution it is :-) Cheers (and congratulations to y'all on releasing Wheezy)! Shyamal -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ehdh2clj@dallas.rhythmnetworks.com
Re: Merging / and /usr (was: jessie release goals)
On Thu, 2013-05-09 at 03:43 +0200, Marco d'Itri wrote:
On May 08, Marc Haber mh+debian-de...@zugschlus.de wrote:
How would that be done for a 200 MB filesystem holding /, no extra
/boot partition, and a multi-gigabyte /usr beyond the 2T barrier?
Let's assume that at this point there are no files in /{bin,sbin,lib}
which have the same name of a file in /usr/{bin,sbin,lib} but are not
a symlink to them (which I suspect is something that we want anyway).
For each $file in /{bin,sbin,lib}:
if $file is a symlink to /usr/.../$file
do nothing
else
cp -a $file to /usr/...
ln -sf ../usr/.../$file $file
When /{bin,sbin,lib} only contain symlinks then they can be quickly
renamed, replaced by a symlink to /usr/$dir and finally safely deleted.
There is a tiny race here, but I am sure that there are much worse
ones while doing a dist-upgrade.
mount -o bind / /tmp/root
mount -o bind /usr/bin /bin
mv /tmp/root/bin /tmp/root/bin.old
ln -s usr/bin /tmp/root/bin
rm -rf /tmp/root/bin.old
umount /bin
umount /tmp/root
This still leaves the system unbootable if it crashes at exactly the
wrong time, but there is no race condition in the running system. (And
the initramfs changes to mount /usr could conceivably include recovering
from missing symlinks in /.)
Ben.
And now you have space in /boot for a 150 MB grml-small rescue image!
--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison
signature.asc
Description: This is a digitally signed message part
