Re: /bin/sh (was Re: jessie release goals)

[Helmut Grohne]

On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote:
> Helmut Grohne  subdivi.de> writes:
> 
> > What are the benefits of using shells other than dash for /bin/sh? (as
> 
> Why does dash get special treatment, anyway? It was ???suddenly??? in
> Debian after having been used in Ubuntu, but??? there never was an
> evaluation of shells.

dash gets special treatment cause it is /bin/sh now. And that happened
because at the time of evaluation it was deemed significantly better
than bash. Which leads us to the real question:

> I still believe the codebase of mksh is better (modulo issues
> introduced due to the active development), but I???m happy with
> freedom to choose one???s own system shell???

Can you quantify those benefits of using mksh? To that end I propose a
few questions, whose answers may help in this discussion.

What issues of dash does mksh solve? How many users are affected?
Is there a benefit in performance? How large is the margin?

> (asides from the two things you mentioned)

>From what you said I count your argument as a "belief" argument, because
it came without data. Sorry.

> ??? or provide an mksh-static binary package. Which could also
> be used in initrd.

Having the same shell for /bin/sh and the initrd actually is something
that can reduce complexity. Did you talk to the initramfs maintainers
about this idea? (Reference?)

Most arguments and weighting of benefits and costs was already done by
Russ Allbery and Steve Langasek, but one thing was not quite right:

Using the diversion mechanism to change /bin/sh is highly risky and was
never supported. Even if Debian only supports running dash (or bash) as
/bin/sh and we ignore problems from broken scripts, there still is the
breakage resulting from the diversion itself. As far as I can tell it
still breaks dash upgrades in all cases. So even the ambitious user
running mksh as /bin/sh and reporting patches for scripts using dashisms
(I never imagined using that word), would be screwed with the next
upgrade.

>From my point of view a change in handling /bin/sh is highly desirable
precisely now, because we all know that the current way is broken and it
was that way for two releases already. Fixing it will cause other
problems (unless all involved parties are geniuses), so fixing it early
in the release cycle is important. As far as I can tell from the huge
bug log partial fixes are already in place and patches are available for
the remainders[1]. IMHO go ahead an break sid now? Waiting longer means
never fixing it or dragging it into the next freeze.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538822#289

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/20130515065550.ga12...@alf.mars

Bug#708326: ITP: node-require-all -- Require all Node.js module files within a directory

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-require-all
  Version : 0.0.6
  Upstream Author : Felix Geisendörfer 
* URL : https://github.com/felixge/node-require-all
* License : Expat
  Programming Lang: Javascript
  Description : Require all Node.js module files within a directory

 This Node.js module provides an easy way to require all module files within a
 directory.
 .
 The require-all call also traverses subdirectories, an exclude regexp for
 subdirs can be specified. Additionally, a regexp filter can be given, so
 that only module files matching the filter pattern get included.


-- 
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/20130515062904.12214.35994.report...@minobo.das-netzwerkteam.de

Re: /bin/sh (was Re: jessie release goals)

[Tollef Fog Heen]

]] "brian m. carlson" 

> On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote:
> > On 05/15/2013 02:16 AM, Michael Biebl wrote:
> > >Am 15.05.2013 01:26, schrieb brian m. carlson:
> > >>On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> > >>>This is utter bullshit and you should already know it. Systemd is much
> > >>>more reliable as a whole than any other implementation. I have yet to
> > >>>see a use case where it is not better.
> > >>
> > >>It is not better if you don't want proprietary binary-format logs in
> > >
> > >The format may be binary, but it certainly is not proprietary [1]
> > 
> > I really can't believe people are still coming up with that non-sense.
> 
> Maybe because I read it on LWN (http://lwn.net/Articles/468381/):
> 
>   All complaints about UUIDs were quickly overshadowed by another issue
>   once the full proposal was posted: one might charitably say that there
>   is not, yet, a consensus around the proposed new logfile format. In a
>   sense, that is unsurprising, since that format is deliberately
>   undocumented and explicitly subject to change at any time.
> 
> You'll pardon me if I believe that LWN is a reputable source for
> information.

This was approximately correct a year and a half ago.  It's not correct
today, partly because people did want the format to be documented and
for it to settle down.

> > I have no idea why people assume that a binary format means it can only
> > be processed with a special, proprietary tool. Binary simply means what
> > it means, binary and not text which means it's a more stream-lined and
> > machine-readable format as opposed to a text format with no formatting
> > at all.
> 
> It means that it works completely differently from every existing Unix
> log parser on the planet.  syslog is hardly "no formatting at all".

syslog and other log files isn't structured particularly well.

> > And, when it comes to processing, binary data is actually *easier* to
> > process. Everyone who has ever written a text parser themselves will
> > agree.
> 
> I have written several, and I still prefer plain text.  I want to use
> the same tools to parse my logs that I have used for years, like
> logcheck.  Text files is the Unix way.

Nothing stops you from having plain text log files too while using the
systemd journal.  We're not planning on taking the old/regular-format
files away.  Adding the journal means you get more information, you get
better searchability and so on.  If you don't want that, turn it off.  I
want it, since it'll make it easier for me to manage my systems.

Cheers,
-- 
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/87ppwsdahz@qurzaw.varnish-software.com

Re: Debianizing the Java world?

[Thomas Koch]

On Tuesday, May 14, 2013 10:18:47 PM Daniel Pocock wrote:
> On 12/05/13 21:11, Bernd Zeimetz wrote:
> > On 05/11/2013 10:12 AM, Daniel Pocock wrote:
> >> On 11/05/13 04:35, Paul Wise wrote:
> >>> I think you want to discuss this on the debian-java list instead.

I'm working on the debian-repo-helper and debian-maven-helper packages to 
improve our packaging workflow. You're very welcome to help. But it's not as 
simple as you suggest.

But please keep this discussion on debian-java. I don't feel comfortable to 
bother everybody with the crap that we've to deal with in debian-java.

Regards,

Thomas Koch, http://www.koch.ro


-- 
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/3750646.9as0tigcde@x121e

Re: /bin/sh (was Re: jessie release goals)

[Tollef Fog Heen]

]] "brian m. carlson" 

> On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote:
> > Am 15.05.2013 01:26, schrieb brian m. carlson:
> > > On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> > >> This is utter bullshit and you should already know it. Systemd is much
> > >> more reliable as a whole than any other implementation. I have yet to
> > >> see a use case where it is not better.
> > > 
> > > It is not better if you don't want proprietary binary-format logs in
> > > /var/log with no documented way to turn them off.
> > 
> > http://www.freedesktop.org/software/systemd/man/journald.conf.html
> > Storage=none
> 
> Silly me.  I expected that if I installed systemd, that the appropriate
> man pages would be shipped with the package:

As you might have noticed, we are not yet shipping the latest upstream
version.  Upstream has added more documentation in the meantime.

-- 
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/87txm4danb@qurzaw.varnish-software.com

Re: Upcoming libgd2-{xpm,noxpm}-dev -> libgd2-dev transition

[Guillem Jover]

Hi!

On Mon, 2013-05-13 at 22:34:36 +0200, Ondřej Surý wrote:
> Two things has happened with GD Library:
> 
> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
>libgd2-dev now.  There are transitional packages which are ment
>to help with the move to libgd2-dev, so you don't have to make
>any changes right now - the binNMUs should work.

Might I suggest libgd-dev instead? If a later API revision makes lots
of other packages FTBFS, a new versioned libgdN-dev package can always
be introduced; otherwise unversioned ones in case of say just ABI bumps
are more correct and cause less painful transitions.

> 2. The upstream, which I accidentaly became part of, has released
>libgd-2.1.0-alpha1 today.  This release has merged most of the code
>from PHP fork of the library (only some custom antialiasing stuff
>was not merged).  But beware not, the API was kept backwards
>compatible.
> 
>The ABI has remained same as well, but I have decided to bump the
>SONAME to 3, because I have implemented the GCC visibility magick,
>so only symbols, which were ment to be exposed, are exposed now.

If the SOVERSION is now 3, then the shared library package would need
to be called libgd3 (and libgd3-dev or as mentioned above ideally
libgd-dev), or did I misunderstood something in the above?

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/20130515055534.ga3...@gaara.hadrons.org

Bug#708321: ITP: python3-pyparsing -- Python parsing module, Python3 package

[Thomas Goirand]

Package: wnpp
Severity: wishlist
Owner: Thomas Goirand 

* Package name: python3-pyparsing
  Version : 2.0.0
  Upstream Author : Paul McGuire 
* URL : http://pyparsing.wikispaces.com/
* License : MIT
  Programming Lang: Python
  Description : Python parsing module, Python3 package

 The parsing module is an alternative approach to creating and
 executing simple grammars, vs. the traditional lex/yacc approach, or
 the use of regular expressions.  The parsing module provides a
 library of classes that client code uses to construct the grammar
 directly in Python code.
 .
 Here's an example:
 .
  from pyparsing import Word, alphas
  greet = Word(alphas) + "," + Word(alphas) + "!"
  hello = "Hello, World!"
  print hello, "->", greet.parseString(hello)
 .
 This package contains the Python3 version of python-pyparsing.

Please note that this is a remix of the currently "pyparsing" package,
which currently exists in version 1.5.6 in Sid. Upstream author decided
to release 1.5.7 for python 2.x, and 2.0.0 for python 3.x, so we have
no other choice but to create 2 different source package to handle the
situation. Upload of both new versions will be done in Experimental
first, in order to handle the NEW queue safely.

Cheers,

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/20130515054037.12532.3446.report...@buzig.gplhost.com

Re: Call for Help: DebConf travel sponsorship team

[Juris Kaminskis]

Hi

Yes i can help

Juris
2013. gada 15. maijs 07:13 "Gunnar Wolf"  rakstīja:

> tl;dr:
>
>   We are trying to assemble a large enough (but not too large?) team
>   to help us rate the travel sponsorship requests for DebConf13. Many
>   aspects are still open to debate, but most probably we will follow
>   the usual, past years' procedure.
>
>   Are you interested in helping us?
>
> Longer version:
>
> A very important part of the DebConf organization is the rating of
> travel sponsorship requests -- Always a hard problem to work out, that
> involves people, involves social interaction. And although we have
> come up with some alternative ideas, we seem to have consensus on
> staying with the previous years' scheme: Have a team go through the
> requests, rate them, and assign the money we have for that. This team,
> the Team of the Thousand Names, is usually refered to within the
> general DebConf organizing team as "Travel Sponsorship Team", "Travel
> Bursaries Team" or simply "Herb".
>
> Obviously, the problem is much harder than just assigning the money to
> the various _tasks_ we have to do, as this decision direcly affects
> individuals. We have tried in the past to include in our team people
> from various areas of Debian, from different geographic origins, even
> with diffrent group of friends, in order to avoid "clique-based"
> rating, or in any way biasing the results.
>
> If being part of this team interests you (regardless of whether you
> are going to attend DebConf13 or not), please take a (casual?) look at
> the thread starting here:
>
>   http://lists.debconf.org/lurker/message/20130507.212452.a6fba4fa.en.html
>
> I have to thank/blame Gaudenz for giving the idea to make this a broad
> call, to the whole of Debian, as it is Debian funds we will be using,
> and it is Debian-related people (whether DDs, DMs, or unofficial
> contributors) we will be assigning to.
>
> What do we need from those who volunteer?
>
> First, during the next *few* days, we want to finish debating how will
> this process be, what should be weighed more and taken into account,
> and finish delineating the dates. If I remember correctly, the
> deadline for requesting this sponsorship is on Sunday 2013-05-19, and
> we are aiming at producing the results in early June (June 1st, did I
> hear?)
>
> Second, some time and patience. You will have to go through the amount
> of people requesting travel sponsorship (I'd expect ~50-100), look at
> their reasoning as to why they are requesting it, how reasonable their
> requested amount sounds (yes, "reasonable" is too broad a word -- The
> team will have to decide about it), and rate numerically. Usually,
> once the requesters are rated, we define a cutoff value -- This time,
> we have already quite a good budget reserved for the task, so it
> *might* be a matter of saying, "we reached up to applicant #45".
>
> Third, an extra bit of time and patience. Once the list is
> mostly-done, we usually have an IRC meeting to make sure the produced
> list looks sane, and to find any hiccups before they explode. And if
> they explode, believe me, it can be ugly. But they don't have to
> explode at all, as we are nice and careful ;-)
>
> Fourth, this year we want to do something that has never been done
> before: As requests for greater transparency have been made, we have
> to find a way on how to report our work, without breaching the privacy
> of the people who request this sponsorship (again, as this is a very
> personal, social and money-related topic, it can be very touchy). So,
> the work will not finish by June 1st, but somewhat later, quite
> probably a bit after DebConf itself.
>
> Again: You don't have to be a DebConf long-time organizer nor
> attendee. You don't have to be a many-years-long DD. We want the group
> to be diverse, and that *surely* includes people that simply are not
> in the same intra-Debian demographic group that most of us are.
>
> So, if you want to be a part of the team, please mail
> lists.debconf.org (and to make it easier to stay in the right thread,
> please reference Message-ID <20130507213815.ga56...@gwolf.org>)
> letting us know.
>
> We are aiming at enlarging the group. I expect a group of ~15 people
> to be large enough, but not too large (and that is roughly double what
> we have had so far).
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQIcBAEBCAAGBQJRkws1AAoJEGc6A+TB25If+u4P/3879NMWYSfxg9XJtOcIRcPj
> 8bUNtzMOtQg+61yOAUoCzwv+nUNQbez62SHqvtAPNskmvT4eENjoAPzjuGv+3S49
> ztyUoJ889h8ggPWrHImtwj+m0H7Bsy11t9++ftGYtVGtsirnqU6QZCMDu6D5GsJe
> RqnXaHSxyxy417KW6nth9oV+oaF+n19udqqisS2jf/3hn5T+boFI1pjHRjgP+IFN
> sVpjFe/TYtSCwfNymODMpXvMbzC0vE185+inTNyIUMRLOYs3BjxOTkhltzAH2B/+
> GCqzTIEEFd6vgvr0wVIJb1GV5GVpdK/G7oEZzNUTdFlSgXsyeNoCbAPlzsvdibBp
> CxfwSE7ZygLMPEnT6D/JFdUCw/S2X1aRsWpZI+h5RgmSvEg9Iom0vlhicivur8D1
> U26dC+249XNsPz79hkD5M0Aj0wDl+JnXUjJlm3H/3X+pSODHGBXyK3dmxB+4eeFK
> 7V0504sWehesXfxddX06tsULvgnapDpGdG+twHPv2UIV1gJCcMwQUv14xe

Re: Temporary solution for changelog problem in binNMUs

[Guillem Jover]

Hi!

On Tue, 2013-05-14 at 09:30:45 +0200, Helmut Grohne wrote:
> I acknowledge that I am coming late to the party. I dug into the
> discussion referenced from your other mail, but had a hard time finding
> specific arguments. This discussion appears to be a good candidate for
> http://wiki.debian.org/Debate even though it is probably too late to
> start that now.

(Personally I think I'd rather summarize all pros and cons of the
different possible proposals in a single place, though.)

I referenced (in <20130513164531.ga18...@gaara.hadrons.org>) a mail with
a list of some of the advantages:

  [adv] 

Something not there, is that I keep finding our handling of when to
ship copyright files (and changelog to a lesser degree) a bit suspect.
We supposedly want all binary packages to ship copyright info, and have
refactored extremely common licenses into base-files, but still some
binary packages (from the same source) are not self contained, and
require a Depended package to be present to provide the required
copyright file, through the usually problematic symlinked doc dir,
just to avoid the duplication.

> On Mon, May 13, 2013 at 03:16:57PM +0200, Guillem Jover wrote:
> > dpkg supports --control-show and --control-list (already in wheezy), which
> > can be used for stuff like:
> > 
> >   $ dpkg-query --control-show dpkg changelog
> > 
> > for installed packages, for example. Or:
> > 
> >   $ dpkg-deb --info foo.deb changelog
> 
> Maybe someone can point me to previous discussion answering aspects of
> the following questions?
> 
> 1) Raphael Hertzog suggested[1] that metadata could be stored
>compressed. Is that implemented already? (As far as I can see it
>would be part of file_show, but isn't.) If not, that would cause
>an increase in installation size. I guess that a typical desktop
>system would grow by about 50MB.

Already listed in [adv], also there that they could be de-duped (so,
yes Michael :). None of the possible db optimizations have been
implemented because they would mostly benefit if these new files are
installed in the dpkg db, so doing the work when it was not yet clear
if it would be used seemed a possible waste of time, or unnecessary
added complexity. Also one of the advantages of having this in the
dpkg db, is that these improvements can be deployed transparently
and incrementally, as they'd be an internal implementation detail.

Checking a currently installed sid system, I get 5 files that repeat
themselves more than 10 times:

  $ md5sum /var/lib/dpkg/info/* | sort | uniq -c -d -w 32 | \
sort -n | grep -E '^ *[0-9]{2,} '
 13 ffed98e3b35997a540e63501bd575415
 60 b8d01f7a8639f5710427ec1aca71c2df
 74 574b713906c216aa174737c0322d1b4b
709 5d0e769df33e016b3c52a0971e8d258c
734 dfdc3bad88b6e98080891d6323e2f58e

Which currently would save close to 6 MiB (assuming files taking 4 KiB
block sizes), otherwise with a more fine-grained filesystem they'd take
near 200 KiB, both quite insignificant.

>Note that the Emdebian crush policy requires copyright files to be
>compressed and changelogs to be absent.

These files being missing, should never be an issue. I can also see
allowing to configure the compression either when building dpkg, at
runtime, or both, depending on what we see makes more sense.

> 2) Some users may want to save disk space by elevating dpkg.cfg
>path-exclude=/usr/share/doc/*/changelog*
>path-exclude=/usr/share/doc/*/copyright
>This saves about 50MB on a desktop system. Is there a feature to
>systematically drop meta data? Being in the ball park of less than a
>percent of the installation size I am not sure whether this is worth
>the effort.

Ansgar asked the same, and yeah I'm not sure that's worth it either,
less so once de-dup and compression might be in place, and what I've
usually seen is for people discarding the doc dir except for the
copyright and changelog files. But I'd be very open to consider adding
options to drop these at install time if we see it does make a difference
or makes sense in places where it was possible before, because I can see
this could be considered a regression.

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/20130515053251.ga1...@gaara.hadrons.org

Re: /bin/sh (was Re: jessie release goals)

[brian m. carlson]

On Wed, May 15, 2013 at 02:12:10AM +0200, Michael Biebl wrote:
> Am 15.05.2013 01:26, schrieb brian m. carlson:
> > On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> >> This is utter bullshit and you should already know it. Systemd is much
> >> more reliable as a whole than any other implementation. I have yet to
> >> see a use case where it is not better.
> > 
> > It is not better if you don't want proprietary binary-format logs in
> > /var/log with no documented way to turn them off.
> 
> http://www.freedesktop.org/software/systemd/man/journald.conf.html
> Storage=none

Silly me.  I expected that if I installed systemd, that the appropriate
man pages would be shipped with the package:

  vauxhall ok % man journald.conf
  No manual entry for journald.conf

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: /bin/sh (was Re: jessie release goals)

[brian m. carlson]

On Wed, May 15, 2013 at 02:29:40AM +0200, John Paul Adrian Glaubitz wrote:
> On 05/15/2013 02:16 AM, Michael Biebl wrote:
> >Am 15.05.2013 01:26, schrieb brian m. carlson:
> >>On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> >>>This is utter bullshit and you should already know it. Systemd is much
> >>>more reliable as a whole than any other implementation. I have yet to
> >>>see a use case where it is not better.
> >>
> >>It is not better if you don't want proprietary binary-format logs in
> >
> >The format may be binary, but it certainly is not proprietary [1]
> 
> I really can't believe people are still coming up with that non-sense.

Maybe because I read it on LWN (http://lwn.net/Articles/468381/):

  All complaints about UUIDs were quickly overshadowed by another issue
  once the full proposal was posted: one might charitably say that there
  is not, yet, a consensus around the proposed new logfile format. In a
  sense, that is unsurprising, since that format is deliberately
  undocumented and explicitly subject to change at any time.

You'll pardon me if I believe that LWN is a reputable source for
information.

> I have no idea why people assume that a binary format means it can only
> be processed with a special, proprietary tool. Binary simply means what
> it means, binary and not text which means it's a more stream-lined and
> machine-readable format as opposed to a text format with no formatting
> at all.

It means that it works completely differently from every existing Unix
log parser on the planet.  syslog is hardly "no formatting at all".

> And, when it comes to processing, binary data is actually *easier* to
> process. Everyone who has ever written a text parser themselves will
> agree.

I have written several, and I still prefer plain text.  I want to use
the same tools to parse my logs that I have used for years, like
logcheck.  Text files is the Unix way.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Web ID as passwordless authentication for debian web services [was: Re: Developer repositories for Debian]

[Daniel Kahn Gillmor]

On 05/14/2013 10:03 AM, Jonas Smedegaard wrote:

> I have also thought WebID would be a perfect match for things like this.
[...]
> Daniel has raised concerns about WebID: 
> http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html
> 
> Quite frustrating, because I trust Daniels reasonings on crypto matters 
> far better than my own, yet feel strongly that WebID is the right way to 
> go for loosely coupled trust chains like this.
> 
> I think the way forward is for someone understanding WebID deeply to 
> explain it to Daniel and others working on Monkeysphere, to get it 
> integrated there.
> 
> As I understand it, technically the paperkey tool can be used to to 
> flesh out the core crypto material from a GPG (sub!)key and wrapping 
> that into an SSL key should be the way to go.  But that alone is not 
> enough: We also need trust in WebID from those in Debian deeply 
> understanding crypto.
> 
> Cc'ing Daniel, hoping he has time to shed some renewed light on this.

Web ID as a key verification mechanism has problems with centralized
authority.  Passwords have their own (distinct) set of serious problems,
as far as i can tell.

However, if we use Web ID as a key discovery mechanism and use other
(non-centralized, non-third-party) mechanisms to validate the keys found
therein, that seems like one decent way forward.

I'd be happy to see debian lead the way on using passwordless client
authentication on the web; other (non-debian) groups might want to use
similar infrastructure, and may even be willing to accept centralized,
third-party points of control.  They might still be better off than the
current FAIL of trying to avoid authentication replay attacks by asking
users politely to not reuse passwords across multiple authentication
domains.

I happen to think that debian is sufficiently capable that our internal
infrastructure should not be able to be MITM'ed by, say, the next
Diginotar (and it should not be DoS'ed by such a disaster either, the
way .nl was).  If adopting WebID puts us in that boat, that would be a
sad thing.  But i'm not saying anything that our DSA doesn't already
know, and they're better sysadmins than that.

And as a project, we already have a community-reinforced authentication
infrastructure (the OpenPGP certification network that all contributors
have to be connected to, as guided by the excellent debian-keyring
maintainers) that we could tie that key verification to without exposing
ourselves to greater risk from the diginotars of the world.

if i can help in implementing a debian-keyring-derived verification of
Web-ID-discovered keys for client-side TLS authentication, i'd be happy
to try to pitch in in my copious (why is there no sarcasm emoticon yet?)
free time.

Regards,

--dkg

PS please cc me on followup.



signature.asc
Description: OpenPGP digital signature

Bug#708314: general: i cannot access my system settings

[scarecrow]

Package: general
Severity: important

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these lines ***



-- System Information:
Debian Release: 7.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
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/20130515144114.12407.11345.reportbug@scarecrow

Re: /bin/sh (was Re: jessie release goals)

[Salvo Tomaselli]

> And, when it comes to processing, binary data is actually *easier* to
> process. Everyone who has ever written a text parser themselves will
> agree.
I guess everyone who has used grep, tr, sed and so on will disagree?

-- 
Salvo Tomaselli

http://web.student.chalmers.se/~saltom/


-- 
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/2166875.xrvvLYdKdA@hal9000

Re: /bin/sh (was Re: jessie release goals)

[John Paul Adrian Glaubitz]

On 05/15/2013 02:16 AM, Michael Biebl wrote:

Am 15.05.2013 01:26, schrieb brian m. carlson:

On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:

This is utter bullshit and you should already know it. Systemd is much
more reliable as a whole than any other implementation. I have yet to
see a use case where it is not better.


It is not better if you don't want proprietary binary-format logs in


The format may be binary, but it certainly is not proprietary [1]


I really can't believe people are still coming up with that non-sense.

I have no idea why people assume that a binary format means it can only
be processed with a special, proprietary tool. Binary simply means what
it means, binary and not text which means it's a more stream-lined and
machine-readable format as opposed to a text format with no formatting
at all.

And, when it comes to processing, binary data is actually *easier* to
process. Everyone who has ever written a text parser themselves will
agree.

Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/5192d6f4.6090...@physik.fu-berlin.de

Re: /bin/sh (was Re: jessie release goals)

[Michael Biebl]

Am 15.05.2013 01:26, schrieb brian m. carlson:
> On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
>> This is utter bullshit and you should already know it. Systemd is much
>> more reliable as a whole than any other implementation. I have yet to
>> see a use case where it is not better.
> 
> It is not better if you don't want proprietary binary-format logs in

The format may be binary, but it certainly is not proprietary [1]

Michael

[1] http://www.freedesktop.org/wiki/Software/systemd/journal-files

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: /bin/sh (was Re: jessie release goals)

[Michael Biebl]

Am 15.05.2013 01:26, schrieb brian m. carlson:
> On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
>> This is utter bullshit and you should already know it. Systemd is much
>> more reliable as a whole than any other implementation. I have yet to
>> see a use case where it is not better.
> 
> It is not better if you don't want proprietary binary-format logs in
> /var/log with no documented way to turn them off.

http://www.freedesktop.org/software/systemd/man/journald.conf.html
Storage=none


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: /bin/sh (was Re: jessie release goals)

[brian m. carlson]

On Sat, May 11, 2013 at 10:08:21PM +0200, Josselin Mouette wrote:
> This is utter bullshit and you should already know it. Systemd is much
> more reliable as a whole than any other implementation. I have yet to
> see a use case where it is not better.

It is not better if you don't want proprietary binary-format logs in
/var/log with no documented way to turn them off.  It is also
not better if you want an init that does not dump its own log messages
to LOG_KERN.  As a reasonably sane person, it had never occurred to me
to put non-kernel logs under LOG_KERN for any reason whatsoever.

For better or for worse, sysvinit provides a lot of modularity.  systemd
provides none of that modularity, and there are a lot of things it does
that I'd rather disable (or better yet, uninstall) because they're just
wrong.  When I've used upstart and sysvinit, I've never had
functionality that I wanted to disable and remove.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Bug#708306: ITP: typecatcher -- Download Google webfonts for off-line use

[Andrew Starr-Bochicchio]

Package: wnpp
Severity: wishlist
Owner: "Andrew Starr-Bochicchio" 

* Package name: typecatcher
  Version : 0.1
  Upstream Author : Andrew Starr-Bochicchio 
* URL :  https://launchpad.net/typecatcher
* License :  GPL-3
  Programming Lang:  Python
  Description : Download Google webfonts for off-line use
 TypeCatcher allows you to search, browse, and download Google webfonts
 for off-line use. You can preview fonts with adjustable size and text.


-- 
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/20130514232119.18383.49128.reportbug@asb-laptop

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

[Benjamin Drung]

Am Dienstag, den 14.05.2013, 20:35 +0900 schrieb Osamu Aoki:
> Hi,
> 
> On Mon, May 13, 2013 at 02:31:43PM +0200, Benjamin Drung wrote:
> > Am Montag, den 13.05.2013, 21:06 +0900 schrieb Osamu Aoki:
> > > This may be still buggy and may needs some more work.  I was thinking to
> > > update maint-guide using this so I need to be less wordy and the debmake
> > > program does more.
> > 
> > Should packaging-dev recommend debmake?
> 
> Not yet.  dh-make should be the standard operationg procedure.
> 
> Let's see how this new debmake program is percieved by others first.

Okay. Feel free to file a bug against packaging-dev once you consider it
mature enough.

-- 
Benjamin Drung
Debian & Ubuntu 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/1368571699.1595.2.camel@deep-thought

Re: Time to summarise the discussion on epoch ?

[Nathan Handler]

On May 14, 2013 5:08 PM, "Charles Plessy"  wrote:
> would there be a volunteer to summarise this discussion as a patch to the
> Developers's Reference ?  You do not need to be an expert: reading and
> understanding this thread is enough.

I would be up for working on this task.

Nathan

Time to summarise the discussion on epoch ?

[Charles Plessy]

Hi all,

would there be a volunteer to summarise this discussion as a patch to the
Developers's Reference ?  You do not need to be an expert: reading and
understanding this thread is enough.

Have a nice day,

-- 
Charles Plessy
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/20130514220738.ga23...@falafel.plessy.net

Re: /bin/sh (was Re: jessie release goals)

[Vincent Bernat]

 ❦ 14 mai 2013 11:54 CEST, Thomas Goirand  :

>> Yes of course, because a different init system will magically make your
>> other disk bootable.
>
> This is absolutely *NOT* what I said. Nothing in my message
> compares this or that init system. I just replied that when you
> have apache, it's easier to recover than with the PID1 crashing.
> That's it, nothing more, nothing less.

And you conveniently removed you original message:

>> That is quite not truth. Let's say you have a broken HDD, and that you
>> forgot to setup grub on the 2nd HDD or something else that will prevent
>> boot up. In one case, you're totally screwed, on the other, you just
>> restart Apache !

I have still hard time to consider that you absolutely did not mention
something related to a bootloader.

Like in the previous discussions, you use some twisted tactics to make
the consensus difficult to reach by using false claims, repeating them
over and over, then claiming otherwise and asking references until
everyone gets tired.
-- 
panic("Attempted to kill the idle task!");
2.2.16 /usr/src/linux/kernel/exit.c


pgpHJWSiu0FEC.pgp
Description: PGP signature

Re: Temporary solution for changelog problem in binNMUs

[Michael Biebl]

Am 14.05.2013 09:30, schrieb Helmut Grohne:
> 1) Raphael Hertzog suggested[1] that metadata could be stored
>compressed. Is that implemented already? (As far as I can see it
>would be part of file_show, but isn't.) If not, that would cause
>an increase in installation size. I guess that a typical desktop
>system would grow by about 50MB.

IIRC there was also the idea, to de-duplicate that metadata. E.g. for
binary packages built from the same source package, you would only store
the changelog and copyright once.
Some packages do that manually via symlinks right now (an approach I
don't particularly like).
If this is done globally, I think this would actually result in space
savings.

Guillem, is that information about de-duplication correct?

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Switching default dpkg-deb compressor to xz

[John Paul Adrian Glaubitz]

On 05/14/2013 10:53 PM, John D. Hendrickson and Sara Darnell wrote:


Ben what basis do you have against .gz ?


It was already mentioned, it takes more space. Everyone (e.g. Fedora 
with rpm) is switching to xz, not just Debian. The Linux kernel is using 
more advanced compression algorithms as well.


What problem are you having with xz?


And I'd love to know if it won't cause dependancy problems when someone
has more than one debian they are dealing with.


Yes, of course, we need to support every single configuration and every 
possible choice of preferred software again, meaning we are doomed to 
stick to old stuff again.


Really, is this argument going to be brought up forever? So if we can't 
make everyone 100% happy, we shouldn't do anything at all?


This isn't an argument anymore, it has become an idiotic circle jerk. 
Stop it, I am getting tired of that!



I doubt it's as simple as stated.


It is. We are already actively using it and you aren't even noticing. I 
have sponsored at least half a dozen packages recently which were using 
xz compression. No problems and no bugs reported at all with them.


If you like, I can verify them to work on my 1993 Amiga 1200, on my 1995 
Sun Ultra 1, on my PowerMac G4 and my Raspberry Pi, just to make sure it 
really works for everyone!



And yes I do think there are some that would inject problems (such as
killing init for a new startup that isn't compatible).


Dude, if you want to stick to 1985 technology, just use something else. 
We don't have and don't want to be compatible to the original(R) 
Unix(TM) because the original Unix is a piece of shit.


Have you ever sat in front of some ancient Sun, HP-UX or OSF/1 
workstation using the original pure Unix design? It's so cumbersome and 
uncomfortable to use, it makes you throw up. I had to deal with plenty 
of these beasts in my career and I was always happy once I were back to 
my Linux box. If you are using one of these, you can forget nearly 
everything you ever learnt about Unix from Linux. It probably won't work.


If we are losing compatibility with old Unix stuff because we're 
introducing new stuff to Linux and Debian, I can only say "god riddance!".


The "Unix Hater's Handbook" exists for a reason. I honestly think that 
everyone who praises the good old Unix design has never actually used 
any of the original Unices, they wouldn't praise them otherwise.



There are all kinds of proposals continually that are unwise.  And this
one has been complained against and re-submitted often already.


Please provide viable sources, thank you.


So why shouldn't I repeat past complaints others have made on previous
posts.


I don't know, but I think you shouldn't. Progress will happen anyways.


I think your singling me out.


My singling what?



Cheers,

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


--
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/5192ac28.6000...@physik.fu-berlin.de

Re: parsable copyright format 1.0 (jessie release goals)

[Bernhard R. Link]

* Sune Vuorela  [130512 12:43]:
> It is too much work for far too little gain. What *is* the gain?
> What is the gain of copyright files?

One big gain of a copyright file is the act of doing it.

For software to be distributable every copyright owner has to have
given his permission. To know that you have all those permissions,
you first need to know who those people actually are.
It also documents our reasonable exercises to reach our believe
that this is distributable.
I'd guess in some legislations such efford can make the difference
between "just distribute it no more" and "pay for every copy that
was made".

Bernhard R. Link


-- 
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/20130514212524.ga3...@client.brlink.eu

Re: Switching default dpkg-deb compressor to xz

[John D. Hendrickson and Sara Darnell]

Ben what basis do you have against .gz ?

And I'd love to know if it won't cause dependancy problems when 
someone has more than one debian they are dealing with.


I doubt it's as simple as stated.

What's wrong with saying so?

And yes I do think there are some that would inject problems (such as 
killing init for a new startup that isn't compatible).


There are all kinds of proposals continually that are unwise.  And 
this one has been complained against and re-submitted often already.


So why shouldn't I repeat past complaints others have made on previous 
posts.


I think your singling me out.


Ben Hutchings wrote:

On Mon, 2013-05-13 at 21:53 -0400, John D. Hendrickson and Sara Darnell
wrote:

I'm complaining.

Why are you fixing something that isn't broken and isn't an issue ?


It's not broken, but there is an issue: it's getting hard to fit a
generally useful set of packages and tasks on CD#1, and xz compression
would make this easier.  In general, xz can achieve substantially better
compression ratios than gzip, with little extra cost in decompression
time.


Are you trying to cause problems with free software?
Are you playing favorites?


What basis do you have for making such accusations?

It's too new to say if it has no long term problems (ie, such as 
support issues).


xz has been supported in Debian for some time, with no problems that I'm
aware of.


How is shipping (ie kernel) in all three of .gz, and .bz2,
and in .xz saving anyone on either size any time or effort?
It isn't.


Er... kernel.org does that, not Debian.

Ben.


I still think Compress is all the rage and the best of
end all solutions :)


Guillem Jover wrote:

Hi!

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







--
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/5192a43b.6070...@cox.net

Re: Your attitude on debian mailinglists

[John D. Hendrickson and Sara Darnell]

As I did you.

You all are WAY late with a new Debian that isn't chalk full of problems.

And you are dead wrong.  I am not the only one who posts disagreements 
with posts.  For example: Paul Wise often disagrees with ill 
alterations to Debian.


I don't like what's going on with the continual breakage of packages, 
the continual switching of things that shouldn't be switched.  The 
continual installer problems.  The prevention of fresh meat 
participating.  The prevention of new software in contributions section.


All of the mentioned are AGAINST Debian policy.  And to me, you trying 
to control speech: you are someone propagating the same things Paul 
Wise or others, and I, would complain of.


You are no list master of me.  Get off my list pal.



Alexander Wirt wrote:

Hi,

I already wrote you some warning(s) in the past about your attitude on Debian
Mailinglist. Unfortunatly I got several new complaints in the last weeks,
therefore I don't have any other choice than to ban you from our lists. This
ban holds at least 12 weeks and will not raised automatically. If you want to
participate again after 12 weeks, please come back to us.

Thanks
Alex - Debian Listmaster





--
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/5192a31b.8000...@cox.net

Re: Debianizing the Java world?

[Daniel Pocock]

On 12/05/13 21:11, Bernd Zeimetz wrote:
> On 05/11/2013 10:12 AM, Daniel Pocock wrote:
>> On 11/05/13 04:35, Paul Wise wrote:
>>> I think you want to discuss this on the debian-java list instead.
>>>
>>
>> The reason I posted here is that the concept is just as viable for other
>> languages with their own distribution systems (e.g. R and Drupal both
>> have their own package distribution mechanisms) and also because the
>> Java issues go beyond those of us who develop in Java - e.g. people now
>> use Eclipse for C++ and Python development.
> 
> Indeed, but then eclipses uses autofoo and distutils and not maven :)
> 

That is Eclipse itself - but there is a mighty stack of plugins
accessible through the official (and third party) marketplaces and they
are likely to be built in many different ways.

The foundation of this effort would simply be to systematically scan
projects (whether they are Java or not, Ivy, Maven, whatever) and try to
work out how many of them provide enough detail in some common place
(such as the Maven  data) to locate the source code and obtain
individual tags.

>From there, it would be possible to build some percentage of projects
automatically and prove that they are genuinely free.

It's not a silver bullet, but it may be a useful starting 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/51929c27.50...@pocock.com.au

Bug#708283: ITP: libmoosex-configuration-perl -- Define attributes which come from configuration files

[Oleg Gashev]

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libmoosex-configuration-perl
  Version : 0.02
  Upstream Author : Dave Rolsky 
* URL : https://metacpan.org/release/MooseX-Configuration
* License : Artistic-2.0
  Programming Lang: Perl
  Description : Define attributes which come from configuration files

 MooseX::Configuration lets you define attributes which can come from a
 configuration file. It also adds a role to your class which allows you to
 write a configuration file.


-- 
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/20130514182452.19269.39967.reportbug@debian.debian

Bug#708280: ITP: libtest-lwp-useragent-perl -- a LWP::UserAgent suitable for simulating and testing network calls

[Oleg Gashev]

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libtest-lwp-useragent-perl
  Version : 0.018
  Upstream Author : Karen Etheridge 
* URL : https://metacpan.org/release/Test-LWP-UserAgent/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : a LWP::UserAgent suitable for simulating and testing 
network calls


-- 
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/20130514175940.17494.88663.reportbug@debian.debian

Re: /bin/sh

[Steve Langasek]

On Tue, May 14, 2013 at 10:03:34AM -0700, Russ Allbery wrote:

> I think that, to convince people that flexibility won't cause stability
> and complexity problems, you're going to need to present a complete and
> fairly bulletproof implementation plan.  Given how difficult the bash to
> dash transition was, I think it's going to have a fairly high bar to meet.

dash still has two outstanding multiply-release-ignored grave bugs as a
result of the last transition.  A minimum demonstration of competence on the
part of anyone proposing to change the shell again is to fix those RC bugs
without introducing new ones.

> That being said, I think removing the use of diversions for handling the
> default shell and simplifying the current situation would remove
> complexity, and therefore should be strongly considered.  Once that's
> done, if you really want to change the root shell on your own system, it
> should again be possible to use a simple local diversion to do so.

Yes.

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

Re: /bin/sh (was Re: jessie release goals)

[Steve Langasek]

On Tue, May 14, 2013 at 08:59:57AM +, Thorsten Glaser wrote:
> Helmut Grohne  subdivi.de> writes:

> > What are the benefits of using shells other than dash for /bin/sh? (as

> Why does dash get special treatment, anyway?

Because /bin/sh is special under Debian policy, as an essential interpreter. 
So the right thing for the project is to treat *some* POSIX sh
implementation specially.  I don't think anyone (except you) actually cares
if this should be mksh or dash - we care that it should *not* be bash which
is too heavyweight, but I don't think there are any strong arguments why
mksh or dash should be preferred.

Which means that there is no strong argument for switching away from dash,
since that change would cause more work and introduce more bugs for no
material gain.

> It was “suddenly“ in Debian after having been used in Ubuntu, but… there
> never was an evaluation of shells.

No, you are apparently lacking in historical context.  The effort to switch
to dash by default began in Debian; it was accomplished in Ubuntu more
quickly because Ubuntu had no established userbase at the time and could
ignore the problem of local diversions of /bin/sh.  Debian then had to play
catch-up with the implementation of its own plan.

> I still believe the codebase of mksh is better (modulo issues
> introduced due to the active development), but I’m happy with
> freedom to choose one’s own system shell…

The end user can always add a local diversion again to point /bin/sh at mksh
if they choose.  But I don't see any reason why an end user should care
about this, period.

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

Re: jessie release goals

[Russ Allbery]

Joey Hess  writes:
> Paul Wise wrote:

>> Probably the rsync package should just ask you via debconf if you want
>> to serve any directories and what their names and paths should be.
>> Since most folks who have rsync installed don't need rsyncd, the
>> default would be to not setup anything.

> No, it should not. 60 packages depend on rsync.
> Installing a package like git should not require batting away debconf
> prompts about unusual configurations that, if something is typed into
> them, can expose the system to security holes.

+1

Debconf should be used in cases where a substantial percentage of the
people installing the package are going to want the thing Debconf is
prompting about.  If the vast majority of users aren't going to care about
that functionality at all, either the package should be split (generally
the best move) or the unusual configuration should be documented elsewhere
(like README.Debian) and possibly automated with an external configuration
tool.

The cvs package went down the debconf path, and it never failed to annoy
me.  When I installed the cvs package to get the cvs command-line client
to access remote CVS repositories, it asked me where I wanted to create a
directory to host CVS repositories.  I bet fewer than 1% of the people
installing cvs wanted to do anything of the sort.

For the specific case of rsync, I think we should just make rsync and
rsyncd (or rsync-server) packages and be done with it.  Yes, small
packages are to be avoided in general, but when the packages are used by
people with very different needs and one of them wants to add init scripts
to launch a daemon, to me that's a good reason for a package split.  I've
been mildly annoyed for years at all the systems I have that have a
completely useless rsync init script installed that runs with every boot.

-- 
Russ Allbery (r...@debian.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/87bo8d4het@windlord.stanford.edu

Re: jessie release goals

[Bob Proulx]

Philip Hands wrote:
> Vincent Lefevre writes:
> > I agree for these services (though Apache is useless after just
> > being installed, as one just has a dummy web page).
> 
> I don't know about you, but I find it quite reassuring to be able to
> confirm that the first half of an install is going pretty well when I
> get to see the "useless" dummy page from Apache.

I also find the empty default placeholder very useful.  I wouldn't
call it useless at all.

There are no security issues.  I see no resource differences since if
it wasn't intended to be used then it shouldn't have been installed.

Also, I am often hosting some service in a subdirectory.  No top level
page is needed.  I often have no reason to modify that top level page
ever and leave it unchanged.  The service hosted in a subdirectory
continues independently.

If things were changed to force users to create a dummy top level page
and enable the server then it would add additional required work over
what is done now.

> The RedHat assumptions on this issue make me as unhappy as the Debian
> ones appear to make you unhappy.  I suggest that this is just a matter
> of taste.

Agreed.  Strongly!

Bob


signature.asc
Description: Digital signature

Re: /bin/sh

[Russ Allbery]

Thorsten Glaser  writes:
> Helmut Grohne  subdivi.de> writes:

>> What are the benefits of using shells other than dash for /bin/sh? (as

> Why does dash get special treatment, anyway? It was “suddenly“ in
> Debian after having been used in Ubuntu, but… there never was an
> evaluation of shells.

There was, at the time.  dash was the fastest and most mature available
Bourne shell that offered a substantial speed improvement over bash in
extensive testing (particularly around boot speed).  We (and Ubuntu, for
similar reasons) therefore switched the default /bin/sh.

It's possible that, if mksh were available at the time and already
packaged and people had been testing it, it may have been chosen instead.
I don't know.  But I don't believe that it was in a state to be a
contender at the time.

Now, dash is already the default shell.  In order to change the default
shell again, I think those advocating a new default shell need to do the
same work that the dash advocates did the first time: show that the new
shell is substantially better than our current default shell in some
measurable, or at least clearly defensible, way.

> I still believe the codebase of mksh is better (modulo issues introduced
> due to the active development), but I’m happy with freedom to choose
> one’s own system shell…

I'm generally in favor of flexibility *provided that* it doesn't cost us
significant complexity.  However, the experience of the root shell switch
from bash to dash was that there's a *lot* of complexity here.

I think that, to convince people that flexibility won't cause stability
and complexity problems, you're going to need to present a complete and
fairly bulletproof implementation plan.  Given how difficult the bash to
dash transition was, I think it's going to have a fairly high bar to meet.

That being said, I think removing the use of diversions for handling the
default shell and simplifying the current situation would remove
complexity, and therefore should be strongly considered.  Once that's
done, if you really want to change the root shell on your own system, it
should again be possible to use a simple local diversion to do so.  (This
would, of course, not be a configuration directly supported by Debian as a
whole, so if anything breaks, you'll have to talk package maintainers into
being willing to take changes to fix it.)

-- 
Russ Allbery (r...@debian.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/87fvxp4hp5@windlord.stanford.edu

Re: jessie release goals

[Thomas Goirand]

On 05/13/2013 07:08 PM, Vincent Lefevre wrote:
> On 2013-05-07 23:54:36 +0800, Thomas Goirand wrote:
>> On 05/07/2013 04:00 AM, Vincent Lefevre wrote:
>>> This can be fine for some daemons/servers. For instance, for a web
>>> server, displaying a default web page is harmless. But what about a
>>> mail server? Any default config would probably lead to loss of mail
>>> if things like virtual alias domains are used.
>> If you set your MX pointer before setting-up your mail server,
>> then it's your fault if you loose some mails, and not at all
>> the fault of the way postfix (for example) is packaged.
> In one case, this was after a full reinstallation of the server (not
> Debian, but the problem would be the same). I didn't have the choice.

This is, IMO, a very special case.

> And removing the MX pointer several hours before the reinstallation
> would also have resulted in loss of mail.

Why do you think so? Normally, a mail server can be down
for up to a day, without any lost of mail.

> The cleanest solution, IMHO,
> would have been to use iptables to prevent SMTP connections before
> installing postfix, but for someone who doesn't know iptables yet,
> that's more complex than having the control on whether the daemon is
> started or not at install time.
I don't think iptables is more complex than postfix (in fact,
to some degree, it might even be more simple, considering
how complex postfix is). I do expect any administrator
handling postfix to also know iptables. Anyway, I don't think
this is a reason good enough to have postfix to not start
when you install it, and add one more step when configuring it.

You are also considering a specific case of the SMTP server,
where it is used to receive outbound emails. Sometimes, you
only install a mail server to handle system mails (like cron
jobs, and so on). In this case, it would really be not convenient
to have the daemon not starting by default.

Of course, YMMV depending on what you do with mail...

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/51926db5.2040...@debian.org

Re: Developer repositories for Debian

[Russ Allbery]

Jonas Smedegaard  writes:
> Quoting Olivier Berger (2013-05-14 14:27:51)

>> I'm not so sure how GPG integrates in the WebID landscape, but it seems
>> to me that WebID, based on Linked Data principles has some similarity
>> with Web of Trust concepts well known in the GPG system.

> Daniel has raised concerns about WebID: 
> http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html

> Quite frustrating, because I trust Daniels reasonings on crypto matters
> far better than my own, yet feel strongly that WebID is the right way to
> go for loosely coupled trust chains like this.

I'd never heard of WebID before this thread, but looking briefly at the
spec, I share Daniel's concerns.  I don't see how this eliminates reliance
on the normal CAs.  You still have to do certificate validation to be able
to trust the link between URL and keypair, and the WebID protocol provides
no way to do that certificate validation other than the normal CA process
(and doesn't provide any alternative CA).

If you're going to trust the normal CAs anyway, all that WebID is really
giving you is the ability to add additional metadata to the user's public
certificate by publishing it at a linked URL; you're still trusting the
public CAs implicitly to verify that user's certificate.

Furthermore, you're not even using a direct CA signature, but rather are
using the server certificate of the web server the user gives you in the
URL to validate that their *client* certificate is owned by them.  I
haven't fully thought through the implications of that, but at first
glance it strikes me as a repurposing of authentication data in a way that
isn't theoretically sound.

WebID is trying to solve both the authentication problem and the
distributed identity management problem.  Do we actually need the identity
management functionality?  If not, then the FOAF data isn't needed, and an
X.509 certificate from a Debian CA that issues certificates based on
GnuPG-signed requests would be sufficient for us to bootstrap our own
X.509 infrastructure without all the additional complexity of WebID.
(With the caveat, as mentioned previously, that we'd have to do some
thinking about expiration times and revocation.)

-- 
Russ Allbery (r...@debian.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/87k3n14i5f@windlord.stanford.edu

Re: jessie release goals

[Wookey]

+++ Stephen Kitt [2013-05-13 19:26 +0200]:

> Yes, but that's not the problem. Take the premise that the target directory
> structure is as described above, so most library development packages ship as
> many headers as possible in /usr/include. For now we'll assume all
> mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use
> mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example),
> the mingw toolchain needs to look in /usr/include as well.
> 
> This is all fine as long as libc6-dev is not installed (say perhaps with
> sbuild and cross-build-essential). But in a typical work environment,
> libc6-dev will be installed, and because we'll always be cross-compiling on
> the buildds, packages which need to build stuff for the host to run during
> the build (wine-gecko does this) need build-essential too, so libc6-dev
> headers end up in /usr/include and are picked up by the mingw toolchain.

Thank you for explaining this. I now understand your issue. It is
helpful to have an example of why a full-split might have advantages
over an 'only arch-dependent' split. Or at least that we need to be
careful about what the definition of 'arch-dependent' is, if we want
to include windows ABIs, or uclibc ABIs (I think those two cases may
well amount to the same problem). Can anyone from BSD camp tell us
whether having glibc-dev headers installed in a common dir would break
cross-building for them too?

Simon has expanded on this helpfully already: 'glibc is somewhat
special as part of the ABI' (remembering that multiarch maps to ABIs).

It's good to know about this before the design is set in stone, so
this conversation is timely. What I'm not sure about is whether the
multiarch-cross design is seriously broken or if it's just a matter of
packaging libc-dev correctly to allow for non-glibc platforms. 

Multiarch has thus far largely been thought of in terms of platforms
you can also install Debian to as well as build for. But
multiarch-cross ought to be a good fit for crossing to other platforms
(within reason) too. So we should certainly consider whether we can
sensibly accomodate that or not.

I'm not quite sure how best to decide that. Some people need to try
some stuff and report back, I suspect.

Would simply moving all the libc headers to /usr/include/$multiarch
fix mingw builds? How many other libraries are similarly affected?

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/20130514163759.ge2...@stoneboat.aleph1.co.uk

Bug#708266: ITP: libtest-failwarnings-perl -- module for adding test failures if warnings are caught

[Oleg Gashev]

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libtest-failwarnings-perl
  Version : 0.005
  Upstream Author : David Golden 
* URL : https://metacpan.org/release/Test-FailWarnings/
* License : Apache-2.0
  Programming Lang: Perl
  Description : module for adding test failures if warnings are caught

 Test::FailWarnings hooks $SIG{__WARN__} and converts warnings to Test::More's
 fail() calls. It is designed to be used with done_testing, when you don't
 need to know the test count in advance.
 .
 Just as with Test::NoWarnings, this does not catch warnings if other things
 localize $SIG{__WARN__}, as this is designed to catch unhandled warnings.


-- 
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/20130514150401.8920.4357.reportbug@debian.debian

Re: jessie release goals

[Joey Hess]

Paul Wise wrote:
> Probably the rsync package should just ask you via debconf if you want
> to serve any directories and what their names and paths should be.
> Since most folks who have rsync installed don't need rsyncd, the
> default would be to not setup anything.

No, it should not. 60 packages depend on rsync.
Installing a package like git should not require batting away debconf
prompts about unusual configurations that, if something is typed into
them, can expose the system to security holes.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Depends: libfoo:foreign ???

[The Wanderer]

On 05/14/2013 09:34 AM, Goswin von Brederlow wrote:


On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote:



If I'm correctly understanding what's being described here, I would
think that the full-functionality 64+32 Wine would probably be
another exception (unless it falls under "emulators", in which case
"another" doesn't apply); the 64-bit side is built against and
depends on 64-bit libraries, and the 32-bit side is built against
and depends on both 32-bit libraries and the already-built 64-bit
side, and both sides are needed for an install capable of handling
both 32-bit and 64-bit Windows programs.

I don't see any practical way to let a package providing the
full-functionality 64+32 Wine work without depending on both the
64-bit (native) and the 32-bit (foreign) libraries.


Wouldn't that be 64-bit + 32-bit binaries? I thought wine had
seperate binaries and a wrapper that picks the right one to start.


It does have separate binaries, but although I'm not an expert on the
Wine software architecture, AFAICT it doesn't have a wrapper; rather, in
a combined build, each binary will apparently detect what kind of
program you're running and either handle things itself (when the
architectures match) or transfer things over the other binary (when they
don't).


Wine depends on wine-bin:i386 or wine64-bin:amd64 (similar for
kfreebsd). The arch qualifier is not needed since the right thing
already happens (normaly).

Except there is wine-bin:powerpc. That kind of ruins that. A system
with amd64, i386 and powerpc configured would hapily use
wine-bin:powerpc instead of wine-bin:i386. Or wine-bin:i386 can be
used instead of wine-bin:kfreebsd-i386. But that is a matter of
pining the architectures corectly.


I'm afraid I don't quite understand what you're talking about here. Or
rather I think I do, but I don't see why you would have mentioned it at
this point, so I suspect I may be wrong.


For the full 64+32 Wine, I don't believe this is possible - or if
it is possible, no way of doing it has yet been documented that I
know of. The official Wine documentation of how to build that
configuration involves compiling the 32-bit side on the same 64-bit
host as the 64-bit side - and, importantly, compiling it against
the already-built but not-yet-installed 64-bit build tree.

Theoretically it might be possible to build the 64-bit side on an
amd64 machine, make the resulting tree available to an i386
machine, let the i386 machine compile the 32-bit side against the
64-bit tree, make the resulting tree available to the amd64 machine
again, and let the amd64 machine do the final 'make install' or
equivalent process. I wouldn't expect that to actually work,
though, given that it looks like the Wine "tools" built on the
64-bit side may get run during the 32-bit side of the build - and
even if it does work, that seems like far more trouble than should
be justifiable for what is otherwise a straightforwardly scriptable
build process.


That seems to be a problem in the wine build system though. It should
already be possible to build a 32bit only wine and a 64bit only
wine. And then you just need something to build the extra tools that
chose between 32bit and 64bit. Or not?

I don't know the wine build system so I can't say how much pain that
would cause. But it would be the most logical way.


As far as I can tell, there are no extra tools; it's all integrated into
the usual Wine binaries. I could be wrong about that, but I haven't seen
anything which seems to indicate such.

The real question is the one you posed in your other mail: can you
assemble a working combined install (with functionality equivalent to
the as-documented combined build) from the results of two separate
standalone builds, by correctly selecting which files from each side to
install, or are there actual important (functional) differences in the
binaries created by a combined build?

I'm running the builds to try to test that now, but it's not clear how
long it will take to come up with an even vaguely reliable answer. I'll
provide what information I come up with when I have it.

(If this becomes specifically about Wine, it may not any longer be
really on topic for -devel; if there would be a better place to discuss
it, I'd be willing to move the discussion, but if this is considered
sufficiently on-topic I don't have a problem with continuing it here.)


(This is the main use case I have for multi-arch -dev packages;
without them, the only way I can think of to potentially accomplish
a full 64+32 Wine build which I would expect to result in full
functionality is to identify all -dev packages needed for the
desired Wine library support, then pause in between build stages to
manually swap which architecture of each of those -dev packages is
installed - and swap back afterwards for normal compilation of
other things.)


Shifting the build tree around between amd64 and i386 and back to 
amd64 is no solution. That will never fly.


Yes, of course; t

Re: Source build-dependencies

[Goswin von Brederlow]

On Sat, May 11, 2013 at 06:03:30PM +0100, Wookey wrote:
> +++ Stephen Kitt [2013-05-09 10:46 +0200]:
> > On Thu, 9 May 2013 10:10:01 +0200, Mike Hommey  wrote:
> 
> > > * source build dependencies (such that e.g binutils-mingw-w64 build
> > >   depends on src:binutils instead of binutils-source)
> > 
> > Yes! That was on my list as well ;-). The Built-Using stanza could even be
> > filled in automatically in such cases...
> 
> I'd vote for that too, as it would be very helpful for
> cross-toolchain building. I hadn't realised that source build-deps
> was a possibility. Is it? Does anyone have a proposal for how it might
> work?
> 
> Wookey

1) dpkg: support dpkg -i foo.dsc, which unpacks the source to
/usr/src/ or something

2) apt: parse Sources.gz and add them to architecture src,
   "apt-get install binutils:src" downloads the dsc, orig.tar,
   debian.tar, ... and then passes the dsc file to dpkg for installing

2b) fix other tools like pbuilder-satify-depends, sbuild, ...

3) Sources can use Build-Depends: binutils:src using the multiarch
   syntax to qualify archs

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/20130514145731.GL27079@frosties

Re: jessie release goals

[Goswin von Brederlow]

On Mon, May 13, 2013 at 07:26:15PM +0200, Stephen Kitt wrote:
> On Sat, 11 May 2013 11:39:28 +0200, Goswin von Brederlow 
> wrote:
> > On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> > > 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).
> > 
> > But it wouldn't. The target directory structure would be the same
> > across all builds. It would always be
> > /usr/include/[$(DEB_HOST_MULTIARCH)] and
> > /usr/lib/[$(DEB_HOST_MULTIARCH)].
> > 
> > The effect of partial architecture is simply that not everything needs
> > to be build for that architecture and the partial architecture might
> > not be self hosting. E.g. we can cross build for mingw but we wouldn't
> > be including windows in Debian nor run a buildd on windows.
> 
> Yes, but that's not the problem. Take the premise that the target directory
> structure is as described above, so most library development packages ship as
> many headers as possible in /usr/include. For now we'll assume all
> mingw-w64-...-dev headers are in /usr/include/...-w64-mingw32; but to use
> mingw-targeted libraries other than mingw-w64-...-dev (libgtk for example),
> the mingw toolchain needs to look in /usr/include as well.

Every compile has to look in /usr/inlclude/triplet and /usr/include/.
mingw is no special case there.
 
> This is all fine as long as libc6-dev is not installed (say perhaps with
> sbuild and cross-build-essential). But in a typical work environment,
> libc6-dev will be installed, and because we'll always be cross-compiling on
> the buildds, packages which need to build stuff for the host to run during
> the build (wine-gecko does this) need build-essential too, so libc6-dev
> headers end up in /usr/include and are picked up by the mingw toolchain.

Only architecture independent header are in /usr/include.

Now in the case of w32/w64 as architectures those headers must also be
suitable for windows or they are no longer architecture independent. I
guess that is the problem you see.

I don't see that anything changes for the layout. You just added a
rather strange arch which breaks the architecture independency of
libc6-dev stuff. Is that any different from building for a uclibc
system? I think you have the same problem there.

How much of libc6-dev and other libs are we talking about here?

Packages could also have:

foo-dev-common:all (or all foo-dev):
/usr/include/foo.h

foo-dev:w32:
/usr/include/w32/foo.h -> ../foo.h

foo-dev:w64:
/usr/include/w64/foo.h -> ../foo.h

Then mingw would only need to look there. This would be special casing
those archs. So not an ideal solution.

> Likewise for other -dev packages which may be available for the host
> architecture but not the target architecture. Imagine the confusion then for
> configure scripts!

Yes, that is a big problem. Luckily we have Build-Depends/Conflicts so
all the right packages are there and all the wrong packages are not.
For buildds that shouldn't be a problem.

Also any link test for libs will fail if the -dev is not installed for
the right arch.
 
> As far as I can see there are three solutions to this:
> * split headers completely

Possible without any toolchain changes. Just move the files in every
-dev package.

> * drop the idea of building mingw packages using the existing Debian
>   packaging

I don't think mingw is overly special there. Cross-compiling,
esspecially for a different libc, will be verry similar.

> * add patches to all supported packages so that they build differently when
>   targeting mingw (and any other partial architecture which can't
>   share /usr/include)

* install w32/w64 packages in a sysroot, i.e. prefix every file on unpack.

Not sure how well that would work with maintainer scripts though. For
other cross-compiles one can use chroot but you probably don't want /
can't use that for w32/w64.

This could be done during build. Sort of like option 3. A small patch
to move debian/package/* to debian/package/usr/lib/mingw/ before
building the deb.

> Fedora went with the second solution; they have mingw-specific packages for
> everything they build targeting Windows. If we could build-depend on source
> packages (which has been mentioned elsewhere in this thread) this would be
> possible on Debian too, although it would be a bit of a chore for me (and
> whoever else wants to chip in). But I wouldn't want supporting a non-free
> operating system to become a chore for more Debian developers than necessary!
> 
> (The aim of all the

Re: Temporary solution for changelog problem in binNMUs

[Stefano Zacchiroli]

On Tue, May 14, 2013 at 09:30:45AM +0200, Helmut Grohne wrote:
> I acknowledge that I am coming late to the party. I dug into the
> discussion referenced from your other mail, but had a hard time finding
> specific arguments. This discussion appears to be a good candidate for
> http://wiki.debian.org/Debate even though it is probably too late to
> start that now.

Uh, why do you think so? One of the many nice things of wiki.d.o/Debate
is that it's really lightweight on the process side, it can be used
whenever one finds it's a good moment to do so.
…but no, I'm not volunteering to write an essay on this topic myself :-)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Temporary solution for changelog problem in binNMUs

[Goswin von Brederlow]

On Mon, May 13, 2013 at 11:09:53PM +0200, Ansgar Burchardt wrote:
> Hi,
> 
> [ dropped -release and -wb-team ]
> 
> Jonathan Nieder  writes:
> > One problem that that doesn't solve is what to do when a package would
> > be able to borrow its /doc/ directory from another package
> > (using a symlink) but for the changelog and copyright (which gets even
> > harder when binnmus are involved).  See http://bugs.debian.org/556015
> 
> Right, that would need looking into. A random idea: if doc/ is
> a symlink to doc/, then copy the binNMU part of the
> changelog to doc//changelog.Debian..gz, but do not
> generate doc//changelog.Debian.gz.
> 
> Ansgar

Huh?

If the changelog is symlinked and the package is binNMUed don't you
end up with something like in the deb?

foo-common:
/usr/share/doc//changelog.Debian.gz

libfoo (binNMU):
/usr/share/doc/ -> 
/usr/share/doc//changelog.Debian.binNMU-.gz (binNMU stanza)

The split off binNMU part needs to be arch qualified for multiarch or
you have the same problem as before in case binNMUs for multiple archs
are done independently (e.g. not the same reason).

I wouldn't want the original changelog to be modified at all at
install time and the other file causes no problem if it is arch
qualified.

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/20130514142258.GJ27079@frosties

Re: Temporary solution for changelog problem in binNMUs

[Goswin von Brederlow]

On Mon, May 13, 2013 at 06:04:58PM +0200, Holger Levsen wrote:
> Hi,
> 
> On Montag, 13. Mai 2013, Guillem Jover wrote:
> > The only thing the metadata solution would need now, is changing
> > packaging helper, all packages not using a helper, and changelog and
> > copyright extractors to look first in the new place, and fallback to
> > the old one for backwards compatibility.
> 
> that will only take four years or so.
> 
> 
> cheers,
>   Holger


If it is going to take 4 years then it is going to take 4 years.

So what? Only the packages being binNMUed need to be fixed already. So
when you want to binNMU something that isn't yet changed you change
it, if it isn't using dh_changelog, and do a sourcefull upload.


I find it more important to get a solution and to start adapting it.
Because if it takes 4 years just to decide we will make changelogs
metadata like propoased then it will take 8 years combined and not 4.

MfG
Goswin

PS: If it gets decided that binNMUs changelogs will be generated as
split-of files then that is OK too. But make an informed decision.
Don't pick something as temporary solution just because it would be
quick to hack together and leave the problem open.


-- 
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/20130514141154.GI27079@frosties

Re: Developer repositories for Debian

[Jonas Smedegaard]

Quoting Olivier Berger (2013-05-14 14:27:51)
> Russ Allbery  writes:
> 
> > Raphael Hertzog  writes:
> >> On Mon, 06 May 2013, Joerg Jaspert wrote:
> >
> >>> Nah, the webinterface just should end up like the DAM 
> >>> webinterface: You do whatever you need, then click a button - and 
> >>> voila, there is everything ready to copy/paste into a MUA. Send 
> >>> with sig, done.
> >
> >> Why? This is just a band-aid and not what I would call a web 
> >> interface. And except lazyness I don't see a good reason for that. 
> >> Web interfaces can be secure (and with an audit trail in case of 
> >> breach). After all we can manage our Debian passwords over a web 
> >> interface...
> >
> > That level of security isn't great, though.  GPG keys are much more 
> > secure than that password.  What we would want for equivalent 
> > security in a web interface is personal X.509 certificates.
> >
> 
> WebID [0] could be useful in this respect. It includes the use of SSL 
> certs for authentication, in addition to other benefits (see some 
> discussion in the thread at [1]).

I have also thought WebID would be a perfect match for things like this.


> > I think it would be interesting to have that infrastructure in 
> > place, but someone would need to build it (probably with some 
> > mechanism to bootstrap GPG keys into X.509 certificates -- and be 
> > careful of expiration times and figure out a good way to deal with 
> > revocation).
> >
> 
> I'm not so sure how GPG integrates in the WebID landscape, but it 
> seems to me that WebID, based on Linked Data principles has some 
> similarity with Web of Trust concepts well known in the GPG system.

Daniel has raised concerns about WebID: 
http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/001030.html

Quite frustrating, because I trust Daniels reasonings on crypto matters 
far better than my own, yet feel strongly that WebID is the right way to 
go for loosely coupled trust chains like this.

I think the way forward is for someone understanding WebID deeply to 
explain it to Daniel and others working on Monkeysphere, to get it 
integrated there.

As I understand it, technically the paperkey tool can be used to to 
flesh out the core crypto material from a GPG (sub!)key and wrapping 
that into an SSL key should be the way to go.  But that alone is not 
enough: We also need trust in WebID from those in Debian deeply 
understanding crypto.

Cc'ing Daniel, hoping he has time to shed some renewed light on this.


 - Jonas

[interest]: 
http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-March/000836.html

[scepticism]: 
http://lists.alioth.debian.org/pipermail/freedombox-discuss/2011-August/002426.html

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


--
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/20130514140321.23166.32...@bastian.jones.dk

Re: Depends: libfoo:foreign ???

[Goswin von Brederlow]

On Mon, May 13, 2013 at 10:31:54AM -0400, The Wanderer wrote:
> On 05/13/2013 10:22 AM, The Wanderer wrote:
> 
> >On 05/13/2013 09:46 AM, Wookey wrote:
> 
> >>Hmm. Do the parts of the 64-bit tree that the 32-bit side compiles
> >>against end up installed in a final installation (as libraries?) or
> >>are they really just intermediate 'during build' items?
> >
> >They do end up getting installed, though whether as libraries or not
> >I don't recall offhand.
> 
> I think I may have misunderstood this question.
> 
> Some of the 64-bit components which would ordinarily get installed in a
> 64-bit-only build get omitted from the final install (and possibly from
> compilation) in a combined build, because the 32-bit components replace
> them. Not all do, however, and some - I think most - do get installed as
> both in parallel.
> 
> I would have to investigate the build process more closely in order to
> say much more with any certainty.

Could you build a 32bit only, a 64bit only and a 32+64bit wine, run
make install for each case and generate a file list for each?
Including "file" output so it shows what is 32bit and what 64bit in
the mixed case.

Also what happens if you take the list for 32+64bit and then manually
pick the respective files from the 32bit only and 64bit only tree
according to bitness of the files? Does that produce something
functional? Equal to the 32+64bit build?

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/20130514134017.GH27079@frosties

Re: Depends: libfoo:foreign ???

[Goswin von Brederlow]

On Mon, May 13, 2013 at 07:55:30AM -0400, The Wanderer wrote:
> On 05/09/2013 11:59 AM, Wookey wrote:
> 
> >+++ Goswin von Brederlow [2013-05-09 11:39 +0200]:
> 
> >>I would say that a foreign dependency on a library is never right.
> >
> >That's too strong. It can make sense for cross-tools, or maybe
> >emulators, which genuinely need a foreign-arch library to operate.
> >But I'm not aware of other sensible usages.
> 
> If I'm correctly understanding what's being described here, I would
> think that the full-functionality 64+32 Wine would probably be another
> exception (unless it falls under "emulators", in which case "another"
> doesn't apply); the 64-bit side is built against and depends on 64-bit
> libraries, and the 32-bit side is built against and depends on both
> 32-bit libraries and the already-built 64-bit side, and both sides are
> needed for an install capable of handling both 32-bit and 64-bit Windows
> programs.
> 
> I don't see any practical way to let a package providing the
> full-functionality 64+32 Wine work without depending on both the 64-bit
> (native) and the 32-bit (foreign) libraries.

Wouldn't that be 64-bit + 32-bit binaries? I thought wine had seperate
binaries and a wrapper that picks the right one to start.

Wine depends on wine-bin:i386 or wine64-bin:amd64 (similar for
kfreebsd). The arch qualifier is not needed since the right thing
already happens (normaly).

Except there is wine-bin:powerpc. That kind of ruins that. A system
with amd64, i386 and powerpc configured would hapily use
wine-bin:powerpc instead of wine-bin:i386. Or wine-bin:i386 can be
used instead of wine-bin:kfreebsd-i386. But that is a matter of pining
the architectures corectly.

> >>If the source compiles binaries for the foreign arch then the
> >>package should be build on the foreign arch directly. Period.
> >
> >Apart from the above exceptions, I agree.
> 
> For the full 64+32 Wine, I don't believe this is possible - or if it is
> possible, no way of doing it has yet been documented that I know of. The
> official Wine documentation of how to build that configuration involves
> compiling the 32-bit side on the same 64-bit host as the 64-bit side -
> and, importantly, compiling it against the already-built but
> not-yet-installed 64-bit build tree.
> 
> Theoretically it might be possible to build the 64-bit side on an amd64
> machine, make the resulting tree available to an i386 machine, let the
> i386 machine compile the 32-bit side against the 64-bit tree, make the
> resulting tree available to the amd64 machine again, and let the amd64
> machine do the final 'make install' or equivalent process. I wouldn't
> expect that to actually work, though, given that it looks like the Wine
> "tools" built on the 64-bit side may get run during the 32-bit side of
> the build - and even if it does work, that seems like far more trouble
> than should be justifiable for what is otherwise a straightforwardly
> scriptable build process.

That seems to be a problem in the wine build system though. It should
already be possible to build a 32bit only wine and a 64bit only wine.
And then you just need something to build the extra tools that chose
between 32bit and 64bit. Or not?

I don't know the wine build system so I can't say how much pain that
would cause. But it would be the most logical way.

> (This is the main use case I have for multi-arch -dev packages; without
> them, the only way I can think of to potentially accomplish a full 64+32
> Wine build which I would expect to result in full functionality is to
> identify all -dev packages needed for the desired Wine library support,
> then pause in between build stages to manually swap which architecture
> of each of those -dev packages is installed - and swap back afterwards
> for normal compilation of other things.)

Shifting the build tree around between amd64 and i386 and back to
amd64 is no solution. That will never fly.

If the two archs can't be build seperately then I guess you will have
to encourage maintainers to make their -dev packages coinstallable
quickly for jessie. And get support for Build-Depends: libfoo-dev:i386
[amd64] added.

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/20130514133439.GG27079@frosties

Re: /bin/sh (was Re: jessie release goals)

[Ben Hutchings]

On Tue, 2013-05-14 at 08:59 +, Thorsten Glaser wrote:
> Helmut Grohne  subdivi.de> writes:
> 
> > What are the benefits of using shells other than dash for /bin/sh? (as
> 
> Why does dash get special treatment, anyway? It was “suddenly“ in
> Debian after having been used in Ubuntu, but… there never was an
> evaluation of shells.
[...]

Because it's our very own tiny shell:
http://en.wikipedia.org/wiki/Debian_Almquist_shell

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered an expert.


signature.asc
Description: This is a digitally signed message part

Re: /bin/sh (was Re: jessie release goals)

[Toni Mueller]

On Sat, May 11, 2013 at 08:44:30PM +0100, Roger Leigh wrote:
> ...
> forcing the rest of the world to conform to our worldview.  One
> desktop environment, and an awful one at that, dictating the
> init system we use is a complete farce.  Debian is a lot bigger
> than GNOME, and if we have to, I'd vote for junking it entirely.

As much as I liked GNOME over competing desktops in the past, this time
I have to fully agree with this statement of yours.


Kind regards,
--Toni++


-- 
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/20130514131241.ga10...@spruce.wiehl.oeko.net

Re: jessie release goals

[Ondřej Surý]

On Tue, May 7, 2013 at 9:06 AM, Thijs Kinkhorst  wrote:
> I suggest that you file a bug against php5 with suggested changes and we can 
> discuss the pros and cons of each for jessie.

And I must add that I consider very rude to push your (sometimes
extreme, sometimes very usefull) ideas how should PHP in Debian look
like directly as a freaking *release goals* instead of opening this
first in php-maint list for discussion.

> All in all I don't see any Release Goal material yet, here.

+1

O.
--
Ondřej Surý 


--
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/CALjhHG_+6nBjVF+ejTEmXJxtVKVA4TEm=BsxCctqdb04=ld...@mail.gmail.com

Re: detailed lists with archive contents - more than just Contents

[Goswin von Brederlow]

On Mon, May 13, 2013 at 03:21:35PM +0200, Helmut Grohne wrote:
> On Mon, May 13, 2013 at 11:48:06AM +0200, Goswin von Brederlow wrote:
> > Both cases would need data for multiple archs.
> > 
> > For the second case if identical files are in all foo_arch.deb then
> > those should be in foo-common_all.deb. A dedup across archs instead of
> > across packages.
> 
> Thanks for explaining. Still this task is quite different from the task
> dedup.d.n is solving, since it requires to look at one package instead
> of looking at one architecture (+ all). Adding support for this to
> dedup.d.n would vastly increase resource usage beyond the currently
> available hardware. In addition the scalability issues differ, since the
> number of architectures is comparatively small to the number of
> packages. Maybe a different tool can solve these two useful tasks you
> proposed?
> 
> Helmut

Well, generating a list of all files in all packages with size and
hash would be a common subtask for both. But you mentioned dedup.d.n
only looks at amd64 so far. That certainly reduces the amount of work.

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/20130514131649.GF27079@frosties

Re: epoch fix?

[Colin Watson]

On Tue, May 07, 2013 at 10:19:18PM +, Thorsten Glaser wrote:
> Matt Zagrabelny  d.umn.edu> writes:
> > Use the mechanism of "really":
> 
> That is *much* *much* *much* *much* *much* *much* *much* *much* *much*
> *much* *much* *much* *much* *much* *much* *much* more ugly than epochs
> and actually a prime example of why we *want* them.

One reason why epochs are somewhat dangerous when reverting to a
previous version are that it's rather tempting to do this:

  1.0-1
  1.1-1
  1:1.0-1

Since the epoch isn't in the filenames, this results in a clash: which
foo_1.0-1.{dsc,debian.tar.gz} do you want?  Normally the Debian archive
prevents this, but I have seen cases where the original "1.0-1" was long
enough ago that it had forgotten about it; I've furthermore even seen
cases where the new foo_1.0.orig.tar.gz wasn't the same as the old one.
For me, this manifests as an inability to sync the new version
unmodified into Ubuntu, but there are doubtless other effects too.  It's
certainly extremely confusing.  The "really" scheme, ugly though it is,
is safer when going back to earlier version numbers.

Epochs are still sensible when changing between entirely different
version numbering schemes.

-- 
Colin Watson   [cjwat...@debian.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/20130514130054.gb7...@riva.ucam.org

Re: epoch fix?

[Colin Watson]

On Wed, May 08, 2013 at 05:55:22PM +0200, Tollef Fog Heen wrote:
> ]] 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,

Fixed a while ago, indeed, largely by the relevant script being entirely
superseded by something better.  (It was never a fatal flaw - it just
required some tedious manual work.)

-- 
Colin Watson   [cjwat...@debian.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/20130514125550.ga7...@riva.ucam.org

Re: Developer repositories for Debian

[Paul Tagliamonte]

On Tue, May 14, 2013 at 02:27:51PM +0200, Olivier Berger wrote:
> >>> Nah, the webinterface just should end up like the DAM webinterface: You
> >>> do whatever you need, then click a button - and voila, there is
> >>> everything ready to copy/paste into a MUA. Send with sig, done.
> >
> >> Why? This is just a band-aid and not what I would call a web interface.
> >> And except lazyness I don't see a good reason for that. Web interfaces
> >> can be secure (and with an audit trail in case of breach). After all we
> >> can manage our Debian passwords over a web interface...
> >
> > That level of security isn't great, though.  GPG keys are much more secure
> > than that password.  What we would want for equivalent security in a web
> > interface is personal X.509 certificates.
> >
> 
> WebID [0] could be useful in this respect. It includes the use of SSL
> certs for authentication, in addition to other benefits (see some
> discussion in the thread at [1]).
> 

Or, we can just add this to dcut, like with DM permissions, and move on
with all of our lives -- I mean, we're using this tool to push stuff, it
seems sane to keep it all in one place, anyway.

Once the format is nailed down, I'll add this to dput-ng.

Right.

Cheers,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Re: Developer repositories for Debian

[Olivier Berger]

Russ Allbery  writes:

> Raphael Hertzog  writes:
>> On Mon, 06 May 2013, Joerg Jaspert wrote:
>
>>> Nah, the webinterface just should end up like the DAM webinterface: You
>>> do whatever you need, then click a button - and voila, there is
>>> everything ready to copy/paste into a MUA. Send with sig, done.
>
>> Why? This is just a band-aid and not what I would call a web interface.
>> And except lazyness I don't see a good reason for that. Web interfaces
>> can be secure (and with an audit trail in case of breach). After all we
>> can manage our Debian passwords over a web interface...
>
> That level of security isn't great, though.  GPG keys are much more secure
> than that password.  What we would want for equivalent security in a web
> interface is personal X.509 certificates.
>

WebID [0] could be useful in this respect. It includes the use of SSL
certs for authentication, in addition to other benefits (see some
discussion in the thread at [1]).

> I think it would be interesting to have that infrastructure in place, but
> someone would need to build it (probably with some mechanism to bootstrap
> GPG keys into X.509 certificates -- and be careful of expiration times and
> figure out a good way to deal with revocation).
>

I'm not so sure how GPG integrates in the WebID landscape, but it seems
to me that WebID, based on Linked Data principles has some similarity
with Web of Trust concepts well known in the GPG system.

Just my 2 cents,

[0] http://webid.info/
[1] http://lists.debian.org/debian-project/2013/02/msg00048.html
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)


-- 
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/8738tpwxtk@inf-8657.int-evry.fr

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

[Osamu Aoki]

Hi,

On Mon, May 13, 2013 at 02:31:43PM +0200, Benjamin Drung wrote:
> Am Montag, den 13.05.2013, 21:06 +0900 schrieb Osamu Aoki:
> > This may be still buggy and may needs some more work.  I was thinking to
> > update maint-guide using this so I need to be less wordy and the debmake
> > program does more.
> 
> Should packaging-dev recommend debmake?

Not yet.  dh-make should be the standard operationg procedure.

Let's see how this new debmake program is percieved by others first.

Regards,

 Osamu

PS: debmake is designed to be compatible with GUI in mind.  I am open
for GUI patch :-)


-- 
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/20130514113535.GB6551@goofy.localdomain

Re: parsable copyright format 1.0 (jessie release goals)

[Jonathan Dowland]

On Sun, May 12, 2013 at 07:52:25PM +0800, Thomas Goirand wrote:
> Being able to write tools to extract the license of any given package.

Well, extract what the maintainer thought the license was when they wrote
debian/copyright. What correlation that has with reality is an open question.


-- 
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/20130514111930.GA3761@debian

Re: jessie release goals

[Jonas Smedegaard]

Quoting Wouter Verhelst (2013-05-14 12:22:14)
> On 13-05-13 05:59, Mark Symonds wrote:
> > Can we keep the distribution simple enough for nearly anyone to 
> > understand?
> 
> No.
> 
> The goal of Debian is not to be "simple". While we should document 
> things as much as possible so that the interested can learn how things 
> work, in no case should we ever avoid doing the technically sound 
> because it is "difficult to understand".
> 
> -- 
> This end should point toward the ground if you want to go to space.
> 
> If it starts pointing toward space you are having a bad problem and you
> will not go to space today.
> 
>   -- http://xkcd.com/1133/

Did you pick that quote to support your point, or was it added 
automatically?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


--
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/20130514111818.4452.28...@bastian.jones.dk

Re: jessie to be a derivative?

[Paul Wise]

On Tue, May 14, 2013 at 6:03 PM, Wouter Verhelst wrote:

> That's already possible, just put mentors.debian.net in your sources.list?
>
> Having said that, the point of mentors.debian.net is that inexperienced
> maintainers can upload their packages there, so that a debian developer
> can look at them and give feedback -- not that people should use it as
> an archive of installable packages.

While mentors.d.n does distribute Packages files, it does not
distribute binary packages. As you say, mentors.d.n isn't meant to be
an archive of installable binary packages.

-- 
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/caktje6h6hl69hsfhvx9vwdwpnfqvk45qag7bcq017k_ulcg...@mail.gmail.com

Aw: Re: DPA instead of PPA

[Steffen Möller]

Hello,

Von: "Steve McIntyre" 
An: debian-devel@lists.debian.org
Betreff: Re: DPA instead of PPA
In article <518b7cf6.3080...@debian.org> you write:
>>On 09/05/13 07:38, Raphael Hertzog wrote:
>>> bikeshed \o/
>>
>>You probably meant this to be a comment on the discussion rather than a
>>suggested name, but "until it gets uploaded to unstable, you can get
>>GNOME 3.8 from the GNOME Team bikeshed" actually sounds like a
>>reasonable sentence to write. :-)

>+1 for the "bikeshed" name. I think it's a *perfect* fit! :-)

A +1 also from my side for using "bikeshed" instead of [DP]PA
for the Debian PPAs, so they would become "Debian bikesheds".

Steffen


--
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/trinity-a063e78e-c6b2-4131-8bfa-7634363148bb-1368527437187@3capp-gmx-bs42

Re: jessie release goals

[Wouter Verhelst]

On 13-05-13 05:59, Mark Symonds wrote:
> Can we keep the distribution simple enough for nearly anyone to understand?  

No.

The goal of Debian is not to be "simple". While we should document
things as much as possible so that the interested can learn how things
work, in no case should we ever avoid doing the technically sound
because it is "difficult to understand".

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
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/51921056.9030...@debian.org

Re: /bin/sh (was Re: jessie release goals)

[Philip Hands]

Josselin Mouette  writes:

> Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit : 
>> On 05/13/2013 06:05 AM, Josselin Mouette wrote:
>> > Having a rock-stable PID 1 is nice and all, but it doesn’t help you if
>> > something important crashes. On a production server, if apache crashes
>> > and fails to reload properly because the scripts don’t get the ordering
>> > right, it doesn’t help you that init is still running fine.
>> 
>> That is quite not truth. Let's say you have a broken HDD, and that you
>> forgot to setup grub on the 2nd HDD or something else that will prevent
>> boot up. In one case, you're totally screwed, on the other, you just
>> restart Apache !
>
> Yes of course, because a different init system will magically make your
> other disk bootable.

Erm, no that's not what he was saying.

He was assuming that there must be a fault somewhere, so if it's not in
the init scripts, it must be in systemd -- this of course is nonsense,
but if you start from that assumption then it is better for apache to
fail to restart than it is for systemd to crash.

He missed the fact that you were contrasting one non-crashing init, that
is capable of restarting dead services, with another non-crashing
init setup that is not able to do so (without help).

Just thought I'd clear that up.

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


pgpu90seuXXzC.pgp
Description: PGP signature

Re: jessie to be a derivative?

[Wouter Verhelst]

On 11-05-13 13:31, Daniel Pocock wrote:
> There have been various discussions about how to change the release process
> 
> I'm not personally convinced that the process is fundamentally flawed.
> If there are still as many wheezy systems in 10 years as there are
> Windows XP machines in corporations today, then people won't remember
> the freeze in a negative way.
> 
> So here's my own contribution: why not make Jessie a derivative?

A "derivative" is a distribution made from debian _by another party_.
Since we'd still be the ones making it, it can't be a derivative, by
definition.

> In
> other words, a greater separation between the unstable world and the
> stable environment, with more ways for unstable packages to be
> cultivated before they emerge in testing and a real stable release.
> 
> Taking this further (and with appropriate safety warnings in the tools):
> 
> a) making packages from mentors installable, so that people can try them
> more quickly and upstreams can get involved at the bleeding edge

That's already possible, just put mentors.debian.net in your sources.list?

Having said that, the point of mentors.debian.net is that inexperienced
maintainers can upload their packages there, so that a debian developer
can look at them and give feedback -- not that people should use it as
an archive of installable packages.

> b) patches sent to the bug tracker should be automatically applied to a
> branch in git and should produce an installable, binary `branch package'
> accessible with apt-get for those who want to validate the patch.  The
> maintainer has last say and what is merged and when, but users can try
> more things.

Bad idea, for security reasons. Anyone can send patches to the BTS,
including patches that change code which is run at build time
(debian/rules or the upstream build system).

Even if you'd figure out a way to do this safely you'd still need a
*lot* of code before you can even start thinking about this:
- something to automatically turn source packages into git repositories
- something to fish patches from the BTS and apply them to said git
repositories
- some workflow to go from "commit on git repository" into "package is
built automatically"

> c) more distinction between core and non-core packages.  There is too
> much focus on packages that are tied to the Debian release and nothing
> can be changed.

That suggestion has been made before, but nobody has ever come up with a
good way to decide what to do when many packages that are not in the
"core" system aren't ready to release. Yes, we could throw them out; but
one of the strengths of Debian is exactly the fact that we have so many
packages, all with the same amount of QA. If we have to throw out many
non-"core" packages, we lose that advantage.

Yes, it has downsides. Deciding that those downsides make it not worth
the effort anymore feels like throwing out the kid with the bathwater to me.

> Here are some examples that challenge that thinking:
>
> - Ganglia: somebody deploying Ganglia to a mixed environment is much
> more concerned about having all their hosts (Debian, Redhat, Windows)
> running a common version of Ganglia than using the Ganglia version that
> corresponds to each host's OS version.

Yes, sometimes the version in Debian stable doesn't fit your needs
because of outside requirements. In that case, the best way forward is
to either install a backport or install from source.

There isn't much we can do about that; I'm sure you're not suggesting we
ensure all possible versions of all possible packages are installable on
a stable system.

> - VoIP/RTC: people want to use the version of the product that maximizes
> their ability to make and receive calls on the public Internet.  Lack of
> interoperability is fundamentally more disruptive than the regular
> updates of such packages.

That is pretty much true for just about any application that speaks a
network protocol; VoIP isn't very special in that regard.

As regards interoperability: I've been doing SIP to a third party which
is not using Debian for quite a few years now, and have never seen any
issues with that. What are you talking about?

> Backports currently goes some way to filling
> that gap, but maybe backports should be enabled on all stable installs
> by default, and maintainers can designate non-core packages that should
> follow backports unless the user chooses otherwise.

Backports do not enjoy the same level of support that Debian stable
does. Installing backports should only be done by informed users, who
know what the downsides are. I don't think we should make some packages
be installable from backports by default, either.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contac

Re: /bin/sh (was Re: jessie release goals)

[Thomas Goirand]

On 05/14/2013 04:51 PM, Josselin Mouette wrote:
> Yes of course, because a different init system will magically make your
> other disk bootable.

This is absolutely *NOT* what I said. Nothing in my message
compares this or that init system. I just replied that when you
have apache, it's easier to recover than with the PID1 crashing.
That's it, nothing more, nothing less.

> If you use tools like monit, you should be able to understand that such
> behavior should be standard for daemons shipped in Debian, and that
> sysadmins should not have to configure it themselves.

I do think that restarting crashed daemons is a nice feature,
yes. Though I believe OpenRC has this feature too (I have no
time to check for that fact right now, but I think I remember
reading it somewhere).

Also, I still believe that monit does its job well on the server
side, and that a generalized tool will not be adapted for it.
Only for servers, we should receive emails when there's
something that happens with a daemon, I don't want my
laptop to do that, even for Apache that I run there. So yes,
it should be configured by the admin!!!

> Such tools also have limitations that systemd and upstart do not have,
> such as having to use heuristics (sometimes convoluted ones) to detect
> when a service is ready.

I'm well aware that cgroups are important, yes.

Though no, I don't think systemd or upstart would be
good tools to do what monit does (unless they send
emails? I haven't seen such a feature in upstart and
systemd...)

> especially when you are unable to tell the difference between an init
> system and a bootloader.

What lead you to believe I can't make such difference? The
fact that I hacked a bit with OpenRC (and bloged about it),
and that I am mentoring a GSoC around it, should give
enough clue that I do know what an init system does.

BTW, I didn't intend to make you angry, or to give "lessons".
Please don't take it this way, I was only kidding you (eg: joking
*with* you, not trying to expose you in public).

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/519209bb.5080...@debian.org

Re: Temporary solution for changelog problem in binNMUs

[Raphael Hertzog]

Hi,

On Tue, 14 May 2013, Игорь Пашев wrote:
> 2013/5/14 Raphael Hertzog :
> > But ansgar's objection about the duplication of the changelog in multiple
> > .deb when it used to be shared via a symlink also makes sense. As does the
> > fact that there's currently no way to not install some control files.
> 
> What about creating symlinks in /var/lib/dpkg/info/ ?
> 
> /var/lib/dpkg/info/.changelog -> .changelog

That's irrelevant in the scheme where the changelog files are merged in
the dpkg database because you should not have to assume anything
about the file layout and you should use official interfaces
(dpkg-query --control-show) to access the content of the database.

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/20130514095326.gb17...@x230-buxy.home.ouaza.com

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

[Osamu Aoki]

Hi,

On Tue, May 14, 2013 at 10:43:59AM +0300, Antti-Juhani Kaijanaho wrote:
> On Mon, May 13, 2013 at 02:52:17PM +0200, Alberto Garcia wrote:
> > Also, is there any relation between this and the old 'debmake' package
> > or they just happen to have the same name?
> 
> My first thought upon seeing this ITP was, whyever for would anyone want to
> resurrect debmake.

Because this inherits some code from the original debmake indirectly via
dh-make and the original debmake is no more in archive.

This serves for the same purpose under new updated packaging service and
the name is available.  I made sure version is higher.  Please consider
this is a reimplementation of debmake.  (dh-make looks to me a
reimplementation of the original debmake.)

 debmake original (1996-2006,shell)  the oldest, 
  template file based
 dh-make  (1998-,perl)   co-existed with debmake original
  template file based
 debmake mine (2013-,python) why not co-existed with dh-make?
  synthesize file contents based on parameters

Since my intended changes were targeted to the command line UI design
and internal program structure, I did not ask dh-make maintainer to
change this way since this will break its current internal elegance.

Once I decided to reimplement, I chose easiest language to do the task
for me.

Regards,

Osamu

FYI: All the codes inherited from debmake original/dh-make in my new
debmake are optional scripts copied into debian/ directory only upon
user's extra action.


-- 
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/20130514094834.GA6551@goofy.localdomain

Re: Temporary solution for changelog problem in binNMUs

[Игорь Пашев]

2013/5/14 Raphael Hertzog :
> But ansgar's objection about the duplication of the changelog in multiple
> .deb when it used to be shared via a symlink also makes sense. As does the
> fact that there's currently no way to not install some control files.


What about creating symlinks in /var/lib/dpkg/info/ ?

/var/lib/dpkg/info/.changelog -> .changelog


-- 
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-q8ws96ugg_gv-f5nb9ihcq-70wxrtmsm4vq3fowyrpy...@mail.gmail.com

Re: Cannot log into people.debian.org

[Norbert Preining]

Thanks everyone,

On Di, 14 Mai 2013, Tollef Fog Heen wrote:
> Your email server certainly accepted a mail from db.debian.org this
> morning.  Look for r4E8r05U001275 in your log files.

Yes indeed, now after fixing the mail server entry, since our
university smtp has changed ... 

sorry for the noise.

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130514093929.gb9...@gamma.logic.tuwien.ac.at

Re: Cannot log into people.debian.org

[Tollef Fog Heen]

]] Norbert Preining 

(debian-devel is the wrong forum for this, you want
debian-admin@lists.d.o to reach the admins.)

> On Di, 14 Mai 2013, Paul Wise wrote:
> > https://db.debian.org/doc-mail.html
> 
> Thanks, hmm, I did also this, but never got an answer.

Your email server certainly accepted a mail from db.debian.org this
morning.  Look for r4E8r05U001275 in your log files.

If you want us to look any more into this, you might want to give us
more precise timestamps to look for any other mails that might have gone
missing.

> Am I supposed to get an answer to an email I sent there?

Yes.

-- 
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/87y5bhdiqw@qurzaw.varnish-software.com

Re: /bin/sh (was Re: jessie release goals)

[Thorsten Glaser]

Helmut Grohne  subdivi.de> writes:

> What are the benefits of using shells other than dash for /bin/sh? (as

Why does dash get special treatment, anyway? It was “suddenly“ in
Debian after having been used in Ubuntu, but… there never was an
evaluation of shells.

I still believe the codebase of mksh is better (modulo issues
introduced due to the active development), but I’m happy with
freedom to choose one’s own system shell…

(asides from the two things you mentioned)

… or provide an mksh-static binary package. Which could also
be used in initrd.

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.20130514t105738-...@post.gmane.org

Re: Apport for Debian

[Josselin Mouette]

Le mardi 14 mai 2013 à 00:40 +0200, Josselin Mouette a écrit : 
> >  - adjust the buildds to begin generating debug symbols packages
> >automatically - perhaps reusing pkgbinarymangler from Ubuntu, or perhaps
> >using it as a reference
> 
> Patches to debhelper already exist, to generate one udeb for each
> arch-dependent deb. No need to change anything in the buildd
> infrastructure.

Of course s/udeb/ddeb/.

-- 
 .''`.  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/1368521633.3585.1617.camel@pi0307572

Re: /bin/sh (was Re: jessie release goals)

[Josselin Mouette]

Le mardi 14 mai 2013 à 15:28 +0800, Thomas Goirand a écrit : 
> On 05/13/2013 06:05 AM, Josselin Mouette wrote:
> > Having a rock-stable PID 1 is nice and all, but it doesn’t help you if
> > something important crashes. On a production server, if apache crashes
> > and fails to reload properly because the scripts don’t get the ordering
> > right, it doesn’t help you that init is still running fine.
> 
> That is quite not truth. Let's say you have a broken HDD, and that you
> forgot to setup grub on the 2nd HDD or something else that will prevent
> boot up. In one case, you're totally screwed, on the other, you just
> restart Apache !

Yes of course, because a different init system will magically make your
other disk bootable.

> > It would help you to have an init implementation that can detect which 
> > components
> > can be initialized and at what time.
> 
> For that, we have stuff like monit, which have been working in production
> for years without issues, and which has some other very interesting
> features (like sending you a mail when the process changes PID).

If you use tools like monit, you should be able to understand that such
behavior should be standard for daemons shipped in Debian, and that
sysadmins should not have to configure it themselves.

Such tools also have limitations that systemd and upstart do not have,
such as having to use heuristics (sometimes convoluted ones) to detect
when a service is ready.

> You aren't much on the server things are you?

I might not have setup any datacenter in a tax haven, but next time, you
might want to look at who people are before giving them lessons,
especially when you are unable to tell the difference between an init
system and a bootloader.

kthxbye,
-- 
 .''`.  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/1368521486.3585.1616.camel@pi0307572

Re: Cannot log into people.debian.org

[Paul Wise]

On Tue, May 14, 2013 at 3:54 PM, Norbert Preining wrote:

> Thanks, hmm, I did also this, but never got an answer.
> Am I supposed to get an answer to an email I sent there?

I got replies to mails I sent there in the past (unrelated to ssh). I
would suggest checking that the OpenPGP key you signed the change with
is the one that keyring.d.o knows about and that the one keyring.d.o
knows about is not expired.

-- 
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/CAKTje6FjNkmM8OjNYmKT79VfoEknD9=ninezdo3dal8aovg...@mail.gmail.com

Re: parsable copyright format 1.0 (jessie release goals)

[Sune Vuorela]

On 2013-05-13, Robert Collins  wrote:
> The use cases are not at all fringe: every company I have worked at since
> open source became the dominant source of libraries has had some set of
> rules and policies around which licenses to use when, and good data about
> that makes decision making easier. As a trivial example GPL 2 only code is

But how many companies would actually base their decisions upon the
content of debian/copyright (which might be wrong or outdated) instead
of actually *checking* themselves?

/Sune


-- 
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/slrnkp3rm1.j8.nos...@sshway.ssh.pusling.com

Re: Temporary solution for changelog problem in binNMUs

[Raphael Hertzog]

Hi,

On Mon, 13 May 2013, Guillem Jover wrote:
> The binNMU issue entails two “sub-problems”. The first is the one
> introduced by different entries in binNMUs on multiple architectures.
> The other is the unmatched versions for possible out-of-step binNMU
> versions.
> 
> Personally I see very clearly what's the best/clean solution for the
> first. For the second, I'm happy to declare it a “non-problem”, and
> that it's what it is; if a package is M-A:same, then well, all arches
> need to have the same version (as my proposal to not require same
> version for M-A:same was shot down on the mega-thread in debian-devel);
> as I've not seen any solution that does not complicate or uglify things
> in very unnecessary ways, by way of revertig us back to having a
> sort-of-revision in a different field, or hacking the version comparison
> logic to special case binNMU-versions (ugh), etc.

I already suggested that we should compare the Source version instead
for the case of M-A: same packages. Do you consider that ugly as well?


For the changelog handling, I tend to agree with Guillem that moving it
to control.tar.gz makes sense (and copyright/NEWS.Debian probably too).

But ansgar's objection about the duplication of the changelog in multiple
.deb when it used to be shared via a symlink also makes sense. As does the
fact that there's currently no way to not install some control files.

He also mentionned that having to fork dpkg to parse all changelog files
is really not very good from a design point of view. It would be better if
we already had a stable libdpkg that we could use to avoid those forks.

It would also be nice to offer some transition periods with compatibility
symlinks but that's not something that can be cleanly implemented outside
of dpkg (unless duplicating the files is deemeed acceptable).

Clearly, if we want to get some broader buy-in for this change, we must
try to come up with solutions to those problems.


For the compatibility symlinks, we can create a new binary package in
the dpkg source that would set them up, keep them up-do-date, and drop
them on removal.

The other points are more difficult to solve but would be useful in their
own to avoid the problem of small packages considered too heavy due to
their meta-data. It might be worth to think a bit about it. What about
allowing us to define some package like this in debian/control:

Package: foo
Extends: bar
Description: 

This new "Extends" field would imply that all meta-data (including other
missing control fields) is shared with the bar package and at build-time
it transparently gets a supplementary "Depends: bar (= )" but
the .deb would not have any changelog/copyright.

(To further save meta-data space, we could have a way to factorize the
part of the description that describes the source package)

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/20130514075931.ge10...@x230-buxy.home.ouaza.com

Re: Switching default dpkg-deb compressor to xz

[Sune Vuorela]

On 2013-05-14, John D. Hendrickson and Sara Darnell  
wrote:
> Are you trying to cause problems with free software?

Quite the opposite. He is trying to ensure that we don't have to modify
all packages to get them xz compressed, but rather does it from a
central place.

/Sune


-- 
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/slrnkp3rfc.j8.nos...@sshway.ssh.pusling.com

Re: [Debian-med-packaging] Upcoming libgd2-{xpm, noxpm}-dev -> libgd2-dev transition

[Charles Plessy]

Le Mon, May 13, 2013 at 10:34:36PM +0200, Ondřej Surý a écrit :
> 
> 1. I have dropped the {xpm,noxpm} dichotomy and there's only
>libgd2-dev now.  There are transitional packages which are ment
>to help with the move to libgd2-dev, so you don't have to make
>any changes right now - the binNMUs should work.

Dear Ondřej,

let me repeat in public: you are my hero !  Unable to prepare a patch myself, I
had waited for that day since many release cycles !

Cheers,

-- 
Charles


-- 
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/20130514075455.ga7...@falafel.plessy.net

Re: Cannot log into people.debian.org

[Norbert Preining]

Hi Paul,

thanks for your answer.

On Di, 14 Mai 2013, Paul Wise wrote:
> https://db.debian.org/doc-mail.html

Thanks, hmm, I did also this, but never got an answer.
Am I supposed to get an answer to an email I sent there?

Norbert


PREINING, Norbert   http://www.preining.info
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094   fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094



-- 
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/20130514075434.ga2...@gamma.logic.tuwien.ac.at

Re: Bug#707601: ITP: debmake -- helper script to make the Debian source package

[Antti-Juhani Kaijanaho]

On Mon, May 13, 2013 at 02:52:17PM +0200, Alberto Garcia wrote:
> Also, is there any relation between this and the old 'debmake' package
> or they just happen to have the same name?

My first thought upon seeing this ITP was, whyever for would anyone want to
resurrect debmake.

Please choose another name.

-- 
Antti-Juhani Kaijanaho


-- 
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/20130514074357.ga10...@teralehti.kaijanaho.fi

Re: Temporary solution for changelog problem in binNMUs

[Helmut Grohne]

On Mon, May 13, 2013 at 03:16:57PM +0200, Guillem Jover wrote:
> The binNMU issue entails two ???sub-problems???. The first is the one
> introduced by different entries in binNMUs on multiple architectures.
> The other is the unmatched versions for possible out-of-step binNMU
> versions.

I acknowledge that I am coming late to the party. I dug into the
discussion referenced from your other mail, but had a hard time finding
specific arguments. This discussion appears to be a good candidate for
http://wiki.debian.org/Debate even though it is probably too late to
start that now.

> dpkg supports --control-show and --control-list (already in wheezy), which
> can be used for stuff like:
> 
>   $ dpkg-query --control-show dpkg changelog
> 
> for installed packages, for example. Or:
> 
>   $ dpkg-deb --info foo.deb changelog

Maybe someone can point me to previous discussion answering aspects of
the following questions?

1) Raphael Hertzog suggested[1] that metadata could be stored
   compressed. Is that implemented already? (As far as I can see it
   would be part of file_show, but isn't.) If not, that would cause
   an increase in installation size. I guess that a typical desktop
   system would grow by about 50MB.

   Note that the Emdebian crush policy requires copyright files to be
   compressed and changelogs to be absent.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=681289#40

2) Some users may want to save disk space by elevating dpkg.cfg
   path-exclude=/usr/share/doc/*/changelog*
   path-exclude=/usr/share/doc/*/copyright
   This saves about 50MB on a desktop system. Is there a feature to
   systematically drop meta data? Being in the ball park of less than a
   percent of the installation size I am not sure whether this is worth
   the effort.

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/20130514073045.ga10...@alf.mars

Re: /bin/sh (was Re: jessie release goals)

[Thomas Goirand]

On 05/13/2013 06:05 AM, Josselin Mouette wrote:
> Le dimanche 12 mai 2013 à 19:40 +0200, Helmut Grohne a écrit : 
>> With all due respect, this might be utter bullshit, but is at least
>> [citation needed]. I have yet to see a failing pid 1 (be that sysv,
>> upstart or systemd). Acquiring data on failure modes of any of those
>> systems appears like a difficult task and d-devel might not be the best
>> place to discuss that.
> Having a rock-stable PID 1 is nice and all, but it doesn’t help you if
> something important crashes. On a production server, if apache crashes
> and fails to reload properly because the scripts don’t get the ordering
> right, it doesn’t help you that init is still running fine.

That is quite not truth. Let's say you have a broken HDD, and that you
forgot to setup grub on the 2nd HDD or something else that will prevent
boot up. In one case, you're totally screwed, on the other, you just
restart Apache !

> It would help you to have an init implementation that can detect which 
> components
> can be initialized and at what time.

For that, we have stuff like monit, which have been working in production
for years without issues, and which has some other very interesting
features (like sending you a mail when the process changes PID).

You aren't much on the server things are you?

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/5191e7ab.80...@debian.org