Re: [debian-mysql] Bug#732878: Add MariaDB as an alternative dependency

2014-01-04 Thread Marcin Kulisz 
On 2013-12-27 01:13:15, Otto Kekäläinen wrote:
> 2013/12/25 Thomas Goirand :

snip

> > P.S: Do you know if the MariaDB package in Sid has the capability to run
> > in cluster, like for Galera?
> 
> No, but I might package MariaDB Galera Cluster later if I have time
> and energy for additional packages. However before that I'll do
> MariaDB 10.0 (Debian now only got 5.5).

Hi Otto,
why not to provide by default Galera enabled version and just omit none-galera
one? Galera is happy enough to run as single machine and if you want cluster
you will just have to change 1 line in config to achieve it.

Don't you think this is going to be slightly better solution (1 pkg to
maintain & 1 pkg in repo called mariadb)?
-- 

|_|0|_|  |
|_|_|0| "Heghlu'Meh QaQ jajVam"  |
|0|0|0|  kuLa -  |

gpg --keyserver pgp.mit.edu --recv-keys 0x58C338B3
3DF1 A4DF C732 4688 38BC F121 6869 30DD  58C3 38B3


signature.asc
Description: Digital signature

Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]

2014-01-04 Thread Luca Capello 
Hi there!

On Sat, 04 Jan 2014 04:29:02 +0100, Paul Tagliamonte wrote:
> On Tue, Dec 31, 2013 at 08:59:53AM -0600, Matt Zagrabelny wrote:
>> > So your doomsday scenario is that if you license something
>> > GPLv2+, someone might fork and modify it to be GPLv3+,
>> 
>> I was under the impression that forks couldn't change licenses. Is the
>> scenario which Clint describes (legally) possible?
>
> I drew up this table a few weeks back when someone was misunderstanding
> the GPL combination stuff.
> /
> |  HELPFUL GPL UPGRADE TABLE

Without checking in details Paul's table, upstream FAQ contains a
commented matrix where copying and usage are separate (as it should):

  

Thx, bye,
Gismo / Luca


signature.asc
Description: PGP signature

Better pdiff handling for apt

2014-01-04 Thread Anthony Towns 
Salut tout le monde,

Some time ago (*cough* 2009), I had a play with working out how to
apply pdiffs more efficiently than apt currently does, and implemented
a proof of concept in python [0]. There weren't any replies (even a
"ooo, cool") when I posted to the deity list, so I left it at that;
though trolling google now, I see that it got mentioned on -devel [1]
not all that long ago (*cough* 2012), so apparently it did get read
after all. Not that it looks like it would've done much good, because
it seems like the script I put on the web, and the one I was actually
using are completely different to the extent that the one on the web
even has syntax errors. WTF?

Anyhoo... Like many, I've been getting annoyed at how tedious pdiff
application is over the past year, so over Christmas I thought I'd
have a go at patching apt to do things "properly". I've got it to the
point where it works now, and apt-get update reports things like:

   Fetched 199 MB in 50s (3919 kB/s)

over a 50kB/s link when updating testing+unstable for i386+amd64 for a
day's worth of changes, rather than reporting 7000 B/s over a megabit
link. It should also be much more pleasant on SSDs, since it only
attempts to write each diff twice (once compressed, once
uncompressed), and each packages file once; rather than writing each
diff once, and the Packages file once for each diff.

My patched apt source is up on github at:

   https://github.com/ajtowns/apt/tree/better-pdiffs

My current theory is that it's best to re-specify the .diff/Index
format by adding an additional header

   Patch-Step-Size: 1 1 4 3 2 1 1

which would indicate that there are six patches available, and that if
you start from the oldest known version, you should apply patch 1,
then patch 2 (patch 1 + 1), then patch 3 (patch 2 + 1), then patch 7
(patch 3 + 4), and then you're done (patch 7 + 1 == patch 8, which
doesn't exist). If you wanted to run an archive where you only had to
download one patch and apply it no matter how old your Packages file
was, the line would look like:

   Patch-Step-Size: 12 11 10 9 8 7 6 5 4 3 2 1

(I think a nice efficient compromise method would be Patch-Step-Size:
8 8 4 4 4 4 2 2 1, which would only update a lg(diffs) each time you
updated the packages file, and only require users to download and
apply a maximum of lg(diffs) to get up to date)

If the line's not present, it should be treated as:

   Patch-Step-Size: 1 1 1 1 1 1 1 ...

which would be compatible with the way Debian does things, but
presumably not with some derivatives.

Anyway, the code works adequately as a proof of concept and I don't
think it should need a major re-write, but the things I think still
need doing to it are:

 * make sure main sha256/sha512/etc hashes are being checked after
patches are applied
 * verify that diff sha1 hashes are being checked on download
 * don't keep diffs around after they've been applied
 * add support for Patch-Step-Size as above
 * more robust parsing of diff files in rred method
 * review code paths in acquire-item to make sure they're sane
 * fix up debug message for rred method and diff acquire-item classes
 * consider just reading the gzipped diffs directly rather than
uncompressing them
 * check that the http downloads are being done as efficiently as possible (?)
 * consider leaving the diffs in partial/
 * allow resuming downloading diffs, rather than always redownloading
them from scratch
 * add an option to only allow diffs up to a fixed total size for
embedded systems (since the diffs are loaded into memory as a whole
before being applied)
 * add/update test suite?
 * fix up any code style issues
 * fix up rred method so it can be used directly from the command line
to merge and apply ed-diffs
 * work out where ed diffs get generated these days, and provide patch
to generate Patch-Step-Size header, and optionally use rred method to
update patches to make it a bit easier to download stuff

If anyone wants to poke around, please do!

Cheers,
aj

[0] https://lists.debian.org/deity/2009/08/msg00169.html
[1] https://lists.debian.org/debian-devel/2012/02/msg00411.html

-- 
Anthony Towns 


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

Re: Better pdiff handling for apt

2014-01-04 Thread Wookey 
+++ Anthony Towns [2014-01-04 20:40 +0800]:
> Salut tout le monde,
> 
> Some time ago (*cough* 2009), I had a play with working out how to
> apply pdiffs more efficiently than apt currently does, and implemented
> a proof of concept in python [0]. There weren't any replies (even a
> "ooo, cool") 

> Anyhoo... Like many, I've been getting annoyed at how tedious pdiff
> application is over the past year, so over Christmas I thought I'd
> have a go at patching apt to do things "properly". I've got it to the
> point where it works now, and apt-get update reports things like:
> 
>Fetched 199 MB in 50s (3919 kB/s)
> 
> over a 50kB/s link when updating testing+unstable for i386+amd64 for a
> day's worth of changes, rather than reporting 7000 B/s over a megabit
> link. 

ooo, cool  :-)

(that will improve all our lives greatly)

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/20140104131948.gp22...@stoneboat.aleph1.co.uk

Bug#734167: ITP: node-ansi-color-table -- Tables for console with ansi colors and formatting support - Node.js module

2014-01-04 Thread Jérémy Lal 
Package: wnpp
Severity: wishlist
Owner: "Jérémy Lal" 

* Package name: node-ansi-color-table
  Version : 0.0.3
  Upstream Author : Quim Calpe 
* URL : https://github.com/quimcalpe/ansi-color-table
* License : Expat
  Programming Lang: JavaScript
  Description : Color and format tables for ansi output - Node.js module

This module outputs borderless tables to stdout or to a writable stream,
with ansi colors and formatting support.
.
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/20140104140107.25733.37075.reportbug@imac.chaumes

Re: Fwd: Re: several SIGSEGV bugs in debian 7/AMD64

2014-01-04 Thread Wouter Verhelst 
Op 28-12-13 21:52, René Kuligowski schreef:
> Hi Adrian,
> 
> 
> Thanks for your quick answer,… but (sounds like a pouting little boy, I
> know):
> Sorry, but I cannot file a bug report against, say, nvidia-glx, because
> it is most likely not the cause.  The problem is far more likely kernel
> 3.x- and/or gcc-related, and I need somebody who knows more intimate
> workings of debian 7 before I can file a bug report to the correct
> topic/person:
> 
> –– newer BIOS for my machine does not exist.  Current/last is from
> 2009.  And, like I wrote, it works perfectly with debian 6 (kernel 2.6)
> or winXP/win7.  *without* *any* problems. And I don't exactly care if
> APM/ACPI standards have changed in the meantime.  Debian used to be
> backward-compatible to even twenty-years-old hardware and their specs.
>
> –– no capacitor or other hardware related issues.  Cannot be, also,
> because things would shred under debian 6 and winXP/win7, too, which
> they don't.  Things are a bit older, but tended well to.
>

That doesn't mean anything, sorry.

While "it works under another OS" is usually a good indicator that
hardware isn't at fault, in no way is it a _guarantee_ that it is not a
hardware issue.

Case in point: a while back I upgraded a server at a customer to wheezy.
Suddenly it started having random poweroffs. Eventually we found that
one of the two processor dies on the mainboard was bad, and that
replacing it fixed the issue.

Now, the reason it was still working on squeeze was that squeeze wasn't
using some particular power management features, which meant the
processor wouldn't reach a particular C-state which triggered the
(hardware) bug.

While I'm not saying this is definitely the case for you, it's certainly
possible. I do believe you if you say you're experiencing more
segfaults, but that doesn't mean it's a bug in wheezy. I, for one, am
*not* experiencing more segfaults in wheezy.

In order to figure out what exactly is wrong, you'll have to provide
more data. Bugs can't be debugged if we don't know what they are.

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

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

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


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

Re: Better pdiff handling for apt

2014-01-04 Thread Dimitri John Ledkov 
On 4 January 2014 12:40, Anthony Towns  wrote:
> Salut tout le monde,
>
> Some time ago (*cough* 2009), I had a play with working out how to
> apply pdiffs more efficiently than apt currently does, and implemented
> a proof of concept in python [0]. There weren't any replies (even a
> "ooo, cool") when I posted to the deity list, so I left it at that;
> though trolling google now, I see that it got mentioned on -devel [1]
> not all that long ago (*cough* 2012), so apparently it did get read
> after all. Not that it looks like it would've done much good, because
> it seems like the script I put on the web, and the one I was actually
> using are completely different to the extent that the one on the web
> even has syntax errors. WTF?
>
> Anyhoo... Like many, I've been getting annoyed at how tedious pdiff
> application is over the past year, so over Christmas I thought I'd
> have a go at patching apt to do things "properly". I've got it to the
> point where it works now, and apt-get update reports things like:
>
>Fetched 199 MB in 50s (3919 kB/s)
>

ooo, cool :-)

I thought that there was some kind of sprint (ftp-masters / dak /
buildd / or some such) which was meant to improve pdiff handling. And
I was waiting for that to happen =) Now i can't find/remember the
reference, and not sure now if that was about the client side
downloading/applying patches or server side pdiff generation.

-- 
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/CANBHLUiinB7=mxdryym-sm0m_rvyzjir7hegsarnvftqp6x...@mail.gmail.com

Re: [DEP 8] About "XS-Testsuite: autopkgtest": time to remove "XS-" ?

2014-01-04 Thread Guillem Jover 
On Fri, 2014-01-03 at 19:40:54 +0100, Jakub Wilk wrote:
> * Guillem Jover , 2014-01-03, 13:13:
> >Given that you (at least) seemed to show opposition to the field
> >(AFAIR), and that you've done an independent implementation of the
> >runner; does 692704 mean that you changed mind?
> 
> No, it just means that I gave up.

Oh, ok. :/ Personally I see it has similar drawbacks to the discarded
Build-Options field that some people wanted to use to list support for
build-arch/build-indep targets, the difference here is, that I can see
it also being useful so that autopkgtest implementations don't take over
the debian/tests/control pathname as the sole owners, and alternative
implementations could use that file with different deb822 contents, for
example.

So, I guess I'll just go ahead and add the two line patch needed to
recognize the field for 1.17.6; queued now locally for my next push.

Thanks,
Guillem


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140104154452.ga23...@gaara.hadrons.org

Re: GnuTLS in Debian

2014-01-04 Thread Wouter Verhelst 
Op 23-12-13 23:43, Clint Adams schreef:
> GPLv2-only folks should be made to see how their antisocial
> behavior is harming everyone.  I think this is a delightful
> situation for them to be in.

I am not a member of the church of GNU, nor do I wish to be. I respect
Richard Stallman (and his band of followers) for what he's accomplished
in jumpstarting the Free Software movement (and the Open Source movement
as an offshoot of that), but since I fundamentally do not agree with
everything the FSF proclaims, I do not trust them to *only* come up with
licenses that protect the rights that I think free software should
protect for its users. Therefore, while I don't mind contributing to a
piece of software that comes with an "or later" clause, I am not likely
to pick a license with an "or later" clause for anything I write myself.

This goes for GPLvX "or later", but also for other "or later" licenses,
where they exist.

I'm convinced that the GPLv2 is a free license, but I'm so far undecided
on the GPLv3 (mainly because I've not read the license text in much
detail myself yet since it's far too long and I just never had the time).

How is that in any way antisocial?

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

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

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



signature.asc
Description: OpenPGP digital signature

Re: Bug#733029: dpkg-buildpackage: disable signing by default (-us -uc should be the default)

2014-01-04 Thread Stefano Rivera 
Hi Jonathan (2014.01.02_19:22:33_+0200)
> >  * having to support remote signing
> 
> It would be fair enough to stderr "not supported, please use the older
> tool in devscripts" and error 1 if such an argument was provided. That
> would be pragmatic if (as I suspect) -r is rarely used.

Aww. I'm a frequent user of -r.
I have better places to build big packages than on my lap, and I prefer
to keep my GPG key in as few places as possible.

But of course, this could be replaced by a new remote signing wrapper.
And, if popular enough, end up in devscripts...

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140104175405.ga7...@bach.rivera.co.za

Re: Removing packages from unofficial repositories

2014-01-04 Thread Arthur de Jong 
On Thu, 2014-01-02 at 12:52 -0500, Simon Ruggier wrote:
> However, I would expect that most users would not have the patience to
> do this via apt preferences, and if there is an easier way, I was not
> aware of it.

I also did this a few times. I remove the third-party repositories from
sources.list, apt-get update and check the output of

apt-show-versions  | egrep -v '/(testing|unstable).*uptodate'

Not ideal, but it works.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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

Re: GnuTLS in Debian

2014-01-04 Thread Andreas Metzler 
Moritz Mühlenhoff  wrote:
> Andreas Metzler  schrieb:
>> #5 Declare GMP to be a system library.
> (..)

>> #5 was how Fedora looked at the OpenSSL library issue. Since Debian
>> has another viewpoint on OpenSSL I somehow doubt we would use it for
>> GMP.

> We should do that (and also reevaluate the position wrt OpenSSL) by
> running it by the Software Freedom Law Center. 

> Red Hat has real lawyers who looked into the issue, we should do the
> same.

Hello,

how do I continue from here?

#1 Do we have some process for talking to the Software Freedom Law
Center, or would I just send them a mail (perhaps after running a
draft through debian-legal).

#2 Is there any point in doing so? Other Mails in the thread show that
there is a non-negligible number of Debian developers who disagrees with
using the system library exception for GMP or OpenSSL.

cu Andreas
-- 
https://wiki.debian.org/gnutls3


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/0j0mpa-p5i@argenau.downhill.at.eu.org

Re: Better pdiff handling for apt

2014-01-04 Thread David Kalnischkies 

Hi,

I had a go on this topic as well in early december, but got "distracted"
which will be for a bit longer still, so just as a somewhat short reply:

On Sat, Jan 04, 2014 at 08:40:34PM +0800, Anthony Towns wrote:
> My patched apt source is up on github at:
>
>https://github.com/ajtowns/apt/tree/better-pdiffs

Looks like you did most of the other half of:
 https://github.com/DonKult/apt/commits/feature/clientmergepdiffs

which implements the proper acquiring of patches and such, but offloads
the actual merging to diffindex-rred (provided by apt-file).
It also keeps API compatibility and handles reprepro server-merged
patches: aka it can switch at will between server-merge [which is
currently assumed to be the case, but never done by dak so far] and
client-merge [which assumes a strict order of patches as it is done
by dak and so would be the better default if it isn't going to change,
which I heard before debconf would be done soon… but I might misheard].
A "wild" mixture of both requires indeed more info in the Index.

I had run some "benchmarks" back then:
(I don't like benchmarks, but anyway)
'normal' pdiff, client-side merged pdiffs and no pdiffs:

# apt-get update -o Acquire::PDiffs::Merge=0
Fetched 21.8 MB in 1min 6s (330 kB/s)

# apt-get update -o Acquire::PDiffs::Merge=1
Fetched 21.8 MB in 11s (1874 kB/s)

# apt-get update -o Acquire::PDiffs=0
Fetched 74.6 MB in 15s (4928 kB/s)

Disclaimer: this system has a strange mixture of everything to test some
extremes, but for us here it means: >10 indexes patchable by pdiff,
>200 pdiffs need to be applied to get up-to-date, http.debian.net as
mirror and an (observed) ~10 MB/s connection at my university (– remember
 that especially 'no pdiff' needs to do a lot of uncompress work, which
 slows down more than you would guess – as you see here).


So, I guess merging both could cross a lot of points of your list and
be relatively easily feed into unstable for proper field-testing.
(a upload of my part was planed as a christmas present to experimental,
 but as usual: If you want to make deity laugh, tell her your plans)


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: [RFH] !!SOS!! totally hosed init system

2014-01-04 Thread Thorsten Glaser 
On Fri, 3 Jan 2014, Roger Leigh wrote:

> If file-rc and/or the maintainer scripts somehow restored the links
> incorrectly, then insserv will ignore the header and preserve your
> customisations

Hm. I can’t remember *ever* doing *any* customisations.
I normally just put an “exit 0” below the shebang to disable
an init script as, back then, nobody knew what the right way
was (now we know update-rc.d is supposed to be used).

But then, I migrated to file-rc *extremely* early, so it’d
obviously not got “all” links in its backup.

> "insserv -d" should revert to the defaults.  And there's not usually
> any reason to deviate from them.

Hm, all it did for me was to emit all those warnings again.

> If not, you could remove the structure entirely and then try re-
> running "insserv -d" again.

Ah! So basically “rm -rf /etc/rc*.d” followed by “insserv -d”?
That may very well be the missing piece. I’ll try that on Monday
(not right now where I have only remote access), but thanks already.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-314
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Boris Esser, Sebastian Mancke


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/alpine.deb.2.10.1401042004180.7...@tglase.lan.tarent.de

Bug#734201: ITP: libbackpan-index-perl -- Perl interface to the BackPAN index

2014-01-04 Thread Stefan Hornburg (Racke) 
Package: wnpp
Owner: Stefan Hornburg (Racke) 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libbackpan-index-perl
  Version : 0.42
  Upstream Author : Michael G Schwern
* URL : https://metacpan.org/release/BackPAN::Index
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl interface to the BackPAN index

BackPAN::Index downloads, caches and parses the BackPAN index into a local 
database for efficient querying.

This is needed for libgit-cpan-patch-perl (ITP #733922).

Regards
  Racke

-- 
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52c860f0.7060...@linuxia.de

Re: [RFH] !!SOS!! totally hosed init system

2014-01-04 Thread Roger Leigh 
On Sat, Jan 04, 2014 at 08:07:08PM +0100, Thorsten Glaser wrote:
> On Fri, 3 Jan 2014, Roger Leigh wrote:
> 
> > If file-rc and/or the maintainer scripts somehow restored the links
> > incorrectly, then insserv will ignore the header and preserve your
> > customisations
> 
> Hm. I can’t remember *ever* doing *any* customisations.
> I normally just put an “exit 0” below the shebang to disable
> an init script as, back then, nobody knew what the right way
> was (now we know update-rc.d is supposed to be used).
> 
> But then, I migrated to file-rc *extremely* early, so it’d
> obviously not got “all” links in its backup.
> 
> > "insserv -d" should revert to the defaults.  And there's not usually
> > any reason to deviate from them.
> 
> Hm, all it did for me was to emit all those warnings again.
> 
> > If not, you could remove the structure entirely and then try re-
> > running "insserv -d" again.
> 
> Ah! So basically “rm -rf /etc/rc*.d” followed by “insserv -d”?
> That may very well be the missing piece. I’ll try that on Monday
> (not right now where I have only remote access), but thanks already.

It might be safer to do something like this:

rm /etc/rc?.d/S* /etc/rc?.d/K*
foreach script in $(ls -1 /etc/init.d | egrep -v "\.dpkg|README|skeleton")
do
  insserv -d "$script"
done

Maybe try that without the initial rm first for safety.


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/20140104200412.gi8...@codelibre.net

Re: Better pdiff handling for apt

2014-01-04 Thread Andrew Shadura 
Hello,

On Sat, 4 Jan 2014 20:40:34 +0800
Anthony Towns  wrote:

> Salut tout le monde,
> 
> Some time ago (*cough* 2009), I had a play with working out how to
> apply pdiffs more efficiently than apt currently does, and implemented
> a proof of concept in python [0]. There weren't any replies (even a
> "ooo, cool") when I posted to the deity list, so I left it at that;
> though trolling google now, I see that it got mentioned on -devel [1]
> not all that long ago (*cough* 2012), so apparently it did get read
> after all. Not that it looks like it would've done much good, because
> it seems like the script I put on the web, and the one I was actually
> using are completely different to the extent that the one on the web
> even has syntax errors. WTF?

ooo, cool  :-)

Having better pdiffs handling would really help!

P.S. Wait, what? Real Anthony J Towns? :)

-- 
Cheers,
  Andrew


signature.asc
Description: PGP signature

Re: Release sprint results - team changes, auto-rm and arch status

2014-01-04 Thread Steve Langasek 
On Tue, Dec 31, 2013 at 10:34:49AM +0100, Niels Thykier wrote:
> > You rightly point out that keeping the architectures in testing has a
> > cost, because the architectures will block testing migration.  But are
> > the kfreebsd archs actually causing testing blockages, in practice?  If
> > there are such blockages, can you give us more information about how
> > this has been the case?

> I have been seeing quite a few packages FTBFS on kFreeBSD being stuck in
> sid with fixes for RC bugs in testing.  Of course, this problem is by no
> means exclusive to kFreeBSD - other architectures (sometimes, even i386
> or amd64) also "features" on that list of blockers.
>   The only purely factual data I got currently, is the little snippet at
> the bottom of Britney's log.  I am not sure how reliable it is, so I'll
> refrain from using it as an argument.  But I think we (i.e. the
> distribution) could do with an accurate data source on this topic!

I agree, it would be nice to have solid data on this.

> On a related note, I suspect a good part of this problem would go away
> if we had an automated tool to deal with the case where a (sid-only)
> FTBFS is ignored.  It happens sometimes that the maintainer does nothing
> (or, maybe, does not realise the package FTBFS on arch X) and neither
> the porters nor the buildd admins filed a bug for it.
>   Then it is not until the package gets in way of a transition (or some
> other RC bug fix), that the package gets its RC bug.  I have seen a
> package stuck in sid for at least 90 days and still no RC bug - the
> "only" thing wrong was an "Out of date binaries" on some architecture
> (don't remember which package nor which architecture).

Historically, it was considered the porters' responsibilities to deal with
these packages that are failing to build in unstable.  Indeed, this was even
expressed in the release criteria at one time: a port is not releasable
unless it's x% up-to-date, because not being up-to-date for any reason
(buildds offline, porters not signing builds timely, toolchain or individual
packages regressing on one particular architecture) causes problems for
testing migration.

Maybe it's time to draw a new line on
https://buildd.debian.org/stats/graph2-week-big.png, corresponding to what's
actually needed for a port to be releasable?
-- 
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