Re: Secret changes for binNMUs
Roger Leigh [EMAIL PROTECTED] writes: This is very true. I wasn't aware of the SVN repository until it was mentioned in this thread. Over the weekend, I have merged almost all the SVN changes: Many thanks for the work. It is greatly appreciated. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Andreas Metzler [EMAIL PROTECTED] writes:
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Sat, 26 Nov 2005, Andreas Metzler wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
[...]
Meanwhile, I am using this: unversioned depends and two conflicts: (
{Upstream-Version}), (= {Upstream-Version}.1).
Depends: foo (={Upstream-Version}), foo ( {Upstream-Version}.1)
instead should also work without the need for a cumbersome conflict.
Yes. It is just a matter of which one you like better.
[...]
Afaiui the different possibilties are not equivalent, because
conflicts need to be satisfied before installation, depends only at
configuration (after unpacking, ...).
Quoting policy:
| A Conflicts entry should almost never have an earlier than version
| clause. This would prevent dpkg from upgrading or installing the
| package which declared such a conflict until the upgrade or removal of
| the conflicted-with package had been completed.
cu andreas
A conflicts is also not checked when other packages are upgraded
(downgraded). In practice that means that one can install the
conflicting old version when downgrading without also downgrading the
conflicting package. With depends dpkg fill error about it.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wouter Verhelst [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: Last year the aim was to get the buildd sbuild and debian sbuild back in sync and it pains me to see Ryan silently diferting it further and further instead of aiding that goal. That's one way to look at it. The other way would be to say that Ryan has recently been actively working on improving the code in the wanna-build SVN, and that the people maintaining the sbuild package in Debian (Roger?) haven't been paying too much attention to their upstream, likely because they didn't see the link on buildd.debian.org--a link which I, admittedly, had missed out on at first too, because it used to point to cvs.linux-m68k.org. There is indeed still a wanna-build CVS repository over there, but it's been effectively unmaintained for as long as I can remember. This is very true. I wasn't aware of the SVN repository until it was mentioned in this thread. Over the weekend, I have merged almost all the SVN changes: http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/sbuild/sbuild?cvsroot=buildd-tools http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2005-November/000388.html As you mentioned, due to cvs.linux-m68k.org being unmaintained for years, the code in the Debian package (maintained by Rick Younie, now group maintained by Francesco Paolo Lovergine, Michael Banck and I), and the code used by the buildds has diverged over the years. Even after the above merge the diff is still around 1000 lines, which I hope we can reduce much further if we can merge the changes both ways to reduce the differences as much as possible. Perl being Perl, so far all the merging has been by hand, and going through the remaining huge diff by hand will take some time. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDi48wVcFcaSW/uEgRAgf2AJ9OeKLykTblYCu9nhVatvBm2lRfeQCgsrpM D6zpcMr6kY7X+WetUgTjo1Q= =Rv3N -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
[...]
Meanwhile, I am using this: unversioned depends and two conflicts: (
{Upstream-Version}), (= {Upstream-Version}.1).
Depends: foo (={Upstream-Version}), foo ( {Upstream-Version}.1)
instead should also work without the need for a cumbersome conflict.
cu andreas
PS: I've spent no thought whether {Upstream-Version}.1 is really
correct, it depends a lot on the versioning upstream chooses.
--
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Sat, 26 Nov 2005, Andreas Metzler wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
[...]
Meanwhile, I am using this: unversioned depends and two conflicts: (
{Upstream-Version}), (= {Upstream-Version}.1).
Depends: foo (={Upstream-Version}), foo ( {Upstream-Version}.1)
instead should also work without the need for a cumbersome conflict.
Yes. It is just a matter of which one you like better. You could also have
one depends and one conflicts instead of two conflicts or two depends.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
* Henrique de Moraes Holschuh [Sat, 26 Nov 2005 08:42:41 -0200]: Yes. It is just a matter of which one you like better. You could also have one depends and one conflicts instead of two conflicts or two depends. Versioned conflicts are said to increase apt's trouble to upgrade from one stable release to the next one. I have never heard the same comment applied to Depends: ( V) relationshipts. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Y sobre todo, tienes mucho de gilipollas. -- B.C.S. addressing P.G.i.Q in b8g -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
On Sat, 26 Nov 2005, Andreas Metzler wrote:
Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote:
[...]
Meanwhile, I am using this: unversioned depends and two conflicts: (
{Upstream-Version}), (= {Upstream-Version}.1).
Depends: foo (={Upstream-Version}), foo ( {Upstream-Version}.1)
instead should also work without the need for a cumbersome conflict.
Yes. It is just a matter of which one you like better.
[...]
Afaiui the different possibilties are not equivalent, because
conflicts need to be satisfied before installation, depends only at
configuration (after unpacking, ...).
Quoting policy:
| A Conflicts entry should almost never have an earlier than version
| clause. This would prevent dpkg from upgrading or installing the
| package which declared such a conflict until the upgrade or removal of
| the conflicted-with package had been completed.
cu andreas
--
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Hi, Henrique de Moraes Holschuh schrieb: We really need another substvar with different semantics. http://lists.debian.org/debian-devel/2002/09/msg01251.html Simon signature.asc Description: OpenPGP digital signature
Re: Secret changes for binNMUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Banck [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 11:02:36AM +, Roger Leigh wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Which sbuild CVS repo? It is a SVN repo now, the one used by the buildd infrastructure. Thanks, I'm going through the changes now. BTW, are there any good reasons why the autobuilders don't use the packaged version anywat? The differences are minimal. Last time I looked the changes seemed to be pretty big, but merging is of course a mid-term goal. I started merging the changes tonight, and I'll try to get through some more tomorrow. Some of the changes appear to be dysfunctional, so I'm testing as I go along. http://cvs.alioth.debian.org/cgi-bin/cvsweb.cgi/sbuild/sbuild?cvsroot=buildd-tools Once the current SVN changes are merged, I'll reindent the source to match the 4 col SVN intentation, re-diff it and manually merge any outstanding changes. Once we are done, I'll see if we can push back the changes we've made to make it more user-friendly. Is there a mailing list for upstream to send patches to? Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDiP9yVcFcaSW/uEgRAlSXAJ9bUT/uehFKNIoyAo4Ymdo3GXYpMwCghfym sqnm3uGVMnZ302nkmJiaUlQ= =Uw5X -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Wouter Verhelst [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: I personally see the packages in unstable as something good for end-users who want to use it, or understand how the system works; but for Debian's purposes, it's not optimal. So non cabal members should look at a different sbuild and then magically figure out where and how the secret one differs? What is the point in looking at sbuild if it isn't THE sbuild? It's in Debian, and it's easy to use and understand. If it doesn't diverge too far from the sbuild actually on svn.cyberhqz.com, it's also good enough to give you a working setup for non-debian systems. IOW, it should be close enough to the actual thing to be useful for the general public, but cannot be close enough to the actual thing to be useful for official build daemons. Except it isn't working. Since a long time it wasn't able to build zsh, zsh-beta, bash3 for some unknown reason. It just deadlocks. Now its worse since the debian sbuild won't interact nicely with the wanna-build/buildd anymore due to interface changes and the binNMU feature. So now the sid sbuild only works standalone. That is a turn for the worse. Last year the aim was to get the buildd sbuild and debian sbuild back in sync and it pains me to see Ryan silently diferting it further and further instead of aiding that goal. That's one way to look at it. The other way would be to say that Ryan has recently been actively working on improving the code in the wanna-build SVN, and that the people maintaining the sbuild package in Debian (Roger?) haven't been paying too much attention to their upstream, likely because they didn't see the link on buildd.debian.org--a link which I, admittedly, had missed out on at first too, because it used to point to cvs.linux-m68k.org. There is indeed still a wanna-build CVS repository over there, but it's been effectively unmaintained for as long as I can remember. It should also be noted that Ryan, as appropriate for an Open Source developer, is happy to review and (provided he doesn't have any objections) apply any patches to sbuild or other things, too, as I've been able to witness first-hand myself in the past. I wasn't looking at it as upstream and debian maintainer but more like a native package with co-maintainers. But yours is a valid point. It just pains me that Debian does not include all the software to build Debian. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Michael Banck [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 06:44:42PM +0100, Goswin von Brederlow wrote: Michael Banck [EMAIL PROTECTED] writes: On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Patches for the Debian package are welcome, of course. Michael Do you know about http://svn.cyberhqz.com/svn/wanna-build/ Was that a question? I stated in the mail you replied to that wanna-build is now maintained in svn. Sorry, my bad. Still, I don't have time to look at it myself right now, so if somebody wants to send a patch, fine, otherwise, we will get to it eventually. Unless the release team and/or ftp-masters think this kind of new binNMU style should be restricted to the buildds (does the old style still work?). No. Michael MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Michael Banck [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. Then he should send patches and bug reports to the debian package. When the sbuild package got orphaned two years ago or so, I asked Ryan whether he would like to maintain it, and he said he was not interested. Which is totally fine for me and about everybody else. This split between the user/developer visible sbuild and the secret actual buildd is just not in the spirit of Debian. 1. Please drop the `secret' immediately. Unless you really want to call http://www.debian.org/devel/buildd `secret'. That your mail got resent with the this subject to debian-devel-announce is already stressing it *a lot*, IMHO. The subject and initial mail is not about sbuild being secret but about the overall change for Debian. I think that one is justified. Nothing to do with this subthread. As for http://www.debian.org/devel/buildd: $ grep sbuild http://www.debian.org/devel/buildd emwanna-build/em and calls emsbuild/em to build the packages. dta href=http://packages.debian.org/sbuild;sbuild/a/dt This nice public page only points to the nice public sbuild debian package. There is no link to the actual sbuild used on buildds. Further the links for wanna-build and buildd (which probably indirectly included sbuild) are broken: http://m68k.debian.org/buildd/getting.html -- connection refused Did you by chance mean the wanna-build svn link on http://buildd.debian.org/? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Adeodato =?utf-8?B?U2ltw7M=?= [EMAIL PROTECTED] writes: * Goswin von Brederlow [Thu, 24 Nov 2005 18:51:24 +0100]: Hi, Wouter Verhelst [EMAIL PROTECTED] writes: They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. Then he should send patches and bug reports to the debian package. This split between the user/developer visible sbuild and the secret actual buildd is just not in the spirit of Debian. I believe this is wrong. In words of one of the sbuild package co-maintainers, the Debian package is the fork, while the sbuild in wanna-build is upstream [1]. And upstreams are not required forward patches to their respective Debian maintainers, are they?; they just make new versions publicly available, as already happens here. [1] http://lists.debian.org/debian-devel/2005/11/msg01463.html Cheers, I'm sorry for that. I didn't see sbuild as an upstream + maintainer package but as a debian package. Developed by Debian people for Debian. Aparently that was a misconception on my part. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, Nov 25, 2005 at 02:38:32PM +0100, Goswin von Brederlow wrote: Michael Banck [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. Then he should send patches and bug reports to the debian package. When the sbuild package got orphaned two years ago or so, I asked Ryan whether he would like to maintain it, and he said he was not interested. Which is totally fine for me and about everybody else. This split between the user/developer visible sbuild and the secret actual buildd is just not in the spirit of Debian. 1. Please drop the `secret' immediately. Unless you really want to call http://www.debian.org/devel/buildd `secret'. That your mail got resent with the this subject to debian-devel-announce is already stressing it *a lot*, IMHO. The subject and initial mail is not about sbuild being secret but about the overall change for Debian. I think that one is justified. Nothing to do with this subthread. Right, these are two different things. However, the binNMU change is mostly/only useful for the release managers and buildd admins, so I fail to see why not having documented/announced it less than a week after its implementation should imply it was done in `secret', as those people are busy with the next library transition. To make this clear, I totally welcome your post documenting the new binNMU features while the authors have been too busy to do so for now. And the existance of the wanna-build/buildd/sbuild packages is not a secret, either. As for http://www.debian.org/devel/buildd: $ grep sbuild http://www.debian.org/devel/buildd emwanna-build/em and calls emsbuild/em to build the packages. dta href=http://packages.debian.org/sbuild;sbuild/a/dt This nice public page only points to the nice public sbuild debian package. There is no link to the actual sbuild used on buildds. Further the links for wanna-build and buildd (which probably indirectly included sbuild) are broken: http://m68k.debian.org/buildd/getting.html -- connection refused The documentation should get fixed, then. Did you by chance mean the wanna-build svn link on http://buildd.debian.org/? So it is documented there as well, good. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, Nov 25, 2005 at 02:03:12PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: It's in Debian, and it's easy to use and understand. If it doesn't diverge too far from the sbuild actually on svn.cyberhqz.com, it's also good enough to give you a working setup for non-debian systems. IOW, it should be close enough to the actual thing to be useful for the general public, but cannot be close enough to the actual thing to be useful for official build daemons. Except it isn't working. Since a long time it wasn't able to build zsh, zsh-beta, bash3 for some unknown reason. It just deadlocks. I think there's a fix for that in svn, not sure though. Now its worse since the debian sbuild won't interact nicely with the wanna-build/buildd anymore due to interface changes and the binNMU feature. So now the sid sbuild only works standalone. That is a turn for the worse. That's only true at this very moment. Resync with svn, done. [...] It just pains me that Debian does not include all the software to build Debian. Sure it does. It just doesn't include the software that Debian uses to automatically build packages, but that's not the same thing. After all, you can build packages in an automated fashion using, e.g., pbuilder; and people do actually do this all the time (where else would I have gotten those FTBFS bugs on doc-linux-nl from? That's an arch:all package). -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Wouter Verhelst [EMAIL PROTECTED] writes: On Fri, Nov 25, 2005 at 02:03:12PM +0100, Goswin von Brederlow wrote: It just pains me that Debian does not include all the software to build Debian. Sure it does. It just doesn't include the software that Debian uses to automatically build packages, but that's not the same thing. Which means not all of it. After all, you can build packages in an automated fashion using, e.g., pbuilder; and people do actually do this all the time (where else would I have gotten those FTBFS bugs on doc-linux-nl from? That's an arch:all package). From someone with sbuild setup to build arch:all packages? :))) MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Michael Banck [EMAIL PROTECTED] writes: On Fri, Nov 25, 2005 at 02:38:32PM +0100, Goswin von Brederlow wrote: Michael Banck [EMAIL PROTECTED] writes: On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. Then he should send patches and bug reports to the debian package. When the sbuild package got orphaned two years ago or so, I asked Ryan whether he would like to maintain it, and he said he was not interested. Which is totally fine for me and about everybody else. This split between the user/developer visible sbuild and the secret actual buildd is just not in the spirit of Debian. 1. Please drop the `secret' immediately. Unless you really want to call http://www.debian.org/devel/buildd `secret'. That your mail got resent with the this subject to debian-devel-announce is already stressing it *a lot*, IMHO. The subject and initial mail is not about sbuild being secret but about the overall change for Debian. I think that one is justified. Nothing to do with this subthread. Right, these are two different things. However, the binNMU change is mostly/only useful for the release managers and buildd admins, so I fail to see why not having documented/announced it less than a week after its implementation should imply it was done in `secret', as those people are busy with the next library transition. To make this clear, I totally welcome your post documenting the new binNMU features while the authors have been too busy to do so for now. The point is that the way binNMUs are done (and accepted by DAK) was _changed_ without discussion or announcement. What should have been announced was disabling the old manual binNMU feature. The problem is that people did a binNMU and DAK refused it out of the blue. The initial mail is just to prevent that in the future. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Blrgh!
OK. So I was working on the problem of fixing dpkg-dev so that
foo Depends: foo-data {SourceVersion}, foo-libs {BinaryVersion}
or something similar actually works. By parsing the version numbers.
Now it's apparently been changed under our noses, in such a way that my
proposed
scheme won't work -- and furthermore anyone who implemented their own
version
of such code, in their own package, will find it magically broken.
Thanks to Goswin and Henrique for *notifying* people of this, since
apparently whoever changed it didn't think about the impacts on other
developers.
Instead binNMU versions are now made by adding +b1 (+b2, +b3) to the
version and containing a Source: foo (non-NMU version) line. The
later makes it possible to reliable associate binNMUs with their
source.
So how do we write a package Depends: line now? Apparently the buildd uses
the original source,
and adds a changelog entry -- *but what happens to the {SourceVersion}
substitution?* Does the buildd
alter the substvars file before compiling? Does the {SourceVersion}
substitution end up being the original 1.2-3 source version, or the 1.2-3+b4
version? Whichever it ends up being, *how do we get the other one* if we
need it?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, 25 Nov 2005, Nathanael Nerode wrote:
OK. So I was working on the problem of fixing dpkg-dev so that
foo Depends: foo-data {SourceVersion}, foo-libs {BinaryVersion}
or something similar actually works. By parsing the version numbers.
I'd very much like debhelper or dpkg-* to give us another variable that
points to the parent version [changelog-wise] when bin NMUs are done, and to
the current version [changelog-wise] otherwise.
Meanwhile, I am using this: unversioned depends and two conflicts: (
{Upstream-Version}), (= {Upstream-Version}.1).
BinNMUs won't break compatibility between arch any and arch all in any of my
packages, and debian revisions breaking them are rare enough that I will
track that by hand, so the above is enough (although far from ideal).
So how do we write a package Depends: line now? Apparently the buildd uses
the original source,
See above. We had that problem already, but now we will have to deploy a
real solution instead of hacks. Ain't that nice? :-)
Does anyone have any idea on how to detect if a currently running buind is a
bin NMU or not?
and adds a changelog entry -- *but what happens to the {SourceVersion}
substitution?* Does the buildd
alter the substvars file before compiling? Does the {SourceVersion}
I bet it works in the simplest way possible, i.e. it is set to the latest
changelog entry: the binNMU version.
substitution end up being the original 1.2-3 source version, or the
1.2-3+b4 version? Whichever it ends up being, *how do we get the other
one* if we need it?
We really need another substvar with different semantics.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Goswin von Brederlow [EMAIL PROTECTED] writes: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Which sbuild CVS repo? I'll be happy to merge the changes into the official sbuild package (buildd-tools CVS). BTW, are there any good reasons why the autobuilders don't use the packaged version anywat? The differences are minimal. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFDhZ3LVcFcaSW/uEgRAqRsAKCKTXgSESNH5ROAiJcdAXyP7yJDOQCbB/+R ox+N2hrCGqlwJIv5V5q6+9I= =Eu1o -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 11:02:36AM +, Roger Leigh wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Which sbuild CVS repo? It is a SVN repo now, the one used by the buildd infrastructure. BTW, are there any good reasons why the autobuilders don't use the packaged version anywat? The differences are minimal. Last time I looked the changes seemed to be pretty big, but merging is of course a mid-term goal. In any case, the Debian package is the fork, while the sbuild in wanna-build is upstream. As I understand it, we do not plan to use the Debian sbuild package for the buildds, the upstream one works well enough (and currently much better for what the buildds need) Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 11:02:36AM +, Roger Leigh wrote: Goswin von Brederlow [EMAIL PROTECTED] writes: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Which sbuild CVS repo? It's actually a subversion repository, and it's at http://svn.cyberhqz.com/svn/wanna-build, as documented on http://buildd.debian.org I'll be happy to merge the changes into the official sbuild package (buildd-tools CVS). BTW, are there any good reasons why the autobuilders don't use the packaged version anywat? Many build daemons run stable rather than unstable, so running the sbuild package from unstable on those is going to be cumbersome, at best. Using the unstable package would require yet another step (getting it through you) after updating the code; currently, the db.d.o repository is updated by Ryan Murray, who also maintains the code itself. Additionally, buildd and sbuild work in fairly close cooperation, and using sbuild from one place and buildd from another (buildd isn't in unstable) would require being, uh, quite careful. Besides, buildd is not arch:all, so would need a recompile and backport for stable anyway. The differences are minimal. They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. I personally see the packages in unstable as something good for end-users who want to use it, or understand how the system works; but for Debian's purposes, it's not optimal. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Michael Banck [EMAIL PROTECTED] writes: On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Patches for the Debian package are welcome, of course. Michael Do you know about http://svn.cyberhqz.com/svn/wanna-build/ MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Wouter Verhelst [EMAIL PROTECTED] writes: They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. Then he should send patches and bug reports to the debian package. This split between the user/developer visible sbuild and the secret actual buildd is just not in the spirit of Debian. I personally see the packages in unstable as something good for end-users who want to use it, or understand how the system works; but for Debian's purposes, it's not optimal. So non cabal members should look at a different sbuild and then magically figure out where and how the secret one differs? What is the point in looking at sbuild if it isn't THE sbuild? Last year the aim was to get the buildd sbuild and debian sbuild back in sync and it pains me to see Ryan silently diferting it further and further instead of aiding that goal. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: I personally see the packages in unstable as something good for end-users who want to use it, or understand how the system works; but for Debian's purposes, it's not optimal. So non cabal members should look at a different sbuild and then magically figure out where and how the secret one differs? What is the point in looking at sbuild if it isn't THE sbuild? It's in Debian, and it's easy to use and understand. If it doesn't diverge too far from the sbuild actually on svn.cyberhqz.com, it's also good enough to give you a working setup for non-debian systems. IOW, it should be close enough to the actual thing to be useful for the general public, but cannot be close enough to the actual thing to be useful for official build daemons. Last year the aim was to get the buildd sbuild and debian sbuild back in sync and it pains me to see Ryan silently diferting it further and further instead of aiding that goal. That's one way to look at it. The other way would be to say that Ryan has recently been actively working on improving the code in the wanna-build SVN, and that the people maintaining the sbuild package in Debian (Roger?) haven't been paying too much attention to their upstream, likely because they didn't see the link on buildd.debian.org--a link which I, admittedly, had missed out on at first too, because it used to point to cvs.linux-m68k.org. There is indeed still a wanna-build CVS repository over there, but it's been effectively unmaintained for as long as I can remember. It should also be noted that Ryan, as appropriate for an Open Source developer, is happy to review and (provided he doesn't have any objections) apply any patches to sbuild or other things, too, as I've been able to witness first-hand myself in the past. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 06:44:42PM +0100, Goswin von Brederlow wrote: Michael Banck [EMAIL PROTECTED] writes: On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Patches for the Debian package are welcome, of course. Michael Do you know about http://svn.cyberhqz.com/svn/wanna-build/ Was that a question? I stated in the mail you replied to that wanna-build is now maintained in svn. Still, I don't have time to look at it myself right now, so if somebody wants to send a patch, fine, otherwise, we will get to it eventually. Unless the release team and/or ftp-masters think this kind of new binNMU style should be restricted to the buildds (does the old style still work?). Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Thu, Nov 24, 2005 at 06:51:24PM +0100, Goswin von Brederlow wrote: Wouter Verhelst [EMAIL PROTECTED] writes: They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. Then he should send patches and bug reports to the debian package. When the sbuild package got orphaned two years ago or so, I asked Ryan whether he would like to maintain it, and he said he was not interested. Which is totally fine for me and about everybody else. This split between the user/developer visible sbuild and the secret actual buildd is just not in the spirit of Debian. 1. Please drop the `secret' immediately. Unless you really want to call http://www.debian.org/devel/buildd `secret'. That your mail got resent with the this subject to debian-devel-announce is already stressing it *a lot*, IMHO. 2. I do not see why this should be against the spirit of Debian. As I stated already, the sbuild package was always a fork intended to be more usuable by humans, whereas the real sbuild is optimized for the buildds. I personally see the packages in unstable as something good for end-users who want to use it, or understand how the system works; but for Debian's purposes, it's not optimal. So non cabal members should look at a different sbuild and then magically figure out where and how the secret one differs? What is the point in looking at sbuild if it isn't THE sbuild? The point of looking at the sbuild package is to have a convenient tool for people to build their packages in a chroot, similar to pbuilder. Nothing more, nothing less. Please keep your cabalistic tendencies to yourself, or at least off this mailing list. Last year the aim was to get the buildd sbuild and debian sbuild back in sync and it pains me to see Ryan silently diferting it further and further instead of aiding that goal. Again: It is the sbuild's packages maintainers duty to sync with upstream, not the other way round, and we've been slacking (again, patches welcome). You seem to look at this from the wrong side of the fork. If somebody wants to package wanna-build, buildd and the accompayning sbuild, they shall be my guest; but I believe the packages provided at db.debian.org are easy enough to setup (as has been shown numerous times now), and I will not engage in that undertaking. If that happens, we can discuss how packages should be named, and whether the current sbuild package should be renamed. Until then, less drama would be welcome. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
* Goswin von Brederlow [Thu, 24 Nov 2005 18:51:24 +0100]: Hi, Wouter Verhelst [EMAIL PROTECTED] writes: They were, originally. Ryan's been very active on it since, and it's diverged a bit from the code you're maintaining. Then he should send patches and bug reports to the debian package. This split between the user/developer visible sbuild and the secret actual buildd is just not in the spirit of Debian. I believe this is wrong. In words of one of the sbuild package co-maintainers, the Debian package is the fork, while the sbuild in wanna-build is upstream [1]. And upstreams are not required forward patches to their respective Debian maintainers, are they?; they just make new versions publicly available, as already happens here. [1] http://lists.debian.org/debian-devel/2005/11/msg01463.html Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Alan Parsons, vocal: Elmer Gantry - Psychobabble -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Fri, 25 Nov 2005, Michael Banck wrote: 1. Please drop the `secret' immediately. Unless you really want to call http://www.debian.org/devel/buildd `secret'. That your mail got resent with the this subject to debian-devel-announce is already stressing it *a lot*, IMHO. I did the forwarding. As far as I am concerned: 1. sbuild has nothing to do with the email sent to d-d-a, and this whole subthread about sbuild upstream and secrets is insane. A Debian maintainer must keep close track of upstream, and build a good enough work relationship with upstream authors to at the very least get informed when repositories move. sbuild is NO exception to this. 2. Any changes to something as basic as the package numbering scheme must be widely announced to all developers, and properly documented. The fact that such changes are now in effect, and no announcement was posted to d-d-a within 48h of they being deployed *IS* enough to *sarcastically* call it a secret change alright, unless DAK is still accepting old-style binary NMUs along with new-style ones (and maybe even then). Calling it secret and actually meaning it is childish, of course. I am pretty sure eventually we would get some proper announcement, but eventually ain't good enough IMHO, thus the forwarding. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
* Goswin von Brederlow ([EMAIL PROTECTED]) [051123 15:51]: - binNMU version scheme changed The developer reference _still_ states binNMU should be versioned as 1.2-3.0.1. The DAK will no longer accept this. I am sorry that the developers reference is a bit lagging currently. Do you have some new wording available, or do you want till I find time to fix it myself? Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Wed, 23 Nov 2005, Goswin von Brederlow wrote: - buildds can recompile a source with a binNMU version We were told about this, although I can't recall if the proper channel (d-d-a) was used. Would you consider posting your message to debian-devel-announce, please? That's where such extremely important messages belong :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Andreas Barth [EMAIL PROTECTED] writes: * Goswin von Brederlow ([EMAIL PROTECTED]) [051123 15:51]: - binNMU version scheme changed The developer reference _still_ states binNMU should be versioned as 1.2-3.0.1. The DAK will no longer accept this. I am sorry that the developers reference is a bit lagging currently. Do you have some new wording available, or do you want till I find time to fix it myself? Cheers, Andi -- http://home.arcor.de/andreas-barth/ I can give it a shot and send you a draft for it. From a technical point I'm unsure how the following version will (sbuild) and should (dak) be handled: old version binNMU version? 1.2 1.2-0+b1 1.2-3.0.1 1.2-3.0.1+b1 I bet the later will confuse wanna-build, sbuild and the dak and just require a new maintainer upload or source NMU instead. But is the former one correct? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: On Wed, 23 Nov 2005, Goswin von Brederlow wrote: - buildds can recompile a source with a binNMU version We were told about this, although I can't recall if the proper channel (d-d-a) was used. Would you consider posting your message to debian-devel-announce, please? That's where such extremely important messages belong :-) Feel free to sign and forward the message. I can't. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Secret changes for binNMUs
On Wed, Nov 23, 2005 at 03:50:11PM +0100, Goswin von Brederlow wrote: If you NEED to do a manual binNMU it is probably best to use sbuild (the cvs, not deb) Patches for the Debian package are welcome, of course. Michael -- Michael Banck Debian Developer [EMAIL PROTECTED] http://www.advogato.org/person/mbanck/diary.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
