Re: Binaryless uploads [Was: FTBFS: architecture all packages]
Chris Cheney <[EMAIL PROTECTED]> writes: > On Mon, Aug 18, 2003 at 02:21:55PM -0600, Joel Baker wrote: > > No, it is based on the assumption that a buildd will only install > > things listed in the Build-Depends, which means it will catch > > stuff that only builds on the maintainers workstation because they > > aren't building inside a chroot and are being sloppy - one of the > > main things they catch for binary-arch targets, today. > > This is (or was) not the case, buildds often have other things > installed on them other than build-essential. I have been bitten by > this in the past. Also, I have a build failure from the arm buildd > on Aug 21 (kdebase) that smells like it, it couldn't install > libcupsys2-dev which I bet is caused by gnome related packages being Then the -dev has to conflict with those. It also might be just a timeing poblem resulting in a momentary uninstability or just plain old apts stupidity not having a smart problem resolver. > installed on the buildd (#203059). Also, I have been told before > buildds in general have various other packages installed to save on > install time, however I don't know if this is actually true. >From my experience the buildd will start with a clean chroot and compile a bunch of packages in there. For each it adds the Build-depends before building and removes them after building (mostly?). After a certain number of runs the chroot is killed and setup again to prevent dirt from collecting. Mfg Goswin
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Mon, Aug 18, 2003 at 02:21:55PM -0600, Joel Baker wrote: > No, it is based on the assumption that a buildd will only install things > listed in the Build-Depends, which means it will catch stuff that only > builds on the maintainers workstation because they aren't building > inside a chroot and are being sloppy - one of the main things they catch > for binary-arch targets, today. This is (or was) not the case, buildds often have other things installed on them other than build-essential. I have been bitten by this in the past. Also, I have a build failure from the arm buildd on Aug 21 (kdebase) that smells like it, it couldn't install libcupsys2-dev which I bet is caused by gnome related packages being installed on the buildd (#203059). Also, I have been told before buildds in general have various other packages installed to save on install time, however I don't know if this is actually true. Chris Cheney pgp5prSRABZOD.pgp Description: PGP signature
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > On Wed, 20 Aug 2003, Goswin von Brederlow wrote: > > > "Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > > > > > On Wed, 20 Aug 2003, Goswin von Brederlow wrote: > > > > > > > The only problem with that is the current failure to comply to policy, > > > > i.e. build from source as they should. > > > > > > > > > > The question remains is simply removing all the extra source from > > > webmin-n.orig.tar.gz except that which is necessary to build the webmin > > > binary package (i.e not any of the modules which will have their own > > > source and binary packages) an aceptable solution to the problem or not? > > > > >From what I read in this thread webmin-n.orig.tar.gz also contains > > some non-free sources, right? > > > > It has source for all the modules including the non-free ones. However > the binary packages for those modules are built from seperate source > packages not this one. > > > Then you have no choice but split it up to get the rest into main. And > > when you don't have a pristine upstream orig.tar.gz you can split it > > up as far as you like or need to. > > > > The only reason for having the webmin.orig.tar.gz as it is was to provide > something approximating the upstream tarball. It sounds like I don't need > to bother about that. The only way you could is to have the source in non-free and you certainly don't want that. MfG Goswin
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Thu, Aug 21, 2003 at 05:20:42PM +1000, Brian May wrote: > As for the problem with the source file containing non-free code, > if you have prestine source code, this is something that > really needs to get fixed upstream :-(, eg. split into two > files. Looking at the other messages in the thread, webmin doesn't have prestine upstream source, so the above isn't relevant. I wonder now why a special build script is required at all, why not just treat each module as a totally seperate debian source package? -- Brian May <[EMAIL PROTECTED]>
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, Aug 20, 2003 at 10:04:40AM -0400, Jaldhar H. Vyas wrote: > Ok. Lets leave aside for a moment the .debs which would go into contrib > or non-free so would have to be built seperately. What happens if > webmin-squid has an RC bug? As Goswin said, all the webmin-* packages > will be held back from testing. What happens if webmin-squid is ok but > squid itself is not in testing? (or is removed from testing. This could > happen if it has an RC bug at freeze time,) Again all the webmin packages > would be affected. What if webmin-squid has one or two upstream bugfix > releases in between major webmin versions? Every other webmin module > would also have to be rebuilt too even though nothing changed. > > What you are suggesting was the way things were done before 0.98 and it > caused all sorts of annoyance for me and the users. I'll make any changes > necessary to be policy-compliant but I'm firm about the multiple-source > package thing. Ok, so when you said "split each module into a seperate binary package." What you really meant was: "split each module into a seperate source package." I gather this is because otherwise webmin would not get into testing unless each of its binary packages gets into testing, right? Is this still an issue? Having lots of source files makes it less convenient to rebuild for woody. I am not going to argue this, now I understand your reason. Is there any reason why webmin and webmin-core need to be seperate source packages? Regardless, it should still be possible to have a working debian/rules for each source package, this just represents a limitation in your current build script. Ideally the build script needs to update debian/rules for each package, or create a script that is called by debian/rules, or ... Lots of options are available here. As for the problem with the source file containing non-free code, if you have prestine source code, this is something that really needs to get fixed upstream :-(, eg. split into two files. -- Brian May <[EMAIL PROTECTED]>
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, 20 Aug 2003, Goswin von Brederlow wrote: > "Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > > > On Wed, 20 Aug 2003, Goswin von Brederlow wrote: > > > > > The only problem with that is the current failure to comply to policy, > > > i.e. build from source as they should. > > > > > > > The question remains is simply removing all the extra source from > > webmin-n.orig.tar.gz except that which is necessary to build the webmin > > binary package (i.e not any of the modules which will have their own > > source and binary packages) an aceptable solution to the problem or not? > > >From what I read in this thread webmin-n.orig.tar.gz also contains > some non-free sources, right? > It has source for all the modules including the non-free ones. However the binary packages for those modules are built from seperate source packages not this one. > Then you have no choice but split it up to get the rest into main. And > when you don't have a pristine upstream orig.tar.gz you can split it > up as far as you like or need to. > The only reason for having the webmin.orig.tar.gz as it is was to provide something approximating the upstream tarball. It sounds like I don't need to bother about that. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, 20 Aug 2003, Goswin von Brederlow wrote: > The only problem with that is the current failure to comply to policy, > i.e. build from source as they should. > The question remains is simply removing all the extra source from webmin-n.orig.tar.gz except that which is necessary to build the webmin binary package (i.e not any of the modules which will have their own source and binary packages) an aceptable solution to the problem or not? -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > On Wed, 20 Aug 2003, Goswin von Brederlow wrote: > > > The only problem with that is the current failure to comply to policy, > > i.e. build from source as they should. > > > > The question remains is simply removing all the extra source from > webmin-n.orig.tar.gz except that which is necessary to build the webmin > binary package (i.e not any of the modules which will have their own > source and binary packages) an aceptable solution to the problem or not? >From what I read in this thread webmin-n.orig.tar.gz also contains some non-free sources, right? Then you have no choice but split it up to get the rest into main. And when you don't have a pristine upstream orig.tar.gz you can split it up as far as you like or need to. MfG Goswin
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
"Jaldhar H. Vyas" <[EMAIL PROTECTED]> writes: > Ok. Lets leave aside for a moment the .debs which would go into contrib > or non-free so would have to be built seperately. What happens if > webmin-squid has an RC bug? As Goswin said, all the webmin-* packages > will be held back from testing. What happens if webmin-squid is ok but > squid itself is not in testing? (or is removed from testing. This could > happen if it has an RC bug at freeze time,) Again all the webmin packages > would be affected. What if webmin-squid has one or two upstream bugfix > releases in between major webmin versions? Every other webmin module > would also have to be rebuilt too even though nothing changed. > > What you are suggesting was the way things were done before 0.98 and it > caused all sorts of annoyance for me and the users. I'll make any changes > necessary to be policy-compliant but I'm firm about the multiple-source > package thing. The only problem with that is the current failure to comply to policy, i.e. build from source as they should. But now that you have seen the light :) keep on working. MfG Goswin
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Tue, 19 Aug 2003, Steve Langasek wrote: > Yep. And given that upstream offers webmin as an all-in-one solution to > web-based management needs, I don't really see any reason why they > shouldn't be kept lock-step with one another. As Debian developers our goal is to make an integrated OS which works according to our own internal logic. From that perspective some of the choices made by upstream maintainers are not optimal. For instance, one of the reasons all the webmin modules are distributed together is because there is no cross-platform dependency mechanism so the author doesn't know what you've got. So he just installs everything and its up to you to switch off the stuff you don't need. Thanks to dpkg, we don't need to do that. If e.g. I'm using postfix, there is absolutely no reason why I should need to have the webmin sendmail module installed. > I particularly don't see > why it's good that bugs in this group of packages themselves be ignored > for testing processing of the others. > > Does webmin even provide any standard APIs that guarantee particular > modules will work with particular versions of webmin? Version slip here > seems like it could pose a serious problem, even *beyond* the usual > partial upgrades question. > No guarantee is given but so far backward compatability has been pretty good fwiw. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, 20 Aug 2003, Brian May wrote: > When Jaldhar takes about dependancies, I assume he means normal > "Depends", not "Build-Depends"??? > Correct. [...] > Source package has the following files (note: this is called a "source > package" not a "binary package"): > > webmin_1.100.orig.tar.gz > webmin_1.100-2.diff.gz > webmin_1.100-2.dsc > > Extracting this source package and running debian/rules build would > produce the following *binary packages*: > > webmin_1.100-2_all.deb > webmin-core_1.100-2_all.deb > webmin-apache_.100-2_all.deb > webmin-squid_.100-2_all.deb > [...list truncated...] > > Jaldhar, please tell me what the problem is with the above approach. > Ok. Lets leave aside for a moment the .debs which would go into contrib or non-free so would have to be built seperately. What happens if webmin-squid has an RC bug? As Goswin said, all the webmin-* packages will be held back from testing. What happens if webmin-squid is ok but squid itself is not in testing? (or is removed from testing. This could happen if it has an RC bug at freeze time,) Again all the webmin packages would be affected. What if webmin-squid has one or two upstream bugfix releases in between major webmin versions? Every other webmin module would also have to be rebuilt too even though nothing changed. What you are suggesting was the way things were done before 0.98 and it caused all sorts of annoyance for me and the users. I'll make any changes necessary to be policy-compliant but I'm firm about the multiple-source package thing. -- Jaldhar H. Vyas <[EMAIL PROTECTED]> La Salle Debain - http://www.braincells.com/debian/
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Tue, Aug 19, 2003 at 09:16:03AM +0100, Andrew Suffield wrote: > On Mon, Aug 18, 2003 at 10:38:10PM -0600, Joel Baker wrote: > > > > If they get hit by a bus, reassigned by their job to Outer Mongolia, or > > just plain get bored with doing it, we lose that benefit entirely, as > > things stand today. I'm proposing that the function appears to be producing > > clear benefits, and that we should, in fact, adjust our expectations so > > that we retain those benefits in a more direct fashion. > > No, you are proposing something else entirely: that we require > somebody like this to upload the binary-indep components before the > packages enter testing. Just like the current system, which requires that uploads be made for all architectures that previously appeared, yes. Funny that. > > No, in fact, it doesn't. Which is the crux of the question. > > Argument by repeated assertion. Back at you. Which would imply that the entire issue can be resolved by demonstrating which of the two assertions is, in fact, correct. > > Are you attempting to suggest that the buildd arrangement uploads broken > > packages more often than maintainers do? > > Probably about as frequently. Okay; we're clear on that assertion, then. > > No, you can't. Or rather, you can swap it, and the wording is equally > > parseable - but no longer accurate. See above. > > And again. Which reduces to the same question. Fine. > > > Note that it is much _more_ important for a maintainer workstation > > > (where all the actually important stuff happens) to be working than it > > > is for a buildd (which is largely automated, and thusly can be easily > > > duplicated, replaced, or re-done). > > > > Where a failed workstation means someone else can build it, upload it, > > do an NMU; hell, you could even use the Debian machine farm (unless > > the workstation is your only access at all, which is quite a different > > question). > > Oh hey, just the same as a failed buildd, then. > > Except that one of these things is easy, and one is not. Agreed, but probably not in the way that you think. I'm going to assert that keeping things sane on a few dozen machines (the buildds) is easier than keeping them sane on 1000+ (assuming each developer has at least one machine to develop on; I have 3, myself). I suspect that's not the assertion you're trying to make, but it comes down, again, to a question of which assertion is *correct*. > > If you're going to assert that the buildds are breaking packages, please > > provide some backing to the assertion; showing that maintainers break > > packages is a trivial excercise in reading the BTS. > > So is showing that buildds break packages. Although a number of those > issues don't go through the BTS. They're probably about as reliable as > some random maintainer workstation - which makes sense, why should > they be any better? Because they have folks who spend a lot of time trying to ensure that they *are* better, for one; for another, the design of the buildd setup guarantees that, barring a very significant bug, it *will* catch one of the primary forms of maintainer error, which was the origional point - that fewer packages would be broken *because of* going through a buildd than would be caught as broken by going through a buildd. But let us take one concrete example: webmin. Which, as the bug filed and the conversation on the list should indicate, would probably have been caught by the proposed change. Feel free to document at least one case of a situation where a buildd would have caused an otherwise-proper upload to become a bad upload, by replacing the maintainer's binary-indep results with those from the buildd. -- Joel Baker <[EMAIL PROTECTED]>,''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpOLt8j905pR.pgp Description: PGP signature
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, Aug 20, 2003 at 12:20:37AM +0200, Goswin von Brederlow wrote: > Brian May <[EMAIL PROTECTED]> writes: > > > Source package has the following files (note: this is called a "source > > package" not a "binary package"): > > > > webmin_1.100.orig.tar.gz > > webmin_1.100-2.diff.gz > > webmin_1.100-2.dsc > > > > Extracting this source package and running debian/rules build would > > produce the following *binary packages*: > > > > webmin_1.100-2_all.deb > > webmin-core_1.100-2_all.deb > > webmin-apache_.100-2_all.deb > > webmin-squid_.100-2_all.deb > > [...list truncated...] > > > > Jaldhar, please tell me what the problem is with the above approach. > > > > You will notice that there is only one source package, but multiple > > binary packages. > Say webmin-squid now has a RC bug, that would keep all webin debs out > of testing, right? Yep. And given that upstream offers webmin as an all-in-one solution to web-based management needs, I don't really see any reason why they shouldn't be kept lock-step with one another. I particularly don't see why it's good that bugs in this group of packages themselves be ignored for testing processing of the others. Does webmin even provide any standard APIs that guarantee particular modules will work with particular versions of webmin? Version slip here seems like it could pose a serious problem, even *beyond* the usual partial upgrades question. > PS: If that is your problem write better code. :) Very... -- Steve Langasek postmodern programmer pgpyH15POXUZP.pgp Description: PGP signature
Re: Binaryless uploads [Was: FTBFS: architecture all packages]
On Wed, 20 Aug 2003, Brian May wrote: > Effectively Jaldhar just needs to merge the source packages together, > and keep the binary packages split. > > However, Jaldhar continues to respond with "we need the binary packages > split.". /me mutters chewbacca under his breath.
