Re: inconsistent versions of M-A: same packages

2014-11-12 Thread Thorsten Glaser
On Sat, 8 Nov 2014, Stuart Prescott wrote: UDD can help with this. A list of source packages that have M-A: same binary packages in jessie that have different versions in any two release architectures is at: Can we do this for the triplet (i386, amd64, x32) too, please? Yes, it’s not a

Re: inconsistent versions of M-A: same packages

2014-11-10 Thread Guillem Jover
Hi! On Sun, 2014-11-09 at 17:18:10 +0100, Johannes Schauer wrote: Quoting Ralf Treinen (2014-11-09 15:58:15) Interesting, I did not know this. Is this documented somewhere? I just looked through apt-get(1) man page and couldn't find it there. it should definitely be documented in

Re: Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)

2014-11-09 Thread Ralf Treinen
On Sat, Nov 08, 2014 at 12:39:41PM +, Holger Levsen wrote: Hi Ralf, On Freitag, 7. November 2014, Ralf Treinen wrote: The issue of architecture=all packages that are not installable on some architecture can IMHO not be solved with our current setup which makes architectures=all

Re: inconsistent versions of M-A: same packages

2014-11-09 Thread Johannes Schauer
Hi, Quoting Ralf Treinen (2014-11-09 15:58:15) On Sat, Nov 08, 2014 at 06:41:24AM +0100, Johannes Schauer wrote: Dpkg and apt allow this just fine. Try to do: apt-get install --simulate gcc-4.9-arm-linux-gnueabihf And you will end up with a number of armhf packages on your system

Re: inconsistent versions of M-A: same packages

2014-11-09 Thread Ralf Treinen
On Sun, Nov 09, 2014 at 05:18:10PM +0100, Johannes Schauer wrote: Ah okay! Somehow I misunderstood your initial email that you wanted to say: Depends: foo:i386, foo:amd64, ..., bar:i386, bar:amd64,... But instead you just want... Depends: foo:i386, foo:amd64, ... ...in

Re: inconsistent versions of M-A: same packages

2014-11-09 Thread Johannes Schauer
Hi, Quoting Ralf Treinen (2014-11-09 18:05:15) But this does only one co-installability check at a time, right ? correct, this makes your solution the better choice. Anyway, the script is very simple (attached). Nifty! I didn't know that dose-debcheck can read from stdin! The raw result of

Re: inconsistent versions of M-A: same packages

2014-11-09 Thread Wookey
+++ Marc Glisse [2014-11-01 11:45 +0100]: A few random packages that currently have an inconsistent version: zlib1g (+b1 on ppc64el) examining this I notice that whilst this page on p.d.o: https://packages.debian.org/jessie/zlib1g shows the issue, and so does this buildd one (for unstable):

Re: inconsistent versions of M-A: same packages

2014-11-09 Thread Wookey
+++ Wookey [2014-11-01 14:19 +]: +++ Marc Glisse [2014-11-01 11:45 +0100]: Hello, sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same packages that have inconsistent version numbers across architectures before releasing Jessie? I am

Re: inconsistent versions of M-A: same packages

2014-11-08 Thread Ralf Jung
Hi, Dpkg and apt allow this just fine. Try to do: apt-get install --simulate gcc-4.9-arm-linux-gnueabihf And you will end up with a number of armhf packages on your system (you have to enable armhf beforehand of course). Interesting, I didn't know that syntax is already supported. As

jenkins-triggers (Re: inconsistent versions of M-A: same packages

2014-11-08 Thread Holger Levsen
Hi, On Freitag, 7. November 2014, Johannes Schauer wrote: is jenkins not triggered by pushes to git and thus sub-optimal for jobs that should be run like a cron job? jenkins can be triggered by many things, currently jobs on jenkins.d.n are triggered - time based - VCS commit based - after

UDD querying jobs on jenkins.d.n (was Re: inconsistent versions of M-A: same packages

2014-11-08 Thread Holger Levsen
Hi, On Samstag, 8. November 2014, Stuart Prescott wrote: UDD can help with this. of course! :-) A list of source packages that have M-A: same binary packages in jessie that have different versions in any two release architectures is at: http://debian.nanonanonano.net/qa/maskew

Re: Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)

2014-11-08 Thread Holger Levsen
Hi Ralf, On Freitag, 7. November 2014, Ralf Treinen wrote: The bad weather in https://qa.debian.org/dose/debcheck/testing_main/index.html is still surprising to see, at this point... not at all ! The weather icons are a bit misleading (this is one reason why I wasn't such a big fan of

Re: UDD querying jobs on jenkins.d.n (was Re: inconsistent versions of M-A: same packages

2014-11-08 Thread Holger Levsen
Hi, On Samstag, 8. November 2014, Holger Levsen wrote: It would be trivial to turn this into a jenkins jobs, shall I? It seems to me, there could be several other UDD querying jobs as well, so my first suggestion for a name (+namespace) would be udd_multiarch_inconsistencies... suggestions

Re: UDD querying jobs on jenkins.d.n (was Re: inconsistent versions of M-A: same packages

2014-11-08 Thread Michael Tautschnig
Hi Holger, On Sat, Nov 08, 2014 at 15:12:42 +, Holger Levsen wrote: Hi, On Samstag, 8. November 2014, Holger Levsen wrote: It would be trivial to turn this into a jenkins jobs, shall I? It seems to me, there could be several other UDD querying jobs as well, so my first suggestion

Re: UDD querying jobs on jenkins.d.n (was Re: inconsistent versions of M-A: same packages

2014-11-08 Thread Holger Levsen
Hi Michael, On Samstag, 8. November 2014, Michael Tautschnig wrote: Have you considered running a groovy script instead of an external shell script? This may make things easier not really, as I'm not at all groovy with groovy, IOW, I hardly know what it is :) /avoid the external script

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Holger Levsen
Hi Ralf, On Mittwoch, 5. November 2014, Ralf Treinen wrote: yes, you did miss something :-) first link on the page: Non-installable packages https://qa.debian.org/dose/debcheck/unstable_main/index.html thanks! (+doh, I guessed I oversaw these links on the debcheck pages and then didnt find

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Johannes Schauer
Hi Holger, Quoting Holger Levsen (2014-11-07 15:46:31) On Mittwoch, 5. November 2014, Ralf Treinen wrote: yes, you did miss something :-) first link on the page: Non-installable packages https://qa.debian.org/dose/debcheck/unstable_main/index.html thanks! (+doh, I guessed I oversaw

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Holger Levsen
Hi Johannes, On Freitag, 7. November 2014, Johannes Schauer wrote: but was your original question not about debcheck checking for multiarch co-installability across architectures? yes, this was just a btw-question on the side... I agree with Ralf, that this would best be done not by

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Johannes Schauer
Hi Holger, Quoting Holger Levsen (2014-11-07 16:31:09) I agree with Ralf, that this would best be done not by debcheck but by a small script which compares if the Packages files for all distributions ship M-A:same packages in the same version. I'd happily run this script on

Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)

2014-11-07 Thread Ralf Treinen
Hi Holger, (repliying separately to the two pointes raised by you) On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote: On Mittwoch, 5. November 2014, Ralf Treinen wrote: yes, you did miss something :-) first link on the page: Non-installable packages

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Ralf Treinen
On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote: 2) if you ask about co-installablity of packages with the same name but different architectictures (and which are M-A=same) : this is a completely different (and much more interesting) question. Since dose is now multi-arch

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Wookey
+++ Ralf Treinen [2014-11-07 17:35 +0100]: On Fri, Nov 07, 2014 at 02:46:31PM +, Holger Levsen wrote: For this reason we should probably limit ourselves to all the interesting cases of combinations of native and foreign architectures. The only reasonable combination that I can currently

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Stuart Prescott
UDD can help with this. A list of source packages that have M-A: same binary packages in jessie that have different versions in any two release architectures is at: http://debian.nanonanonano.net/qa/maskew There are currently 247 source packages in that list (assuming I've not done

Re: inconsistent versions of M-A: same packages

2014-11-07 Thread Johannes Schauer
Hi, Quoting Ralf Treinen (2014-11-07 17:35:06) It just appeared to me that we probably do not have a syntax to pinpoint a package built for a specific architecture. We meaning in this case dpkg, apt, and dose (if I am not mistaken). No. We do have it. The usual trick in dose would be, for

Re: inconsistent versions of M-A: same packages

2014-11-05 Thread Holger Levsen
Hi, indeed I forgot about multiarch... and I ment that non-installibility is a bug for sure (though just a sympton of the real bug), but often packages can still be installed even though the versions of a package differs due to binNMUs. Andway - more to the point: (leaving full context for

Re: inconsistent versions of M-A: same packages

2014-11-05 Thread Ralf Treinen
Hi, On Wed, Nov 05, 2014 at 04:22:06PM +0100, Holger Levsen wrote: (also, btw, I couldn't find the daily DOSE runs linked from tttps://qa.debian.org/dose - did I miss it or is it missing?) yes, you did miss something :-) first link on the page: Non-installable packages then you choose

inconsistent versions of M-A: same packages

2014-11-01 Thread Marc Glisse
Hello, sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same packages that have inconsistent version numbers across architectures before releasing Jessie? I understand that in testing or unstable, rebuilding for all platforms every time a single one

Re: inconsistent versions of M-A: same packages

2014-11-01 Thread Holger Levsen
Hi Marc, On Samstag, 1. November 2014, Marc Glisse wrote: sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same packages that have inconsistent version numbers across architectures before releasing Jessie? [...] A few random packages that currently

Re: inconsistent versions of M-A: same packages

2014-11-01 Thread The Wanderer
On 11/01/2014 at 07:38 AM, Holger Levsen wrote: Hi Marc, On Samstag, 1. November 2014, Marc Glisse wrote: sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same packages that have inconsistent version numbers across architectures before releasing

Re: inconsistent versions of M-A: same packages

2014-11-01 Thread Marc Glisse
On Sat, 1 Nov 2014, Holger Levsen wrote: Hi Marc, On Samstag, 1. November 2014, Marc Glisse wrote: sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same packages that have inconsistent version numbers across architectures before releasing Jessie?

Re: inconsistent versions of M-A: same packages

2014-11-01 Thread Guillem Jover
Hi! On Sat, 2014-11-01 at 11:45:56 +0100, Marc Glisse wrote: sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same packages that have inconsistent version numbers across architectures before releasing Jessie? That's something for the release-team and

Re: inconsistent versions of M-A: same packages

2014-11-01 Thread Wookey
+++ Marc Glisse [2014-11-01 11:45 +0100]: Hello, sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same packages that have inconsistent version numbers across architectures before releasing Jessie? I don't know, but I think there should be. Thank you

Re: inconsistent versions of M-A: same packages

2014-11-01 Thread Julien Cristau
On Sat, Nov 1, 2014 at 13:17:11 +0100, Guillem Jover wrote: [ Fixed CC and M-F-T addresses, and bounced to debian-release. ] Hi! On Sat, 2014-11-01 at 11:45:56 +0100, Marc Glisse wrote: sorry for the naive question, but is there a plan for massively rebuilding all Multi-Arch: same