Re: /export (was Re: jessie release goals)

[Thomas Goirand]

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 :
> 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)

[Josselin Mouette]

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)

[Andrey Rahmatullin]

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?

[Josselin Mouette]

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 :
> 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 :
> 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?

[Thorsten Glaser]

Bart Martens  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?

[Thorsten Glaser]

Kurt Roeckx  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?

[Josselin Mouette]

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

[Dmitrijs Ledkovs]

On 7 May 2013 05:38, Stephen Kitt  wrote:
> Hi Wookey,
>
> On Tue, 7 May 2013 03:04:50 +0100, Wookey  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

[Raphael Hertzog]

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

[Raphael Hertzog]

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?

[Thomas Goirand]

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

[Dmitrijs Ledkovs]

On 8 May 2013 01:46, Raphael Hertzog  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

[Ansgar Burchardt]

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] 

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?

[Lars Wirzenius]

On Wed, May 08, 2013 at 08:26:13AM +, Thorsten Glaser wrote:
> Kurt Roeckx  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

[Julien Cristau]

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

[Goswin von Brederlow]

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?

[Adam Borowski]

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  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

[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.  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

[Stephen Kitt]

On Wed, 8 May 2013 03:57:20 +0100, Wookey  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  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 (

Re: Switching packages to non-awaiting triggers

[Jakub Wilk]

* Raphael Hertzog , 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

[Adam Borowski]

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] 
> 
> 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

[Goswin von Brederlow]

On Fri, May 03, 2013 at 07:11:35PM +0200, Bernhard R. Link wrote:
> * Holger Levsen  [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?

[Lars Wirzenius]

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

[Bastian Blank]

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?

[Mailbox]

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: [15606

Re: Merging / and /usr (was: jessie release goals)

[Philipp Kern]

On Wed, May 08, 2013 at 01:06:41AM +0200, Marco d'Itri wrote:
> On May 07, Marc Haber  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 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?

[Alberto Garcia]

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

[Goswin von Brederlow]

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)

[Philipp Kern]

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?

[Peter Samuelson]

[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 :
> 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

[Philipp Kern]

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

[Jakub Wilk]

* Goswin von Brederlow , 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?

[Bastian Blank]

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

[Guillem Jover]

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] 
> > 
> > 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?

[Bastian Blank]

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

[Guillem Jover]

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?

[Adam Borowski]

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)

[The Wanderer]

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  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?

[Matthias Klumpp]

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)

[Andrey Rahmatullin]

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?

[anarcat]

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?

[Wookey]

+++ 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)

[Marco d'Itri]

On May 08, The Wanderer  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?

[Philip Hands]

Hi Wookey,

Wookey  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)

[Helmut Grohne]

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

[Mikael Livchenko]

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

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: Jérémy Bobbio 

* Package name: parsley
  Version : 1.1
  Upstream Author : Allen Short 
* 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
.

-- 
Jérémy Bobbio.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

wheezy postmortem re rc bugfixing

[Ian Jackson]

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?

[Tollef Fog Heen]

]] 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

[Darac Marjal]

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.


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

[Michael Banck]

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] 
> 
> 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?

[Jakub Wilk]

* Tollef Fog Heen , 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

[Jérémy Bobbio]

Package: wnpp
Severity: wishlist
Owner: Jérémy Bobbio 

* Package name: txsocksx
  Version : 0.0.2
  Upstream Author : Arturo Filastò 
* 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)

[Andrey Rahmatullin]

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

[Samuel Thibault]

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

[Mikael Livchenko]

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

[Neil Williams]

On Wed, 8 May 2013 16:51:14 +0100
Ian Jackson  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?

[Clint Byrum]

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

[Bastian Blank]

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

[Joey Hess]

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

[Paul Wise]

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

[Raphael Hertzog]

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)

[Steve Langasek]

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

[Holger Levsen]

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?

[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.

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

[Marc Haber]

On Wed, 8 May 2013 11:56:15 +0200, Bastian Blank 
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)

[Marc Haber]

On Wed, 8 May 2013 01:06:41 +0200, m...@linux.it (Marco d'Itri) wrote:
>On May 07, Marc Haber  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)

[Marc Haber]

On Wed, 8 May 2013 17:32:13 +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?

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

[Ben Hutchings]

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.
> 
> 
> 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

[Eugene V. Lyubimkin]

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

[Carlos Alberto Lopez Perez]

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)

[Arno Töll]

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

[Adam Borowski]

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.
> > 
> > 
> > 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

[Adam Borowski]

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

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-readdirp
  Version : 0.2.4
  Upstream Author : Thorsten Lorenz 
* 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?

[Michael Biebl]

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)

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: ejs.js
  Version : 0.8.4
  Upstream Author : TJ Holowaychuk 
* 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

[Joey Hess]

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

[Florian Weimer]

* 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?

[Jakub Wilk]

* Michael Biebl , 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

[Jakub Wilk]

* Joey Hess , 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

[anarcat]

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

[Bastian Blank]

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

[Christoph Anton Mitterer]

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

[Charles Plessy]

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

[Ben Hutchings]

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

[Shyamal Prasad]

> "Darac" == Darac Marjal  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)

[Marco d'Itri]

On May 08, Marc Haber  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)

[Marco d'Itri]

On May 08, Marc Haber  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

[musicdev]

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 wrote:

>
> > "Darac" == Darac Marjal  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)

[Ben Hutchings]

On Thu, 2013-05-09 at 03:43 +0200, Marco d'Itri wrote:
> On May 08, Marc Haber  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

Depends: libfoo:foreign ???

[Andreas Beckmann]

Hi,

I just noticed that we have the first amd64 package in the archive that
has dependencies on :i386 qualified libraries:

Package: teamspeak-client
Version: 2.0.32-4
Installed-Size: 14360
Maintainer: Debian QA Group 
Architecture: amd64
Depends: libc6-i386 (>= 2.1.3), libice6:i386 (>= 1:1.0.0),
libjpeg62:i386 (>= 6b1), libsm6:i386, libx11-6:i386, libxext6:i386
Description: VoIP chat for online gaming
Homepage: http://www.teamspeak.com/
Description-md5: 99cc6b98b2f017b4c24e7c2d17526465
Tag: interface::x11, protocol::voip, role::program, uitoolkit::qt,
 use::gameplaying, works-with::audio
Section: non-free/net

Did we start to allow this?

If not, why wasn't that upload rejected?


Andreas


-- 
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/518b2f46.3060...@debian.org

Re: epoch fix?

[Nikolaus Rath]

Bastian Blank  writes:
> 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.

There is a real-world outside the buildds.

My first step to get a newer package version for a stable system in the
absence of an official backport is typically apt-get source foo &&
apt-get build-deps foo (with deb-src from unstable), followed by
dpkg-buildpackage. If the first works, but the second fails because of
unsatisfied build dependencies, something is definitely broken.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
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/87bo8k4tkq@vostro.rath.org

Re: Depends: libfoo:foreign ???

[Paul Wise]

On Thu, May 9, 2013 at 1:08 PM, Andreas Beckmann wrote:

> I just noticed that we have the first amd64 package in the archive that
> has dependencies on :i386 qualified libraries:
>
> Package: teamspeak-client

It appears that will block it from reaching testing:

http://packages.qa.debian.org/t/teamspeak-client.html

The proper thing to do would be to remove the amd64 package entirely
and have users install the i386 version.

-- 
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/CAKTje6GeFuc6usA7r=jbznhp2fkugupwv6-fywuvxj9k2uc...@mail.gmail.com

Re: epoch fix?

[Thomas Goirand]

On 05/08/2013 06:30 PM, Peter Samuelson wrote:
> # 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.
Yeah! And this mistake is very easy to make.

I did a similar "woopsie" recently myself with Breaks / Replaces,
(which was quickly solved) even though I quite know what
I was doing, simply because I forgot about the epoch. Of course,
that made the Breaks / Replaces completely useless.

Though, is there a way to fix human brains? I don't think so...
Would having the epoch written in the generated file names
solve the problem? I don't think so either...

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/518b429e.7030...@debian.org