arch all node modules should not build-depend nodejs (was Re: Bad weather in testing? on -devel)
Le vendredi 14 novembre 2014 à 07:03 +0800, Paul Wise a écrit : > On Fri, Nov 14, 2014 at 6:19 AM, Jérémy Lal wrote: > > Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit : > >> On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: > >> > >> > As a workaround, this is the reason why arch:all nodejs modules have a > >> > build-dependency on nodejs - it prevents them to be available on arches > >> > where nodejs isn't. > >> > >> I think you meant dependency, a build-dependency would not achieve that. > > > > Ha damn, i never got this right, then what's the correct approach for > > solving > > https://bugs.debian.org/725363 > > ? > > That appears to be an arch:any package not an arch:all one so your > current Build-Depends/Depends workaround is correct. Checking the > packages with debbindiff --html, I see that the .debs are identical > between architectures, except for the architecture name and the > timestamps, so it should be arch:all instead. > > The rest of this post is about arch:all node-* packages only... > > The "correct" approach would be to fix the portability issues in > nodejs but looking at the buildd page I see this is mostly caused by > libv8 and I guess Google doesn't care much about browser portability > so this is unlikely to get fixed. > > An easy workaround if that isn't possible is to make every node-* > package arch any and Build-Depend on nodejs, this is what happened > this with node-xmlhttprequest but personally I would not recommend it. > > A more socially responsible workaround would be to patch > dak/reprepro/etc so that some arch:all packages are not present in the > Packages files on some architectures. This could be a hard problem, > especially when you consider that all node-* arch:all packages should > become available on platforms where nodejs is newly ported to (for > example ppc64el is probably going to be a popular cloud platform at > some point). Another fix to dak/dpkg we need in this is something like > linux-all, for example iotop is written in Python but only supports > the I/O monitoring interfaces of the Linux kernel, so the architecture > restriction cannot be expressed by Depends. > > Personally I would just use arch:all for node-* packages, drop the > Build-Depends: nodejs (since it is false AFAIK), keep the Depends: > nodejs and otherwise ignore the issue, it doesn't cause much of a > problem IMO. That makes sense to me, cc-ing this clear explanation to pkg-javascript-devel, thank you. Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415920941.25276.9.ca...@melix.org
Re: Bad weather in testing?
On Fri, Nov 14, 2014 at 6:19 AM, Jérémy Lal wrote: > Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit : >> On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: >> >> > As a workaround, this is the reason why arch:all nodejs modules have a >> > build-dependency on nodejs - it prevents them to be available on arches >> > where nodejs isn't. >> >> I think you meant dependency, a build-dependency would not achieve that. > > Ha damn, i never got this right, then what's the correct approach for > solving > https://bugs.debian.org/725363 > ? That appears to be an arch:any package not an arch:all one so your current Build-Depends/Depends workaround is correct. Checking the packages with debbindiff --html, I see that the .debs are identical between architectures, except for the architecture name and the timestamps, so it should be arch:all instead. The rest of this post is about arch:all node-* packages only... The "correct" approach would be to fix the portability issues in nodejs but looking at the buildd page I see this is mostly caused by libv8 and I guess Google doesn't care much about browser portability so this is unlikely to get fixed. An easy workaround if that isn't possible is to make every node-* package arch any and Build-Depend on nodejs, this is what happened this with node-xmlhttprequest but personally I would not recommend it. A more socially responsible workaround would be to patch dak/reprepro/etc so that some arch:all packages are not present in the Packages files on some architectures. This could be a hard problem, especially when you consider that all node-* arch:all packages should become available on platforms where nodejs is newly ported to (for example ppc64el is probably going to be a popular cloud platform at some point). Another fix to dak/dpkg we need in this is something like linux-all, for example iotop is written in Python but only supports the I/O monitoring interfaces of the Linux kernel, so the architecture restriction cannot be expressed by Depends. Personally I would just use arch:all for node-* packages, drop the Build-Depends: nodejs (since it is false AFAIK), keep the Depends: nodejs and otherwise ignore the issue, it doesn't cause much of a problem IMO. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6edztf-c9qxpf6cswd4gyvqfajwfxr_f1gqo6beuov...@mail.gmail.com
Re: Bad weather in testing?
Le jeudi 13 novembre 2014 à 19:23 +0800, Paul Wise a écrit : > On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: > > > As a workaround, this is the reason why arch:all nodejs modules have a > > build-dependency on nodejs - it prevents them to be available on arches > > where nodejs isn't. > > I think you meant dependency, a build-dependency would not achieve that. Ha damn, i never got this right, then what's the correct approach for solving https://bugs.debian.org/725363 ? Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415917157.25276.7.ca...@melix.org
Re: Bad weather in testing?
On Thu, Nov 13, 2014 at 6:26 PM, Jérémy Lal wrote: > As a workaround, this is the reason why arch:all nodejs modules have a > build-dependency on nodejs - it prevents them to be available on arches > where nodejs isn't. I think you meant dependency, a build-dependency would not achieve that. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6gfhc09nqwwei45kropwafxbnm3kxg9h6jnqefws_n...@mail.gmail.com
Re: Bad weather in testing?
Le mercredi 12 novembre 2014 à 18:42 +0800, Paul Wise a écrit : > On Wed, Nov 12, 2014 at 6:34 PM, Thorsten Glaser wrote: > > > This is a bug, I’ve seen this affect buildd dependency resolution, > > and anyway, if it’s not installable everywhere, why is it arch:all? > > I would guess that uninstallable arch:all things happens when they > depend on non-portable things. For example pixbros/pixfrogger depend > on fenix. Indeed. As a workaround, this is the reason why arch:all nodejs modules have a build-dependency on nodejs - it prevents them to be available on arches where nodejs isn't. Jérémy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1415874379.10001.4.ca...@melix.org
Re: Bad weather in testing?
On Wed, Nov 12, 2014 at 6:34 PM, Thorsten Glaser wrote: > This is a bug, I’ve seen this affect buildd dependency resolution, > and anyway, if it’s not installable everywhere, why is it arch:all? I would guess that uninstallable arch:all things happens when they depend on non-portable things. For example pixbros/pixfrogger depend on fenix. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caktje6eue70ozrmhk9v5ohy84uuavdnw4ij9qrtfcyx279f...@mail.gmail.com
Re: Bad weather in testing?
On Fri, 7 Nov 2014, Ralf Treinen wrote: > architecture-specific. 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 available on every > architecture. This is a bug, I’ve seen this affect buildd dependency resolution, and anyway, if it’s not installable everywhere, why is it arch:all? bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1411121134010.9...@tglase.lan.tarent.de
Re: Bad weather in testing ?
On 09/11/14 08:38, Ralf Treinen wrote: > On Fri, Nov 07, 2014 at 06:11:45PM +, Simon McVittie wrote: >> On 07/11/14 16:15, Ralf Treinen wrote: >>> There is only one package in the "each" category, and this is a false >>> positive due to multiarch: lib32nss-mdns, which exists only on amd64 >>> (this is why it shows up in the each category) and depends on an i386 >>> package, which is deliberate in this case. >> >> That's a transitional hack [...] >> (I'm surprised the wine* family of packages don't get similar results >> though - that's where I stole the idea from.) > > can you be more specific? Why do you think that there may be an issue with > the wine packages? I thought I remembered that wine:amd64 depended on wine32 which is only available on i386, but in fact it depends on wine64|wine32, so QA tools are happy with the situation. It seems a little odd that wine64 would be the preferred dependency, since I would guess that most users of Wine are still more interested in running 32-bit Windows software (I've certainly never wanted to run Win64 stuff), but presumably the Wine maintainers have done the research and determined that upgrades from wheezy behave acceptably. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5460994c.7020...@debian.org
Re: Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)
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 available on every > > architecture. > > The issue would become a non-issue if the "end user tools" (eg apt) would not > show such packages as available, or? Right. But what would be a good way to achieve this? One possible way is to remove non-installable packages from the Packages file, by having dak run dose-debcheck. However, I do not think that we want to do this for sid, and even for a stable release we have to be careful since there may be legitimate cases where we want to include a package that is found to be non-installable. How does the release team feel about this? Having apt run dose-debcheck to filter out the non-installable packages is not an option IMHO as it takes about 20-30 seconds to run on a desktop machine. -Ralf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109095016.gc10...@seneca.home.org
Re: Bad weather in testing ?
On Fri, Nov 07, 2014 at 06:11:45PM +, Simon McVittie wrote: > On 07/11/14 16:15, Ralf Treinen wrote: > > There is only one package in the "each" category, and this is a false > > positive due to multiarch: lib32nss-mdns, which exists only on amd64 > > (this is why it shows up in the each category) and depends on an i386 > > package, which is deliberate in this case. > > That's a transitional hack, and I intend to get rid of it in jessie+1. I > think it's OK that QA tools complain about it. > > (I'm surprised the wine* family of packages don't get similar results > though - that's where I stole the idea from.) can you be more specific? Why do you think that there may be an issue with the wine packages? -Ralf. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141109083802.gb10...@seneca.home.org
Re: Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)
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 these), one has to look at the figures. > "Storm" is indicated for the "some" category, that is packages that are > not installable on *some* architecture. There are 1449 of these, but > 1440 of them are architecture=all, and only 9 of them are > architecture-specific. well, I was surprised to uninstallable packages in testing at all, I was of the (foolish) impression that the testing migration scripts made sure this would not happen at all. Now I've remembered all the force being used to beat testing in shape and that we are not there yet.. ;-) > 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 available on every > architecture. The issue would become a non-issue if the "end user tools" (eg apt) would not show such packages as available, or? cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Bad weather in testing ?
On 07/11/14 16:15, Ralf Treinen wrote: > There is only one package in the "each" category, and this is a false > positive due to multiarch: lib32nss-mdns, which exists only on amd64 > (this is why it shows up in the each category) and depends on an i386 > package, which is deliberate in this case. That's a transitional hack, and I intend to get rid of it in jessie+1. I think it's OK that QA tools complain about it. (I'm surprised the wine* family of packages don't get similar results though - that's where I stole the idea from.) s -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/545d0b61.7020...@debian.org
Bad weather in testing ? (was: Re: inconsistent versions of M-A: same packages)
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" > > 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 anything for the outdated and file-overwrite checks so I didnt > check again. > > 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 these), one has to look at the figures. "Storm" is indicated for the "some" category, that is packages that are not installable on *some* architecture. There are 1449 of these, but 1440 of them are architecture=all, and only 9 of them are architecture-specific. 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 available on every architecture. There is only one package in the "each" category, and this is a false positive due to multiarch: lib32nss-mdns, which exists only on amd64 (this is why it shows up in the each category) and depends on an i386 package, which is deliberate in this case. -Ralf. -- Ralf Treinen Laboratoire Preuves, Programmes et Systèmes Université Paris Diderot, Paris, France. http://www.pps.univ-paris-diderot.fr/~treinen/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141107161504.ge9...@vanadium.pps.jussieu.fr
