Re: pulseaudio related problems....

[Matthias Urlichs]

Hi,

Helmut Grohne:
> Once you manually move a stream to a different sink, PA records your
> decision and the default sink is no longer relevant for that client. So
> when you move back, and restart your client, it is not affected by the
> default sink. What you propose does not work. Do you have an alternative
> in mind?
> 
You either didn't say that you want to override user decisions,
or I misread your email.

In any case, if you look at PA's dbus page, the Stream Restore Extension is
documented and accessible; presumably you can use that to find the relevant
entries and delete them.

Finding that page took somewhat less time than writing this mail does,
so frankly I don't really understand what your problem is.


> > Well, that's what libraries are for -- they encapsulate complicated things
> > with an easy interface. Write that code once, use it anywhere.
> 
> If PA is too crappy to interface directly, then it's not for me.

That does not follow. The whole point of libraries is to transform
high-level- into low(er)-level interfaces.

Your code uses malloc() even though the kernel only offers sbrk() and mmap().

Similarly, why do you use Gnome libraries if all these do is to transform
your calls into GTK calls? Or GTK if all they do (or rather, did) is to
call Xlib? Or Xlib, if all *that* does is to open a TCP or Unix-domain
stream socket and read/writes random(-seeming) bytes?

Same thing.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Bug#739483: ITP: duck -- checks URLs in debian/control and debian/upstream files

[Simon Kainz]

Package: wnpp
Severity: wishlist
Owner: Simon Kainz 

* Package name: duck
  Version : 0.1
  Upstream Author : Simon Kainz 
* URL : http://duck.debian.net
* License : GPL
  Programming Lang: Perl
  Description : checks URLs in debian/control and debian/upstream files

duck  extracts  links  and  VCS-* entries from

debian/control
debian/upstream
debian/upstream-metadata.yaml
debian/upstream/metadata

It tries to access those VCS-* entries and URLs using the approriate tool and
tries to find out wether  the given URLs or entries are broken or working. If
errors are detected, the  filename,  fieldname and URL of the broken link/URL
are displayed.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140219074324.15457.87091.report...@zidpc9027.tu-graz.ac.at

Re: default init on non-Linux platforms

[Matthias Urlichs]

Hi,

Thomas Goirand:
> > [0] Can we haz a release name?
> 
> It's been years that I've been asking that we have the release name a
> way sooner. Ideally, one release earlier, so that we can prepare for the
> new name soon enough (and not fix things during the freeze). But the
> release team doesn't seem to agree with this! :)
> 
I'm all for going with "zurg" here.

This transition mentions jessie+1 so often that naming it now make sense.

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

retitle RFP: caja-extensions

[Vangelis Mouhtsis]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Control: retitle -1 RFP: caja-extensions -- extensions for Caja file
manager adding extra-functionality

Hi,
Please accept my apologizes for my mistake by sending an incorrect
RFP for caja-extensions Descriprion and correct it with the following
below:

Package: wnpp
Severity: wishlist

* Package name: caja-extensions
  Version : 1.7.0
  Upstream Author : Stefano Karapetsas 
* URL : http://www.mate-desktop.org/
* License : GPL
  Programming Lang: C
  Description : provides extensions for caja file manager in MATE

 The extensions help caja file manager to handle extra functions
 working with: gksu, open-terminal, image-converter, sendto and
 share in MATE Desktop Environment.
 .
 This package will be maintained by the MATE Packaging Team.


Thank you
gnugr
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQEcBAEBAgAGBQJTBG6KAAoJEOWQha2zhDgv+REIAMMqOar+cLiEZ3PYthMBbQZz
mferRiGpPqfUpX4ZxhvzRyqczuSpfshHyqDUr0ETnt1MKOFABmfbTsZVaQ3tzSdQ
2oNC5tDf2K6dc7YihjSJoF/qHtsULomcr4wAkg9qsQsjei1NH+XaQ3nfNEsh2Oe9
mNtpdstrd4aZ4g+r8z884nitI5udafgSS2sxP/6r6X6BojAfg3i4Hqxt83VyuOm2
TK4MSjOGahv7LsCOvjTSHwETsgyHet2aDyPNtV9l/ErvYjogsIIeciPSE30MCZmn
2ieu37y2LD49mDq/46DzT7MlNFzZeIlapocxxfIT4jaif09vpZLAFUgb6RkLkvQ=
=BObW
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/53046e95.4090...@gnugr.org

Re: default init on non-Linux platforms

[Chris Bannister]

On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > [0] Can we haz a release name?
> > 
> 
> Sure. It's Debian 8.0, "zurg". [0]
> 
> Neil
> [0] Note: may be a lie.

Umm, Debian 9.0?

-- 
"If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing." --- Malcolm X


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

Re: default init on non-Linux platforms

[Neil McGovern]

On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> > > [0] Can we haz a release name?
> > > 
> > 
> > Sure. It's Debian 8.0, "zurg". [0]
> > 
> > Neil
> > [0] Note: may be a lie.
> 
> Umm, Debian 9.0?
> 

For those who may not be following along at home, I'm no longer a
release manager. I don't get to pick release names. The use of 8.0 was
deliberate to try and make it clearer that I have no say in the matter.

Neil
-- 


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Dimitri John Ledkov]

On 19 February 2014 11:22, Neil McGovern  wrote:
> On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
>> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> > > [0] Can we haz a release name?
>> > >
>> >
>> > Sure. It's Debian 8.0, "zurg". [0]
>> >
>> > Neil
>> > [0] Note: may be a lie.
>>
>> Umm, Debian 9.0?
>>
>
> For those who may not be following along at home, I'm no longer a
> release manager. I don't get to pick release names. The use of 8.0 was
> deliberate to try and make it clearer that I have no say in the matter.
>

But it's such a good name!

-- 
Regards,

Dimitri.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/canbhluhsjcqzxh3l1yrzduzl6ahxwsurgjzyfgxzvkwmodm...@mail.gmail.com

Bug#739504: ITP: fonts-sahl-naskh -- a fork of Droid Arabic Naskh font

[Mohamed Amine]

Package: wnpp
Severity: wishlist
Owner: Mohamed Amine 

* Package name: fonts-sahl-naskh
  Version : 20140125+git
  Upstream Author : Khaled Hosny 
* URL : https://github.com/khaledhosny/sahl-naskh
* License : Apache 2.0
  Description : a fork of Droid Arabic Naskh font

Sahl (Arabic for even, easy, convenient) is a fork of Droid Arabic Naskh font,
 fixing some of the issues in the original font.
 .
 Changes:
 .
   - Quranic annotation marks:
 - Made U+06E4 bigger, it was tiny and almost invisible!
 - Changed U+06E0 to be a small 0, not a black rectangle!
 - Changed U+06DF to be a small sukun, not black circle!
 - Changed U+06E1 to not be a small initial haa!
   - Increased the distance between vowel marks and base letter, 
 they were too close to be readable.
   - Removed the Riyal ligature, this symbol should be used directly
 if needed, not automatically replace the Arabic word riyal.
   - Added GDEF ligature caret, just in case any application begins
 to support them.
   - Merged the Droid Serif in the font, so that it covers Latin and
 punctuation marks.
   - Raised the isolated Noon to the baseline, as it looks out of place
 next to Waw, Raa or even Alef (the glyphs it is likely to come next to).
   - Fixed the position of Hamza below Lam-Alef; it was placed under the Lam!


signature.asc
Description: Digital signature

Re: Status of build-arch coverage

[Roger Leigh]

On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> Thanks for doing the rebuilds!
> 
> * Roger Leigh , 2014-02-18, 22:58:
> >┌┬┬───┐
> >│  current   │ buildarch  │ count │
> >├┼┼───┤
> >│ attempted  │ attempted  │   317 │
> >│ attempted  │ successful │26 │
> >│ failed │ failed │35 │
> >│ failed │ successful │ 3 │
> >│ successful │ attempted  │  1483 │
> >│ successful │ failed │ 3 │
> >│ successful │ successful │  8650 │
> >└┴┴───┘
> >
> >Raw data:
> >http://www.codelibre.net/~rleigh/rebuild-buildarch-20140218.sql.xz
> 
> Do I understand correctly that your rebuilds were with -B, and
> therefore packages that build only arch:all package were not tested
> at all?

This is correct.  I can repeat to test this.  However, I would
suspect that the results will not be as good in general--these
codepaths are not currently tested by building for upload unless
special action is taken, or by our autobuilders.  While most
packages using dh/cdbs should work correctly, it's quite likely
that we'll see regressions here.

> It would be interesting to see how packages that builds arch:all
> packages behave when rebuilt with -A.

Definitely.  I would also be interested to see what the coverage
looks like here.  I'll repeat and we'll see how things look like.
I'll probably be another week to do another two full sets of
builds.  I'll set it going later on today.

> >I hope the above is useful for measuring progress on this front.
> >Do we have any plans for enforcing build-arch for jessie at this
> >point? If we haven't already, stronger warnings when running
> >dpkg-buildpackage and stronger lintian warnings (errors?) would be
> >useful to add.
> 
> If build-{arch,indep} is missing, Lintian currently emits
> debian-rules-missing-recommended-target[0]. I think we should go
> ahead and make it emit debian-rules-missing-required-target[1],
> which is on ftp-masters' auto-reject list.

That sounds good.  When we do this, a clear announcement on d-d-a would
be good.  If we can reduce the failing count much further prior to
jessie freezing, what would be considered an acceptable threshold for
disabling the autodetection?  (Zero is unlikely to be attainable.)

> I attached dd-list of packages that were is non-successful state in
> the "buildarch" rebuild. Packages marked with "*" were also in
> non-successful state in the "current" build.

Thanks, that's much appreciated.


Regards,
Roger

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


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

Re: default init on non-Linux platforms

[Michael Biebl]

Am 18.02.2014 19:18, schrieb Didier 'OdyX' Raboud:
> Le mercredi, 19 février 2014, 00.56:07 Thomas Goirand a écrit :
>> On 02/18/2014 11:10 PM, Jonathan Dowland wrote:
>>> On Tue, Feb 18, 2014 at 10:55:32PM +0800, Thomas Goirand wrote:
 Once I consider OpenRC ready for it, would it be ok to just replace
 sysv-rc by OpenRC, and transform sysv-rc into a transitional
 package?
 What is the opinion of other DDs? Is there anyone which would like
 to
 keep the old featureless sysv-rc?
>>>
>>> What problem does that solve?
>>
>> In this way, we'd have only 2 init systems to take care of, and we
>> could start replacing init.d scripts by OpenRC runscripts *IF*
>> there's a systemd service file.
> 
> Yes. And three different daemon-starting syntaxes to manage the Wheezy-
> to-Jessie upgrades.
> 
> Again, for Jessie, I don't think it's reasonable to change the default 
> init _and_ replace the common baseline. I, for one, am not going to 
> replace my awkward-but-working sysvinit scripts by anything but 
> systemd/upstart unit files and that is doomed to happen in jessie+1 [0].

I'd like to add that switching to openrc breaks the SysV/LSB support in
systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
symlinks which signal if a service is active for a given runlevel.
(those symlinks are created in /etc/runlevel/* afaics)

This means systemd doesn't consider the SysV/LSB init script as enabled
and won't start it on boot.


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



signature.asc
Description: OpenPGP digital signature

Re: default init on non-Linux platforms

[Michael Biebl]

Am 19.02.2014 00:52, schrieb Russ Allbery:
> Henrique de Moraes Holschuh  writes:
> 
>> They *HAVE* to be provided by the active init system.  They are an
>> impedance matching layer (aka stable API) used by maintainer scripts to
>> interface with the active init system.
> 
> If you look at the existing implementation, you'll find that the version
> provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
> So this isn't precisely true.  If we stick with the current model, then
> some (probably essential) package just needs to provide those
> implementations and accept patches to work with new init systems, but each
> init system doesn't need to provide its own version.
> 
> There are some advantages to providing only one version with knowledge of
> all of the init systems given that we're supporting init system switching,
> and therefore may need to set up state for init systems that aren't
> currently running so that switching can work properly.  A good example is
> registering an init script with insserv so that the correct S and K links
> are created even if the system is currently booted with a different init
> system.

If you look at e.g. update-rc.d enable|disable, it currently has support
for systemd, upstart and sysv-rc. So whenever you enable a service, this
state is kept in sync across the different init systems (assuming the
service in question ships native support for other init systems).

I don't find equivalent functionality in openrc's implementation of
update-rc.d



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



signature.asc
Description: OpenPGP digital signature

Bug#739508: ITP: fitgpc -- fitting genome coverage distributions with mixture models

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: fitgpc
  Version : 0.0.20130418
  Upstream Author : Martin S. Lindner 
* URL : http://sourceforge.net/projects/fitgcp/files/
* License : BSD
  Programming Lang: Python
  Description : fitting genome coverage distributions with mixture models
 Genome coverage, the number of sequencing reads mapped to a position in
 a genome, is an insightful indicator of irregularities within sequencing
 experiments. While the average genome coverage is frequently used within
 algorithms in computational genomics, the complete information available
 in coverage profiles (i.e. histograms over all coverages) is currently
 not exploited to its full extent. Thus, biases such as fragmented or
 erroneous reference genomes often remain unaccounted for. Making this
 information accessible can improve the quality of sequencing experiments
 and quantitative analyses.
 .
 fitGCP is a framework for fitting mixtures of probability distributions
 to genome coverage profiles. Besides commonly used distributions, fitGCP
 uses distributions tailored to account for common artifacts. The mixture
 models are iteratively fitted based on the Expectation-Maximization
 algorithm.


This package is maintained by the Debian Med team and the packaging
is available at

   git://anonscm.debian.org/debian-med/fitgpc.git


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140219145641.15506.46788.report...@mail.an3as.eu

Bug#739509: ITP: gasic -- genome abundance similarity correction

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: gasic
  Version : 0.0.r18
  Upstream Author : Martin S. Lindner 
* URL : http://sourceforge.net/projects/gasic/files/
* License : BSD
  Programming Lang: Python
  Description : genome abundance similarity correction
 One goal of sequencing based metagenomic analysis is the quantitative
 taxonomic assessment of microbial community compositions. However, the
 majority of approaches either quantify at low resolution (e.g. at phylum
 level) or have severe problems discerning highly similar species. Yet,
 accurate quantification on species level is desirable in applications
 such as metagenomic diagnostics or community comparison. GASiC is a
 method to correct read alignment results for the ambiguities imposed by
 similarities of genomes. It has superior performance over existing
 methods.


This package is maintained by the Debian Med team and the packaging
is available at

   git://anonscm.debian.org/debian-med/gasic.git


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140219145930.15574.78491.report...@mail.an3as.eu

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/19/2014 10:44 PM, Michael Biebl wrote:
> I'd like to add that switching to openrc breaks the SysV/LSB support in
> systemd. Openrc doesn't use the /etc/rc?.d/ directories to create the
> symlinks which signal if a service is active for a given runlevel.
> (those symlinks are created in /etc/runlevel/* afaics)
> 
> This means systemd doesn't consider the SysV/LSB init script as enabled
> and won't start it on boot.

Oh, that's interesting!

First, yes, OpenRC uses /etc/runlevel, with the folders below that being
the *names* of the runlevel (which IMO is a way more user friendly than
just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
everything-else=default. So we do have these 4 directory names, and
OpenRC doesn't care about /etc/rc?.d.

Could you expand the above text and give a bit more explanations /
details? :)

So, systemd is still using /etc/rc?.d. Could you tell exactly what it
uses out of /etc/rc?.d, and what for? Does it only needs to see them as
S??script-name in runlevel 2 or 4 (or whatever it uses...)?

If systemd needs links in /etc/rcX.d, then I think it should be possible
to hack something.

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/5304c91a.1090...@debian.org

Re: default init on non-Linux platforms

[Ondřej Surý]

Dimitri,

On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
> On 19 February 2014 11:22, Neil McGovern  wrote:
> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
> >> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
> >> > > [0] Can we haz a release name?
> >> > >
> >> >
> >> > Sure. It's Debian 8.0, "zurg". [0]
> >> >
> >> > Neil
> >> > [0] Note: may be a lie.
> >>
> >> Umm, Debian 9.0?
> >>
> >
> > For those who may not be following along at home, I'm no longer a
> > release manager. I don't get to pick release names. The use of 8.0 was
> > deliberate to try and make it clearer that I have no say in the matter.
> >
> 
> But it's such a good name!

are you aware that media are already quoting your blogpost as official
announcement of next Debian codename?

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392823700.31129.85290293.71ac1...@webmail.messagingengine.com

Re: default init on non-Linux platforms

[Dimitri John Ledkov]

On 19 February 2014 15:28, Ondřej Surý  wrote:
> Dimitri,
>
> On Wed, Feb 19, 2014, at 12:57, Dimitri John Ledkov wrote:
>> On 19 February 2014 11:22, Neil McGovern  wrote:
>> > On Wed, Feb 19, 2014 at 11:37:08PM +1300, Chris Bannister wrote:
>> >> On Tue, Feb 18, 2014 at 06:31:12PM +, Neil McGovern wrote:
>> >> > On Tue, Feb 18, 2014 at 07:18:30PM +0100, Didier 'OdyX' Raboud wrote:
>> >> > > [0] Can we haz a release name?
>> >> > >
>> >> >
>> >> > Sure. It's Debian 8.0, "zurg". [0]
>> >> >
>> >> > Neil
>> >> > [0] Note: may be a lie.
>> >>
>> >> Umm, Debian 9.0?
>> >>
>> >
>> > For those who may not be following along at home, I'm no longer a
>> > release manager. I don't get to pick release names. The use of 8.0 was
>> > deliberate to try and make it clearer that I have no say in the matter.
>> >
>>
>> But it's such a good name!
>
> are you aware that media are already quoting your blogpost as official
> announcement of next Debian codename?
>

Nah, wasn't aware =) I blame Neil, I thought he still was a release manager ;-)
Any reason, not to make it official? =)

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUjk=szx4ztfxwzhjnyxptgeovtqtbesa_cf_dnuqyj...@mail.gmail.com

Re: default init on non-Linux platforms

[Simon McVittie]

On 19/02/14 15:09, Thomas Goirand wrote:
> First, yes, OpenRC uses /etc/runlevel, with the folders below that being
> the *names* of the runlevel (which IMO is a way more user friendly than
> just numbers). FYI, we have: shutdown=0, recovery=1, reboot=6, and
> everything-else=default. So we do have these 4 directory names, and
> OpenRC doesn't care about /etc/rc?.d.

Similar to systemd's multi-user.target etc. (which are made to depend on
native systemd units), then. However, systemd still needs to know
whether an LSB init script with no corresponding systemd unit should be
started or not, which it does by looking in /etc/rcX.d (I think it
assuems that anything started in any of rc[2345].d should be included in
multi-user.target).

> If systemd needs links in /etc/rcX.d, then I think it should be possible
> to hack something.

I suspect the right thing would be to share one implementation of
update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
supported init implementations, provided by either src:sysvinit or
src:init-system-helpers. The implementations in sysv-rc and
sysvinit-utils already seem to support sysv-rc[1], systemd and Upstart;
teaching them about OpenRC shouldn't be rocket science.

This has the advantage that if you install a daemon while your init is
sysvinit/sysv-rc, enable and/or disable it, then switch to systemd or
OpenRC and reboot, that daemon remains enabled or disabled (as appropriate).

S

[1] and probably file-rc for that matter


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

Re: default init on non-Linux platforms

[The Wanderer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:

> On 19 February 2014 15:28, Ondřej Surý  wrote:
> 
>> Dimitri,

>> are you aware that media are already quoting your blogpost as
>> official announcement of next Debian codename?
> 
> Nah, wasn't aware =) I blame Neil, I thought he still was a release
> manager ;-) Any reason, not to make it official? =)

Well, back in 2002 there was a probably-joking sort-of decision that
"zurg" should be the codename of the release where the Hurd and *BSD
ports were fully ready [1]. Given that we seem to be moving more towards
dropping ports than finalizing them at the moment, using the name zurg
would not seem to be in keeping with that idea.

I like the idea (and the method of choosing, and of announcing, it)
otherwise, though.


[1] https://lists.debian.org/debian-devel/2002/07/msg01139.html

- --
   The Wanderer

Secrecy is the beginning of tyranny.

A government exists to serve its citizens, not to control them.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJTBNSBAAoJEASpNY00KDJrxTkP/2JtWJDGwrw+EXNaUBE5fFv+
zjWMPUqmCZgvaS/LUe8aiwbPUGXXy18pyIQwsHH30XPcouCQTbX7K1I8PuUekMc1
E4axQ6F5/aFZHki1n1VxWqW3VUxPU+hDP4CpPr+OymSQDkXduMir2WXYx1JMyYKR
405zV2NjirFuwS9ldD/EaEA5zCXAK2KSw1KG3KVRJN3N/r2/y1nxomJ9B6lMuUJT
RrjlCg3DYuwWQGMDHuA3OAnIxRP/qI2EkNp5qPCY6zAsZf4co8PDrjsC/4cx4AVo
Zqu6FDkR+vROzhF7+016s2buVUsGmExDysY1dNaflXGB3A0jpIBcEQ0qxXuYbR1a
Eo0CSn34+7DuMCeIYslW7vtEviAH4K5gxt4kAQTqU65OVGGEUDCaj3T8VwQ0bb5l
BD5YryZA/bXdBXVZm3geGa9Ft41Bg2WGqd5G1/muvmc+yP0oocWmTnDJaEqBSDaH
sp5YvVVXgK7G7azMvCjpL0M2gXAoaDcPjsoG/9D8jEThnVshk3fmu1EgsCxnecR+
qY1fBhCP88GpSXSc2jb0cPvGFIZJSH6V7q2r9ZUniT9wsL53rq5mGnM6soM+Gn/c
uz+5IK2gc5yO1o/besgkGGFd3RbIrYEvFOqjfdJIqexV4Lrw2r8LH1rOX66gaSB1
4Ephwd895xZzC/5wP4Tj
=wIwk
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5304d481.9000...@fastmail.fm

New debian "codename" (Was: default init on non-Linux platforms)

[Ondřej Surý]

On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
> 
> > On 19 February 2014 15:28, Ondřej Surý  wrote:
> > 
> >> Dimitri,
> 
> >> are you aware that media are already quoting your blogpost as
> >> official announcement of next Debian codename?
> > 
> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> > manager ;-) Any reason, not to make it official? =)

And obviously the phoronix and others thought you are on the release
team and you have a say about next codename (since you have blogged
about it, it must be true). *palmface* (not targeted at Neil nor
Dimitri...)

> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports were fully ready [1]. Given that we seem to be moving more towards
> dropping ports than finalizing them at the moment, using the name zurg
> would not seem to be in keeping with that idea.
> 
> [1] https://lists.debian.org/debian-devel/2002/07/msg01139.html
> 
> I like the idea (and the method of choosing, and of announcing, it)
> otherwise, though.

Well, it makes me really sad how little effort the current journalists
make to verify the claims. Dimitry blogs some insider joke and it's
already on phoronix. And since it's written on the internet it must be
true. *double palmface*

O.
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392825915.7856.85305641.6b618...@webmail.messagingengine.com

Re: default init on non-Linux platforms

[Dimitri John Ledkov]

On 19 February 2014 15:57, The Wanderer  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>
>> On 19 February 2014 15:28, Ondřej Surý  wrote:
>>
>>> Dimitri,
>
>>> are you aware that media are already quoting your blogpost as
>>> official announcement of next Debian codename?
>>
>> Nah, wasn't aware =) I blame Neil, I thought he still was a release
>> manager ;-) Any reason, not to make it official? =)
>
> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports were fully ready [1]. Given that we seem to be moving more towards
> dropping ports than finalizing them at the moment, using the name zurg
> would not seem to be in keeping with that idea.
>
> I like the idea (and the method of choosing, and of announcing, it)
> otherwise, though.
>

To be honest Zurg is living up to it's expectations. kFreeBSD is
looking very solid on jessie already, and it can only get better by
Zurg time. Initial porting work is done, and now work is mostly put
into polishing and providing new features. It really is something i'm
comfortable running as my main server. And given Zurg's ambitious
plans drafted today the name is both suitable and telling as predicted
back then.

And if scope is limitted to virtual machines / cloud instances - Hurd
also looks very good.

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUiB==jdfc1sjchgnitacorzraa966cwfu6vuagaekq...@mail.gmail.com

Re: New debian "codename" (Was: default init on non-Linux platforms)

[Dimitri John Ledkov]

On 19 February 2014 16:05, Ondřej Surý  wrote:
> On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
>>
>> > On 19 February 2014 15:28, Ondřej Surý  wrote:
>> >
>> >> Dimitri,
>>
>> >> are you aware that media are already quoting your blogpost as
>> >> official announcement of next Debian codename?
>> >
>> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
>> > manager ;-) Any reason, not to make it official? =)
>
> And obviously the phoronix and others thought you are on the release
> team and you have a say about next codename (since you have blogged
> about it, it must be true). *palmface* (not targeted at Neil nor
> Dimitri...)
>
>> Well, back in 2002 there was a probably-joking sort-of decision that
>> "zurg" should be the codename of the release where the Hurd and *BSD
>> ports were fully ready [1]. Given that we seem to be moving more towards
>> dropping ports than finalizing them at the moment, using the name zurg
>> would not seem to be in keeping with that idea.
>>
>> [1] https://lists.debian.org/debian-devel/2002/07/msg01139.html
>>
>> I like the idea (and the method of choosing, and of announcing, it)
>> otherwise, though.
>
> Well, it makes me really sad how little effort the current journalists
> make to verify the claims. Dimitry blogs some insider joke and it's
> already on phoronix. And since it's written on the internet it must be
> true. *double palmface*
>

Wait, wait, somebody needs to edit Debian's wikipedia article with
citations, for it to be _triple_ official and verified =)))

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANBHLUgNmZbhrW1_RY=f+6nabx-vcpj+-qf5kid2rtqisvi...@mail.gmail.com

Re: New debian "codename" (Was: default init on non-Linux platforms)

[Ondřej Surý]

On Wed, Feb 19, 2014, at 17:09, Dimitri John Ledkov wrote:
> On 19 February 2014 16:05, Ondřej Surý  wrote:
> > On Wed, Feb 19, 2014, at 16:57, The Wanderer wrote:
> >> -BEGIN PGP SIGNED MESSAGE-
> >> Hash: SHA512
> >>
> >> On 02/19/2014 10:45 AM, Dimitri John Ledkov wrote:
> >>
> >> > On 19 February 2014 15:28, Ondřej Surý  wrote:
> >> >
> >> >> Dimitri,
> >>
> >> >> are you aware that media are already quoting your blogpost as
> >> >> official announcement of next Debian codename?
> >> >
> >> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> >> > manager ;-) Any reason, not to make it official? =)
> >
> > And obviously the phoronix and others thought you are on the release
> > team and you have a say about next codename (since you have blogged
> > about it, it must be true). *palmface* (not targeted at Neil nor
> > Dimitri...)
> >
> >> Well, back in 2002 there was a probably-joking sort-of decision that
> >> "zurg" should be the codename of the release where the Hurd and *BSD
> >> ports were fully ready [1]. Given that we seem to be moving more towards
> >> dropping ports than finalizing them at the moment, using the name zurg
> >> would not seem to be in keeping with that idea.
> >>
> >> [1] https://lists.debian.org/debian-devel/2002/07/msg01139.html
> >>
> >> I like the idea (and the method of choosing, and of announcing, it)
> >> otherwise, though.
> >
> > Well, it makes me really sad how little effort the current journalists
> > make to verify the claims. Dimitry blogs some insider joke and it's
> > already on phoronix. And since it's written on the internet it must be
> > true. *double palmface*
> >
> 
> Wait, wait, somebody needs to edit Debian's wikipedia article with
> citations, for it to be _triple_ official and verified =)))

That should have been your first step: https://xkcd.com/978/

:-P

Ondrej
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1392826366.9816.85310137.7f3d3...@webmail.messagingengine.com

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/19/2014 10:47 PM, Michael Biebl wrote:
> Am 19.02.2014 00:52, schrieb Russ Allbery:
>> Henrique de Moraes Holschuh  writes:
>>
>>> They *HAVE* to be provided by the active init system.  They are an
>>> impedance matching layer (aka stable API) used by maintainer scripts to
>>> interface with the active init system.
>>
>> If you look at the existing implementation, you'll find that the version
>> provided by sysv-rc already supports systemd, upstart, and sysv-rc itself.
>> So this isn't precisely true.  If we stick with the current model, then
>> some (probably essential) package just needs to provide those
>> implementations and accept patches to work with new init systems, but each
>> init system doesn't need to provide its own version.
>>
>> There are some advantages to providing only one version with knowledge of
>> all of the init systems given that we're supporting init system switching,
>> and therefore may need to set up state for init systems that aren't
>> currently running so that switching can work properly.  A good example is
>> registering an init script with insserv so that the correct S and K links
>> are created even if the system is currently booted with a different init
>> system.
> 
> If you look at e.g. update-rc.d enable|disable, it currently has support
> for systemd, upstart and sysv-rc. So whenever you enable a service, this
> state is kept in sync across the different init systems (assuming the
> service in question ships native support for other init systems).
> 
> I don't find equivalent functionality in openrc's implementation of
> update-rc.d

How come? I just took what was in the sysinit package! Or probably, what
you are talking about is new features, which I should merge it back into
the OpenRC version?

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/5304e46b.8050...@debian.org

Re: FFmpeg vs. libav packaging

[Moritz Mühlenhoff]

Jonathan Dowland  schrieb:
> Moritz, what's the security team's opinion on ffmpeg being reintroduced
> as a binary package (providing /usr/bin/ffmpeg) only?

Doesn't make much of a difference, since it still exposes all the same decoders
and demuxers through the ffmpeg binary.

Cheers,
Moritz


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnlg9o2v.5gd@inutil.org

Re: default init on non-Linux platforms

[Thomas Goirand]

On 02/19/2014 11:53 PM, Simon McVittie wrote:
> I suspect the right thing would be to share one implementation of
> update-rc.d(8), invoke-rc.d(8) and possibly service(8) between all
> supported init implementations, provided by either src:sysvinit or
> src:init-system-helpers.

Surprisingly, "service" is shared among all init systems (it's in
sysvinit-utils), while the other 2 are not.

I agree we should have a common interface and make sure one daemon
remains enabled / disabled in all init systems.

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/5304e53b.9050...@debian.org

Re: default init on non-Linux platforms

[Matthias Urlichs]

Hi,

The Wanderer:
> > Nah, wasn't aware =) I blame Neil, I thought he still was a release
> > manager ;-) Any reason, not to make it official? =)
> 
> Well, back in 2002 there was a probably-joking sort-of decision that
> "zurg" should be the codename of the release where the Hurd and *BSD
> ports were fully ready [1].

Only 14 years late, then. (Assuming it'll be ready sometime in 2016.)

Let's put it this way: we're unlikely to exceed that delay any time soon.

> I like the idea (and the method of choosing, and of announcing, it)
> otherwise, though.

+1

-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Press updates [Was: Re: default init on non-Linux platforms]

[Neil McGovern]

On Wed, Feb 19, 2014 at 03:45:12PM +, Dimitri John Ledkov wrote:
> On 19 February 2014 15:28, Ondřej Surý  wrote:
> > are you aware that media are already quoting your blogpost as official
> > announcement of next Debian codename?
> >
> 
> Nah, wasn't aware =) I blame Neil, I thought he still was a release manager 
> ;-)
> Any reason, not to make it official? =)
> 

You should read your lovely bits mails more carefully then :) I also
wouldn't call phoronix "the media". And on a slight tangent, I'd always
welcome more people who are interested in the press and publicity team
:)

Neil
-- 


signature.asc
Description: Digital signature

Re: default init on non-Linux platforms

[Kevin Chadwick]

previously on this list Thomas Goirand contributed:

> So, systemd is still using /etc/rc?.d. Could you tell exactly what it
> uses out of /etc/rc?.d, and what for? Does it only needs to see them as
> S??script-name in runlevel 2 or 4 (or whatever it uses...)?
> 
> If systemd needs links in /etc/rcX.d, then I think it should be possible
> to hack something.

One of the main things I like about OpenRC and especially OpenBSDs rc
system is that you can modify the files directly intuitively.

The main thing I hate about the current system is those links and them
requiring a tool to edit them in any timely fashion. Almost as much as
the huge commandlines needed to do so for systemd without it's tools
or for things it's tools can't or couldn't do at the time I tested it
out, if I remember rightly to do with
org.??? lines.

Do people use all those runlevels?

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/494637.19636...@smtp114.mail.ir2.yahoo.com

Re: systemd's journal

[Kevin Chadwick]

previously on this list Helmut Grohne contributed:

> > It's just occurred to me that the binary format may not work with append
> > only logging?  
> 
> That's true for the journal. When the journal opens its binary log, it
> flags the file as being opened, but what is the issue with not being
> append only?
> 

I like to use the kernel to enforce append only on certain log files so
that they can't be tampered without finding a kernel exploit or
rebooting. Your right in that it does mean you can't compress but I
find logs are small on modern disks.

I do it all the time on OpenBSD with schg backed up by it's ace
critical bug free kernel and have done so on Linux with chattr -a mixed
with another trick that I forget right now though I believe it can be
done with RBACs like grsecurities or SELinux.

> > Also recovering those logs from a possibly intentionally
> > uncompletely wiped disk would be much harder especially on an ext3/ext4
> > filesystem where carving is required when otherwise you could image or
> > ddrescue in case of hardware failure and use grep.  
> 
> I have not tried, but I imagine it not being that much harder for the
> following reasons:
> 
> If your journal is compressed, you basically lose, but that is true for
> compressed text logs as well. So if you need this recovery scenario,
> don't compress.
> 
> If your journal is uncompressed, you can exploit aspects of the format
> to find the log. Specifically, log entry consists of key-value pairs,
> most of which likely match /\(_SYSTEMD_[A-Z_]*\|MESSAGE\)=.*/. Another

True and fair enough, though can you read partial fragments from a
journal or does it need the whole thing or complete chunks recovered.

Anyway it's not like I have ever needed to do this but it's good to
know you can and for the same reason I save my odt files as text
occasionally when writing them as a more reliable format and advise
others to do so.

-- 
___

'Write programs that do one thing and do it well. Write programs to work
together. Write programs to handle text streams, because that is a
universal interface'

(Doug McIlroy)

In Other Words - Don't design like polkit or systemd
___


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/889772.23942...@smtp150.mail.ir2.yahoo.com

Bug#739538: ITP: libghc-setlocale -- Haskell bindings to setlocale()

[Sven Bartscher]

Package: wnpp
Severity: wishlist
Owner: Sven Bartscher 

* Package name: libghc-setlocale
  Version : 0.0.3
  Upstream Author : Name l@web.de
* URL : http://hackage.haskell.org/package/setlocale
* License : PublicDomain
  Programming Lang: haskell
  Description : Haskell bindings to setlocale()

This package provides haskell bindings to setlocale()

I'm going to maintain this package together with a co-maintainer,
Thomas Bartscher.
We're going to need a sponsor.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20140219192836.13187.99322.reportbug@sven.bartscher

Bug#739540: ITP: golang-go-xdg -- Go interface for XDG standards

[Sergio Schvezov]

Package: wnpp
Severity: wishlist
Owner: Sergio Schvezov 

* Package name: golang-go-xdg
  Version : 0~bzr20140219-1
  Upstream Author : John R. Lenton 
* URL : https://launchpad.net/go-xdg
* License : BSD-2-Clause
  Programming Lang: Go
  Description : Go interface for XDG standards

After importing this package, you can support the XDG base directories
standard in your programs.


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

Re: Status of build-arch coverage

[Steve Langasek]

On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> Thanks for doing the rebuilds!

> * Roger Leigh , 2014-02-18, 22:58:
> >┌┬┬───┐
> >│  current   │ buildarch  │ count │
> >├┼┼───┤
> >│ attempted  │ attempted  │   317 │
> >│ attempted  │ successful │26 │
> >│ failed │ failed │35 │
> >│ failed │ successful │ 3 │
> >│ successful │ attempted  │  1483 │
> >│ successful │ failed │ 3 │
> >│ successful │ successful │  8650 │
> >└┴┴───┘

> >Raw data:
> >http://www.codelibre.net/~rleigh/rebuild-buildarch-20140218.sql.xz

> Do I understand correctly that your rebuilds were with -B, and
> therefore packages that build only arch:all package were not tested
> at all?

> It would be interesting to see how packages that builds arch:all
> packages behave when rebuilt with -A.

> >I hope the above is useful for measuring progress on this front.
> >Do we have any plans for enforcing build-arch for jessie at this
> >point? If we haven't already, stronger warnings when running
> >dpkg-buildpackage and stronger lintian warnings (errors?) would be
> >useful to add.
> 
> If build-{arch,indep} is missing, Lintian currently emits
> debian-rules-missing-recommended-target[0]. I think we should go
> ahead and make it emit debian-rules-missing-required-target[1],
> which is on ftp-masters' auto-reject list.

> I attached dd-list of packages that were is non-successful state in
> the "buildarch" rebuild. Packages marked with "*" were also in
> non-successful state in the "current" build.

> [0] 
> http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html
> [1] http://lintian.debian.org/tags/debian-rules-missing-required-target.html


> Steve Langasek 
>  * openldap (U)
>samba (U)

This is not useful without build logs.  Both of these packages use dh(1),
which is perfectly build-arch-compatible; there's bug #738641 reported on
openldap about the libdb5.1 transition, but that doesn't actually cause a
build failure yet.

So I think this build environment is suspect, and such a summary report is
not useful without substantial details.

-- 
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: Status of build-arch coverage

[Roger Leigh]

On Wed, Feb 19, 2014 at 01:02:55PM -0800, Steve Langasek wrote:
> On Wed, Feb 19, 2014 at 01:58:48PM +0100, Jakub Wilk wrote:
> > Thanks for doing the rebuilds!
> 
> > * Roger Leigh , 2014-02-18, 22:58:
> > >┌┬┬───┐
> > >│  current   │ buildarch  │ count │
> > >├┼┼───┤
> > >│ attempted  │ attempted  │   317 │
> > >│ attempted  │ successful │26 │
> > >│ failed │ failed │35 │
> > >│ failed │ successful │ 3 │
> > >│ successful │ attempted  │  1483 │
> > >│ successful │ failed │ 3 │
> > >│ successful │ successful │  8650 │
> > >└┴┴───┘
> 
> > >Raw data:
> > >http://www.codelibre.net/~rleigh/rebuild-buildarch-20140218.sql.xz
> 
> > Do I understand correctly that your rebuilds were with -B, and
> > therefore packages that build only arch:all package were not tested
> > at all?
> 
> > It would be interesting to see how packages that builds arch:all
> > packages behave when rebuilt with -A.
> 
> > >I hope the above is useful for measuring progress on this front.
> > >Do we have any plans for enforcing build-arch for jessie at this
> > >point? If we haven't already, stronger warnings when running
> > >dpkg-buildpackage and stronger lintian warnings (errors?) would be
> > >useful to add.
> > 
> > If build-{arch,indep} is missing, Lintian currently emits
> > debian-rules-missing-recommended-target[0]. I think we should go
> > ahead and make it emit debian-rules-missing-required-target[1],
> > which is on ftp-masters' auto-reject list.
> 
> > I attached dd-list of packages that were is non-successful state in
> > the "buildarch" rebuild. Packages marked with "*" were also in
> > non-successful state in the "current" build.
> 
> > [0] 
> > http://lintian.debian.org/tags/debian-rules-missing-recommended-target.html
> > [1] http://lintian.debian.org/tags/debian-rules-missing-required-target.html
> 
> 
> > Steve Langasek 
> >  * openldap (U)
> >samba (U)
> 
> This is not useful without build logs.  Both of these packages use dh(1),
> which is perfectly build-arch-compatible; there's bug #738641 reported on
> openldap about the libdb5.1 transition, but that doesn't actually cause a
> build failure yet.
> 
> So I think this build environment is suspect, and such a summary report is
> not useful without substantial details.

I took a complete amd64+source debmirror archive snapshot on 20140212 at 0253.

>From this, I debootstrapped a fresh build chroot from the NFS mount of the
mirror, and set it up to use the file:// apt source of the bind mounted
mirror inside the chroot, which is fast and saves needing to download the
debs before unpacking.

I would suspect that most failures which weren't due to transient lack of
buildability in unstable, and not due to lacking build-arch support are
due to timeouts (see below) or timing issues due to the system load.


Current unstable dpkg building openldap:

> Starting test048-syncrepl-multiproxy for mdb...
running defines.sh
Starting master slapd on TCP/IP port 9011...
Using ldapsearch to check that master slapd is running...
Using ldapadd to create the context prefix entry in the master...
Starting P1 slave slapd on TCP/IP port 9012...
Using ldapsearch to check that P1 slave slapd is running...
Starting R1 slave slapd on TCP/IP port 9013...
Using ldapsearch to check that R1 slave slapd is running...
1 > Using ldapadd to populate the master directory...
Waiting 7 seconds for syncrepl to receive changes...
1 < Comparing retrieved entries from master and P1 slave...
1 < Comparing retrieved entries from master and R1 slave...
test failed - master and R1 slave databases differ
> test048-syncrepl-multiproxy failed for mdb
(exit 1)
make[3]: *** [mdb-mod] Error 1
make[3]: Leaving directory `/«PKGBUILDDIR»/debian/build/tests'
make[2]: *** [test] Error 2

Maybe the 7 seconds wasn't enough if the system was heavily
loaded?

samba failed due to timing out while linking.  I'll identify and
reschedule the jobs which timed out.  It's about 30 per run, which
isn't going to affect the statistics, but obviously there are a few
false positives as a result, which I'll rectify.  I'll increase the
timeout for the next runs.

I can make the collection of build logs available if needed.  I'll
get the rebuilds done first though.


Regards,
Roger

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


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

Re: Status of build-arch coverage

[Steve Langasek]

On Wed, Feb 19, 2014 at 09:28:48PM +, Roger Leigh wrote:
> Current unstable dpkg building openldap:

> > Starting test048-syncrepl-multiproxy for mdb...
> running defines.sh
> Starting master slapd on TCP/IP port 9011...
> Using ldapsearch to check that master slapd is running...
> Using ldapadd to create the context prefix entry in the master...
> Starting P1 slave slapd on TCP/IP port 9012...
> Using ldapsearch to check that P1 slave slapd is running...
> Starting R1 slave slapd on TCP/IP port 9013...
> Using ldapsearch to check that R1 slave slapd is running...
> 1 > Using ldapadd to populate the master directory...
> Waiting 7 seconds for syncrepl to receive changes...
> 1 < Comparing retrieved entries from master and P1 slave...
> 1 < Comparing retrieved entries from master and R1 slave...
> test failed - master and R1 slave databases differ
> > test048-syncrepl-multiproxy failed for mdb
> (exit 1)
> make[3]: *** [mdb-mod] Error 1
> make[3]: Leaving directory `/«PKGBUILDDIR»/debian/build/tests'
> make[2]: *** [test] Error 2

> Maybe the 7 seconds wasn't enough if the system was heavily
> loaded?

Must be awfully loaded, considering this test passes reliably on buildds of
all archs (including the really slow ones).

> samba failed due to timing out while linking.  I'll identify and
> reschedule the jobs which timed out.  It's about 30 per run, which
> isn't going to affect the statistics, but obviously there are a few
> false positives as a result, which I'll rectify.  I'll increase the
> timeout for the next runs.

Ok.  The statistics still seem awfully low to me; but I guess
http://people.debian.org/~cjwatson/dhstats.png shows there hasn't actually
been a huge uptick in dh(1) adoption over the past year, as a percentage of
all packages.  Maybe it's time for a MBF on non-dh packages. ;-)

-- 
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: default init on non-Linux platforms

[Tollef Fog Heen]

]] Thomas Goirand 

> How come? I just took what was in the sysinit package! Or probably, what
> you are talking about is new features, which I should merge it back into
> the OpenRC version?

It's probably better to just contribute your changes to the sysv-rc
version and so make that one able to manage openrc in addition to the
others it already knows how to.  No point in forking it.

-- 
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/m2ppmi4cvu@rahvafeir.err.no

Re: default init on non-Linux platforms

[heroxbd]

Hi Tollef,

Tollef Fog Heen  writes:

> It's probably better to just contribute your changes to the sysv-rc
> version and so make that one able to manage openrc in addition to the
> others it already knows how to.  No point in forking it.

Forking was a decision made by me in the early phase of packaging
OpenRC. At that time I referred to the way file-rc handled update-rc.d
as in

 sysvinit: /usr/share/sysvinit/update-rc.d

A central package providing update-rc.d and invoke-rc.d is nice. Though
it should not be sysv-rc, which OpenRC is intending to replace.

Cheers,
Benda


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/86a9dmbbtp@moguhome00.in.awa.tohoku.ac.jp

Re: default init on non-Linux platforms

[Russ Allbery]

hero...@gentoo.org writes:

> Forking was a decision made by me in the early phase of packaging
> OpenRC. At that time I referred to the way file-rc handled update-rc.d
> as in

>  sysvinit: /usr/share/sysvinit/update-rc.d

> A central package providing update-rc.d and invoke-rc.d is nice. Though
> it should not be sysv-rc, which OpenRC is intending to replace.

One possibility would be to move those programs to init-system-helpers,
since that is, after all, the point of that package (even if right now
it's only used for systemd glue).  That package does currently depend on
perl, though, which isn't appropriate for an essential package.  I'm not
sure the best way to approach that.  The dependency is because
deb-systemd-helper uses a bunch of modules that are not currently in
perl-core (File::Path, File::Basename, File::Find, File::Temp,
Text::ParseWords, and Data::Dumper, although the last is only used for
debugging and could be loaded on demand if available and skipped
otherwise).

File::Path and File::Basename can be easily replaced with some short
functions and simple regexes, but the rest are a bit harder to replace.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r46y8i63@windlord.stanford.edu