dh_make issue/suggestion
Hello, I have recently started learning how to create debian packages. I have some thoughts on what I see as an issue, and some thoughts on resolving it. Keep in mind I have only been at this for a couple of days, so take this with a grain of salt. dh_make does a good job of providing reasonable defaults, with one exception I have encountered. Regarding manpage documentation, I see the following scenarios: 1. the upstream source already has manpages. they are either in nroff format and are installed via the upstream Makefile's "install" target, or they are in sgml, are built in the upstream Makefile "build" target, and the resulting nroff is then installed via the upstread Makefile "install" target. 2. there are no upstream manpages. manpages are created during debianization. they reside in nroff format in /debian, and the rules "install" target calls "dh_installman foo.1", etc to install them, or they reside in sgml format in /debian, the rules "build" target calls docbook-to-man, and then the rules "install" target installs the resulting nroff. it is the latter half of the second option where I see a possible improvement. thoughtfully, the dh_make rules file includes a commented call to docbook-to-man in the rules "build" target. however, this results in debian/../foo.1, etc. this temporary file does not get cleaned with a call to "debuild clean", which I beleive is what should be responsible for cleaning it. I propose adding the following commented line to the rules "clean" target to supplement the commented call to docbook-to-man: # uncomment this if you uncommented the docbook-to-man call above. #rm -f foo.1 however, this leads to the problem of "what if debian/../foo.1 was supplied by upstream?". thus, we need to make it a little more intelligent: # uncomment this if you uncommented the docbook-to-man call above. #if test -e debian/foo.sgml; then rm -f foo.1; fi thus, if the user renamed debian/manpage.sgml.ex to debian/foo.sgml, it is safe to assume that either there is no upstream manpage, or that it is safe to overwrite the upstream manpage. this also leads to the idea that we should really wrap the call to docbook-to-man in the rules build target: #if test -e debian/foo.sgml; then /usr/bin/docbook-to-man debian/foo.sgml > foo.1; fi finally, I propose an addition be made to the new maintainer's guide to point out that you have to give dh_installman some arguments for it to do anything. section 5.8 discusses all the required steps to supply a manpage when the upstream source lacks one, but they don't mention you need to change the call from "dh_installman" to "dh_installman foo.1" again, I am new to all this, so constructive criticism is very welcome. -jason pepas [EMAIL PROTECTED]
Re: Packages file under version control
On Tue, Jun 03, 2003 at 05:11:23PM +0800, Cameron Patrick wrote: > Anything to back this up? I just did and apt-get update/dist-upgrade > and it wants to download 86MB of stuff. Considering that I last > dist-upgraded my (sid) machine just a few days ago, I suspect that > for anyone running unstable the Packages.gz and Sources.gz files will > be the tip of the iceberg. If you just one to install one package, or one package source, yes, the size of the Packages/Sources files exceeds the size of the package to download. Also apt-get doesn't have provision for downloading only one Packages file, it has to download every one listed in sources.list. -- Brian May <[EMAIL PROTECTED]>
Re: new bug tags
On Sun, Jun 01, 2003 at 03:33:29PM +0100, James Troup wrote: > I don't; it's silly. At best you'll get an architecture tag for the > arch that the buildd maintainer reported the bug on, but that's it. > An inaccurate architecture tag is worse than useless, it's misleading. > Just parse wanna-build's failed logs; it's trivial. What about architecture specific bugs that don't result in build errors? Or does this not happen often enough to be a concern? -- Brian May <[EMAIL PROTECTED]>
Re: /etc/hostname
On Sun, Jun 01, 2003 at 11:08:52AM +1000, Herbert Xu wrote: > Bob Proulx <[EMAIL PROTECTED]> wrote: > > But this second configuration requires the network and will fail in > > the case that you have taken it offline. On laptops that is not a > > desireable situation. Even in the desktop environment there are cases > > You can solve that by adding the external address to the loopback interface: > > ip a a 192.168.65.5/32 dev lo ...and if you plug your laptop into a network that already uses 192.168.65.5 for another computer that you want to access? -- Brian May <[EMAIL PROTECTED]>
Re: Proposal: a generic dpkg event hook broker
On Mon, Jun 02, 2003 at 05:23:03PM -0500, Adam Heath wrote: > Already being planned for dpkg 2.0. Note, this has to be tied in with the > status of the package being hooked, as the status changes state, so it really > needs to be done in dpkg. Great! There is also the SE-Linux version of dpkg which has support for something similar, but the dpkg 2.0 implementation may be completely different. -- Brian May <[EMAIL PROTECTED]>
Re: Bug#193497: marked as done (svtools: svsetup uses bashism "echo -e")
On Sun, Jun 01, 2003 at 06:17:57PM +0200, Rene Engelhard wrote: > yes. And what is when someone is offline and wants to see what > that bug was about? It also helps if the maintainer accidently closes the wrong bug in the Changelog. * New upstream version (closes: #). means nothing if say bug # is for a completely different package, People are left wondering "How did this new upstream package fix the bug in this other package? Was it accidental? Was it deliberate?" However: * New upstream version, fixes bad error message (closes: #). Serves two purposes: #1. Makes it clear that bug # was the wrong bug. #2. Gives the chance of somebody else being able to look up what bug the maintainer really intended to close. Especially, if say, there was a bug #1 against the same package with a title "bad error message produced when ". In this case it becomes pretty obvious that the maintainer probably forgot to enter an extra digit. -- Brian May <[EMAIL PROTECTED]>
Re: Packages file under version control
On Tue, Jun 03, 2003 at 10:04:16AM +0200, David Weinehall wrote: > No. Fetching Packages.gz over modem is a pain in the arse. Having it > only rsync the changes would be so nice. Try apt-rsync. http://home.worldonline.cz/~cz210552/ HTH, Nick -- x--x | What your soldier wants -- really, really wants -- | |is no-one shooting back at him. | | (Terry Pratchett, alt.fan.pratchett) | |--| | Nicolas Kratz <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> | x--x pgpDWyn6wMvbp.pgp Description: PGP signature
Re: Packages file under version control
On Tue, 3 Jun 2003 10:04:16 +0200 David Weinehall <[EMAIL PROTECTED]> wrote: > No. Fetching Packages.gz over modem is a pain in the arse. Having it > only rsync the changes would be so nice. I must say that apt-get update using sid is a hell with my 56 k ;( Most of the Packages file doesn't change a lot in a single update, and it takes a lot of time to download the file. Even more, most of the times only the version and dependencies change (package comments remains) This is bad for me, as it takes a lot of time; and bad for servers/mirrors since it requires more server/mirror resources. Fine-grained package file updating would be cool, you could download only the needed updates (putting some kind of version control in the name of the package description file perhaps would only require a ls to know what packages to to update) (ie: the libc6 package and gnome* info file) and leave the rest untouched, so updates would be faster and servers/mirrors would be happy. Just a though about doing the same in a different form.
Re: Managing package sources with subversion?
Marcelo E. Magallon wrote: On Wed, Jun 04, 2003 at 01:47:28AM +1200, Carey Evans wrote: [...] > % svn ls file:///home/repos/debian/tn5250/vendor > 0.16.5/ > current/ what's current? (in the context of svn, it's obvious that current is the current upstream version) I've set this up as a vendor branch as described in the SVN book: http://svnbook.red-bean.com/html-chunk/ch06s04.html Reading it again, I see that their description is for only part of the main code, not all of it, though. I see you have only one upstream version. Any experience with importing and/or merging new upstream sources? No; there hasn't been an upstream release since I imported this into Subversion, and I haven't tested it with previous versions. The procedure described in the book looks straightforward: use svn_load_dirs to update a checked-out current, or do it manually, tag it by copying vendor/current to vendor/, and use svn merge to copy the new changes from vendor/ into trunk. -- "Hanging is too good for a man who makes puns; he should be drawn and quoted." -- Fred Allen
Re: Debian menu system update
On Tue, Jun 03, 2003 at 09:13:09PM +0200, Bill Allombert wrote: > On Tue, Jun 03, 2003 at 02:08:38PM -0500, Chris Cheney wrote: > > On Tue, Jun 03, 2003 at 08:39:02PM +0200, Bill Allombert wrote: > > > How do you expect menu to generate menus without an /etc/menu-method/ > > > directory ? Also autogenerated menus should go in /var. > > > > Oops you are correct, for window managers that don't support the spec > > natively we still need that directory. > > Then could you answer my original question again ? As far as I can tell /etc/menu, /usr/lib/menu, and /usr/share/menu will go away once we start using the desktop entry spec and /usr/share/applications directory. Anything natively supporting the desktop spec won't have any reason to use /etc/menu-method at all (afaik). The desktop menu spec will probably need an addition of $XDG_CONFIG_DIRS/applications/ to replace debian's /etc/menu that is a global admin menu entry directory. Chris Cheney Debian KDE Maintainer PS - I am cc:ing this to xdg-list so that the proper people can see that a global applications override directory would be a useful addition. Please note that I am not subscribed to xdg-list.
Re: Debian menu system update
On Tue, Jun 03, 2003 at 02:08:38PM -0500, Chris Cheney wrote: > On Tue, Jun 03, 2003 at 08:39:02PM +0200, Bill Allombert wrote: > > How do you expect menu to generate menus without an /etc/menu-method/ > > directory ? Also autogenerated menus should go in /var. > > Oops you are correct, for window managers that don't support the spec > natively we still need that directory. Then could you answer my original question again ? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Debian menu system update
On Tue, Jun 03, 2003 at 08:39:02PM +0200, Bill Allombert wrote: > How do you expect menu to generate menus without an /etc/menu-method/ > directory ? Also autogenerated menus should go in /var. Oops you are correct, for window managers that don't support the spec natively we still need that directory. Chris
Re: ATI Linux Driver Packages
On Mon, Jun 02, 2003 at 05:34:57PM +1000, Daniel Stone wrote: > On Sun, 1 Jun 2003 23:16:12 -0500, Adam Majer wrote: > > On Sun, Jun 01, 2003 at 09:42:10PM -0500, Chris Cheney wrote: > > > Are these drivers much better then than XFree ones or is there a reason > > > to be promoting nonfree drivers? I orginally packaged up the nvidia ones > > > in the way they are done due to the fact the XFree ones had no 3d > > > acceleration at all and that it was illegal to distribute nvidia's > > > binaries directly. Also binary only drivers will taint the kernel and > > > can cause the user to have trouble getting help with kernel related > > > issues. I got rid of my nvidia cards (some poor sucker took them) and > > > now use only ATI cards. 8) > > > > I think you might be the "sucker". :) [ok, it's not a flame thing]. > > Does the radeon driver support 3D accel for cards beyond the R1xx level? > > ie. something like Radeon 7500. I don't think that Radeon 8500, 8800, etc..a > > are supported since they use the former FireGL GPU. The drivers from > > ATI fill the gap to support FireGL, and yes they are better. They > > can be used with Maya etc.. [at least it says that on ATI's site.] > > 3D acceleration exists for r[12]xx and r250; I'm not sure whether it > exists for the rv280. Indeed, it's in the stock XFree86 4.3 debs > previously distributed by myself, now distributed by the XSF. As i understand it, the rv280 is just an rv250 with agpx8 support. As such it should be supported without problems. Maybe you would have to fake pci ids though. Friendly, Sven Luther
Re: ATI Linux Driver Packages
On Sun, Jun 01, 2003 at 11:16:12PM -0500, Adam Majer wrote: > On Sun, Jun 01, 2003 at 09:42:10PM -0500, Chris Cheney wrote: > > Are these drivers much better then than XFree ones or is there a reason > > to be promoting nonfree drivers? I orginally packaged up the nvidia ones > > in the way they are done due to the fact the XFree ones had no 3d > > acceleration at all and that it was illegal to distribute nvidia's > > binaries directly. Also binary only drivers will taint the kernel and > > can cause the user to have trouble getting help with kernel related > > issues. I got rid of my nvidia cards (some poor sucker took them) and > > now use only ATI cards. 8) > > I think you might be the "sucker". :) [ok, it's not a flame thing]. > Does the radeon driver support 3D accel for cards beyond the R1xx level? > ie. something like Radeon 7500. I don't think that Radeon 8500, 8800, etc..a > are supported since they use the former FireGL GPU. The drivers from > ATI fill the gap to support FireGL, and yes they are better. They > can be used with Maya etc.. [at least it says that on ATI's site.] R1x0 and R2x0 are supported in XFree86 4.3.0. Radeon R3x0 are not though. Friendly, Sven Luther
Re: buildd failure
On Tue, Jun 03, 2003 at 04:13:29PM +0100, Colin Watson wrote: > On Tue, Jun 03, 2003 at 05:04:15PM +0200, Sam Hocevar wrote: > > On Tue, Jun 03, 2003, Matt Zimmerman wrote: > > > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > > > > > Go to buildd.debian.org, read the log and find out what happened. > > > >But the buildd didn't even try to build 2.0.26.4-1. > > > >Attila, if I were you I'd just try to upload a new release. > > I wouldn't, that just means you get another 10-day delay before the > package gets into testing. Try asking debian-hppa. Plus, it'd trigger a rebuild for 11 architectures, just because 'something' happened for hppa. That's a waste of resources, if it's only to solve this specific issue. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts. pgpwNTjaQPHlw.pgp Description: PGP signature
Re: Debian menu system update
On Tue, 2003-06-03 at 06:24, Bill Allombert wrote: > On Sun, Jun 01, 2003 at 11:08:00PM -0400, Colin Walters wrote: > > > I have read it, and I have still difficulty to understand its > > > full implication. > > > > The implication is basically that we use it as the format of our menu > > database (instead of /usr/lib/menu), and convert the menu-methods to > > taking that information and translating it to legacy formats such as the > > fvwm menu system. > > How GNOME and KDE will honor menu configuration in /etc/menu, > /etc/menu-method/menu.h, ~/.menu and ~/.menu-method/menu.h with your > scheme ? We will likely have to break backwards compatibility, if that's what you're asking. But that's what Debian major releases are for: sarge will do that with g++, python, probably perl...
Re: buildd failure
On Tue, Jun 03, 2003 at 05:03:09PM +0200, Marcelo E. Magallon wrote: > On Tue, Jun 03, 2003 at 10:35:51AM -0400, Matt Zimmerman wrote: > > On Tue, Jun 03, 2003 at 12:31:42PM +0200, Attila SZALAY wrote: > > > > > What can I do with this (from packages.qa.debian.org): > > > > > > # 42 days old (needed 10 days) > > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > > > > > This is with package libzorpll. > > > > Go to buildd.debian.org, read the log and find out what happened. > > For hppa: > > * 1.5.55-1 (latest build at Nov 18 15:01: maybe-failed) > * 2.0.5.2-1 (latest build at Mar 23 17:18: maybe-successful) > > For alpha: > > * 1.5.55-1 (latest build at Nov 19 02:02: maybe-failed) > * 1.5.57-1 (latest build at Nov 19 19:00: maybe-failed) > * 2.0.1.3-1 (latest build at Nov 25 08:33: maybe-successful) > * 2.0.5.2-1 (latest build at Nov 27 03:31: maybe-successful) > * 2.0.26.4-1 (latest build at Apr 21 15:11: maybe-successful) > > Now, what does that mean? That it got lost somehow. It happens. Send a mail to the relevant mailinglist (debian-hppa@lists.debian.org is my first guess), and ask if they can build your package. If they can't, they'll explain why. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts. pgpfoCF5UMQc0.pgp Description: PGP signature
Re: package naming
On Tue, Jun 03, 2003 at 03:25:15PM +0200, Mario Lang wrote: > Sure, the epoch is of course necessary. What I am wondering about is how > katie will react if a source package is uploaded which produces a binary > package which is already produced by another source package. > > I.e., is there any thing one would need to be careful about, or > does this Just Work? It won't install the new package if the old one isn't removed first, but if you upload the -cvs flavour at the same time as the normal one, the binary package in the 'wrong' source package will go away, and problems will solve themselves. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts. pgpu8S1NmKF4Z.pgp Description: PGP signature
Re: Debian menu system update
On Tue, Jun 03, 2003 at 01:24:01PM -0500, Chris Cheney wrote: > On Tue, Jun 03, 2003 at 12:24:34PM +0200, Bill Allombert wrote: > > How GNOME and KDE will honor menu configuration in /etc/menu, > > /etc/menu-method/menu.h, ~/.menu and ~/.menu-method/menu.h with your > > scheme ? > > As I understand it, those would go away entirely. All menu entries would > be in /usr/share/applications, or $HOME/.local/share/applications as per > desktop menu specification. The menu's themselves would go into > /etc/xdg/menus, or $HOME/.config/menus/ (If I have read the basedir and > menu specs correctly). How do you expect menu to generate menus without an /etc/menu-method/ directory ? Also autogenerated menus should go in /var. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Debian menu system update
On Tue, Jun 03, 2003 at 12:24:34PM +0200, Bill Allombert wrote: > On Sun, Jun 01, 2003 at 11:08:00PM -0400, Colin Walters wrote: > > > I have read it, and I have still difficulty to understand its > > > full implication. > > > > The implication is basically that we use it as the format of our menu > > database (instead of /usr/lib/menu), and convert the menu-methods to > > taking that information and translating it to legacy formats such as the > > fvwm menu system. > > How GNOME and KDE will honor menu configuration in /etc/menu, > /etc/menu-method/menu.h, ~/.menu and ~/.menu-method/menu.h with your > scheme ? As I understand it, those would go away entirely. All menu entries would be in /usr/share/applications, or $HOME/.local/share/applications as per desktop menu specification. The menu's themselves would go into /etc/xdg/menus, or $HOME/.config/menus/ (If I have read the basedir and menu specs correctly). Chris
Re: buildd failure
Hi All! On 2003 Jun 03, Matt Zimmerman wrote: > > In any case, debian-devel in general is not likely to know, but the buildd > admin will. I only ask what can I do. - Send an email to hppa buildd maintainer - Send an email to debian-hppa mail list - Report a bug - Wait - Other. That's all. And yes, I got the answer. Thanks all! -- PGP ID 0x8D143771, /C5 95 43 F8 6F 19 E8 29 53 5E 96 61 05 63 42 D0 GPG ID ABA0E8B2, 45CF B559 8281 8091 8469 CACD DB71 AEFC ABA0 E8B2 A helpdesk olyan, mint a firewall. Nehez rajta atjutni, de utana mar megy minden. - Gabor HALASZ
Re: Contents files and removed packages
On Tue, Jun 03, 2003 at 05:32:47PM +0200, Bill Allombert wrote: > kinkatta is not listed as being part of unstable, but kinkatta files are > part of unstable/Contents-i386.gz. Contents files are updated infrequently - once a week or so, I think. kinkatta was only removed on 28 May. -- Colin Watson [EMAIL PROTECTED]
Re: buildd failure
On Tue, Jun 03, 2003 at 05:03:09PM +0200, Marcelo E. Magallon wrote: > On Tue, Jun 03, 2003 at 10:35:51AM -0400, Matt Zimmerman wrote: > > On Tue, Jun 03, 2003 at 12:31:42PM +0200, Attila SZALAY wrote: > > > > > What can I do with this (from packages.qa.debian.org): > > > > > > # 42 days old (needed 10 days) > > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > > > > > This is with package libzorpll. > > > > Go to buildd.debian.org, read the log and find out what happened. > > For hppa: > > * 1.5.55-1 (latest build at Nov 18 15:01: maybe-failed) > * 2.0.5.2-1 (latest build at Mar 23 17:18: maybe-successful) > > For alpha: > > * 1.5.55-1 (latest build at Nov 19 02:02: maybe-failed) > * 1.5.57-1 (latest build at Nov 19 19:00: maybe-failed) > * 2.0.1.3-1 (latest build at Nov 25 08:33: maybe-successful) > * 2.0.5.2-1 (latest build at Nov 27 03:31: maybe-successful) > * 2.0.26.4-1 (latest build at Apr 21 15:11: maybe-successful) > > Now, what does that mean? It could mean that the autobuilder never attempted the build, in which case it is my understanding that a buildd admin could prod it into doing so. It could also mean that a build was attempted, but something went wrong, the log was lost, etc. In any case, debian-devel in general is not likely to know, but the buildd admin will. -- - mdz
Re: buildd failure
On Tue, Jun 03, 2003, Colin Watson wrote: > >Attila, if I were you I'd just try to upload a new release. > > I wouldn't, that just means you get another 10-day delay before the > package gets into testing. Yup, but you missed the subliminal message in my "try lintian" hint :-) Regards, -- Sam.
Re: buildd failure
On Tue, Jun 03, 2003 at 10:43:25AM -0400, Aaron M. Ucko wrote: > Attila SZALAY <[EMAIL PROTECTED]> writes: > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > Hm, http://buildd.debian.org/build.php?arch=&pkg=libzorpll seems to > indicate that the hppa autobuilder never attempted 2.0.26.4-1 for some > reason. Try building it yourself in paer's sid chroot? http://auric.debian.org/~tausq/buildd/hppa-latest.html lists it as "Not-for-us" I have no clue why though as it doesn't appear to be architecture specific? -- --( Users rock, it's programmers should )-- Simon ( should be shot.. ) Nomis Htag.pl 0.0.22
Contents files and removed packages
Hello Debian devel, kinkatta is not listed as being part of unstable, but kinkatta files are part of unstable/Contents-i386.gz. Comments ? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Changelog issues with (among others) tkdiff 1:3.08-4
Hi, Herbert Xu wrote:
> Seriously, please find something more productive to do than making
> these never-ending complaints about changelog entries.
IMHO if developers would write correct changelog entries, this discussion
wouldn't be necessary in the first place. :-/
Seriously, please find something more productive to do than making
these never-ending complaints about people who complain about bad
changelog entries.
An appropriate filter in your email / news program should help.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
A friend of mine won't get a divorce, because he hates lawyers more than he
hates his wife.
Re: buildd failure
On Tue, Jun 03, 2003 at 05:04:15PM +0200, Sam Hocevar wrote: > On Tue, Jun 03, 2003, Matt Zimmerman wrote: > > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > > > Go to buildd.debian.org, read the log and find out what happened. > >But the buildd didn't even try to build 2.0.26.4-1. > >Attila, if I were you I'd just try to upload a new release. I wouldn't, that just means you get another 10-day delay before the package gets into testing. Try asking debian-hppa. -- Colin Watson [EMAIL PROTECTED]
Re: buildd failure
On Tue, Jun 03, 2003 at 10:35:51AM -0400, Matt Zimmerman wrote: > On Tue, Jun 03, 2003 at 12:31:42PM +0200, Attila SZALAY wrote: > > > What can I do with this (from packages.qa.debian.org): > > > > # 42 days old (needed 10 days) > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > > > This is with package libzorpll. > > Go to buildd.debian.org, read the log and find out what happened. For hppa: * 1.5.55-1 (latest build at Nov 18 15:01: maybe-failed) * 2.0.5.2-1 (latest build at Mar 23 17:18: maybe-successful) For alpha: * 1.5.55-1 (latest build at Nov 19 02:02: maybe-failed) * 1.5.57-1 (latest build at Nov 19 19:00: maybe-failed) * 2.0.1.3-1 (latest build at Nov 25 08:33: maybe-successful) * 2.0.5.2-1 (latest build at Nov 27 03:31: maybe-successful) * 2.0.26.4-1 (latest build at Apr 21 15:11: maybe-successful) Now, what does that mean? -m.
Re: Managing package sources with subversion?
On Wed, Jun 04, 2003 at 01:47:28AM +1200, Carey Evans wrote: > % svn ls file:///home/repos/debian/tn5250 > branches/ > debian/ > tags/ > trunk/ > vendor/ > % svn ls file:///home/repos/debian/tn5250/debian > 0.16.5-1/ > 0.16.5-2/ > 0.16.5-3/ > 0.16.5-4/ > 0.16.5-5/ > % svn ls file:///home/repos/debian/tn5250/vendor > 0.16.5/ > current/ what's current? (in the context of svn, it's obvious that current is the current upstream version) I see you have only one upstream version. Any experience with importing and/or merging new upstream sources? A few small attempts at this exploded in my face... but this was some months ago, so things might have changed in the meantime. Marcelo
Re: buildd failure
Attila SZALAY <[EMAIL PROTECTED]> writes: > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) Hm, http://buildd.debian.org/build.php?arch=&pkg=libzorpll seems to indicate that the hppa autobuilder never attempted 2.0.26.4-1 for some reason. Try building it yourself in paer's sid chroot? -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: buildd failure
On Tue, Jun 03, 2003, Matt Zimmerman wrote: > > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > Go to buildd.debian.org, read the log and find out what happened. But the buildd didn't even try to build 2.0.26.4-1. Attila, if I were you I'd just try to upload a new release. Do not forget to run lintian and linda on your packages (and .dsc file), they give a lot of useful information. Regards, -- Sam.
Re: buildd failure
On Tue, Jun 03, 2003 at 12:31:42PM +0200, Attila SZALAY wrote: > What can I do with this (from packages.qa.debian.org): > > # 42 days old (needed 10 days) > # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) > > This is with package libzorpll. Go to buildd.debian.org, read the log and find out what happened. -- - mdz
Re: Managing package sources with subversion?
Joey Hess wrote: - cvs2svn works ok, but can be _very_ slow. Be prepared for significant archive bloat too. I also had to run it three times due to some subversion bug that I have supressed memory of. I didn't bother importing all the history of tn5250 from CVS into Subversion. The old changes are still in CVS if I need them. [snip] - After I imported mooix into subversion, I went back and de-munged all the tags generated by cvs-buildpackage. cvs has limits on tag names (no periods allowed) so you probably have ugly tags like debian_version_1_01 and so on. You can use svn mv, pointed directly at the repo, to rename these tags to debian_version_1.01 or whatever you feel is appropriate. I eventually decided that there was no particular reason to use the tags directory for Debian versions, and created a new "debian" directory: % svn ls file:///home/repos/debian/tn5250 branches/ debian/ tags/ trunk/ vendor/ % svn ls file:///home/repos/debian/tn5250/debian 0.16.5-1/ 0.16.5-2/ 0.16.5-3/ 0.16.5-4/ 0.16.5-5/ % svn ls file:///home/repos/debian/tn5250/vendor 0.16.5/ current/ The branches and tags directories are both empty. [snip] Or you can use subversion's nice fast export command to get a clean export without the .svn directories and build in there. Note that svn export copies the tree, including any uncommitted changes, which is both good and bad. You can use it while offline. I'm probably going to switch to using this technique. Ooh, I missed this option for svn export. Thanks. -- "Hanging is too good for a man who makes puns; he should be drawn and quoted." -- Fred Allen
Re: package naming
"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes: > Hi, > > On Mon, Jun 02, 2003 at 03:15:19PM -0400, Deedra Waters wrote: > > > I've been working on the package "kernel-patch-speakup" which has a > > source package called speakup-cvs and produces the binary called > > kernel-patch-speakup_20021221-1_all.deb, well, there is a stable > > version of speakup that I'd like to package and have it keep the > > kernel-patch-speakup name. This source package is called speakup, and > > produces a similar binary called "kernel-patch-speakup_1.5-1_all.deb" > > > The problem currently is that the new source package produces a > > binary package which already exists, and is generated by a different > > source package > > I am not sure I understand why that's a problem. The only thing you > have to take into account is adding an epoch to the new > kernel-patch-speakup, Sure, the epoch is of course necessary. What I am wondering about is how katie will react if a source package is uploaded which produces a binary package which is already produced by another source package. I.e., is there any thing one would need to be careful about, or does this Just Work? -- CYa, Mario | Debian Developer http://debian.org/> | Get my public key via finger [EMAIL PROTECTED] | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44
Re: Debian menu system update
On Sun, Jun 01, 2003 at 11:08:00PM -0400, Colin Walters wrote: > > I have read it, and I have still difficulty to understand its > > full implication. > > The implication is basically that we use it as the format of our menu > database (instead of /usr/lib/menu), and convert the menu-methods to > taking that information and translating it to legacy formats such as the > fvwm menu system. How GNOME and KDE will honor menu configuration in /etc/menu, /etc/menu-method/menu.h, ~/.menu and ~/.menu-method/menu.h with your scheme ? Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
buildd failure
Hi All! What can I do with this (from packages.qa.debian.org): # 42 days old (needed 10 days) # out of date on hppa: libzorpll, libzorpll-dev (from 2.0.5.2-1) This is with package libzorpll. -- PGP ID 0x8D143771, /C5 95 43 F8 6F 19 E8 29 53 5E 96 61 05 63 42 D0 GPG ID ABA0E8B2, 45CF B559 8281 8091 8469 CACD DB71 AEFC ABA0 E8B2 An exaggeration is a thruth that has lost its temper -- Kahlil Gibran
Re: Packages file under version control
Cameron Patrick <[EMAIL PROTECTED]> writes: > I suspect that for anyone running unstable the Packages.gz and > Sources.gz files will be the tip of the iceberg. > > For anyone running stable, the Packages.gz files rarely change and so > apt-get update will not normally bother to download them again. Try testing. Obviously sometimes there are big packages to download, but often there are not, and Packages.gz is the huge bulk of what's transferred (and you can always put that new release of X on hold while you download smaller stuff). -Miles -- "Though they may have different meanings, the cries of 'Ye-haw!' and 'Allahu akbar!' are, in spirit, not actually all that different."
Re: Packages file under version control
On Tue, Jun 03, 2003 at 10:04:16AM +0200, David Weinehall wrote: | > However, given the packages.gz file is much smaller than the total | > files being downloaded, is it really worth it? | | When the mirrors sync, yes, when the average user runs | | # apt-get update | # apt-get -u upgrade | | No. Anything to back this up? I just did and apt-get update/dist-upgrade and it wants to download 86MB of stuff. Considering that I last dist-upgraded my (sid) machine just a few days ago, I suspect that for anyone running unstable the Packages.gz and Sources.gz files will be the tip of the iceberg. For anyone running stable, the Packages.gz files rarely change and so apt-get update will not normally bother to download them again. Cameron.
Re: package naming
Hi, On Mon, Jun 02, 2003 at 03:15:19PM -0400, Deedra Waters wrote: > I've been working on the package "kernel-patch-speakup" which has a > source package called speakup-cvs and produces the binary called > kernel-patch-speakup_20021221-1_all.deb, well, there is a stable > version of speakup that I'd like to package and have it keep the > kernel-patch-speakup name. This source package is called speakup, and > produces a similar binary called "kernel-patch-speakup_1.5-1_all.deb" > The problem currently is that the new source package produces a > binary package which already exists, and is generated by a different > source package I am not sure I understand why that's a problem. The only thing you have to take into account is adding an epoch to the new kernel-patch-speakup, since its old version 20021221-1 is newer than its new version 1.5-1. That is, you have to use 1:1.5-1 for the new version. In short: Source: speakup Version: 1:1.5-1 this produces the package kernel-patch-speakup Source: speakup-cvs Version: 20021221-1 this produces the package kernel-patch-speakup-cvs The epoch is necessary if you really want people to "upgrade" from the old CVS package to the new stable package. I see the package was not present in woody, so it's not a problem for people upgrading across Debian releases. Marcelo
Re: Packages file under version control
David Weinehall <[EMAIL PROTECTED]> writes: > Fetching Packages.gz over modem is a pain in the arse. Having it > only rsync the changes would be so nice. Exactly. I use `testing' via a slow modem link, and I'd like to update frequently, to keep individual updates as small as possible (testing does a reasonable job of avoiding the `flurry of bug-fix releases' problem) -- but the huge Packages.gz file means that updates are _never_ small... -Miles -- Love is a snowmobile racing across the tundra. Suddenly it flips over, pinning you underneath. At night the ice weasels come. --Nietzsche
Re: [Gaim-devel] Re: Gaim-Encryption plugin violates Gaim's license#
On Monday 02 June 2003 23:31, Sean Egan wrote: > "If the program dynamically links plug-ins, and they make function calls > to each other and share data structures, we believe they form a single > program, so plug-ins must be treated as extensions to the main program. > This means they must be released under the GPL or a GPL-compatible free > software license, and that the terms of the GPL must be followed when > those plug-ins are distributed." > --http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins ... or not be released/distributed at all, which is what a source-only distribution aims at sneaking around. Uli
Re: Packages file under version control
On Tue, Jun 03, 2003 at 05:10:24PM +1200, Corrin Lakeland wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Tue, 03 Jun 2003 13:59, Glenn McGrath wrote: > > If we put the Packages file under some sort of version control (e.g. > > cvs), bandwidth requirments would be minimised as cvs automatically > > takes care of diff's and patching, and i assume the CPU load from cvs > > server is a lot better than rsync. > > You could use cvsup rather than cvs to reduce load further. But > ideally you'd just use rsync and make the gzip using --rysncable... > However, given the packages.gz file is much smaller than the total > files being downloaded, is it really worth it? When the mirrors sync, yes, when the average user runs # apt-get update # apt-get -u upgrade No. Fetching Packages.gz over modem is a pain in the arse. Having it only rsync the changes would be so nice. /David -- o/~ It would be so nice, it would be so nice o/~ o/~ It would be so nice to meet some time o/~ Five brownie points to the first to guess the artist...
Re: console mode(probally off)
On Jun/03, Adam Borowski wrote: > It might be just me, but my eyes hurt more after a few hours of doing > things in graphics mode than after a 48h straight programming run on a > text console. It might be just you :-) I think that depends very much on the quality of your monitor (both "crispness" and refresh). Text mode works usually at 70Hz, while in graphics mode you can achieve, in a <3 year old monitor, 100Hz at 640x480. If you can use framebuffer and change its resolution (i.e., not with standard VESA fb), you could use that resolution and you should be able to have the same 48h "uptime" that you had with text mode :-) If you don't have a graphics card with native support for framebuffer, you could try svgatextmode and achieve similar results. It could also be because of the size of the fonts. I had a tendence to use small fonts in X, so I could have more information on screen. No more. Now I use big fonts (14-16 points), and having a 1024x768 resolution I can still maintain 80Hz in my crappy Compaq V75 monitor :-) -- Roberto Suarez Soto Alfa21 Outsourcing [EMAIL PROTECTED]http://www.alfa21.com
Re: Celebrating Debian's 10th birthday?
Ben Burton wrote: >>Are there any parties planned already? ;) > > > Well, it coincides with the first day of the international olympiad in > informatics, so with all the computer geeks around I'm hoping there will > be someone else there to celebrate with. :) > > Ben. > > Hey, Do you want to hold a small party in IOI? Although the Hong Kong team of IOI have not been selected yet, I hope there will have some debian user(s) there to have the party with you. Ben Lau
Re: Debian conference in the US?
Branden Robinson <[EMAIL PROTECTED]> writes: > (Not saying you're a nationalist, Manoj.) Even worse, you're comparing him to Ayn Rand! -Miles -- "I distrust a research person who is always obviously busy on a task." --Robert Frosch, VP, GM Research
Re: console mode(probally off)
On Tue, Jun 03, 2003 at 02:47:09AM +0200, Adam Borowski wrote: > As a completely unrelated note, I wonder what is the reason to use fbdev > instead of real text console/svgatextmode in the default kernel. i18n. A 'normal' text mode doesn't allow for CJK charachters to be displayed. [...] > What about reverting the installation kernels back to the good old real > text console, which has been enjoyed full hardware acceleration since > the times of MDA cards? I won't stop you, but probably asian people would. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts. pgp7MJfNnPm0e.pgp Description: PGP signature
Re: Debian conference in the US?
On Sun, May 25, 2003 at 07:39:07PM +0200, Sven Luther wrote: > Notice that the US governement never said that was their aim, they said > Iraq was dangerous because they have mass destruction weapons and > support terrorism, which has turned out to be blatant lie. The french > governement opposed this, because they felt that the UNO investigators > were enough to prove that Iraq had (or had not) mass destruction > weapons. (Sigh, hopelessly off-topic.) My theory: Britain and the U.S. wanted to invade Iraq so that oil contracts more favorable to large petroleum companies that strongly influence their governments could be written. France and Russia wanted to preserve the status quo because large petroleum companies that strongly influence their governments already *had* very favorable oil contracts. Yes, It Really Was All About Oil. All this talk of principle, self-determination, brutal dicators, and inspections was window-dressing and a distraction from the real issues. The only people who felt deeply about it were the people who had no real power over the situation, like protestors in the streets. It was also a case of "Meet the New Boss, Same as the Old Boss." Iraq was largely run by oil companies and will continue to be for the forseeable future. All that have or will change are the logos on the employees' uniforms. The Americans and the French aren't so different. Just ask the Vietnamese. -- G. Branden Robinson|You can have my PGP passphrase when Debian GNU/Linux |you pry it from my cold, dead [EMAIL PROTECTED] |brain. http://people.debian.org/~branden/ |-- Adam Thornton pgp8x5JugW9VL.pgp Description: PGP signature
Re: Debian conference in the US?
On Sun, May 25, 2003 at 11:59:32AM -0500, Manoj Srivastava wrote: > > and he will try to harm any other people is someone tell him that it > > helps USA. His approach is completely nationalistic. You cannot > > understand him and agree with him until he drops this attitude or > > until you adopt it. > > Considering I am an Indian, this is getting hilarious; the US > is merely my country of adoption. Actually, I am given to understand that many immigrants are more passionate nationalists about their adopted country than native-born folks are of their default country. This makes sense when once considers that many immigrants to a country have to make some sort of sacrifice to get there and stay there, which makes them more likely to seek justifications for their decision. It's human nature; people are passionate about their choice of automobile or computer for similar reasons -- they represent a relatively large outlay of capital (or a relatively large assumption of debt), and people are loath to second-guess their decisions under such circumstances, lest they be characterized as "suckers". Look at the example of Ayn Rand, for instance. (Not saying you're a nationalist, Manoj.) -- G. Branden Robinson| Debian GNU/Linux | Please do not look directly into [EMAIL PROTECTED] | laser with remaining eye. http://people.debian.org/~branden/ | pgpQh1kC61I4f.pgp Description: PGP signature
Re: Packages file under version control
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 03 Jun 2003 13:59, Glenn McGrath wrote: > If we put the Packages file under some sort of version control (e.g. > cvs), bandwidth requirments would be minimised as cvs automatically > takes care of diff's and patching, and i assume the CPU load from cvs > server is a lot better than rsync. You could use cvsup rather than cvs to reduce load further. But ideally you'd just use rsync and make the gzip using --rysncable... However, given the packages.gz file is much smaller than the total files being downloaded, is it really worth it? Corrin -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+3C3Ai5A0ZsG8x8cRAiEwAKCHGsT0VUFTIjaCdO5xJWZASNUr4wCdGr1+ tFEWkO4/9+VRpwmpBe3KO7Y= =Vom/ -END PGP SIGNATURE-
