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

[Marc Haber]

On Sun, 12 May 2013 10:40:53 +0800, Thomas Goirand 
wrote:
>On 05/12/2013 03:44 AM, Roger Leigh wrote:
>> We all saw where GNOME took use with their lack of choice: an
>> unusable trainwreck.  It's a disgrace that this shipped as the
>> default desktop for wheezy, it really is.
>
>Like for everything in Debian, this is bound to someone killing
>the concept of a default Desktop. It is indeed a shame that
>nobody worked on that.

What is planned to do so? I surely hope that we don't end up building
Kebian, Gebian and Xebian Images, which has always striked (stricken?)
me as an utter waste.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/e1ubqfe-0006za...@swivel.zugschlus.de

Re: parsable copyright format 1.0 (jessie release goals)

[Bart Martens]

On Sun, May 12, 2013 at 01:43:31PM +0800, Thomas Goirand wrote:
> Since it ever existed, I wrote my debian/copyright file using the
> new format. It's quite well established, and it isn't hard to do
> the switch. It is just a bit boring work though.
> 
> I do think it would be nice to be able to parse all of the
> archive to know what kind of license we're using. If we all work
> a bit on our own packages, it should be fine, and at some
> point, we should move forward. But does anyone think it is
> too much work? I would understand that point of view.
> 
> Thoughts anyone?

I would regret that the new debian/copyright format would become a jessie
release goal.  The cost/benefit ratio is, in my opinion, very low.  It costs
quite some human time to recode the upstream copyright and license information,
and I have not yet seen the benefit of more easy parsing by software.  The
licenses in the upstream source code are already in text, so they are already
in a format suitable for parsing by software.  In 2013 I don't see the need for
humans to recode text to be even more easily parseable by software.  Our human
time would be better spent on developing tools to extract the copyright and
license information from the upstream sources, in my opinion.  If we develop a
really smart tool, then most debian/copyright can be fully generated
automatically in a format designed to be well readable by humans.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130512063806.ga14...@master.debian.org

Bug#707917: ITP: libpackage-locator-perl -- module to find the distribution that provides a given package

[Oleg Gashev]

Package: wnpp
Severity: wishlist
Owner: Oleg Gashev 

* Package name: libpackage-locator-perl
  Version : 0.006
  Upstream Author : Jeffrey Ryan Thalhammer 
* URL : https://metacpan.org/release/Package-Locator/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : module to find the distribution that provides a given 
package

 Package::Locator attempts to answer the question: "Where can I find a
 distribution that will provide this package?" The answer is divined by
 searching the indexes for one or more CPAN-like repositories. If you also
 provide a specific version number, Package::Locator will attempt to find a
 distribution with that version of the package, or higher. You can also ask to
 find the latest version of a package across all the indexes.
 .
 Package::Locator only looks at the index files for each repository, and those
 indexes only contain information about the latest versions of the packages
 within that repository. So Package::Locator is not BackPAN magic -- you
 cannot use it to find precisely which distribution a particular package (or
 file) came from.


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

Re: parsable copyright format 1.0 (jessie release goals)

[Thomas Goirand]

On 05/06/2013 08:49 PM, Andreas Beckmann wrote:
> Hi,
>
> now might be the right time to start a discussion about release goals
> for jessie. Here are some points that come into my mind right now (and
> some were already discussed very recently):
>
> * multiarch compatible binNMUs
> * discarding maintainer uploaded binary packages [!arch:all]
> * discarding maintainer uploaded binary packages [incl. arch:all]
> * extending binNMUs to allow rebuilding arch:all packages (so it's no
> longer a "binary only" but a sourceful no-change rebuild - the classic
> binNMU should stay of course)
>
>
> Andreas
>
> ... looking forward to have PPAs in the future :-)
Since it ever existed, I wrote my debian/copyright file using the
new format. It's quite well established, and it isn't hard to do
the switch. It is just a bit boring work though.

I do think it would be nice to be able to parse all of the
archive to know what kind of license we're using. If we all work
a bit on our own packages, it should be fine, and at some
point, we should move forward. But does anyone think it is
too much work? I would understand that point of view.

Thoughts anyone?

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/518f2c03.1060...@debian.org

Re: Source build-dependencies

[Johannes Schauer]

Hi,

Quoting Paul Wise (2013-05-12 04:03:54)
> Another one I would like is to be able to depend or build-dep on
> foo:build-depends or foo [Build-Depends] (or by extension foo:depends), which
> would mean we could get rid of the ugly hack that is mk-build-deps.

Should a dependency of a source package src:A on src:foo not mean that src:A
also automatically build depends on the build dependencies of src:foo?

It would be weird if the transitive dependencies are taken into account for
build dependencies on binary packages but not for build dependencies on source
packages.

cheers, josch


--
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/20130512051516.32278.72480@hoothoot

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

[Thomas Goirand]

On 05/12/2013 03:44 AM, Roger Leigh wrote:
> We all saw where GNOME took use with their lack of choice: an
> unusable trainwreck.  It's a disgrace that this shipped as the
> default desktop for wheezy, it really is.

Like for everything in Debian, this is bound to someone killing
the concept of a default Desktop. It is indeed a shame that
nobody worked on that. Let's hope someone finds the time to
fix that for Jessie.

> The fact that GNOME is going to *require* systemd is really
> just yet another reflection upon the stupidity of tight-coupling
> and what happens when you start trying to control others.  What
> are they, Microsoft or something?  It's a bad attitude I never
> thought I'd see in the free software world--up until now we took
> great pains to be interoperable with each others rather than
> 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.

I 100% agree with the above. Let's hope we can demonstrate
that OpenRC is a viable choice. Working on it is so much better
than just fighting on -devel.

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/518f0135.5060...@debian.org

Re: Source build-dependencies

[Paul Wise]

On Sun, May 12, 2013 at 1:03 AM, Wookey wrote:

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

It isn't a possibility yet, it could be if the apt maintainers implemented it.

I suggest: depending or build-depending on foo:source would make apt
place source packages at /usr/src/debian/.

Another one I would like is to be able to depend or build-dep on
foo:build-depends or foo [Build-Depends] (or by extension
foo:depends), which would mean we could get rid of the ugly hack that
is mk-build-deps.

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

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

[Wookey]

+++ Steve Langasek [2013-05-11 09:33 -0700]:
> On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote:

> > While that might be of some interest the real goal of the change was
> > to be able to have more than *2* packages provide /bin/sh.
> 
> > Currently, due to the totaly screwed up way this is done, only dash or
> > bash can be /bin/sh.
> 
> This is not a sensible goal.  Choice of /bin/sh should *not* be the goal,
> the goal should be to get a good, fast, minimal, policy-compliant /bin/sh
> for *everyone*.
> 
> See also: Linux is not about choice.
> 
> All this added complexity to provide users a "choice" about something that
> doesn't matter undermines the robustness of the base system.  Please stop.
> 
> Yes, the diversion hack should be superseded by a single, static symlink
> belonging to the dash package, and the rest of this pointless complexity
> should be jettisoned.

I'm very keen to lose the diversion hack. It causes pain for
cross-debootstrapping, especially on embedded images. 

Someone would need to make a case for replacing dash as /bin/sh. What
do we get for enabling /bin/mksh fill that role too, for example? If
it really is just better then why not just swap from dash to mksh and
everyone can benefit? 

Swappable system shells is a nice idea, but Steve is right that it's a
critical thing that really does need to work so there has to be some
real gain from futzing with it. If it can be done cleanly then great.
If not then lets see if we can't just pick one (almost) everyone can
live with. 

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/20130512014039.gk2...@stoneboat.aleph1.co.uk

Re: wheezy postmortem re rc bugfixing

[Vincent Lefevre]

On 2013-05-10 14:57:46 +0200, Piotr Ożarowski wrote:
> [Charles Plessy, 2013-05-09]
> >   For a large number of packages if not all, we should allow the
> > package maintainers to manually migrate their packages to Testing during the
> > Freeze, within boundaries set on debian-devel-announce by the release team.
> 
> +1

+1

The boundaries shouldn't be very strict, or there could be discussions
between the maintainers and the release team in particular cases where
there could be a big benefit for the user. Note also that not all new
upstream versions are equal (e.g. some are bug-fix releases), not
packages are equal (e.g. some have regression tests...), and not all
upstreams are equal.

> or a soft freeze (as described above) a month (or two) before hard freeze

I doubt that it would change much, unless the hard freeze is time
limited.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130511235456.ge26...@ioooi.vinc17.net

Bug#707887: ITP: unorm.js -- Common JS Unicode Normalizer

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: unorm.js
  Version : 1.0.3
  Upstream Author : Bjarke Walling 
* URL : https://github.com/walling/unorm
* License : Expat
  Programming Lang: Javascript
  Description : Common JS Unicode Normalizer

 Normalization is a process that involves transforming characters and sequences
 of characters into a formally-defined underlying representation. This process
 is most important when text needs to be compared for sorting and searching,
 but it is also used when storing text to ensure that the text is stored in a
 consistent representation.
 .
 This package provides a Common JS Unicode Normalizer.


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

Re: epoch fix?

[Vincent Lefevre]

On 2013-05-09 00:25:06 +0200, Jakub Wilk wrote:
> Let me try to explain where the difference lies. Consider the following
> sequences of uploads:
> 
> foo_4
> foo_5
> foo_1:4
> foo_1:6
> 
> bar_4
> bar_5
> bar_5really4
> bar_6
> 
> Two kind of "bugs" in (build-)dependencies on these packages could happen:
> 
> 1)
> 
> "foo (>= 5)" doesn't guarantee you that you get upstream version 5 or later.
> You need to use "foo (>= 1:5)".

To avoid this bug, shouldn't the epoch be ignored in comparisons for
dependencies (unless this is made explicit)?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
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/20130511230334.gd26...@ioooi.vinc17.net

Bug#707883: ITP: node-log4js -- Conversion of the log4js framework to work with Node.js.

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: node-log4js
  Version : 0.6.4
  Upstream Author : Gareth Jones 
* URL : https://github.com/nomiddlename/log4js-node
* License : Apache-2.0
  Programming Lang: Javascript
  Description : Conversion of the log4js framework to work with Node.js.

 Logging support for Node.js based on the log4js Javascript (browser/client)
 framework.
 .
 Supported features:
 .
- coloured console logging
- replacement of node's console.log functions (optional)
- file appender, with log rolling based on file size
- SMTP appender
- GELF appender
- hook.io appender
- multiprocess appender (useful when you've got worker processes)
- a logger for connect/express servers
- configurable log message layout/patterns
- different log levels for different log categories (make some parts
  of your app log as DEBUG, others only ERRORS, etc.)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130511224739.8606.88275.report...@minobo.das-netzwerkteam.de

Re: /bin/sh

[Nikolaus Rath]

Thorsten Glaser  writes:
> Steve Langasek  debian.org> writes:
>
>> This is not a sensible goal.  Choice of /bin/sh should *not* be the goal,
>> the goal should be to get a good, fast, minimal, policy-compliant /bin/sh
>> for *everyone*.
>
> Sure. We just disagree which one that is.
>
>> See also: Linux is not about choice.
>
> Debian is not just about Linux.
>
> Oh, sorry, I forgot, you work for Canonical (which totally explains some
> of your writings in the other eMail too, which I’m not going to comment
> on). Of course, for *buntu people it’s not about choice.
>
> Now please take that attitude and go back to *buntu, where you *can*
> force one “desktop environmen”, one system shell, etc. on your users.
[...]


Please reconsider your tone. Debian-devel is not the right place to vent
your personal animosity towards Canonical/Ubuntu/Steve, wherever it may
come from.


Best,

   -Nikolaus

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

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


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8761yp884k@vostro.rath.org

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

[Svante Signell]

On Sat, 2013-05-11 at 22:08 +0200, Josselin Mouette wrote:
> Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit : 
> > I can't agree with having no choice with regard to init.  We aren't
> > all using GNOME, and Debian is used in an extremely diverse set of
> > fields for a multitude of different purposes.  No one init is
> > appropriate for all of these applications.  systemd fails on safety
> > grounds alone for a good number of uses.  That much complexity is
> > an unacceptable risk for PID1 failure.
> 
> 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.

So the old discussion is back, nice: let's spend some 100+ post on this
again. Maybe the DPL and the tech committe could make their voices
heard. Debian can definitely survive without Canonical (and RedHat).
Debian is about Free Software (as well as free speech, users choice,
user freedom, etc by the Social Contract) 



-- 
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/1368306524.4595.64.camel@PackardBell-PC

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

[darkestkhan]

On Sat, May 11, 2013 at 8:08 PM, Josselin Mouette  wrote:
> Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit :
>> We all saw where GNOME took use with their lack of choice: an
>> unusable trainwreck.
>
> This is your opinion. There are other users who happen to value features
> over configurability. Given that iOS and Android sell by millions every
> week, maybe there are quite a lot of them.
>

I dare you to answer a simple question - if I don't choose iOS, Android
or Blackberry, what other OS comes preinstalled with modern
smartphone?

--
darkestkhan
--
Feel free to CC me.
jid: darkestk...@gmail.com
May The Source be with You.


--
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/CACRpbMhz_1CugK=vihfcedvw08kek2w+qsszxkyoxsyspf6...@mail.gmail.com

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

[Thorsten Glaser]

>Debian is about Free Software.

Actually, about Free Users, isn't it?

http://mako.cc/copyrighteous/freedom-for-users-not-for-software

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/kmmadn$u3u$1...@ger.gmane.org

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

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

2013/5/12 Josselin Mouette :
> GNOME depends on a working glibc, too. Does it dictate the C library?


Yes. Portability still makes sense. Portability is a part of the word
"Free" in "Free Software".

Debian is about Free Software.


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

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

[Josselin Mouette]

Le samedi 11 mai 2013 à 20:44 +0100, Roger Leigh a écrit : 
> I can't agree with having no choice with regard to init.  We aren't
> all using GNOME, and Debian is used in an extremely diverse set of
> fields for a multitude of different purposes.  No one init is
> appropriate for all of these applications.  systemd fails on safety
> grounds alone for a good number of uses.  That much complexity is
> an unacceptable risk for PID1 failure.

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.

> We all saw where GNOME took use with their lack of choice: an
> unusable trainwreck.

This is your opinion. There are other users who happen to value features
over configurability. Given that iOS and Android sell by millions every
week, maybe there are quite a lot of them.

>   It's a disgrace that this shipped as the
> default desktop for wheezy, it really is.  Quite how that
> happened I have no idea.  I absolutely don't want to see a
> repeat of that horror with the basic operation of our system.

We have only had one init system since the first Debian release. Why do
we suddenly need more than one? What does make choice important now,
that was not relevant before?

> The fact that GNOME is going to *require* systemd is really
> just yet another reflection upon the stupidity of tight-coupling
> and what happens when you start trying to control others.  

Please go implement a decent user tracking system with the same APIs
(which are not tightened to systemd at all), and you’ll see GNOME has no
dependency on systemd at all.

Oh wait… this is already being worked on. By Ubuntu.

But regardless, we don’t need more than one init system. We just need a
good one. This is completely unrelated to GNOME. The bunch of idiots who
try to pin it down on GNOME, Fedora or the Illuminati look like just
another group of conspiracy theories lunatics.

> What
> are they, Microsoft or something?  It's a bad attitude I never
> thought I'd see in the free software world--up until now we took
> great pains to be interoperable with each others rather than
> 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.  

The complete farce is having project members saying that a desktop
environment is “dictating the init system”.

GNOME depends on a working glibc, too. Does it dictate the C library? It
only runs on X. Does it dictate the windowing system?

Such an amount of stubborn, willing ignorance dismisses anything else
you might have to say on this topic.

> Debian is a lot bigger
> than GNOME, and if we have to, I'd vote for junking it entirely.

Yeah sure, whatever floats your boat. Apparently it floats a lot on hate
and not much on rational reasoning.

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/1368302901.12318.36.camel@tomoyo

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

[Roger Leigh]

On Sat, May 11, 2013 at 08:52:29PM +0200, Josselin Mouette wrote:
> Being able to choose between two entirely different desktop
> environments, with different user experiences, is a good thing.
> Being able to choose between two /bin/sh shells or two /sbin/init
> implementations is not.

The shell I can agree with.  It is required to provide a POSIX shell,
so as long as it is fully functional and performs well, just
picking one and sticking with it is absolutely fine.

I can't agree with having no choice with regard to init.  We aren't
all using GNOME, and Debian is used in an extremely diverse set of
fields for a multitude of different purposes.  No one init is
appropriate for all of these applications.  systemd fails on safety
grounds alone for a good number of uses.  That much complexity is
an unacceptable risk for PID1 failure.

We all saw where GNOME took use with their lack of choice: an
unusable trainwreck.  It's a disgrace that this shipped as the
default desktop for wheezy, it really is.  Quite how that
happened I have no idea.  I absolutely don't want to see a
repeat of that horror with the basic operation of our system.
The fact that GNOME is going to *require* systemd is really
just yet another reflection upon the stupidity of tight-coupling
and what happens when you start trying to control others.  What
are they, Microsoft or something?  It's a bad attitude I never
thought I'd see in the free software world--up until now we took
great pains to be interoperable with each others rather than
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.


-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130511194430.gb21...@codelibre.net

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

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

2013/5/11 Josselin Mouette :
> We have had two releases with kfreebsd, which failed to
> provide anything usable. Debian is only about Linux, and has always
> been.


I have some news about it ;-)


-- 
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-Q8wC9UYa=3g-5vuphm1reen+qs0rournmxwzeuupmdu...@mail.gmail.com

Re: Debian development and release: always releasable (essay)

[Mehdi Dogguy]

Le 2013-05-10 17:24, Russ Allbery a écrit :


But by and large they only do this on a large scale during the freeze, 
at
which point, in a way, it's too late.  We've already built a huge 
backlog
of work, and everyone is anxious to release.  I think we should be 
doing
this continuously during the release and much more aggressively than 
we've

been willing to do in the past.



The idea was to do it even during the development cycle. It was mainly 
an

issue of manpower that we did it only during the freeze, I think.

I'm fairly confident that we will be able to do it during the 
development

cycle this time.

--
Mehdi


--
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/a9216453b89dd7358222efbc2734d...@dogguy.org

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

[Josselin Mouette]

Le samedi 11 mai 2013 à 18:53 +, Thorsten Glaser a écrit : 
> >I believe you are being needlessly rude right now.  Please keep in mind
> 
> Probably… but I think Canonical employees and *buntu developers have
> a conflict of interest, which *does* have “interesting” effects, such
> as wheezy releasing with different gcc versions being default across
> architectures. (I like Doko, and he’s very welcoming and helpful, but
> I can’t help but notice this… “interesting” effect.)

Ben mentioned hotplug stuff, but I believe that the latter if you do not
going to replace uses of Fedora problem caused by Knoppix destroy the
package manually instead of glibc slow.  There’s dependencies are a
desktop but I’d be happy were it as long as well; us Germans and he’s
apparently did liked to consider is the nvram of well, Yes, this
interesting effects, such as they apparently did was booting WiXP. 
Probably have more of my laptop’s apparently did was about choice and
that not buy the only Open Source ecosystem offered than you can force
one desktop but as for the conflict of my choice and anything that
being a reflection. 

Merging mentioned hotplug stuff.  They think it and upstream; or it
doesn’t.  And I would like you do: it was doesn’t. 

//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/1368300485.12318.23.camel@tomoyo

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

[Niels Thykier]

On 2013-05-11 20:53, Thorsten Glaser wrote:
> [...]
>> that:
>>
>> """
>> The Debian Project welcomes and encourages participation by everyone. """[1]
>>
>> That includes Canonical and *buntu.
> 
> … but that doesn’t give either preferential treatment.
> 

I never said that and I never said I took Steve's side; I have not.
Personally, I could almost not care any less what shell provides sh as
long as it works and it is compatible with the current one.

> That line includes me too, [...]
> 
> //mirabilos
> 

Yes.  If I see someone being obviously rude to you on a public mailing
list, I will do my best to step up against that as well.

If somebody did that to you, I am sorry that I did not notice it - it
was not my intention to single you out.


~Niels



-- 
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/518e99d1.2070...@thykier.net

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

[Thorsten Glaser]

Niels Thykier dixit:

>I believe you are being needlessly rude right now.  Please keep in mind

Probably… but I think Canonical employees and *buntu developers have
a conflict of interest, which *does* have “interesting” effects, such
as wheezy releasing with different gcc versions being default across
architectures. (I like Doko, and he’s very welcoming and helpful, but
I can’t help but notice this… “interesting” effect.)

GNOME packagers probably have a conflict of interest too, considering
that GNOME wants to push their own “OS” with everything integrated, no
choices, and even theming forbidden (because they believe that there’s
no way to use a desktop but theirs).

Yes, it was probably *too* rude for the mailing list… take it as being
a Devil’s Advocate. Steve, I would like to apologise for the rudeness
and anything that might be taken personal (as opposed to the conflict
of interest I believe happens here, and the other stuff).

>that:
>
>"""
>The Debian Project welcomes and encourages participation by everyone. """[1]
>
>That includes Canonical and *buntu.

… but that doesn’t give either preferential treatment.

That line includes me too, even though that’s apparently liked to be
forgotten.

Of course, no preferential treatment, either.

//mirabilos
-- 
Sorry,  I’m annoyed today and you came by as an Arch user. These are the
perfect victims for any crime against humanity, like  systemd,  feminism
or social democracy.
-- Christoph Lohmann on d...@suckless.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/pine.bsm.4.64l.1305111848330.13...@herc.mirbsd.org

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

[Josselin Mouette]

Le samedi 11 mai 2013 à 18:26 +, Thorsten Glaser a écrit : 
> > See also: Linux is not about choice.
> 
> Debian is not just about Linux.

Yes it is. We have had two releases with kfreebsd, which failed to
provide anything usable. Debian is only about Linux, and has always
been.

> In Debian, Developers are also users, and it can only be the
> UNIVERSAL operating system when there is choice.

Let me say that from someone who cannot be suspected of collusion with
Canonical: Debian is not about choice.

Being able to choose between two entirely different desktop
environments, with different user experiences, is a good thing.
Being able to choose between two /bin/sh shells or two /sbin/init
implementations is not.

> Why dash? It’s clearly inferiour, buggy and not taken care of well.
> 
> Oh, I forgot, you work for Canonical, who apparently invested into it.

WTF? Seriously you need to bring your crusade elsewhere.

> Users in Debian are NOT just desktop end users. They are also developers,
> both Debian and upstream. They are also systems engineers. And lots more.
> Including once-deployed embedded devices in remote locations requiring
> “node” to refer to the hamradio tool (remember this discussion?).

I want a unique /bin/sh and systemd as sole init system. Not just for my
desktops, I want them for my servers too. Especially for my servers. I
don’t do embedded devices, but I’m pretty sure I’d prefer simplicity and
ease of administration for them too.

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/1368298349.12318.19.camel@tomoyo

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

[Steve Langasek]

On Sat, May 11, 2013 at 08:17:51PM +0200, Jonas Smedegaard wrote:
> Quoting Steve Langasek (2013-05-11 18:33:03)
> > On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote:
> > > [...] the real goal of the change was to be able to have more than 
> > > *2* packages provide /bin/sh.

> > > Currently, due to the totaly screwed up way this is done, only dash 
> > > or bash can be /bin/sh.

> > This is not a sensible goal.  Choice of /bin/sh should *not* be the 
> > goal, the goal should be to get a good, fast, minimal, 
> > policy-compliant /bin/sh for *everyone*.

> > See also: Linux is not about choice.

> > All this added complexity to provide users a "choice" about something 
> > that doesn't matter undermines the robustness of the base system.  
> > Please stop.

> Choice ridiculous to some is relevant to others.

I look forward to the addition of /usr/share/cdbs/1/rules/mangle-bin-sh.mk
in your next release.

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

[Niels Thykier]

On 2013-05-11 20:26, Thorsten Glaser wrote:
> Oh, sorry, I forgot, you work for Canonical (which totally explains some
> of your writings in the other eMail too, which I’m not going to comment
> on). Of course, for *buntu people it’s not about choice.
> 
> Now please take that attitude and go back to *buntu, where you *can*
> force one “desktop environmen”, one system shell, etc. on your users.

Hi,

I believe you are being needlessly rude right now.  Please keep in mind
that:

"""
The Debian Project welcomes and encourages participation by everyone. """[1]

That includes Canonical and *buntu.

~Niels

[1] http://www.debian.org/intro/diversity



-- 
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/518e8e6c.1050...@thykier.net

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

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

2013/5/11 Aron Xu :
> An easy example is that, on Solaris, there is a something called boot
> environment (BE), which is essentially snapshots of the combination of
> /usr and /boot, users can switch between different BEs easily without
> affecting any user data. Without /usr merge, doing such work could be
> much more complicated because user data and system data is mixed in
> the file system's hierarchy, it's hard to make sure switching between
> different snapshots won't change user data.


Aron, merging / and /usr is not related to the ability of creating
BEs. The beadm utility
will create a snapshot of / and all underlying filesystems. Even
/var/tmp (if it is separated fs)
should be a part of BE (not shared between BEs), because of FHS..


-- 
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-q8xe3jwmqyw_9b1yeqqurcbbw5cggspbmqopaak+vb1...@mail.gmail.com

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

[Thorsten Glaser]

Steve Langasek  debian.org> writes:

> This is not a sensible goal.  Choice of /bin/sh should *not* be the goal,
> the goal should be to get a good, fast, minimal, policy-compliant /bin/sh
> for *everyone*.

Sure. We just disagree which one that is.

> See also: Linux is not about choice.

Debian is not just about Linux.

Oh, sorry, I forgot, you work for Canonical (which totally explains some
of your writings in the other eMail too, which I’m not going to comment
on). Of course, for *buntu people it’s not about choice.

Now please take that attitude and go back to *buntu, where you *can*
force one “desktop environmen”, one system shell, etc. on your users.

In Debian, Developers are also users, and it can only be the
UNIVERSAL operating system when there is choice.

> Yes, the diversion hack should be superseded by a single, static symlink
> belonging to the dash package

Why dash? It’s clearly inferiour, buggy and not taken care of well.

Oh, I forgot, you work for Canonical, who apparently invested into it.

Well, newsflash: there are others who don’t. (And I’ve made it a
personal crusade to replace uses of ash as shell, so why not dash
either. Yes, this means I’m totally biased as well. I admit it
though, and this is why I fight for the freedom for the users to
choose their system shell. I don’t even care about the default,
I’d be happy were it mksh or mksh-static of course, but I don’t.
And I’ve successfully run both Debian and Kubuntu with mksh as
system shell.)

> No, it is NOT about choice.  It is about providing a high quality, free
> operating system to our users.  This ridiculous complexity in /bin/sh

But your users may have a more broad horizon than you, as Canonical
employee, can imagine. They may want to have more of the Open Source
ecosystem offered than you want to give them, especially to keep the
saying “if it’s not in Debian it doesn’t exist” true.

Users in Debian are NOT just desktop end users. They are also developers,
both Debian and upstream. They are also systems engineers. And lots more.
Including once-deployed embedded devices in remote locations requiring
“node” to refer to the hamradio tool (remember this discussion?).

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.20130511t202028-...@post.gmane.org

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

[Jonas Smedegaard]

Quoting Steve Langasek (2013-05-11 18:33:03)
> On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote:
> > [...] the real goal of the change was to be able to have more than 
> > *2* packages provide /bin/sh.
> 
> > Currently, due to the totaly screwed up way this is done, only dash 
> > or bash can be /bin/sh.
> 
> This is not a sensible goal.  Choice of /bin/sh should *not* be the 
> goal, the goal should be to get a good, fast, minimal, 
> policy-compliant /bin/sh for *everyone*.
> 
> See also: Linux is not about choice.
> 
> All this added complexity to provide users a "choice" about something 
> that doesn't matter undermines the robustness of the base system.  
> Please stop.

Choice ridiculous to some is relevant to others.


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

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

[Aron Xu]

On Wed, May 8, 2013 at 12:52 AM, Marco d'Itri  wrote:
> On May 07, Jonathan Dowland  wrote:
>
>> > If we do this, I'd prefer to make /usr a symlink to / on new installs
>> I've always thought that myself, but it seems most folks who are pro
>> merge tend to propose going the other way. I've never understood why.
> I was trying to not start a new discussion about this, but since you
> asked: moving /usr in / does not solve any significant problem, while
> moving /{bin,sbin,lib} to /usr allows some very interesting new things
> like being able to have a truly shared stateless /usr containing the
> whole OS, which can be used for things like appliances which can then be
> upgraded and rolled back with a single rename(2).
>
> The Fedora page explains some:
> http://fedoraproject.org/wiki/Features/UsrMove
>

I support doing /usr move, for it can help on making better use of
snapshot function of BTRFS/ZFS.

An easy example is that, on Solaris, there is a something called boot
environment (BE), which is essentially snapshots of the combination of
/usr and /boot, users can switch between different BEs easily without
affecting any user data. Without /usr merge, doing such work could be
much more complicated because user data and system data is mixed in
the file system's hierarchy, it's hard to make sure switching between
different snapshots won't change user data. While if such thing is
done properly, then user won't be bothered about messing up the system
on upgrades or experiments anymore. They can switch among different
working environments easily, without dealing with the odds caused by
multi-boot.

There is apt-btrfs-snapshot around for some time (hasn't been in
Debian, yet), and it can be relied upon in production systems only
when the separation of system data and user data is done.



-- 
Regards,
Aron Xu


-- 
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/CAMr=8w6enqh2uphthhezupggq0oj_hftm32ufunipbcpwki...@mail.gmail.com

Re: Debian development and release: always releasable (essay)

[Antonio Terceiro]

On Sat, May 11, 2013 at 06:32:21PM +0800, Thomas Goirand wrote:
> Hi Lars,
> 
> I do like a lot the idea of running things like piuparts and such at
> upload time.
> If you have time to work this out with the FTP masters, that would be a very
> good idea IMO, and I warmly welcome you to do that. However...
> 
> On 05/10/2013 03:49 AM, Lars Wirzenius wrote:
> > Tests for running reference installation might include the following:
> >
> > * Basic networking setup works: System responds to ping from the outside.
> > * Mail server responds appropriate on the SMTP, submission, IMAPS, and POPS
> >   ports.
> > * LAMP server responds on the HTTP and HTTPS ports.
> > * A desktop system that automatically logs in a test user has the right
> >   processes running, and can start some common applications.
> > * In each case, it's possible to log in remotely with ssh and run
> >   "sudo apt-get install hello".
> 
> These wont help. They were not the RC bugs we had during the release
> cycle.  I believe for example, that Apache, MySQL, and PHP were quite
> well maintained and didn't suffer from RC bugs that stayed for a long
> time. I didn't see bugs for Exim, Postfix, ssh or Bind either. We had
> problems with Dovecot though, but they were well identified, and
> having tests against it wouldn't have help in any ways.
> 
> If you want to find out which tests would help, you would have to conduct
> a better analysis of the problems we had during the freeze, IMO.

You can't assume that just because something works today, it will work
forever. Having such tests in place will help to automatically catch
regressions if they arise. If they don't, fine, but you never know.

While I agree with you that there are a lot more we can test, I don't
think it's useless to include tests for stuff we know is working. Even
"trivial" tests have their value with so many moving parts.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

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

[Steve Langasek]

On Sat, May 11, 2013 at 04:06:38PM +, Thorsten Glaser wrote:
> And I absolutely do not buy the argument that Debian does not
> have enough manpower to keep the / vs. /usr separation (for many
> use cases) working.

  https://lists.debian.org/debian-devel/2012/08/msg00858.html

When you've demonstrated that these issues can be adequately resolved in
Debian without introducing more bugs in core library packages, then we can
have a conversation about whether it makes sense to mount /usr from the
initramfs.  Until then, this discussion is a waste of time.

> Ben mentioned hotplug stuff. Can that not be deferred to until
> after /usr is mounted?

Feel free to bring us a working proof of concept - not a handwavy assertion
that this can be made to work.

And using udev, please, not eudev.  It's clear that eudev doesn't have the
necessary critical mass to maintain feature parity with udev.  Debian should
not tether itself to an implementation that's going to hinder us, when
you're already swimming against the current by trying to enforce this
requirement.

-- 
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: Merging / and /usr (was: jessie release goals)

[Josselin Mouette]

Le vendredi 10 mai 2013 à 14:46 +0100, Roger Leigh a écrit : 
> > There are various benefits, discussed before at length (here,
> > elsewhere). Suggesting/summarizing this as "satisfying Lennart" is a bit
> > telling.
> 
> It's still entirely accurate though.  This is ultimately being driven by
> uncooperative upstreams unwilling to maintain their stuff properly, and
> this really means udev, and this is part of systemd for better or worse.
> Well, worse.

This is just a story you like to tell yourself. Give you an enemy for a
good crusade for the “right” (way of developing a UNIX system) instead
of working yourself on making things better.

> Ensuring /usr is mounted at boot time is one thing.  It provides
> certain very useful guarantees which we currently don't have.  Merging
> / and /usr is another matter entirely, and it's just one of several
> increasingly bizarre and technically questionable decisions coming
> from the Fedora camp of late.

Once /usr is mounted at boot time, what does it change?
Once / and /usr are treated the same way, why should you care about
whether a given binary lives under / or /usr? What is the impact?

> How are those udev replacement projects coming along?  Something else
> to think about for jessie.

Why should we care? We need one udev implementation that works
correctly, not seven that don’t.

-- 
 .''`.  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/1368293674.12318.14.camel@tomoyo

Re: Source build-dependencies

[Wookey]

+++ 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
-- 
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/20130511170329.gg2...@stoneboat.aleph1.co.uk

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

[Steve Langasek]

On Sat, May 11, 2013 at 11:22:10AM +0200, Goswin von Brederlow wrote:
> On Tue, May 07, 2013 at 07:46:43PM +0200, Marc Haber wrote:
> > On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote:
> > >On May 07, Thorsten Glaser  wrote:
> > >> My stated goal here is, indeed, to be able to run at least some useful
> > >> configurations of a Debian installation without *both* bash and dash
> > >> installed.
> > >What is the point?

> > A smaller footprint of the intalled system? This may be interesting
> > for embedded things.

> While that might be of some interest the real goal of the change was
> to be able to have more than *2* packages provide /bin/sh.

> Currently, due to the totaly screwed up way this is done, only dash or
> bash can be /bin/sh.

This is not a sensible goal.  Choice of /bin/sh should *not* be the goal,
the goal should be to get a good, fast, minimal, policy-compliant /bin/sh
for *everyone*.

See also: Linux is not about choice.

All this added complexity to provide users a "choice" about something that
doesn't matter undermines the robustness of the base system.  Please stop.

> Double that for multiarch on amd64/i386 because there is bash:i386 and
> bash:amd64 that both work just fine as /bin/sh. Trying to install a
> foreign bash or dash fails horribly though with the current diversion
> hack.

Yes, the diversion hack should be superseded by a single, static symlink
belonging to the dash package, and the rest of this pointless complexity
should be jettisoned.

> The current implementation of /bin/sh handling simply restricts the
> freedom to choose a /bin/sh. Not because only 2 shells are suitable
> and maintainable but simply because of the way the /bin/sh link is
> managed with diversions. Debian is about freedom and choice, right?

No, it is NOT about choice.  It is about providing a high quality, free
operating system to our users.  This ridiculous complexity in /bin/sh
handling undermines that quality.

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

[Thorsten Glaser]

Goswin von Brederlow  web.de> writes:

> Add 2 more if dash and mksh build static flavours too. posh, ksh93,

mksh already builds a static flavour ;-) It’s just not an mksh-static
separate binary package because waldi, who kindly sponsored my first
several uploads, taught me that binary packages are a costly resource.

I intended /bin/mksh-static to be used by initramfs-tools in place
of the ash or busybox-sh they use (maybe pick it up automatically
once mksh is installed, like it does with busybox if it’s installed).
No idea whether approaching them would not be shot down either… plus
it’d add a few dozen KiB (more on hurd/kfreebsd due to lack of non-
eglibc C libraries there) to the already huge initrd… but you’d get
a modern, robust shell, tab completion, the works.

Nowadays I mostly run with /bin/sh@ -> mksh-static (started on the
m68k systems where there’s noticeable benefit, doing it everywhere).


Sven Joachim dixit:

> On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote:

> > Proposed solution:

> I'm afraid your plan as outlined is not going to work.

I’d be delighted if you can explain which part(s) aren’t, and
even more if you have a (general) idea how to fix it? We tried
several scenarios and did a lot of brainstorming, but in the
end it turns out there’s few people who fully understand even
one of the subsystems involved…

Please keep at least mksh@p.d.o in the loop, eMail wise (can’t
talk about the others, but I guess Cc’ing the package address
of the shells involved would be sensible).

Thanks,
//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.20130511t182813-...@post.gmane.org

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

[Thorsten Glaser]

Marco d'Itri  Linux.IT> writes:

> People use live CDs for rescue all the time, do you have some data which 
> show that this is actually a problem in real life and not an imaginary 

I’ve had Knoppix destroy the nvram of my laptop’s graphics chipset.
(I sent it in, and all they apparently did was booting WiXP once,
whose driver seems to have reset that; the problem caused by Knoppix
was OS-independent: happened under DOS and even in the BIOS Setup
screens. I do not own WiXP.)

That being said – is people like you and software like udev and
systemd really the reason for this?

Just use eudev and do not use systemd. Or fork it. Debian has a
history of patching packages to death away from what upstream,
or other distros, do.

And I absolutely do not buy the argument that Debian does not
have enough manpower to keep the / vs. /usr separation (for many
use cases) working.

Ben mentioned hotplug stuff. Can that not be deferred to until
after /usr is mounted? (If need be, patch eudev so that it looks
at whether a triggered’s dependencies are available and defer it
if not.)

Another thing to consider is: my m68k boxen run udev now too, but
they boot very finely without it (and devtmpfs.mount=1, with some
code in /etc/rc.local to create /dev/std{in,out,err} symlinks).
How about supporting / vs. /usr separation if either an initrd is
used or it’s a server/embedded setup, but require an initrd or /usr
to be on the same filesystem as / for a desktop?

Ah well, us Germans and convoluted sentences. Let me make a matrix.

 \  desktop/laptop   server/embedded
/ and /usr on same fs   supportedsupported
separate, initrd used   supportedsupported
separate, no initrd not supportedsupported, will patch

Right now, to me, from the discussion, it looks like the lower-right
corner is the only one doing actual work, and the only one in question,
and that the two upper lines are “a given” even by the upstreams in
question. Merging / and /usr, one way or the other, has never been
mentioned as a requirement as long as they’re on the same filesystem
or initrd mounts them early, it’s merely been proposed on the grounds
of “Fedora does it and they think it’s convenient”.

Fedora/RedHat being entangled with some upstreams also never was a
problem for Debian to do it differently in the past, either – just
look at eglibc when RHEL people were keeping development of glibc slow.


(Putting several responses and thoughts into *one* mail because some
“fellow” DDs seem to take offence at reading several eMails within
a few days from me. And I hope, dear unnamed co-DD, that the things
I proposed here are constructive enough. I also hope Debian will
continue to support freedom of choice and appreciate people looking
at things from a different PoV, as for the latter if only to have
a reflection.)

bye,
//mirabilos (still not subscribed, reading via GMane)


-- 
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.20130511t175722-...@post.gmane.org

Re: Depends: libfoo:foreign ???

[Thorsten Glaser]

Goswin von Brederlow  web.de> writes:

> I would say that a foreign dependency on a library is never right. If

Nope. I’m waiting for support for that for pcc.
(And that pcc CVS HEAD gets stable/usable again, but that’s
a totally different issue.)

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.20130511t173458-...@post.gmane.org

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

[Sven Joachim]

On 2013-05-11 11:22 +0200, Goswin von Brederlow wrote:

> While that might be of some interest the real goal of the change was
> to be able to have more than *2* packages provide /bin/sh.
>
> Currently, due to the totaly screwed up way this is done, only dash or
> bash can be /bin/sh.

I think that dash could probably stop diverting /bin/sh, now that bash
no longer ships it (as of version 4.2-1).  That would make it possible
to locally divert /bin/sh for those who want it (#538822, #540512).

> Double that for multiarch on amd64/i386 because there is bash:i386 and
> bash:amd64 that both work just fine as /bin/sh. Trying to install a
> foreign bash or dash fails horribly though with the current diversion
> hack.

Huh? No it doesn't, dpkg handles this just fine (apt doesn't because it
does not support crossgrades, but that is another story).  Make sure you
have dpkg >= 1.16.2, though.

> Proposed solution:
>
> - New virtual package system-shell with something essential
>   depending on it (base-files?)

Would probably need pre-depends so that system-shell cannot be removed
temporarily (similar situation as with awk).

> - bash, dash pre-depend on system-shell for the transition
>
> - new packages system-shell-
>   Provides, Replaces, Conflicts: system-shell
>   contains /bin/sh -> /bin/ symlink
>
> None of system-shell-* would be essential but through the dependency
> of something essential at least one would always be installed
> (pseudo-essential). One of them (system-shell-dash) should have a
> higher priority than the rest to be singled out as the default and
> the essential package would depend system-shell-dash | system-shell.
>
> Choosing /bin/sh is then simply done by installing the right package
> and dpkg does the change atomically.

Only if the packages declare Conflicts/Replaces on every real provider
of system-shell, and with apt you lose outright because it insists on
removing the conflicting package(s) first.

> No messing around in
> pre/postinst/rm scripts or race conditions where the link might
> disapear for a while. No artificial limit on how many system-shell-*
> packages there could be. 

I'm afraid your plan as outlined is not going to work.

Cheers,
   Sven


-- 
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/8738ttk00m@turtle.gmx.de

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Scott Kitterman]

Christoph Egger  wrote:

>Hi!
>
>Barry Warsaw  writes:
>> For the 13.04 release, Ubuntu made a change to its procedure whereby
>> source-only uploads to the development release (e.g. raring) actually
>go to
>> e.g. raring-proposed first.  The builds are attempted and only if
>they
>> succeed, pass their autopkgtests, *and* don't make the archive less
>> installable than before the new upload, are the packages copied over
>to the
>> release, e.g. raring.
>
>s/raring/testing s/raring-proposed/unstable and the whole thing sounds
>familar. Packages don't go into testing if they show regressions in
>buildability or decrease installablility in the archive. Now if we add
>whatever autopkgtests does it's eaxctly what we have, no?

Close. Because there is no aging requirement it moves much more quickly and as 
a result, there's much less risk of multiple transitions getting entangled and 
delayed.

Ubuntu explicitly defines the $ RELEASE-proposed pocket as 'not meant for 
humans'. It's only for building/automatic testing. 

A nice side effect of this moving faster is that the Ubuntu release team 
doesn't pre-coordinate transitions.

It's very close to what Debian has, but that small difference has a large 
impact. 

Scott K


-- 
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/99af1ae2-f1a3-48bb-a911-81c227aba...@email.android.com

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Scott Kitterman]

Joachim Breitner  wrote:

>Hi,
>
>Am Freitag, den 10.05.2013, 16:05 -0400 schrieb Barry Warsaw:
>> For the 13.04 release, Ubuntu made a change to its procedure whereby
>> source-only uploads to the development release (e.g. raring) actually
>go to
>> e.g. raring-proposed first.  The builds are attempted and only if
>they
>> succeed, pass their autopkgtests, *and* don't make the archive less
>> installable than before the new upload, are the packages copied over
>to the
>> release, e.g. raring.
>
>that sounds like very good QA.
>
>What if I upload two (or 200) packages that need to be copied to the
>target suite together, as each package individually will decrease
>installation count. Will that require manual intervention or does the
>infrastructure detect hat automatically? Are you using britney for
>that,
>or a custom tool?

It's britney with no aging requirement.  Sometimes you have to force a group of 
packages together. It's rare, but it does happen. 

Scott K


-- 
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/930ffda1-d95e-4a0e-90a2-84d116031...@email.android.com

Bug#707823: ITP: libunicode-utf8-perl -- encoding and decoding of UTF-8 encoding form

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: libunicode-utf8-perl
  Version : 0.59
  Upstream Author : Christian Hansen C
* URL : http://search.cpan.org/dist/Unicode-UTF8/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : encoding and decoding of UTF-8 encoding form

 Unicode::UTF8 provides functions to encode and decode UTF-8 encoding
 form as specified by Unicode and ISO/IEC 10646:2011.
 .
 Performs between 600% and 1200% faster than Encode.


-- 
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/20130511143125.32328.19872.report...@auryn.jones.dk

Re: Bug#707740: general: fails with video Hi10p

[Uoti Urpala]

Josselin Mouette wrote:
> Hi10p is a useless hack that makes videos unreadable with hardware
> acceleration. I wouldn’t recommend using it in the general case. The

The "useless hack" part is false. 10-bit H264 is a clear improvement in
video compression for some types of videos. Existing hardware video
accelerators[1] lack support for decoding it, but that does not make it
useless.

[1] "Accelerators" is a somewhat misleading term, as typically
multithreaded software decoding on modern AMD64 CPUs is faster.



-- 
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/1368279115.1926.50.camel@glyph.nonexistent.invalid

jessie to be a derivative?

[Daniel Pocock]

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

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.

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

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


-- 
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/518e2c16.30...@pocock.com.au

Re: Debian development and release: always releasable (essay)

[Tollef Fog Heen]

]] Johannes Schauer 

> Maybe the puppet question can just be solved by introducing an openstack task?

puppet isn't important because it's used by/part of openstack (which I
don't think it is?)  It's important because it's a tool lots of
sysadmins use to automate their infrastructures.  Also, it's generally a
bigger problem if something goes away than if it was never shipped.
Going away means leaving users hanging.  Not ever having something just
means, well, we didn't have it and those who wanted it had to install it
from elsewhere.

-- 
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/87vc6p23fc@xoog.err.no

Bug#707788: ITP: librdf-trinex-serializer-mockturtlesoup-perl -- RDF/Turtle serializer pleasant for humans to look at

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: librdf-trinex-serializer-mockturtlesoup-perl
  Version : 0.001
  Upstream Author : Toby Inkster 
* URL : 
https://metacpan.org/release/RDF-TrineX-Serializer-MockTurtleSoup
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : RDF/Turtle serializer pleasant for humans to look at

 Resource Description Framework (RDF) is a standard model for data
 interchange on the Web.
 .
 RDF::Trine provides an RDF framework with an emphasis on extensibility,
 API stability, and the presence of a test suite.
 .
 RDF::TrineX::Serializer::MockTurtleSoup provides an RDF::Trine
 serializer like RDF::Trine::Serializer::Turtle but real pretty.
 .
 And slower.
 .
 And probably breaks with some complex graphs.


-- 
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/20130511100936.25784.76906.report...@auryn.jones.dk

Re: Debian development and release: always releasable (essay)

[Thomas Goirand]

Hi Lars,

I do like a lot the idea of running things like piuparts and such at
upload time.
If you have time to work this out with the FTP masters, that would be a very
good idea IMO, and I warmly welcome you to do that. However...

On 05/10/2013 03:49 AM, Lars Wirzenius wrote:
> Tests for running reference installation might include the following:
>
> * Basic networking setup works: System responds to ping from the outside.
> * Mail server responds appropriate on the SMTP, submission, IMAPS, and POPS
>   ports.
> * LAMP server responds on the HTTP and HTTPS ports.
> * A desktop system that automatically logs in a test user has the right
>   processes running, and can start some common applications.
> * In each case, it's possible to log in remotely with ssh and run
>   "sudo apt-get install hello".

These wont help. They were not the RC bugs we had during the release cycle.
I believe for example, that Apache, MySQL, and PHP were quite well
maintained
and didn't suffer from RC bugs that stayed for a long time. I didn't see
bugs
for Exim, Postfix, ssh or Bind either. We had problems with Dovecot though,
but they were well identified, and having tests against it wouldn't have
help
in any ways.

If you want to find out which tests would help, you would have to conduct
a better analysis of the problems we had during the freeze, IMO.

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/518e1e35.1070...@debian.org

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Joachim Breitner]

Hi,

Am Samstag, den 11.05.2013, 12:00 +0200 schrieb Christoph Egger:
> Barry Warsaw  writes:
> > For the 13.04 release, Ubuntu made a change to its procedure whereby
> > source-only uploads to the development release (e.g. raring) actually go to
> > e.g. raring-proposed first.  The builds are attempted and only if they
> > succeed, pass their autopkgtests, *and* don't make the archive less
> > installable than before the new upload, are the packages copied over to the
> > release, e.g. raring.
> 
> s/raring/testing s/raring-proposed/unstable and the whole thing sounds
> familar. Packages don't go into testing if they show regressions in
> buildability or decrease installablility in the archive. Now if we add
> whatever autopkgtests does it's eaxctly what we have, no?

Close, but not quite. From what I understood the packages undergo these
checks before entering the development release (i.e. unstable), and that
without a 10 days delay. This means that unstable would be in a
constantly better shape, the release team would probably have an easier
time keeping testing close to unstable (as things are installable in
unstable) and the individual developer would pay more attention to these
things (as he does not get his packages in otherwise).

(Ah, just noticed that you did not reply to me but to Barry. Still, I
hope my answers apply.)

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Bug#707786: ITP: python-zxcvbn -- Password strength estimator

[Bas Westerbaan]

Package: wnpp
Severity: wishlist
Owner: Bas Westerbaan 


* Package name: python-zxcvbn
  Version : 1.0
  Upstream Author : Ryan Pearl 
* URL : https://www.github.com/rpearl/python-zxcvbn
* License : Expat
  Programming Lang: Python
  Description : Password strength estimator

Python port of the zxcvbn password strength estimator.  zxcvbn tries to
give sound password advice through pattern matching and conservative
entropy calculations.


-- 
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/20130511095747.18353.78714.report...@vinnana.karpenoktem.nl

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Christoph Egger]

Hi!

Barry Warsaw  writes:
> For the 13.04 release, Ubuntu made a change to its procedure whereby
> source-only uploads to the development release (e.g. raring) actually go to
> e.g. raring-proposed first.  The builds are attempted and only if they
> succeed, pass their autopkgtests, *and* don't make the archive less
> installable than before the new upload, are the packages copied over to the
> release, e.g. raring.

s/raring/testing s/raring-proposed/unstable and the whole thing sounds
familar. Packages don't go into testing if they show regressions in
buildability or decrease installablility in the archive. Now if we add
whatever autopkgtests does it's eaxctly what we have, no?

Christop[h

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer


-- 
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/87wqr525ux@hepworth.siccegge.de

Re: [Popcon-developers] encrypted popcon submissions

[Goswin von Brederlow]

On Sat, May 11, 2013 at 11:43:25AM +0200, Bill Allombert wrote:
> On Fri, May 10, 2013 at 10:44:25PM +0200, Peter Palfrader wrote:
> > On Fri, 10 May 2013, Bill Allombert wrote:
> > 
> > > I am considering activating encryption of popularity-contest submissions
> > > using public key cryptography to protect popcon submission while in 
> > > transit.
> > 
> > Do you think the benefits outweight the drawback that the admin no
> > longer can be certain we don't send anything we shouldn't?
> 
> I do not think it makes much difference. The report is sent by a simple shell 
> script
> which you can easily audit. Even if you use a network scanner, you can check 
> that
> what is sent is the encrypted file since you have a copy of it.
> 
> And in any case, there will be an option do deactivate encryption if you so 
> chose.
> 
> > > - The popcon.debian.org server will know the matching private key and use 
> > > it to
> > > decrypt report before storing them.
> > 
> > > The drawback is the computing cost on the server. Currently we are 
> > > processing
> > > about 25000 report each days, which would require about 2 hours of 'real' 
> > > CPU time to decrypt, which is too much for popov.debian.org. On the other 
> > > hand
> > > this is easily parallelisable. 
> > 
> > Why do you think this is too much for popov to handle? 
> 
> I did some benchmark. Currently popov CPU has about 20% of a real CPU.
> Currently processing the popcon data takes between 6h30 and 8h30.
> At this rate decrypting the report would take an additional 7h.
> 
> > And if it really is, adding vCPUs is easy.
> 
> Excellent.
> 
> > Why is transport encryption (ala https) not sufficient?
> 
> I do not see why https would be faster than gpg for the same level of 
> security. 
> 
> There are some issues with https:
> 1) https does not handle email submissions. gpg is transport agnostic.
> 2) https requires more client-side support than what perl-base provide.
> On the other hand, apt already depends on gpg, so we can assume that gpg is
> available.
> 3) managing https certificate is harder. A gpg public key can easily be 
> included
> in the popularity-contest package

On the other hand it can not as easily be changed when the private key
is compromised. The window between the hack being detected and data
being secure again would be far greater with a gpg key in the package.

> 4) https allows the web server to see the decrypted content. gpg encryption
> only allow the popcon user to read it.
> 5) https require CPU time when the reports is received. At time where a lot of
> reports are received at the same time, this can overload the CPU. By contrast,
> gpg provides much flexibility in CPU time allocations.
> 
> Cheers,

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/20130511095535.GF3334@frosties

Re: [Popcon-developers] encrypted popcon submissions

[Bill Allombert]

On Fri, May 10, 2013 at 09:53:25PM +0100, Ian Jackson wrote:
> Bill Allombert writes ("encrypted popcon submissions"):
> > The drawback is the computing cost on the server. Currently we are
> > processing about 25000 report each days, which would require about 2
> > hours of 'real' CPU time to decrypt, which is too much for
> > popov.debian.org. On the other hand this is easily parallelisable.
> 
> Is that using RSA ?  If so then perhaps EC El Gamal would perform
> better, if it's available in the relevant versions of gnupg.

My understanding is that the released version of gpg does not yet
include support for EC El Gamal.

But in any case, RSA/El Gamal are only used to encrypt the AES key used
to encrypt the file. the subsequent AES decryption should take the majority of
the running time.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
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/20130511095137.GD31106@yellowpig

Bug#707781: ITP: xf86-input-xwiimote -- X.Org Wii remote input driver

[Dmitry Kurochkin]

Package: wnpp
Severity: wishlist
Owner: Dmitry Kurochkin 

* Package name: xf86-input-xwiimote
  Version : 0.3
  Upstream Author : David Herrmann 
* URL : https://github.com/dvdhrm/xf86-input-xwiimote
* License : MIT
  Programming Lang: C
  Description : X.Org Wii remote input driver

This package includes an X.Org input driver for Nintendo Wii Remotes
based on XWiimote.


-- 
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/20130511094533.23195.33804.reportbug@think5

Re: [Popcon-developers] encrypted popcon submissions

[Bill Allombert]

On Fri, May 10, 2013 at 10:44:25PM +0200, Peter Palfrader wrote:
> On Fri, 10 May 2013, Bill Allombert wrote:
> 
> > I am considering activating encryption of popularity-contest submissions
> > using public key cryptography to protect popcon submission while in transit.
> 
> Do you think the benefits outweight the drawback that the admin no
> longer can be certain we don't send anything we shouldn't?

I do not think it makes much difference. The report is sent by a simple shell 
script
which you can easily audit. Even if you use a network scanner, you can check 
that
what is sent is the encrypted file since you have a copy of it.

And in any case, there will be an option do deactivate encryption if you so 
chose.

> > - The popcon.debian.org server will know the matching private key and use 
> > it to
> > decrypt report before storing them.
> 
> > The drawback is the computing cost on the server. Currently we are 
> > processing
> > about 25000 report each days, which would require about 2 hours of 'real' 
> > CPU time to decrypt, which is too much for popov.debian.org. On the other 
> > hand
> > this is easily parallelisable. 
> 
> Why do you think this is too much for popov to handle? 

I did some benchmark. Currently popov CPU has about 20% of a real CPU.
Currently processing the popcon data takes between 6h30 and 8h30.
At this rate decrypting the report would take an additional 7h.

> And if it really is, adding vCPUs is easy.

Excellent.

> Why is transport encryption (ala https) not sufficient?

I do not see why https would be faster than gpg for the same level of security. 

There are some issues with https:
1) https does not handle email submissions. gpg is transport agnostic.
2) https requires more client-side support than what perl-base provide.
On the other hand, apt already depends on gpg, so we can assume that gpg is
available.
3) managing https certificate is harder. A gpg public key can easily be included
in the popularity-contest package
4) https allows the web server to see the decrypted content. gpg encryption
only allow the popcon user to read it.
5) https require CPU time when the reports is received. At time where a lot of
reports are received at the same time, this can overload the CPU. By contrast,
gpg provides much flexibility in CPU time allocations.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


-- 
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/20130511094325.GC31106@yellowpig

Re: jessie release goals

[Goswin von Brederlow]

On Wed, May 08, 2013 at 11:57:58AM +0200, Stephen Kitt wrote:
> Let me explain where I'm coming from... With MinGW-w64, we have a set of
> compilers, headers and libraries which allow building software targeting
> native Windows, without Cygwin or much in the way of wrappers at all. This is
> definitely non-POSIX and not much like Debian; but I imagine similar problems
> crop up when targeting a different libc. Despite the differences, and thanks
> to a lot of work by upstream developers, a lot of the libraries in Debian
> build fine when targeting Windows, and most of the time the only change
> required is to pass the correct target triplet to the configure script. This
> makes it sorely tempting to add mingw (i386, amd64 and arm as Dmitrijs
> mentions) as partial architectures in Debian and use all the existing
> packaging as much as possible to provide at least -dev packages and DLLs for
> as many libraries as possible; this would greatly simplify the lives of
> people working on building stuff for Windows (currently they basically have
> to produce Makefiles which build all their dependencies - and then you end up
> with things like the Firefox source packages which include all their
> dependencies on all platforms).
> 
> The big issue which crops up then isn't so much the directory structure's
> impact on the build process, but rather its impact on the packaging process.
> If the target directory structure depends on whether we're building for a
> full Debian architecture or for a partial architecture or just some
> cross-compiler target, that means ad-hoc changes in the packaging for the
> various cases and that much more friction (see for example
> http://bugs.debian.org/671437 - although in zlib's case packaging changes are
> necessary to build for Windows).

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.

> I know (2) is well-tested, and it reduces duplication drastically. Does this
> outweigh being able to use multiarch and Debian's existing packaging work as
> a generic means of supporting cross-compilers?
> 
> > > we could support cross-compiling to anything with the same
> > > structure - I'm thinking MinGW-w64 here of course, but I imagine it would
> > > apply to other targets too, some of which are supported in Debian already
> > > using the /usr/triplet/include directories.
> > 
> > The header-layout issue is independent of the need for dpkg-architecture to
> > know about an arch to use multiarch mechanisms for cross-building to it. But
> > that's very easy to do (An easy way to add arches in a local config
> > file is something that's been mentioned before). Having mingw as an
> > arch is a good idea if it isn't already.
> > 
> > And you can still use a sysroot and non-multiarch ways of filling it
> > if you prefer. I haven't really experimented with multiarch and
> > sysroot at the same time but SFAICS it should work. 
> 
> Indeed, but when I first saw multiarch I couldn't help but think this was a
> really nice way to support cross-compilation too; at the time I was told it
> was too early to consider that, it would appear now is the right time before
> things become set in stone.
> 
> Unless I'm mistaken, if we go down the (2) route we could still have a mingw
> (partial) architecture, but every single package we'd want to build on it
> would need to handle it specifically...
> 
> Regards,
> 
> Stephen

I think you are mistaken. mingw should handle just like any other
architecture. Only difference being that you can't build natively, you
have to cross-build. But let us know if you tried it.

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/20130511093928.GE3334@frosties

Re: Debian development and release: always releasable (essay)

[Johannes Schauer]

Hi,

Quoting Paul Wise (2013-05-11 10:40:18)
> Lucas created a script that displays a list of "important" packages, puppet
> isn't on that either:
> 
> http://udd.debian.org/cgi-bin/important_packages.cgi

Not surprising as the algorithm (from what can be read in the comments)
executes what we call build_closure algorithm in this paper [1].  During
bootstrapping we execute the same algorithm with the only difference that we do
not pull in source packages that only contribute arch:all packages (for obvious
reasons).

While we also recognized this selection of packages as important from a
bootstrapping point of view (as it contains the largest strongly connected
component in the dependency graph) it is not surprising that puppet is not in
it. Instead, puppet is just a leaf package in the dependency graph.

So while the set of source packages found by the build_closure algorithm should
certainly be part of the "important" packages, this also shows an observation
that we made during dependency graph analysis: The syntax of the dependency
graph is not enough to make semantic conclusions of the contained packages.

So instead, the important packages should be the union of:

 - the result of the build_closure algorithm
 - the transitive dependencies of all tasks and all blends
 - ???

Maybe the puppet question can just be solved by introducing an openstack task?
Adding new tasks could help codify the set of features that are deemed
"important".

cheers, josch

[1] http://mancoosi.org/~abate/bootstrapping-software-distributions


--
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/20130511093758.32278.6057@hoothoot

Re: jessie release goals

[Goswin von Brederlow]

On Tue, May 07, 2013 at 10:31:10PM +0100, Wookey wrote:
> +++ Stephen Kitt [2013-05-07 14:38 +0200]:
> > Hi Wookey,
> > 
> > On Tue, 7 May 2013 03:04:50 +0100, Wookey  wrote:
> > > (just a decision to leave arch-independent headers in /usr/include and
> > > move arch-dependent headers to /usr/include/triplet).
> > 
> > Doesn't this limit us to cross-compiling only across Debian architectures? 
> > If
> > we go for a full /usr/include/triplet split (in the same way as for
> > libraries)
> 
> Libraries are always different for different architectures. Only a
> fairly small subset of headers is, so you could say we are doing
> exactly the same thing for both libaries and headers: 
> arch-indep stuff goes in /usr/{lib,include}
> arch-dependent stuff goes in /usr/{lib,include}/triplet
> 
> But your point is taken.
> 
> The tradeoff is:
> 1) (Move _all_ headers to /usr/include/triplet)
>  * Much duplication of installed headers
>  * Only one system include dir, which fits current build-system 
>  expectations
>  
> 2) (Move only arch-dependent headers to /usr/include/triplet)
>  * No duplication of headers
>  * Two system include dirs, which may confuse/break some builds
>  
> In both cases things which manage to explictly look only in '/usr/include'
>  may fail to build, but much more likely for 2. I have no idea how
> much a problem this would be in practice.
> '1)', above has been reasonably well tested in Ubuntu raring, and telling the
> compiler to look in both dirs for system headers by default works
> well, but there could be issues when given paths to subdirs.

Note: #include  will implicitly look in /usr/include/triplet
and /usr/include. You have to do something strange to fail to build.
E.g. "grep SOMETHING $dir/foo.h" in configure instead of test
compiling like macros usualy do.

So this is less of an issue than it sounds. It realy needs to be
explicitly broken to fail.

> > we could support cross-compiling to anything with the same
> > structure - I'm thinking MinGW-w64 here of course, but I imagine it would
> > apply to other targets too, some of which are supported in Debian already
> > using the /usr/triplet/include directories.
> 
> The above issue is independent of the need for  dpkg-architecture to know
> about an arch to use multiarch mechanism for cross-building to it. But
> that's very easy to do (An easy way to add arches in a local config
> file is something that's been mentioned before). Having mingw as an
> arch is a good idea if it isn't already.
> 
> And you can still use a sysroot and non-multiarch ways of filling it
> if you prefer. I haven't really experimented with mulitarch and
> sysroot at the same time but SFAIK it should work. 
> 
> Wookey

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/20130511092922.GD3334@frosties

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

[Goswin von Brederlow]

On Tue, May 07, 2013 at 07:46:43PM +0200, Marc Haber wrote:
> On Tue, 7 May 2013 16:46:46 +0200, m...@linux.it (Marco d'Itri) wrote:
> >On May 07, Thorsten Glaser  wrote:
> >> My stated goal here is, indeed, to be able to run at least some useful
> >> configurations of a Debian installation without *both* bash and dash
> >> installed.
> >What is the point?
> 
> A smaller footprint of the intalled system? This may be interesting
> for embedded things.
> 
> Greetings
> Marc

While that might be of some interest the real goal of the change was
to be able to have more than *2* packages provide /bin/sh.

Currently, due to the totaly screwed up way this is done, only dash or
bash can be /bin/sh.

But we already have 4 working candidates for /bin/sh:
bash, bash-static, dash, mksh

Add 2 more if dash and mksh build static flavours too. posh, ksh93,
(yash or zsh) could also become candidates with a little work it seems.

Double that for multiarch on amd64/i386 because there is bash:i386 and
bash:amd64 that both work just fine as /bin/sh. Trying to install a
foreign bash or dash fails horribly though with the current diversion
hack.

Double that for kfreebsd with multiarch. kfreebsd-amd64 currently has
16 /bin/sh candidates.

The current implementation of /bin/sh handling simply restricts the
freedom to choose a /bin/sh. Not because only 2 shells are suitable
and maintainable but simply because of the way the /bin/sh link is
managed with diversions. Debian is about freedom and choice, right?


Proposed solution:

- New virtual package system-shell with something essential
  depending on it (base-files?)

- bash, dash pre-depend on system-shell for the transition

- new packages system-shell-
  Provides, Replaces, Conflicts: system-shell
  contains /bin/sh -> /bin/ symlink

None of system-shell-* would be essential but through the dependency
of something essential at least one would always be installed
(pseudo-essential). One of them (system-shell-dash) should have a
higher priority than the rest to be singled out as the default and
the essential package would depend system-shell-dash | system-shell.

Choosing /bin/sh is then simply done by installing the right package
and dpkg does the change atomically. No messing around in
pre/postinst/rm scripts or race conditions where the link might
disapear for a while. No artificial limit on how many system-shell-*
packages there could be. 

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/20130511092210.GC3334@frosties

Bug#707777: ITP: node-cookie -- Basic cookie parser and serializer module for Node.js

[Jérémy Lal]

Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-cookie
  Version : 0.1.0
  Upstream Author : Roman Shtylman 
* URL : https://github.com/shtylman/node-cookie
* License : Expat
  Programming Lang: JavaScript
  Description : Basic cookie parser and serializer module for Node.js

node-cookie just provides a way to read and write RFC6265 HTTP cookie
headers.
.
Node.js is an event-based server-side javascript engine.


-- 
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/20130511090919.14332.37267.reportbug@imac.chaumes

Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes

[Joachim Breitner]

Hi,

Am Freitag, den 10.05.2013, 16:05 -0400 schrieb Barry Warsaw:
> For the 13.04 release, Ubuntu made a change to its procedure whereby
> source-only uploads to the development release (e.g. raring) actually go to
> e.g. raring-proposed first.  The builds are attempted and only if they
> succeed, pass their autopkgtests, *and* don't make the archive less
> installable than before the new upload, are the packages copied over to the
> release, e.g. raring.

that sounds like very good QA.

What if I upload two (or 200) packages that need to be copied to the
target suite together, as each package individually will decrease
installation count. Will that require manual intervention or does the
infrastructure detect hat automatically? Are you using britney for that,
or a custom tool?

Once we have PPA (DPA?) I’d really like to have that for „my“ staging
PPAs.

Greetings,
Joachim
-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



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

Re: jessie release goals

[Goswin von Brederlow]

On Tue, May 07, 2013 at 09:34:09PM +0100, Noel David Torres Taño wrote:
> On Lunes, 6 de mayo de 2013 13:49:57 Andreas Beckmann wrote:
> > Hi,
> > 
> > now might be the right time to start a discussion about release goals
> > for jessie. Here are some points that come into my mind right now (and
> > some were already discussed very recently):
> > 
> > * multiarch compatible binNMUs
> > * discarding maintainer uploaded binary packages [!arch:all]
> > * discarding maintainer uploaded binary packages [incl. arch:all]
> > * extending binNMUs to allow rebuilding arch:all packages (so it's no
> > longer a "binary only" but a sourceful no-change rebuild - the classic
> > binNMU should stay of course)
> > 
> > 
> > Andreas
> > 
> > ... looking forward to have PPAs in the future :-)
> 
> I would like to see multiarch fully working (it is not, see #705834)

What does that have to do with multiarch. The actual problem there
seems to be:

update-alternatives: error: alternative path /usr/bin/wine32-unstable doesn't 
exist
dpkg: error processing wine-bin-unstable (--install):
 subprocess installed post-installation script returned error exit status 2

That is just a single packaging bug. Nothing worth a release goal.

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/20130511084450.GB3334@frosties

Re: Debian development and release: always releasable (essay)

[Andrei POPESCU]

On Jo, 09 mai 13, 20:49:51, Lars Wirzenius wrote:
> 
> The fundamental change is to start keeping our "testing" branch
> as close to releasable as possible, at all times. 

It's probably obvious for debian-devel readers, but I think it is worth 
saying it out loud: this would also give us CUT/rolling/etc. for free.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Debian development and release: always releasable (essay)

[Paul Wise]

On Sat, May 11, 2013 at 4:28 PM, Tollef Fog Heen wrote:

> (Where can I look up what tasks or blends use a given package?)

For the blends part, we plan to add that to the PTS (#703402). I
should extend that to tasks too I think.

Until then, use your favourite rdepends viewer, the aptitude curses
interface is mine.

> I don't know if, say, puppet is in a task or a blend, but it's one of
> the packages where I'm fairly sure that lots of people (DSA included)
> would be less than impressed if it was missing from a stable release.
> I'd also not be surprised if it wasn't in an existing blend or task.

aptitude says it doesn't have any reverse dependencies so it isn't in
any task/blend (both use metapackages).

Lucas created a script that displays a list of "important" packages,
puppet isn't on that either:

http://udd.debian.org/cgi-bin/important_packages.cgi

-- 
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/CAKTje6Ep2=t1qqvqof9ycgpkk-puipmn7gnirod7f-wk0xj...@mail.gmail.com

Re: Debian development and release: always releasable (essay)

[Tollef Fog Heen]

]] Paul Wise 

> Agreed. Do you have any example use-cases that should block releases
> but aren't in blends or tasks? Perhaps we need to start some new
> blends or add new tasks.

(Where can I look up what tasks or blends use a given package?)

I don't know if, say, puppet is in a task or a blend, but it's one of
the packages where I'm fairly sure that lots of people (DSA included)
would be less than impressed if it was missing from a stable release.
I'd also not be surprised if it wasn't in an existing blend or task.

-- 
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/87zjw12a4d@xoog.err.no

Processed: Re: Bug#707740: general: fails with video Hi10p

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> reassign 707740 gstreamer0.10-ffmpeg
Bug #707740 [general] general: fails with video Hi10p
Bug reassigned from package 'general' to 'gstreamer0.10-ffmpeg'.
Ignoring request to alter found versions of bug #707740 to the same values 
previously set
Ignoring request to alter fixed versions of bug #707740 to the same values 
previously set
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
707740: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707740
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
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/handler.s.c.136826069820884.transcr...@bugs.debian.org

Bug#707740: general: fails with video Hi10p

[Josselin Mouette]

reassign 707740 gstreamer0.10-ffmpeg
thanks

Le vendredi 10 mai 2013 à 16:28 -0500, Yuuji Sakai a écrit : 
> fails to convert a video Hi10P, style subs lost (DeVeDe for example 
> http://i.imgur.com/LWkmHj2.jpg http://i.imgur.com/n9R4G.png 
> http://i.imgur.com/zM0yDKZs.jpg), and show error in some programs to edit 
> video as avidemux, subtitle editor
> 
>  open subtitle Editor
> Archivo media no hallado.
> file:///home/yuuji/Escritorio/battle1.mkv
> 
> Internal GStreamer error: negotiation problem. 
> Please file a bug at 
> http://bugzilla.gnome.org/enter_bug.cgi?product=GStreamer.

Hi10p is a useless hack that makes videos unreadable with hardware
acceleration. I wouldn’t recommend using it in the general case. The
GStreamer packages don’t understand Hi10p anyway, even in sid. Feel free
to propose patches, but upstream.

You can use the avconv package instead of avidemux to manipulate Hi10p
files, and mplayer/smplayer can read them.

Cheers,
-- 
 .''`.  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/1368260692.12318.3.camel@tomoyo

Re: Debianizing the Java world?

[Daniel Pocock]

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.


-- 
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/518dfd76.1050...@pocock.com.au

Re: can someone explain what is happen on line one from this listing?

[John Paul Adrian Glaubitz]

On 05/11/2013 08:50 AM, Mailbox wrote:

i aks this list because i will now more about the "lost Interrupt 0x50)
error.
A faulty hard disk, makes other Logentries and this disk are replace by
the vendor this disk is a new/refurbished disk.


And I am still pretty sure your question is off-topic. This question is 
not really specific to the development of Debian. You should rather 
resort to other sources.


Since this seems to be a driver/hardware-related issue, I strongly 
recommend looking for a different list. Maybe either of the two 
storage-related kernel mailing lists [1] or [2] might be worth a shot or 
even try linux-admin [3] which seems to fit your question well.


I am pretty sure there are more people on the kernel mailing list which 
could help you understand the issue.



I have test with other Serverhardware what is happen if i put out the
power cabel from the disk. it is interesting but in all my test/hacks i
never have see a "lost interrupt"


Then it's obviously a hardware issue and not a software issue and your 
question is not fit on a mailing list focusing on software development.


Cheers,

Adrian

> [1] http://vger.kernel.org/vger-lists.html#linux-raid
> [2] http://vger.kernel.org/vger-lists.html#linux-scsi
> [3] http://vger.kernel.org/vger-lists.html#linux-admin

--
 .''`.  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/518df03d.7080...@physik.fu-berlin.de