Re: Using pbuilder to test packages with gcc-snapshot
On Thu, Nov 13, 2008 at 08:19:38PM -0600, Kumar Appaiah wrote: > I was wondering if you could suggest a nice way to use pbuilder to > test package builds with gcc-snapshot. Just a note to point out that sbuild supports the use of gcc-snapshot without any special configuration. Just add the --use-snapshot option and it will make sure it's installed, and alter the build environment to use it in place of the default gcc. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: zoo: directory traversal security bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jose Carlos do Nascimento <[EMAIL PROTECTED]> writes: > I thought to be a mantainer I just must know debian-policy, how to > create Debian package,, how to create docs,etc . > I read many Debian Docs, and I didnt read anything about people must > be C, python, php ,etc developer. Being a maintainer is more than knowing good packaging practices. If you aren't able to dive into the source and tinker with it, you won't be able to investigate user bug reports and patch them, evaluate patches others provide, selectively include upstream changes to fix bugs, deal with security issues, etc.. If you can't hack on the source, you can only do ¼ of what the job requires. What if a porter reports a platform-specific bug, and it requires you to investigate and patch it? If you can't understand what you are packaging, you shouldn't be packaging it, IMHO. - -- 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.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFC1vDzVcFcaSW/uEgRAnn2AKC17XrJYUxBE5mqR9eXjpw88Tlk8QCfWci8 M99r3+Le5rvbibOOJ9IBWyw= =638J -END PGP SIGNATURE-
Moving conffiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, Is there a recommended way of changing the location of a conffile while still preserving user modifications? In this case, I'd like to move /etc/schroot.conf to /etc/schroot/schroot.conf. Thanks, 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.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFDJB1QVcFcaSW/uEgRApVnAJ0SXfBu3zm2U0GsrsbXg0vpzz/AEwCgufZ1 hdnv3Yx64MyG/B5awE2KsPY= =JgmE -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving conffiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kilian Krause <[EMAIL PROTECTED]> writes: > Hi Roger, > > Am Sonntag, den 11.09.2005, 13:04 +0100 schrieb Roger Leigh: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi folks, >> >> Is there a recommended way of changing the location of a conffile >> while still preserving user modifications? >> >> In this case, I'd like to move /etc/schroot.conf to >> /etc/schroot/schroot.conf. > > mv? Alternatively cp -a&&rm. Yes, but I want to properly comply with policy. I only want to do the copy on upgrade if the conffile is (a) untouched and (b) the original exists. I'm not sure this is sufficient, though, and others must have needed to do this in the past. Thanks, 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.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFDJCDzVcFcaSW/uEgRAjYkAJ4ljo1cEP4Az4yCNwffnrsZ2Fq6JACgwnD3 4S/XPa0yXpoRCN5DOEUz4vY= =H2eB -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Moving conffiles
Kilian Krause <[EMAIL PROTECTED]> writes: >> >> In this case, I'd like to move /etc/schroot.conf to >> >> /etc/schroot/schroot.conf. >> > >> > mv? Alternatively cp -a&&rm. >> >> Yes, but I want to properly comply with policy. I only want to do the >> copy on upgrade if the conffile is (a) untouched and (b) the original >> exists. I'm not sure this is sufficient, though, and others must have >> needed to do this in the past. > > well, see the debian policy about maintainer scripts, find the place > where you have the upgrade path as described and do as you say. OK, I'll do something like this. There's not much point in asking the user, because it always needs doing. Thanks, Roger if [ "$1" = "configure" ]; then # Move the configuration file to the new location. if [ -f /etc/schroot.conf ]; then echo "Moving /etc/schroot.conf to new location /etc/schroot/schroot.conf" mv /etc/schroot.conf /etc/schroot/schroot.conf fi elif [ "$1" = "abort-upgrade" ] || [ "$1" = "abort-remove" ] || [ "$1" = "abort-deconfigure" ]; then : else echo "postinst called with unknown argument \`$1'" >&2 exit 0 fi -- 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Putting accented characters in manpages?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rogério Brito <[EMAIL PROTECTED]> writes:
> So, I guess that's not only me that would benefit from some light from
> people from debian-mentors on what is the best-current-practice on
> getting accented characters on manpages.
man groff_char
For example, to write your name use "Rog\['e]rio Brito", or for full
AT&T troff compatibility, use "\('e" (\[] is groff-specific).
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/>
iD8DBQFDSOy8VcFcaSW/uEgRAu6ZAKClwosEcyiqdRF17axRubv5QcbubwCdHegD
yE8JYbVkm1a1u4PbQG5t/WI=
=jDqy
-END PGP SIGNATURE-
Re: RFS: directnet -- A serverless, mesh network instant messaging client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Hutchings <[EMAIL PROTECTED]> writes: > Thijs Kinkhorst wrote: >> On Tue, January 3, 2006 09:47, Gregor Richards wrote: >> > I updated the package to 1.0.0. The version compare algorithm doesn't >> > like it ... it thinks that 1.0.0 is less than 1.0.0rc5 ... but that's not >> > how release candidates work :) >> >> That's indeed a caveat on the Debian version compare algorithm. When >> you're packaging a release candidate, you normally should watch out for >> adding 'rcN' to the version to avoid being able to update it to the real >> version later. >> >> What's done commonly is something like this: 0.9.9+1.0.0rc5, or for a >> higher version: 2.4.3+2.4.4rc1. > > I believe this practice has been obsolete since the release of sarge. > dpkg now considers "~" to sort before anything, even a null string, so > you can use e.g. "1.0.0~rc5". The last time I checked, the archive infrastructure couldn't cope with this, so while you could build and install, you couldn't upload packages with a '~' in the version. It may be the situation has now changed; hopefully someone might be able to clarify that. 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/> iD8DBQFDuxRKVcFcaSW/uEgRAo3lAKDFjd2CP/H1TTb28N7st7Q2uW4T1gCg2bW+ FwpOAsDOroSxamNrPJBdvuM= =quTe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: looking for a sponsor
john aikins <[EMAIL PROTECTED]> writes: [nothing] It's customary to provide details of what you would like sponsoring, plus pointers to the sources. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpXxPm6h7SjW.pgp Description: PGP signature
Re: C Tutorial ?
Michelle Konzack <[EMAIL PROTECTED]> writes: > Since I am using Debian GNU/Linux since 1999 (Slink, 2.1) > successfuly, my four daughters (17, 14, 12 and 7years) too... > > Now Laila (14) want to start coding in C and GTK and she need > really good tutorials (with real examples). OK, we have found > allready "libgtk2.0-doc" which is perfectl written. Note that programming GTK+ in C is not "C programming", it's "GObject programming". This requires that you know not only about how objects are implemented on a fundamental level by the C++ compiler (virtual method despatch with vtables, typeinfo, inheritance, polymorphism, RTTI etc.), but how to re-implement these concepts in C. And, in addition, several features from smalltalk such as properties. If your daughter wants to learn C, that's great, but GTK+ isn't really what you do first with C; it's what you do once you've mastered C *and* C++, and then decided to use C instead. I.e. it's not something you would want to intimidate a beginner with (or many experienced programmers!), and is not generally a good choice. If it was me, I'd stay with PyGTK! For learning "plain" ISO C, I would suggest one of the many C books that cover all the C89 language basics. If it covers C99, that's even better. If she still wants to learn to use GTK+, she might find this useful: http://people.debian.org/~rleigh/gtk/ogcalc/ (PDF and source code examples) Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpKmoRQXeEei.pgp Description: PGP signature
Re: C Tutorial ?
Jon Dowland <[EMAIL PROTECTED]> writes: > At 1146961412 past the epoch, Roger Leigh wrote: >> Note that programming GTK+ in C is not "C programming", >> it's "GObject programming". This requires that you know >> not only about how objects are implemented on a >> fundamental level by the C++ compiler (...), but how to >> re-implement these concepts in C. And, in addition, >> several features from smalltalk such as properties. > > I disagree here. You do not need to know about most of the > OO/C++ concepts you list in order to *use* GTK+, at least in > a superficial sense. Some of them (properties) are needed > for non-trivial programs, but low-level stuff like vtables > etc. are hidden from you quite well. I would argue that to build anything more complex than a trivial "hello world" application, comprehensive knowledge of GObject/GType is a requirement. If you look at any GNOME application (gnumeric is a good example), it is a set of objects all derived from GObject or GtkWidget and their derived types, and the working application is a collection of these objects linked together with e.g. signals and containment. That said, it's hard and error prone, which is why I abandoned C GTK+ development last year in favour of python. It's IMO the main cause of bugs, because the compiler just can't catch many mistakes. If you do use the C API, you end up expending a great deal of energy for relatively little gain compared with using one of the other language bindings. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gutenprint.sourceforge.net/ Debian GNU/Linuxhttp://www.debian.org/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. pgpIamTLj5OSq.pgp Description: PGP signature
Re: build-indep and buildd
On Wed, Feb 01, 2012 at 12:18:00PM +0100, Mathieu Malaterre wrote: > Could someone please gives an update on the status of build-indep > target and buildd machine ? I am using the following pattern (as per > dh documentation): > >#!/usr/bin/make -f >%: >dh $@ > >override_dh_auto_build-indep: >$(MAKE) -C docs > ># No tests needed for docs >override_dh_auto_test-indep: > > However buildd machine are still running -indep target. I'd like to > test my package first on my local machine to mimic what would a buildd > machine do (I cant find the dpkg-buildpackage command line option used > for buildd) I would make sure you are Build-Depending upon a new enough debhelper; some versions were buggy until recently. The earliest non-broken version is 8.9.10, though at this point >= 9 is probably best. To test outside a buildd, run "dpkg-buildpackage -b" to check that it's working correctly in addition to plain dpkg-buildpackage. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201125204.gb8...@codelibre.net
Re: build-indep and buildd
On Wed, Feb 01, 2012 at 01:59:41PM +0100, Jakub Wilk wrote: > * Roger Leigh , 2012-02-01, 12:52: > >>Could someone please gives an update on the status of > >>build-indep target and buildd machine ? I am using the following > >>pattern (as per dh documentation): > >> > >> #!/usr/bin/make -f > >> %: > >> dh $@ > >> > >> override_dh_auto_build-indep: > >> $(MAKE) -C docs > >> > >> # No tests needed for docs > >> override_dh_auto_test-indep: > >> > >>However buildd machine are still running -indep target. I'd like > >>to test my package first on my local machine to mimic what would > >>a buildd machine do (I cant find the dpkg-buildpackage command > >>line option used for buildd) > > > >I would make sure you are Build-Depending upon a new enough > >debhelper; some versions were buggy until recently. The earliest > >non-broken version is 8.9.10, though at this point >= 9 is > >probably best. > > But that of course won't help, as dpkg-buildpackage doesn't use > build-indep. Argh. I keep forgetting it's still calling build. Hopefully soon now... In the meantime, you can test the targets by hand. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120201130729.gc8...@codelibre.net
Re: looking for debian developers in manchester to sign my key
On Sun, Feb 19, 2012 at 08:07:57PM +, peter green wrote: > I have been encouraged to apply to become a debian developer by > Steve McIntyre and Hector Oron. > > However before I can do so I need to get my GPG key signed by a > couple of debian-developers. > > Also can someone confirm whether all 4096 bit RSA keys are "sha2 > capable" and if not how I check whether my key is "sha2" capable. I > don't want to waste peoples time requesting signatures on a key that > turns out to be unsuitable for debian. I believe so. But to test, just try signing a file with e.g. "gpg --clearsign", and check the hash at the top. It's also possible to configure gpg to use different hashes, but in my experience, it defaults to SHA2[56] with 4096 bit RSA with current GnuPG versions. > I am currently a PHD student at the university of manchester than > the uni would be my preffered meeting location though I will also > consider other public places. I do not want to travel to the home of > someone I do not know. I'm not in Manchester, I'm afraid; I'm a researcher at the University of York. If you did want to venture out of Manchester, I would certainly be willing to meet up in York, and there are other DDs also in York who would be happy to meet up for keysigning; probably even more so if it involved meeting up in a nice pub (of which York has many)! (I got my key signed by Paul Martin originally in Manchester... in April 2002... yikes! and had to travel to Manchester for the day to meet him. My first and only tour around an ISP!) Also, FYI, there's a Debian-UK mailing list. You might have more success asking there. And as a developer in the UK, you would also be welcome on the list in any case. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120219205709.gl26...@codelibre.net
Re: Status of B-D-I ?
On Mon, Apr 02, 2012 at 04:03:10PM +0200, Mathieu Malaterre wrote: > Hi mentors, > > I am starring at the buildd status page of mrmpi: > > https://buildd.debian.org/status/package.php?p=mrmpi > > I cannot make any sense of the results on armel, armhf, i386, ia64, > mips and powerpc. Why are those arch running *-indep rules ? It depends on the version of dpkg in use on the buildd. Until recently, dpkg-buildpackage would run 'debian/rules build', rather than 'debian/rules build-arch' which will typically run build-arch build-indep. If you're using proper build-arch and build-indep targets in your package, this is most likely a transient failure--you could use an explicit versioned build-dep on dpkg-dev to avoid it. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120402143136.gm30...@codelibre.net
Bug#678705: RFS: e2defrag/0.80 ITP: #678598
On Sat, Jun 23, 2012 at 05:03:39PM -0400, Phillip Susi wrote: > I am looking for a sponsor for my package "e2defrag". This package used to > be known as defrag, and was removed from the archive back in 2008 due to > being abandoned by its authors and rotting for many years. I have taken over > maintainership of it and would like to get it back into the archive. Have you taken over upstream maintainership as well? This was always a tool which needed to be used with great caution, and was removed for good reason. Is this safe to use with all ext2, ext3 and ext4 filesystems? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120624160010.gh9...@codelibre.net
Re: Bug#678705: RFS: e2defrag/0.80 ITP: #678598
On Sun, Jun 24, 2012 at 09:14:47PM -0400, Phillip Susi wrote: > Exactly. I was planning on announcing it once it's in the archive to call > for testing and feedback. The usage of experimental is still unclear to me. If it's of release quality, then use unstable. If it needs wider testing before you're confident it can go into unstable, then upload to experimental so others can try it out. But if it is known to eat filesystems, then it's not suitable for either, really. Do we actually need an ext2 defragmenter? I don't want to sound too pessimistic, but maintaining the integrity of a filesystem is perhaps one of the most critical functions of the system, and e2defrag has a bad history here--I'd need quite some convincing before I'd consider it safe to include in Debian for end-users to use. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120625083904.gn9...@codelibre.net
Re: Moving /home of a package account, and to where?
On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote: > Hi, > > Debian QA decided recently that it is bad to have a system/package > account created with its home directory in /home/package, as it is > adduser --system's default btw. I am therefore faced with having to > change /home to some non-/home place. Unfortunately, policy does not > give any hint about how to do it right. > > Where do I put my user's home directory? In this case, the user's home > directory contains a .ssh with known_hosts, authorized_keys and actual > keys and it might additionally accumulate some regular dotfiles. I'd go with /var/lib, which is what most packages do. I don't count the user-specific stuff to be package configuration, in general. % getent passwd | grep /var/lib gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh libuuid:x:100:101::/var/lib/libuuid:/bin/sh statd:x:102:65534::/var/lib/nfs:/bin/false dictd:x:107:114:Dictd Server,,,:/var/lib/dictd:/bin/false postgres:x:111:121:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash sbuild:x:115:124:Debian source builder,,,:/var/lib/sbuild:/bin/bash buildd:x:116:125:Debian build daemon,,,:/var/lib/buildd:/bin/bash ntop:x:118:128::/var/lib/ntop:/bin/false Debian-gdm:x:120:132:Gnome Display Manager:/var/lib/gdm3:/bin/false colord:x:123:135:colord colour management daemon,,,:/var/lib/colord:/bin/false Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701120417.gp9...@codelibre.net
Re: Moving /home of a package account, and to where?
On Sun, Jul 01, 2012 at 02:56:13PM +0200, Marc Haber wrote: > On Sun, Jul 01, 2012 at 01:04:17PM +0100, Roger Leigh wrote: > > On Sun, Jul 01, 2012 at 12:44:48PM +0200, Marc Haber wrote: > > > Debian QA decided recently that it is bad to have a system/package > > > account created with its home directory in /home/package, as it is > > > adduser --system's default btw. I am therefore faced with having to > > > change /home to some non-/home place. Unfortunately, policy does not > > > give any hint about how to do it right. > > > > > > Where do I put my user's home directory? In this case, the user's home > > > directory contains a .ssh with known_hosts, authorized_keys and actual > > > keys and it might additionally accumulate some regular dotfiles. > > > > I'd go with /var/lib, which is what most packages do. I don't count > > the user-specific stuff to be package configuration, in general. > > .ssh is used to log in to another system running my package, it holds > manually created authorized_keys and keys. I'd call that configuration. Yes, but it's user configuration not system configuration. If you do want to have that as configuration in /etc, I'd suggest symlinking it from /var/lib/foo to /etc/foo/authorized_keys (or vice versa), like e.g. postgresql handles cluster configuration. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120701132905.gq9...@codelibre.net
Re: Copyright problems for the opensource reimplementation of a closed-source library (ITP #679504)
On Fri, Jul 06, 2012 at 11:35:34AM +0200, Christophe-Marie Duquesne wrote: > I want the libary to be a fully compatible runtime and compile-time > replacement for the closed-source one, so I have no choice but to use > the exact same symbol names in my header. What I do is I take the > header of the closed-source library, wipe out the comments and > elaborated macros, and then implement all the functions of the exposed > API in a .c file. As a consequence, there is very little actual > difference between my header and the one of the closed-source library. To avoid any implication that anything from the headers has been copied, why not just use the output of "nm [-D]". This is the interface that programs use to link with the library, and is what you need to provide as a drop-in replacement. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120706124012.ga25...@codelibre.net
Re: RFS: xinetd
On Sat, Aug 04, 2012 at 08:05:08PM +0200, Salvo Tomaselli wrote: > > > Generally, you should only seek a freeze exception for an upload > > containing strictly backported fixes for RC bugs and release goals. > > New upstream versions, minor bug fixes and packaging improvements > > should be omitted if you're targeting the release. > > this bug[1], which is the only one that could be more serious, isn't RC, so > the upload should only target sid i guess. There's always the option of using experimental; you can then put it into unstable once we've released wheezy. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120804182650.gt25...@codelibre.net
Re: RFS: xinetd
On Mon, Aug 06, 2012 at 12:09:51AM +0200, Salvo Tomaselli wrote: > > > There's always the option of using experimental; you can then > > put it into unstable once we've released wheezy. > > well an upload to sid would just stay in sid right? No implications with the > upcoming release... It complicates two things: 1) migration to testing of other packages. If other packages with versioned depends on your package get uploaded, xinetd will block their migration (since it won't be migrated) 2) if you need to update the xinetd in testing, you'll be forced to upload to testing-proposed-updates rather than unstable, and it'll complicate versioning and potentially managing a separate VCS branch Neither of these are showstoppers, but add extra complexity. > That way i would receive bugreports in case something is wrong. Guess not > that many people use experimental. You will still get bugreports for experimental. If you need testing, then users who wish to use the latest xinetd can get it if they wish. But at the moment, work on Debian isn't aimed at packaging the latest and greatest--we're frozen--so the focus is on testing and fixing what we have to make it releasable. So experimental is a fine place for new package versions until the freeze ends. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120805231857.gv25...@codelibre.net
Re: debian/rules stamp-* targets
On Mon, Sep 03, 2012 at 05:30:42PM -0400, The Wanderer wrote: > On 09/03/2012 02:56 PM, Igor Pashev wrote: > > >03.09.2012 21:53, Arno Töll пишет: > > > >>Hi, > >> > >>On 03.09.2012 18:55, The Wanderer wrote: > >> > >>>I have not been able to find any documentation on these stamp-* targets, > >>>although searching has revealed that they or something like > >>>them appear to be (or to have been) used in a number of other > >>>packages as well. What > >>>are they used for, and how "necessary" are they? > >> > >>They are entirely optional, in fact. It's a custom behavior to work around > >>issues with pseudo-phony targets which aren't declared as such for some > >>reason [1]. That's just one way (among many) to implement a debian/rules > >>file. > > > >I can also suggest to use *-stamp: such files will be removed by dh_clean > >automatically :-) > > From what I can see, the stamp-* files seem to be removed automatically as > well. At least by 'debian/rules clean' from that package, which appears to > simply run 'dh clean' as far as I can tell. And better, if you're using dh, it maintains its own internal stamp files so that you don't have to. -- .''`. Roger Leigh : :' : Debian GNU/Linuxhttp://people.debian.org/~rleigh/ `. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools `-GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120903220410.gk3...@codelibre.net
Re: RFS: magicfilter (QA update of the package) (fwd) (fwd)
On Mon, Apr 20, 2009 at 07:32:46PM -0300, Rogério Brito wrote: > Hi. > > Probably this was missed the past few times that I posted to the list. > > Please, could anybody sponsor it? I don't know if you already looked into this or already did it, but IIRC there's a new upstream for magicfilter which is actually maintained last time I looked. Are you just uploading a new version of the old magicfilter sources, or are you intending to package the new upstream? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFS: magicfilter (QA update of the package) (fwd) (fwd)
On Fri, Apr 24, 2009 at 08:05:34AM -0300, Rogério Brito wrote: > On Apr 22 2009, Roger Leigh wrote: > > > Are you just uploading a new version of the old magicfilter sources, > > or are you intending to package the new upstream? > > For this time, I just uploaded a new revision of the old magicfilter > sources, but I intend to package the v2.x quite soon, since I use low > profile print servers. > > Li Daobing has kindly sponsored the package for me. Cool. > Hummm, I see that gutenprint is orphaned (or RFA, I forgot) on wnpp. I'm > interested in the ijs plugin to ghostscript so that, dependind on the > architecture of magicfilter 2, I would like to combine those two. Oh, > and lprng too. OK. gutenprint is still RFA/Orphaned. I don't have the time to maintain it during my PhD, and I no longer have an inkjet printer, so I can't do any real testing. I'm still looking for a maintainer or comaintainer if you or anyone else is interested. It's all in git on collab-maint. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian clean?
On Mon, May 04, 2009 at 01:12:30PM -0700, Russ Allbery wrote: > Patrick Matthäi writes: > > Russ Allbery schrieb: > > >> Given that anyone can upload packages to mentors, this seems like a > >> fairly worrisome security risk. > > > Why that? It may be implemented as the current Debian buildd network. > > OpenSuSE is also providing such a buildd service for their users, but > > yeah, we need more buildd servers for that (if the pkgs should be > > realy build for every arch). > > Builds are conventionally done as root under sbuild, and you can break > out of chroots when you're root, thus enabling an attacker to upload a > package that compromises the security of the buildd. Agreed. Since sbuild nowadays can use schroot for building, the root access issue is mitigated somewhat since root is only used for installing build-deps and such. But the other issues you mentioned are still potentially hazardous. Previously you even had passwordless sudo access from inside the chroot on some systems! With the addition of copy-on-write chroots such as LVM snapshots and (not released yet but nearly done) union filesystems, the attacker would only have access to a transient filesystem which will be purged immediately after the build. Longer term, I'm also looking at integrating KVM (and I guess qemu) support which would provide a complete scratch system to avoid such issues. But not all arches can support this, and the attacker would still have user access to the build environment for the duration of the build. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: pbuilderrc BINDMOUNTS option
On Fri, Aug 07, 2009 at 12:31:11AM +0200, Jaromír Mikeš wrote: > I am using successfully this trick on my 32bit Ubuntu Hardy based machine for > building packages in pbuilder with local packages. > But when I run pbuilder --create process always fail like this ... > > I: mounting /proc filesystem > I: mounting /dev/pts filesystem > I: Mounting /var/cache/pbuilder/result/ > does not existdevice /var/cache/pbuilder/result/ > W: Aborting with an error > I: cleaning the build env > I: removing directory /var/cache/pbuilder/build//13596 and its subdirectories > rmdir: failed to remove `/var/cache/pbuilder/build//13596/dev/pts': Device or > resource busy > rmdir: failed to remove `/var/cache/pbuilder/build//13596/dev': Directory not > empty > rmdir: failed to remove `/var/cache/pbuilder/build//13596/proc': Device or > resource busy > rmdir: failed to remove `/var/cache/pbuilder/build//13596': Directory not > empty > > Is there something what I am missing? I was checking man pages and googling > but can't find out what is wrong. I don't use pbuilder, but there's probably two things going on here: 1) "does not existdevice /var/cache/pbuilder/result/" Does the mountpoint /var/cache/pbuilder/result exist to mount on to inside the chroot image? If it doesn't, mount will fail. 2) On error, /dev/pts, /dev and /proc were not umounted and/or deleted following umounting, which is why rmdir fails. This may be a pbuilder bug, where it isn't coping properly with failure? Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: can i use 'piuparts' within 'pbuilder'
On Thu, Aug 13, 2009 at 06:53:04PM -0400, Jonathan Yu wrote: > 2009/8/12 Leinier Cruz Salfran : > > hello dd. > > > > 1- can i use 'piuparts' within 'pbuilder'? > For what it's worth, Ryan Niebur (Ryan52) -- NM and DD candidate -- > has managed to hack piuparts to run inside a sbuild chroot. Sounds pretty cool! Once it's working and tested a bit more, feel free to run it past the buildd-tools-devel list if you want it integrated into sbuild proper. One thing I've been thinking about, and people have requested, is the ability to run checks after a successful build. Having a hookable mechanism to run lintian, piuparts etc. would be great. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Using ccache with sbuild/schroot
On Sat, Oct 24, 2009 at 08:07:04AM -0700, Ryan Niebur wrote: > On Sat, Oct 24, 2009 at 10:59:03AM -0400, Ryan Kavanagh wrote: > > Hi list, > > Has anybody setup ccache in an LVM schroot for sbuild and if so, how? My > > blocking point is that sbuild uses an LVM snapshot of the schroot to build a > > package, which means that any cached compiling would get lost at the end of > > the > > build. > > > > If anybody knows of a way to make this work, or to decrease compile times > > some > > other way, please let me know :) > > > > I set my environment for sbuild like this: > exec env PATH=/usr/lib/ccache:$PATH CCACHE_DIR=/home/ryan52/.ccache/ > DISTCC_HOSTS='10.0.0.10 10.0.0.17' CCACHE_PREFIX=distcc > DEB_BUILD_OPTIONS=parallel=4 "$@" > > /home/ (apparently by default, I don't think I did anything) is bind > mounted so this is preserved. That is the default. You can just edit /etc/schroot/mount-defaults (fstab format) to add additional bind mounts, or remove ones you don't want. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Man and UTF-8.
On Tue, Nov 17, 2009 at 10:53:52PM +0900, Charles Plessy wrote:
> Le Tue, Nov 17, 2009 at 05:31:29AM -0200, Rogério Brito a écrit :
> >
> > On Nov 17 2009, Charles Plessy wrote:
> > > Is there a way to put an indication in the manpage source code for the
> > > nroff parser, that the UTF-8 encoding is used?
> >
> > I don't know the answer to that. OTOH, if you only need to use accented
> > latin characters, you can use something like this:
> >
> > Rog\('erio Brito
> >
> > This is described in man 7 groff_char. Perhaps other characters are too.
>
> Hi Rog\('erio,
>
> this is the answer I was afraid reading :)
>
> In the manpage I wrote, I wanted to use English guillemets (‘’).
I use these in my manpages (e.g. schroot). I quote them using
\[oq] and \[cq], ('\(oq' and '\(cq' for compatibility with troffs
other than groff).
However, TTBOMK UTF-8 manpages should be OK as well, though I have
found some issues with more esoteric characters. I would suggest
reporting bugs or contacting the maintainer or groff upstream if
you run into problems here.
> This lead to
> errors and I gave up, replacing them by `'. Guess what? Groff understood what
> I wanted and put nice Unicode guillemets in the ouptut! I am quite amazed,
> even
> if it looks like a strange hack to me.
Ye gods, that's nasty. Should be removed IMO, since '`' is not and
never was an opening single quotation mark.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: Can /usr/share/doc/ be deleted on upgrade ?
On Thu, Nov 26, 2009 at 03:00:18PM +0100, Lucas B. Cohen wrote: > Of course I understand the standard files under doc/ (and even the whole > directory) are under dpkg's control (obviously the, changelog copyright, > etc.). But perhaps user's don't. Users don't have write access to anything under /usr in general (and /usr/share/doc in particular). If they did place files there, they must have done it after gaining root privs. I.e. they took deliberate steps to do something they should not under normal circumstances have been permitted to do. The user is clearly at fault here for writing "personal" data into a directory managed by the packaging system. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Debian changelog vs upstream changelog
On Thu, Nov 26, 2009 at 10:29:31PM +, Tony Houghton wrote: > What should go in a Debian changelog compared to the upstream changelog? > > (a) Confine it to "new upstream release", a list of any closed debian > bugs and packaging changes? > > (b) As above plus a summary of the most important upstream changes? I do mainly (a) and occasionally (b) where it bears some relation to the Debian packaging or is of noteworthy importance. > (c) Details of all the upstream changes too? I never do this, since it's already packaged in the upstream changelog.gz. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Can /usr/share/doc/ be deleted on upgrade ?
On Fri, Nov 27, 2009 at 03:13:35AM +1100, Matthew Palmer wrote: > On Thu, Nov 26, 2009 at 01:38:32PM +0100, Lucas B. Cohen wrote: > > Is it considered acceptable for a package to blindly delete, then > > recreate its entire directory under /usr/share/doc upon installation or > > upgrade ? > > I would consider it extremely unacceptable. Your package can fiddle with > files > it owns, but anything else is Right Out. This does sound odd, but I have in some cases needed to do this. For example, cupsys-driver-gimpprint used to generate PPD files on installation and would purge and re-create them on upgrade (under /usr/share/ppd/gimpprint/$version). Because these were not under the control of the packaging system, I felt that blindly removing that part of the tree was acceptable--nothing else would ever have a reason to alter or put anything in that location. Thankfully nowadays we no longer need to pre-generate that data so we can simply rely on dpkg to do its job. For static documentation, I don't think the same justification can be made, so I would agree it's unacceptable. Unless, in this specific case, the documentation is automatically generated through some other mechanism and this is the only reasonable way. But, if that was the case, I would still question if it couldn't be done at build time so dpkg could do its job. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: git-import-dsc and deleted files
On Wed, Dec 02, 2009 at 12:32:13PM +0100, Pietro Battiston wrote: > Hello, > > if in sid I do: > > apt-get source poedit > git-import-dsc poedit_1.4.2-5.dsc > cd poedit > git-buildpackage > > , it will complain about a lot of deleted files. What's happening?! > Shouldn't git-import-dsc import and commit _all_ changes in the debian > source package, even deletions? Yes, it's (I think) a bug, probably related to #506211. It should be fixed by using git-fast-import in the future. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Use, "Depends: locales-all|locales" or not
On Fri, Jan 08, 2010 at 12:36:44AM +0900, Osamu Aoki wrote: > Hi, > > On Wed, Jan 06, 2010 at 04:43:28PM -0800, Russ Allbery wrote: > > Ben Finney writes: > > > Russ Allbery writes: > ... > > > In a minimal ‘pbuilder’ environment, this is happening all the time for > > > me now. What should users of ‘pbuilder’ be doing to avoid this problem? > > > > Install locales in your chroot, specifically: > > > > echo 'locales locales/locales_to_be_generated multiselect en_US.UTF-8 > > UTF-8' \ > > | debconf-set-selections > > aptitude install locales > > I thought manual configuration of build environment should not be > done... Am I wrong? This is my understanding as well. My question here is why lintian is run inside the build environment at all, since it's run after the packages are built, and there shouldn't be any problem with this being run on the host system. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Use, "Depends: locales-all|locales" or not
On Thu, Jan 07, 2010 at 09:50:23AM -0800, Russ Allbery wrote:
> The package itself doesn't depend on locales in this case, though.
>
> The problem is that Lintian depends on locales, but it doesn't just depend
> on the locales package. Having locales installed doesn't help. Lintian
> specifically depends on having a UTF-8 locale available.
>
> The best solution is to do something that ensures a C.UTF-8 locale is
> always available. This would also help other problems in Debian.
You could add a check such as
if (strcmp(nl_langinfo(CODESET), "UTF-8") && // This one is sufficient on
Debian
strcmp(nl_langinfo(CODESET), "UTF8") &&
strcmp(nl_langinfo(CODESET), "utf-8") &&
strcmp(nl_langinfo(CODESET), "utf8"))
{
// Not in a UTF-8 locale, so some tests may not be correct
}
which would allow lintian to detect that some of its tests may
produce incorrect results.
> Absent that, we're considering adding some sort of ugly hack to Lintian to
> force the locales package to generate a UTF-8 locale if one isn't already
> available. Unfortunately, there's no straightforward way to do that in
> Debian without doing things that are kind of questionable.
You are free to call localedef and place the generated locale in a
temporary directory, then use that. Is that too ugly?
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: Use, "Depends: locales-all|locales" or not
On Thu, Jan 07, 2010 at 11:48:18AM -0800, Russ Allbery wrote: > Roger Leigh writes: > > On Thu, Jan 07, 2010 at 09:50:23AM -0800, Russ Allbery wrote: > > >> Absent that, we're considering adding some sort of ugly hack to Lintian > >> to force the locales package to generate a UTF-8 locale if one isn't > >> already available. Unfortunately, there's no straightforward way to do > >> that in Debian without doing things that are kind of questionable. > > > You are free to call localedef and place the generated locale in a > > temporary directory, then use that. Is that too ugly? > > No, that's cleaner than I thought it would be. How does Lintian then use > that locale (or, to be more precise, how does Lintian get man and the > programs man calls to use that locale), when it's not in the standard > system locale directory? AFAICT just set the LOCPATH environment variable and all programs will pick it up (in addition to LC_xxx to make your locale get used). You might not even need to restart lintian, since you can do the generation, set the environment and then just call setlocale() to start using it. It's mentioned in locale(5) and environ(7). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Use, "Depends: locales-all|locales" or not
On Thu, Jan 07, 2010 at 04:17:35PM -0800, Russ Allbery wrote: > Roger Leigh writes: > > > AFAICT just set the LOCPATH environment variable and all programs will > > pick it up (in addition to LC_xxx to make your locale get used). You > > might not even need to restart lintian, since you can do the generation, > > set the environment and then just call setlocale() to start using it. > > I think I'll just generate it in postinst so that it's always available. > It doesn't take that long to do. > > > It's mentioned in locale(5) and environ(7). > > It's actually not mentioned in locale(5) at all, at least on my system. > (Or in locale(7).) That was the first place I looked. It is mentioned, > but not defined, in environ(7). Thank you! Sorry, I meant to type "locale(1)", which has it in the environment section at the end. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: C.UTF-8 : udeb exist :-)
On Sat, Jan 09, 2010 at 12:32:29AM +0900, Osamu Aoki wrote: > PS: Do not ask me what is the difference between en_US.UTF-8 and C.UTF-8. They are only similar in that they share the UTF-8 charmap. They have different sort orders for LC_COLLATE (C is strictly numeric) They have different character classes for LC_CTYPE (C restricts to POSIX ASCII subset for digit classes, and there are other restrictions) C and en_US are otherwise similar, but you would use C.UTF-8 where you would have otherwise used the default C locale but with a UTF-8 charmap rather than ASCII. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Use, "Depends: locales-all|locales" or not
On Fri, Jan 08, 2010 at 10:50:25AM +0100, Adam Borowski wrote: > On Thu, Jan 07, 2010 at 09:50:23AM -0800, Russ Allbery wrote: > > The problem is that Lintian depends on locales, but it doesn't just depend > > on the locales package. Having locales installed doesn't help. Lintian > > specifically depends on having a UTF-8 locale available. > > > > The best solution is to do something that ensures a C.UTF-8 locale is > > always available. This would also help other problems in Debian. > > Hell yeah. Get the glibs folks to make C.UTF-8 built-in like "ISO-8859-1" > and "koi8-r" used to be, and you'll be my hero. In the past, those were > removed since they shouldn't be special cased above all other locales -- > but it's long overdue to give UTF-8 preferential treatment. > > And since the set_locale() call has to read multiple files, it takes over > 20% of typical process startup+shutdown time. I looked at the glibc codebase to try to do this. Unfortunately, I was defeated by lack of time and the complexity of the code. One weird thing is that all locale facets have the locale name embedded in AFAICT. This means that the ASCII charmap hard- coded in for C is only usable by C unless there's some trickery I'm unaware of. The implication is that you need a UTF-8 charmap for each UTF-8 locale you have in use! There's no sharing. I may be incorrect here, and hope I am, but that's what it looks like reading the locale sources. My main stumbling block is generating the C sources from the existing locale data. I presume since the C locale is so small it may have been hand-written, but the Unicode tables are huge. Does anyone have any ideas? The generated locale files are binary so aren't too accessible unless you can dump them as parsable plaintext. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Support for non UTF8 encodings
On Fri, Feb 26, 2010 at 03:35:20PM +0100, Julien Valroff wrote:
> A user recently reported a bug[0] regarding localized messages from
> rkhunter not being correctly displayed with other encodings than UTF-8.
>
> This is simply caused by the translations being encoded in UTF-8.
>
> UTF-8 being the default encoding for new installations, I am not sure
> whether other encodings should absolutely be supported. Am I right?
> What do you think of it?
There's no requirement that Unicode localised messages only use the
Unicode subset represented by the legacy encoding for the
locale/language. Otherwise, we would be stuck using limited character
sets for ever. The localisation machinery should however contain some
fallbacks (transliterations) for non-represented characters which are
a best effort, albeit lossy, conversion. For example, ‘“”’ → ‘""’.
That said, this doesn't look like this is what is happening in this
case. In this case, the localised messages are not being recoded
from UTF-8 to the locale charmap at runtime, and this is the cause
of the corrupted output. This is a bug. Localisation systems
such as gettext (what pretty much everything uses) will automatically
recode from the .po/.mo translation encoding to the locale encoding
('locale -k charmap'). If this isn't happening, rkhunter's
localisation is broken.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: Support for non UTF8 encodings
On Fri, Feb 26, 2010 at 04:14:27PM +, Roger Leigh wrote:
> On Fri, Feb 26, 2010 at 03:35:20PM +0100, Julien Valroff wrote:
> > A user recently reported a bug[0] regarding localized messages from
> > rkhunter not being correctly displayed with other encodings than UTF-8.
> >
> > This is simply caused by the translations being encoded in UTF-8.
> >
> > UTF-8 being the default encoding for new installations, I am not sure
> > whether other encodings should absolutely be supported. Am I right?
> > What do you think of it?
[...]
> That said, this doesn't look like this is what is happening in this
> case. In this case, the localised messages are not being recoded
> from UTF-8 to the locale charmap at runtime, and this is the cause
> of the corrupted output. This is a bug. Localisation systems
> such as gettext (what pretty much everything uses) will automatically
> recode from the .po/.mo translation encoding to the locale encoding
> ('locale -k charmap'). If this isn't happening, rkhunter's
> localisation is broken.
I can't see any evidence of a de translation in the source. I
can only see the Debian debconf translations in debian/po, and
some other type of translation in files/i18n (but no .de). That
directory does have two zh files (one for UTF-8, one other, maybe
BIG-5?). Looking at how rkhunter is doing its localisation
internally, it's just mapping to keys in this file, and there's
no recoding, which *is* buggy.
Personally, I'd just recommend that rkhunter should switch to
using GNU gettext, which can be called from shell scripts using
gettext(1), and will automatically do the necessary recoding.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: How to test a manpage? ‘ nroff -man | less’ does not display like ‘man ’.
On Wed, Jul 14, 2010 at 08:57:12AM +0200, Luca Falavigna wrote: > Il 14/07/2010 6.50, Charles Plessy ha scritto: > > Does anybody know how a more convenient to display a > > manpage the same way as users will get it by using ‘man’ ? > > groff -T ascii -man > zcat /usr/share/man/manX/XXX | groff -T ascii -m man You want '-T utf8' to match the output in the original question. And you also need to run it through the preprocessors. 'cat manpage.1 | tbl | eqn | pic | groff -T utf8 -man > manpage.txt' or use groffer(1) to automatically run the needed preprocessors. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: How to use --as-needed
On Wed, Nov 17, 2010 at 01:34:21PM +, Tony Houghton wrote: > How should one add --as-needed linker flags to an autotools-based > package? I ended up adding CFLAGS=-Wl,--as-needed to my > dh_auto_configure parameters but is it OK to just overwrite CFLAGS like > that, or should I add it to any existing CFLAGS? > > BTW, at first I tried LDFLAGS=--as-needed but automake/libtools passed > it to gcc without -Wl, which I thought wasn't very clever. I then used > CFLAGS because the -Wl makes it a gcc option, but OTOH it is explicitly > a linker option (according to the man page) so perhaps I should stick > with LDFLAGS after all? Check the rule in your generated Makefile.in (example): LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \ $(LDFLAGS) -o $@ You can see LDFLAGS is used, but --as-needed (and --no-as-needed) are /positional/ parameters. So you need --as-needed immediately before $(AM_LDFLAGS), which is why you see it working when added to $(CFLAGS). I would just add it to the front of AM_LDFLAGS. BTW, it's worth considering whether or not you actually need to use --as-needed, or if there are better ways of removing unwanted libraries (such as not linking them in in the first place). Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: How to use --as-needed
On Wed, Nov 17, 2010 at 03:12:35PM +, Tony Houghton wrote: > On 17/11/10 13:47, Roger Leigh wrote: >> On Wed, Nov 17, 2010 at 01:34:21PM +, Tony Houghton wrote: >>> How should one add --as-needed linker flags to an autotools-based >>> package? I ended up adding CFLAGS=-Wl,--as-needed to my >>> dh_auto_configure parameters but is it OK to just overwrite CFLAGS like >>> that, or should I add it to any existing CFLAGS? >>> >>> BTW, at first I tried LDFLAGS=--as-needed but automake/libtools passed >>> it to gcc without -Wl, which I thought wasn't very clever. I then used >>> CFLAGS because the -Wl makes it a gcc option, but OTOH it is explicitly >>> a linker option (according to the man page) so perhaps I should stick >>> with LDFLAGS after all? >> >> Check the rule in your generated Makefile.in (example): >> >> LINK = $(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) \ >> --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) \ >> $(LDFLAGS) -o $@ >> >> You can see LDFLAGS is used, but --as-needed (and --no-as-needed) >> are /positional/ parameters. So you need --as-needed immediately >> before $(AM_LDFLAGS), which is why you see it working when added >> to $(CFLAGS). I would just add it to the front of AM_LDFLAGS. > > AIUI AM_LDFLAGS is only meant to be used in Makefile.am (and not > guaranteed to be used anyway, if there are per-program flags) and you > should use LDFLAGS to pass in flags from an external command or script > such as debian/rules. Does it matter if --as-needed comes after other > flags as long as it's before the list of objects to link? Yes. You could, for example, have -Wl,--as-needed -lfoo -lbar -Wl,--no-as-needed -lbaz which would only apply it to libfoo and libbar. Where you want to do this depends upon what level you want to work at. You could patch the Makefile.am to to exactly what you want, and here you're free to tamper with AM_LDFLAGS etc, or even introduce entirely new variables which may be set/overridden later. If you're just passing flags in debian/rules then you're more limited. >> BTW, it's worth considering whether or not you actually need to use >> --as-needed, or if there are better ways of removing unwanted >> libraries (such as not linking them in in the first place). > > I think it's caused by pkg-config adding libraries that my binaries > don't depend on directly, but do depend on via the higher level > libraries they directly link with. Looking at the package dependencies > (for roxterm) there's nothing there that I'm not fairly certain is > needed so perhaps it would be best just to ignore the warnings? They are certainly harmless. Ideally, the dependency problem should be fixed on the pkg-config side by trimming what gets linked in by the GTK+ .pc files etc. It might be worth compiling with GCC 4.5 from experimental and also linking with the gold linker in place of the standard ld. These have stricter linking requirements, and it may be the case that with gold those extra libs may be needed. http://wiki.debian.org/ToolChain/DSOLinking (changes planned for wheezy, currently being discussed on -ports and -gcc; I don't agree with it all, mainly making --add-needed the default, but it's useful to know what's coming up after squeeze.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Build-Depends-Indep, please review
On Fri, Nov 19, 2010 at 04:40:57PM +0100, Goswin von Brederlow wrote: > David Kalnischkies writes: > > > On Thu, Nov 18, 2010 at 19:25, Ø£Ø٠د اÙÙ ØÙ Ùد٠> > wrote: > >> On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote: > >>> And as discussed before policy disagrees with reality in this. > >> > >> Would you please elaborate ? > > > > Goswin likely refers to this thread: Buildd & binary-indep > > http://lists.debian.org/debian-devel/2010/09/msg00590.html > > Message-id: <20100924204433.ga4...@apache.rbscorp.ru> > > > > > > Best regards > > > > David Kalnischkies > > And in short: > > Buildds install only Build-Depends but not Build-Depends-Indep but still > call the "build" target. In reality the "build" target must work with > only Build-Depends installed contrary to what policy says. I do hope this mess can be sorted out after squeeze is released. Mandating build-arch and build-indep would be a good thing, IMHO. It's not the buildd software that can change this though--the actual sticking point is dpkg-buildpackage, which is used by sbuild. sbuild is actually perfectly capable of installing Build-Depends-Indep and removing Build-Conflicts-Indep when invoked with the -A (build arch-all) option, but there are no buildds building arch-indep packages yet. If we ever throw away uploaded binaries and build everything on buildds, this would then be useful. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Build-Depends-Indep, please review
On Sat, Nov 20, 2010 at 01:29:12PM -0600, Boyd Stephen Smith Jr. wrote: > In <20101120183255.gf12...@khazad-dum.debian.net>, Henrique de Moraes > Holschuh > wrote: > >On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote: > >> >But hey, all the maintainer has to do is add 1, in words ONE, char to > >> >debian/rules. Just change "build:" to "build%:" and dpkg-buildpackage > >> >could use build-arch/indep targets instead of build. Aparently that is > >> >too much to ask. > >> > >> I volunteer to make /this/ fix to any package that is unmaintained or > >> whose maintainer is unresponsive, *if* Debian will change policy to > >> /require/ build- arch/indep and make dpkg-buildpackage use them instead > >> of build sometime after the Squeeze release and before the Wheezy freeze. > > > >It can be done, but it must be done in at least two steps: > > > >1. Make it SHOULD, start fixing packages. You don't have to wait for the > > SHOULD to start fixing packages, either. > > I'm not willing to manually test random packages for this breakage. What's > the best way to get an automated process to report on the PTS or BTS the > existence of build-arch and build-indep? Could it simply be a lintian test? > > Also, I thought it was already a SHOULD. > > >2. When almost everything is fixed, make it MUST. Whatever doesn't get > > fixed after that, gets axed from the next stable. > > My time was volunteered (in my last posting) *after* it becomes a MUST, but > with some help I might be willing to put some time in as part of a DEP. Two suggestions: 1) Use the lintian lab on lintian.debian.org (/srv/lintian.debian.org/laboratory) which contains all 15796 unpacked source packages. Alternatively, download and unpack them all on your own machine [] You can write a script to check for the presence of build-arch: and/or build-indep: Note: this won't pick out make pattern rules which don't have (directly) those named rules, so you might want to check for build% etc. There are other special cases such as included Makefiles when packages use cdbs etc., so you will get false positives that need manual review. Example: find . -type f -name rules | grep 'debian/rules$' | while read rule; do egrep -H '^(build(.*%)?|build-(arch|indep)):' "$rule"; done gives you somewhere to start. 2) Directly patch dpkg-buildpackage and do a whole-archive rebuild. If you patch dpkg-buildpackage to require build-arch and build-indep in place of build, you can then build every source package and get success or failure. This can be done fairly trivially by scripting sbuild to build all sources with the new dpkg-buildpackage installed in the build chroot. There's also rebuildd for use with pbuilder/cowbuilder if you prefer that. This will take much longer, but should be 100% reliable bar FTBFS bugs. If there was a reliable way of getting make to tell you if a target rule exists or not, that would be much quicker than doing a full rebuild. Additionally, it could be added to lintian to warn people about the requirement. Totally agree with hmh about making it a SHOULD in Policy followed by MUST. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Build-Depends-Indep, please review
On Sat, Nov 20, 2010 at 08:23:59PM +, Roger Leigh wrote: > On Sat, Nov 20, 2010 at 01:29:12PM -0600, Boyd Stephen Smith Jr. wrote: > > In <20101120183255.gf12...@khazad-dum.debian.net>, Henrique de Moraes > > Holschuh > > wrote: > > >On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote: > > >> >But hey, all the maintainer has to do is add 1, in words ONE, char to > > >> >debian/rules. Just change "build:" to "build%:" and dpkg-buildpackage > > >> >could use build-arch/indep targets instead of build. Aparently that is > > >> >too much to ask. > > >> > > >> I volunteer to make /this/ fix to any package that is unmaintained or > > >> whose maintainer is unresponsive, *if* Debian will change policy to > > >> /require/ build- arch/indep and make dpkg-buildpackage use them instead > > >> of build sometime after the Squeeze release and before the Wheezy freeze. > > > > > >It can be done, but it must be done in at least two steps: > > > > > >1. Make it SHOULD, start fixing packages. You don't have to wait for the > > > SHOULD to start fixing packages, either. > > > > I'm not willing to manually test random packages for this breakage. What's > > the best way to get an automated process to report on the PTS or BTS the > > existence of build-arch and build-indep? Could it simply be a lintian test? > > > > Also, I thought it was already a SHOULD. > > > > >2. When almost everything is fixed, make it MUST. Whatever doesn't get > > > fixed after that, gets axed from the next stable. > > > > My time was volunteered (in my last posting) *after* it becomes a MUST, but > > with some help I might be willing to put some time in as part of a DEP. > > Two suggestions: > >r 1) Use the lintian lab on lintian.debian.org >(/v/lintian.debian.org/laboratory) which contains all 15796 unpacked >source packages. Alternatively, download and unpack them all on your >own machine [] > >You can write a script to check for the presence of build-arch: >and/or build-indep: >Note: this won't pick out make pattern rules which don't have >(directly) those named rules, so you might want to check for build% >etc. There are other special cases such as included Makefiles when >packages use cdbs etc., so you will get false positives that need >manual review. > >Example: find . -type f -name rules | grep 'debian/rules$' | while read > rule; do egrep -H '^(build(.*%)?|build-(arch|indep)):' "$rule"; done >gives you somewhere to start. Output at http://people.debian.org/~rleigh/build-rule-check.bz2 I haven't had time to analyse this, if someone else wants to, that would be cool. Done on lintian.debian.org using the following: #!/bin/sh cd /srv/lintian.debian.org/laboratory/source find . -type f -name rules | grep 'debfiles/rules$' | while read rule do egrep -H '^(build(.*%)?|build-(arch|indep)):' "$rule" done Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Build-Depends-Indep, please review
On Sun, Nov 21, 2010 at 07:09:44PM +0100, Goswin von Brederlow wrote:
> > Output at http://people.debian.org/~rleigh/build-rule-check.bz2
> > I haven't had time to analyse this, if someone else wants to,
> > that would be cool.
> >
> > Done on lintian.debian.org using the following:
> >
> > #!/bin/sh
> >
> > cd /srv/lintian.debian.org/laboratory/source
> > find . -type f -name rules | grep 'debfiles/rules$' | while read rule
> > do
> > egrep -H '^(build(.*%)?|build-(arch|indep)):' "$rule"
> > done
> >
> >
> > Regards,
> > Roger
>
> Now why does it only list 8k sources if it matches the required
> "build:" target? Are 50% of all sources already dropping through that
> grep because they use dh ('%:') or include files?
That's what I think, and a cursory look at a few gives the same
impression. Which is surprisingly good--there's only a single
tool to update to get support added for a huge chunk of the
archive (well, there's cdbs as well of course, so it's two main
ones).
> Anyway, grepping for sources that (probably) have build-arch/indep:
>
> % bzcat build-rule-check.bz2 | egrep
> '/rules:(build(.*%)+|build-(arch|indep)):' | cut -d":" -f1 | sort -u | wc -l
> 572
>
> Lots of work to do.
Agreed! But, should be an achievable goal for squeeze+1 if we start
on it early.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: Build-Depends-Indep, please review
On Mon, Nov 22, 2010 at 05:03:39PM +0100, Goswin von Brederlow wrote:
> Roger Leigh writes:
>
> > On Sun, Nov 21, 2010 at 07:09:44PM +0100, Goswin von Brederlow wrote:
> >>
> >> Now why does it only list 8k sources if it matches the required
> >> "build:" target? Are 50% of all sources already dropping through that
> >> grep because they use dh ('%:') or include files?
> >
> > That's what I think, and a cursory look at a few gives the same
> > impression. Which is surprisingly good--there's only a single
> > tool to update to get support added for a huge chunk of the
> > archive (well, there's cdbs as well of course, so it's two main
> > ones).
>
> I would think dh already supports them. So we might actuay have >50%
> coverage of binay-arch/indep already or verry close to it.
>
> Maybe we can actualy change policy post squeeze because the majority of
> sources supports it.
I checked, and dh currently doesn't support build-arch and build-indep
at all internally (you need to add the rules yourself). I've made a
patch to add proper support which I'll submit once I've tested it.
I've submitted a proposed change to Policy to require the use
of these targets (#604397), but we need at least 50% coverage first.
But, we'll get that as soon as dh and cdbs support it.
We also need a lintian check to warn if these targets are missing;
but I'm not at all familiar with hacking on lintian.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
Re: Build-Depends-Indep, please review
On Mon, Nov 22, 2010 at 04:39:20PM +, Roger Leigh wrote:
> I checked, and dh currently doesn't support build-arch and build-indep
> at all internally (you need to add the rules yourself). I've made a
> patch to add proper support which I'll submit once I've tested it.
FWIW, the current progress on this is attached. No guarantees--it's
totally untested.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
diff --git a/dh b/dh
index d2771ab..794ff4f 100755
--- a/dh
+++ b/dh
@@ -16,13 +16,15 @@ B I [B<--with> I[B<,>I ...]] [B<--list>] [B<--until>
=head1 DESCRIPTION
B runs a sequence of debhelper commands. The supported Is
-correspond to the targets of a F file: B, B,
-B, B, B, and B.
+correspond to the targets of a F file: B,
+B, B, B, B, B,
+B, and B.
-Commands in the B sequence are passed the B<-i> option to ensure
-they only work on binary independent packages, and commands in the
-B sequences are passed the B<-a> option to ensure they only work
-on architecture dependent packages.
+Commands in the B and B sequences are passed
+the B<-i> option to ensure they only work on binary independent packages,
+and commands in the B and B sequences are
+passed the B<-a> option to ensure they only work on architecture
+dependent packages.
If F contains a target with a name like BI,
then when it would normally run I, B will instead call that
@@ -322,6 +324,8 @@ $sequences{build} = [qw{
dh_auto_build
dh_auto_test
}],
+$sequences{'build-indep'} = [...@{$sequences{build}}];
+$sequences{'build-arch'} = [...@{$sequences{build}}];
$sequences{clean} = [qw{
dh_testdir
dh_auto_clean
@@ -367,19 +371,25 @@ $sequences{install} = [...@{$sequences{build}}, qw{
dh_compress
dh_fixperms
}];
+$sequences{install-indep} = [...@{$sequences{build-indep}}, @i];
+$sequences{install-arch} = [...@{$sequences{build-arch}}, @i];
my @b=qw{
dh_installdeb
dh_gencontrol
dh_md5sums
dh_builddeb
};
-$sequences{'binary-indep'} = [...@{$sequences{install}}, @b];
+$sequences{'binary-indep'} = [...@{$sequences{install-indep}}, @b];
$sequences{binary} = [...@{$sequences{install}}, qw{
dh_strip
dh_makeshlibs
dh_shlibdeps
}, @b];
-$sequences{'binary-arch'} = [...@{$sequences{binary}}];
+$sequences{'binary-arch'} = [...@{$sequences{install-arch}}, qw{
+ dh_strip
+ dh_makeshlibs
+ dh_shlibdeps
+}];
# Additional command options
my %command_opts;
@@ -514,14 +524,18 @@ my @packag...@{$dh{dopackages}};
# Get the options to pass to commands in the sequence.
# Filter out options intended only for this program.
my @options;
-if ($sequence eq 'binary-arch') {
+if ($sequence eq 'build-arch' ||
+$sequence eq 'install-arch' ||
+$sequence eq 'binary-arch') {
push @options, "-a";
# as an optimisation, remove from the list any packages
# that are not arch dependent
my %arch_packages = map { $_ => 1 } getpackages("arch");
@packages = grep { $arch_packages{$_} } @packages;
}
-elsif ($sequence eq 'binary-indep') {
+elsif ($sequence eq 'build-indep' ||
+ $sequence eq 'install-indep' ||
+ $sequence eq 'binary-indep') {
push @options, "-i";
# ditto optimisation for arch indep
my %indep_packages = map { $_ => 1 } getpackages("indep");
signature.asc
Description: Digital signature
Re: Build-Depends-Indep, please review
On Mon, Nov 22, 2010 at 04:42:03PM +, Roger Leigh wrote: > On Mon, Nov 22, 2010 at 04:39:20PM +0000, Roger Leigh wrote: > > I checked, and dh currently doesn't support build-arch and build-indep > > at all internally (you need to add the rules yourself). I've made a > > patch to add proper support which I'll submit once I've tested it. > > FWIW, the current progress on this is attached. No guarantees--it's > totally untested. Final tested patch in #604563. -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Workflow with debian/ in VCS
On Sun, May 15, 2011 at 10:46:00AM -0400, Nikolaus Rath wrote: > Am I missing a tool? Or is a bad idea to try to manage debian/ in a VCS? > Or should my repo also include the upstream source rather than just the > debian directory? I've never been a big fan of having just the debian/ directory under version control. It makes it a real pain to checkout a source package and work on it, and it also makes it impossible to use the VCS to manage the source package as a whole, making one of the major gains of a VCS redundant. Personally, I would have separate "upstream" and "debian" branches and import all the upstream releases onto the upstream branch. You can also use pristine-tar to recreate the orig.tar from the VCS (see git-buildpackage for example). You can then merge each new upstream release onto the debian branch and add the debian/ changes on top. This means that each debian/ change is tied to a specific upstream version, and you can merge new upstream releases easily and compare changes between upstream releases and different debian revisions etc. You can also have multiple upstream branches, so you can track development and stable releases. And you can do the same for debian, so you can maintain stable releases in unstable, development releases in experimental should you need to, and also handle stable point releases, backports etc. with ease. And because it's all in one place, you can cherry pick changes, branch and merge at will etc. You also gain (with git) signed tags for all upstream imports and debian releases, so you also have integrity checking and cryptographic validation of the entire thing as well. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [imagemagick] Strange bug in one of my packages need help (maybe glibc bug?)
On Wed, May 25, 2011 at 12:20:09PM +0200, Bastien ROUCARIES wrote: > Hi, > > I have two strange bug in my package imagemagick. I am really clueless about > these.upstream have no idea also. Any help welcome > see #625250 % c++filt _ZNSt14error_categoryD2Ev std::error_category::~error_category() % nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev 003380272800 T _ZNSt14error_categoryD2Ev % nm -C -D /usr/lib/libstdc++.so.6 | grep error_category 003380272800 T std::error_category::~error_category() This is on a sid system. On squeeze: $ nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev $ echo $? 1 If imagemagick was built against the current libstdc++ and run using an older libstdc++ without the symbol, you will get this error. I don't see any direct libstdc++ dependency in either the imagemagick package, or its library needed sections. What's using libdjvulibre? Is it being dlopened. If this is the case, libdjvulibre is using an old version of libstdc++, and that's an issue with its dependencies (and/or the libstdc++ symbol versioning). You'll need a full stack trace to work out what's using this library if you haven't done so already. > and #622591. For the latter, rebuild libuuid1 with debugging symbols and get a full stack trace. Probably not a bug in libuuid: make sure that the caller is passing a valid uuid_t. Here's how I use it: uuid_t uuid; char uuid_str[37]; uuid_generate(uuid); uuid_unparse(uuid, uuid_str); uuid_clear(uuid); Note that uuid_t is not a pointer, it's a char array which decays to a pointer: typedef unsigned char uuid_t[16]; You can use gdb to check what its value is before the call to uuid_generate and after the segfault. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [imagemagick] Strange bug in one of my packages need help (maybe glibc bug?)
On Mon, May 30, 2011 at 01:21:07PM +0200, roucaries bastien wrote: > On Wed, May 25, 2011 at 7:34 PM, Roger Leigh wrote: > > On Wed, May 25, 2011 at 12:20:09PM +0200, Bastien ROUCARIES wrote: > >> Hi, > >> > >> I have two strange bug in my package imagemagick. I am really clueless > >> about these.upstream have no idea also. Any help welcome > >> see #625250 > > > > % c++filt _ZNSt14error_categoryD2Ev > > std::error_category::~error_category() > > > > % nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev > > 003380272800 T _ZNSt14error_categoryD2Ev > > > > % nm -C -D /usr/lib/libstdc++.so.6 | grep error_category > > 003380272800 T std::error_category::~error_category() > > > > This is on a sid system. > > > > On squeeze: > > $ nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev > > $ echo $? > > 1 > > > > If imagemagick was built against the current libstdc++ and run > > using an older libstdc++ without the symbol, you will get this > > error. > > > > I don't see any direct libstdc++ dependency in either the > > imagemagick package, or its library needed sections. What's using > > libdjvulibre? Is it being dlopened. > > Yes it is dlopened > > > If this is the case, > > libdjvulibre is using an old version of libstdc++, and that's an > > issue with its dependencies (and/or the libstdc++ symbol > > versioning). > > Seems so, more strangely using LD_PRELOAD=/usr/lib64/libdjvulibre.so > or LD_BIND_NOW=1 fix this issue. Will reassign to libdvu This library may just require a rebuild. You could request a binNMU to get it rebuilt if this is the case. > > You'll need a full stack trace to work out what's using this > > library if you haven't done so already. > > It does not coredump. How can I get a backtrace ? using LD_DEBUG=all > option point to libdjvu Well, you can get a backtrace at any point, not just on coredump. You could 'break dlopen' to stop and get a backtrace at all dlopen calls. Or on any function call you like. This will let you find out what's responsible for the dlopen in the first place. If you have multiple copies of libstdc++ loaded, that could cause some issues. For this reason, it may be that all the C++ parts need rebuilding against the current version if some parts are using an old one. Normally this would be enforced by the package dependencies, but dlopen means this is avoided (which can result in breakage). Normally it's not good practice to dlopen random libraries for just this reason--it's normally restricted to modules within a package, which means the dlopened bits are then compatible. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: [imagemagick] Strange bug in one of my packages need help (maybe glibc bug?)
On Mon, May 30, 2011 at 02:27:28PM +0200, roucaries bastien wrote: > On Mon, May 30, 2011 at 1:54 PM, Roger Leigh wrote: > > On Mon, May 30, 2011 at 01:21:07PM +0200, roucaries bastien wrote: > >> On Wed, May 25, 2011 at 7:34 PM, Roger Leigh wrote: > >> > On Wed, May 25, 2011 at 12:20:09PM +0200, Bastien ROUCARIES wrote: > >> >> Hi, > >> >> > >> >> I have two strange bug in my package imagemagick. I am really clueless > >> >> about these.upstream have no idea also. Any help welcome > >> >> see #625250 > >> > > >> > % c++filt _ZNSt14error_categoryD2Ev > >> > std::error_category::~error_category() > >> > > >> > % nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev > >> > 003380272800 T _ZNSt14error_categoryD2Ev > >> > > >> > % nm -C -D /usr/lib/libstdc++.so.6 | grep error_category > >> > 003380272800 T std::error_category::~error_category() > >> > > >> > This is on a sid system. > >> > > >> > On squeeze: > >> > $ nm -D /usr/lib/libstdc++.so.6 | grep _ZNSt14error_categoryD2Ev > >> > $ echo $? > >> > 1 > >> > > >> > If imagemagick was built against the current libstdc++ and run > >> > using an older libstdc++ without the symbol, you will get this > >> > error. > >> > > >> > I don't see any direct libstdc++ dependency in either the > >> > imagemagick package, or its library needed sections. What's using > >> > libdjvulibre? Is it being dlopened. > >> > >> Yes it is dlopened > >> > >> > If this is the case, > >> > libdjvulibre is using an old version of libstdc++, and that's an > >> > issue with its dependencies (and/or the libstdc++ symbol > >> > versioning). > >> > >> Seems so, more strangely using LD_PRELOAD=/usr/lib64/libdjvulibre.so > >> or LD_BIND_NOW=1 fix this issue. Will reassign to libdvu > > > > This library may just require a rebuild. You could request a > > binNMU to get it rebuilt if this is the case. > > > >> > You'll need a full stack trace to work out what's using this > >> > library if you haven't done so already. > >> > >> It does not coredump. How can I get a backtrace ? using LD_DEBUG=all > >> option point to libdjvu > > > > Well, you can get a backtrace at any point, not just on coredump. > > You could 'break dlopen' to stop and get a backtrace at all dlopen > > calls. Or on any function call you like. This will let you find > > out what's responsible for the dlopen in the first place. > > It break in __libc_start_main > _start > > Any idea ? No. You'll need to look at the backtrace at that point. It may be irrelevant; just continue and look at all the break points, inspecting the backtrace each time. Note that ELF contructors (.init section) run early before main() is called. They can do arbitrary stuff. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Junior packaging tasks within the Debian Printing Team
On Mon, May 30, 2011 at 01:50:09PM +0200, Didier Raboud wrote: > Dear prospective maintainers, > > As packaging in teams and work on specific areas of Debian is often (and > rightly so) preferred to one-shot pet-package sponsoring, I would like to > propose 4 "relatively easy" packaging tasks. I'd also like to mention that if you're interested in printing, the "gutenprint" printer drivers are also looking for a new maintainer (or at the very least, additional team members). If you're interested in inkjet printing, and have access to an inkjet printer for testing, new contributions would be most welcome. I'll be available to give any help and assistance, having been the primary maintainer for quite a number of years, but no longer having an inkjet printer. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Nitpicking: you are doing it wrong
On Sat, Jul 09, 2011 at 04:23:05AM +0800, Thomas Goirand wrote: > On 07/08/2011 08:47 PM, Scott Howard wrote: > > Right now, the general consensus is the dh and cdbs produce > > debian packages that are easier to maintain in the long run (if the > > sponsor has to take over maintenance of the package or if NMUs are > > required in the future.) > With all the due respect... > > I really would like you to explain WHERE you saw such a consensus. > When it goes down to myself, I would *not* sponsor a package that > is using either dh or CDBS, because I like to be in the control and see > what's going on. I believe that CDBS/dh is hiding what's necessary to > do a good packaging, and is calling too many unnecessary helpers, > which slows down the build process. Also, with dh_override_*, if you > have a lot of them, it soon becomes unreadable. That's only my opinion > though, but I suspect that I might not be the only one to think this way. > In anyways, I don't see at all a consensus here!!! I'd like to give a concrete example of why I have changed my opinion from perferring "control" to preferring dh/cdbs. Consider the recent discussion on -policy and -ctte about changing dpkg-buildpackage (and policy) to use the "build-arch" and "build-indep" targets in debian/rules. These are currently optional, so many packages don't provide them. If you use cdbs, you get full support for these rules "for free", in that cdbs will provide them for you. If you use a recent debhelper, dh also provides them for you. This means that as and when dpkg-buildpackage and policy change to requiring these targets, over half the archive can switch to using them with *zero changes required*. Conversely, the packages which chose to do things by hand require *manual changes* to add support. That's over 8000 packages, and a lot of essentially pointless make-work, since it could quite easily be automated. This is just one example. By not hard-coding the list of dh_ helpers being called, it means that your package will automatically use any new helpers without any manual source changes. And as the helpers are updated to match policy, your package stays compliant with current policy. I think that due to the massive size of Debian, we do need to consider that making even a small change is often difficult, not because it's intrinsically complex, but because of the huge amount of manual work required to complete it. By using helpers such as dh, many things become trivial to change, archive wide, with nothing more than a binNMU. So from the POV of the distribution as a whole, helpers do provide a tangible and significant benefit. I would argue that not using a helper unnecessarily increases the maintenance burden we all shoulder, and that we should actively encourage further adoption of dh and cdbs. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it
On Wed, Jul 27, 2011 at 08:23:42AM +1000, Ben Finney wrote: > Kilian Krause writes: > > > Hi Ben, > > > > On Tue, 2011-07-26 at 17:10 +1000, Ben Finney wrote: > > > Lintian recommends (via tag ‘debian-rules-missing-recommended-target’): > > > > > > = > > > N: Note that the following form is recommended however: > > > N: > > > N: build: build-arch build-indep > > > N: build-arch: build-stamp > > > N: build-indep: build-stamp > > > N: build-stamp: > > > N: build here > > > = > > > > If you're sure that you want to use dh but .PHONY then just put into > > your rules something like: > > > > build-indep: > > dh $@ > > build-arch: > > dh $@ > > build: build-arch build-indep > > > > No need for a stamp as dh is already producing stamps internally. > > This doesn't match Lintian's recommendation. Nor does the common ‘%:’ > style rule. > > Should Lintian's recommendation be changed? Quite possibly, I'm sure the lintian maintainers would be happy to have improved help text. I didn't write it with dh in mind, since dh works with build-arch and build-indep automatically since 8.1.0, and since 8.9.0 with v9 compatibility mode, dh supports proper overriding of sequences with make targets. But unless you're doing something really different, you shouldn't need to specify any build rules at all--just use override_dh_auto_build, e.g. override_dh_auto_build: ifneq (,$(shell dh_listpackages -a 2>/dev/null)) $(MAKE) -C debian/build all endif ifneq (,$(shell dh_listpackages -i 2>/dev/null)) $(MAKE) -C debian/build doc endif This does all the arch and indep building in the conditionals. The main problems with build-arch: build build-indep: build is that it can cause infinite recursion in combination with dh: build → dh build → build-arch → build → … because build-arch and build-indep are dependencies of build, not the wrong way around as in this case. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it
On Wed, Jul 27, 2011 at 09:12:37PM +1000, Ben Finney wrote: > Roger Leigh writes: > > > On Wed, Jul 27, 2011 at 08:23:42AM +1000, Ben Finney wrote: > > > Kilian Krause writes: > > > > > > > Hi Ben, > > > > > > > > On Tue, 2011-07-26 at 17:10 +1000, Ben Finney wrote: > > > > > Lintian recommends (via tag > > > > > ‘debian-rules-missing-recommended-target’): > > > > > > > > > > = > > > > > N: Note that the following form is recommended however: > > > > > N: > > > > > N: build: build-arch build-indep > > > > > N: build-arch: build-stamp > > > > > N: build-indep: build-stamp > > > > > N: build-stamp: > > > > > N: build here > > > > > = > […] > > > > Should Lintian's recommendation be changed? > > > > Quite possibly, I'm sure the lintian maintainers would be happy to > > have improved help text. I didn't write it with dh in mind > > Okay. (Thanks for writing it.) > > If you were to write it with ‘dh’ in mind, what would be the recommended > set of explicit targets? For an idealised package, there would be no explicit targets, except for any overrides required. Using schroot and gutenprint as examples: http://anonscm.debian.org/gitweb/?p=buildd-tools/schroot.git;a=blob;f=debian/rules;h=253d68daefece8c7cbfac6e1e29e6da768b6591f;hb=HEAD http://anonscm.debian.org/gitweb/?p=collab-maint/gutenprint.git;a=blob;f=debian/rules;h=be10561b84be50eea894c1104f4efa05f7b77a8b;hb=HEAD Neither of these need explicit build targets. They do need explicit install targets, but only due to the need to autogenerate .install files via a separate rule for multiarch dirs, which I'm triggering via a make dependency. In both cases, I am simply using "override_dh_auto_build" to make it do the particular build command for the package, and at least for gutenprint, it's probably entirely redundant since the default would do the same. > > The main problems with > >build-arch: build > >build-indep: build > > I'm not sure who suggested that; it doesn't seem to be in this thread. It's the first part of the lintian message; I just mentioned it for completeness in case it got trimmed out of the first message I saw in the thread, in particular because of the dh-related recursion gotcha that might catch people unawares. > > since dh works with build-arch and build-indep automatically since > > 8.1.0 > > Ah, thank you. I now need to increase the ‘debhelper’ dependency and > ‘compat’ level to correctly rely on its support for those targets. Yes. v8 will support build-arch and build-indep as "sequences", v9 will allow you to use the rules in debian/rules (and have dh realise that and use them in place of its build-in sequences) in addition. > > and since 8.9.0 with v9 compatibility mode, dh supports proper > > overriding of sequences with make targets. But unless you're doing > > something really different, you shouldn't need to specify any build > > rules at all > > Both of those are rather too much magic. One of the great benefits of > using debhelper( as opposed to CDBS) is that one can look at a > ‘debian/rules’ file without specific knowledge about debhelper, and see > at least what commands will be run when. > > So, if Lintian is going to recommend these targets, what text would make > it a suitable recommendation for both no-helper and ‘debhelper’ rules > styles? Without any helper: build: build-arch build-indep build-arch: # Build arch-dep here build-indep: # Build arch-indep here And this can include additional dependencies for build-arch and build-indep such as the build-stamp suggested in the lintian text (saves building twice if both rules use the same logic). build can't have any additional dependencies, since it's optional--it can only depends on build-arch and build-indep, and should do nothing else (since it's not guaranteed to be called if you used build-arch and/or build-indep directly). With dh v8 compat: Same command for arch and indep: override_dh_auto_build: $(MAKE) foobar If you have different commands for arch and indep: override_dh_auto_build: ifneq (,$(shell dh_listpackages -a 2>/dev/null)) $(MAKE) -C debian/build all endif ifneq (,$(shell dh_listpackages -i 2>/dev/null)) $(MAKE) -C debian/build doc endif With dh v9 compat: Same command for arch and indep: override_dh_auto_build: $(MAKE) foobar If you have different commands for arch and indep: build-arch: dh_testdir $(MAKE) arch-foo build-indep: dh_testdir
Re: Using dh to build >1 binary package with different configure options
On Fri, Aug 12, 2011 at 10:18:52AM +0200, Gergely Nagy wrote: > Tony Houghton writes: > > > I'm pretty sure I once read something about how to get a single source > > package to build multiple binary packages from the same source with > > different configure options. Unfortunately I can't remember what I read > > and it didn't apply to dh anyway. Can anyone recommend a guide to doing > > this with dh? > > If you're using short form dh, this would be one way to do it: > > cd debian/build-gtk3 && make > > cd debian/build-gtk2 && make install DESTDIR=$(CURDIR)/debian/pkg-gtk2 Note make has a '-C' option to avoid the cd: make -C debian/build-gtk3 make -C debian/build-gtk3 install DESTDIR=$(CURDIR)/debian/pkg-gtk2 Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. signature.asc Description: Digital signature
Re: New autoconf-archive package
On Mon, Oct 31, 2011 at 06:39:48PM +0100, Bastien ROUCARIES wrote: > I am looking for a sponsor for the new version 20110917-1 > of my package "autoconf-archive". Link to the dsc? I'll see if I have time to look at it tonight. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2003170629.gk28...@codelibre.net
Re: debian/rules override_dh_auto_build-indep
On Thu, Nov 10, 2011 at 10:25:27AM +0100, Niels Thykier wrote: > On 2011-11-10 08:20, Mathieu Malaterre wrote: > > I have been trying to split indep operations from the rest on the > > activiz.net package, see: > > > > http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup > > > > However the -indep rules are still being called on the buildd machine: > > > > Eg: > > > > http://buildd.debian-ports.org/status/fetch.php?pkg=activiz.net&arch=s390x&ver=5.6.1-2&stamp=1320869304 > > > > [...] > > > > Am I missing something here ? > > This is one of the real issue behind the optional build-arch/build-indep > targets; since they are optional dpkg-buildpackage/buildds do not use > them. Therefore, you cannot rely on them as a maintainer (yet). [...] Agreed with all Niels comments. Your source package is fine; the issue is that dpkg-buildpackage (run by sbuild on the buildds) calls: debian/rules build debian/rules binary-arch when it should be running debian/rules build-arch debian/rules binary-arch I wrote a patch to fix this some time back, and it was discussed by the TC months ago. I guess it needs chasing up to get it applied. Once that's done, it will Just Work. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010111438.gs28...@codelibre.net
Re: debian/rules override_dh_auto_build-indep
On Thu, Nov 10, 2011 at 10:19:28PM +0100, Mathieu Malaterre wrote: > On Thu, Nov 10, 2011 at 12:14 PM, Roger Leigh wrote: > > On Thu, Nov 10, 2011 at 10:25:27AM +0100, Niels Thykier wrote: > >> On 2011-11-10 08:20, Mathieu Malaterre wrote: > >> > I have been trying to split indep operations from the rest on the > >> > activiz.net package, see: > >> > > >> > http://anonscm.debian.org/viewvc/debian-med/trunk/packages/activiz.net/trunk/debian/rules?view=markup > >> > > >> > However the -indep rules are still being called on the buildd machine: > >> > > >> > Eg: > >> > > >> > http://buildd.debian-ports.org/status/fetch.php?pkg=activiz.net&arch=s390x&ver=5.6.1-2&stamp=1320869304 > >> > > >> > [...] > >> > > >> > Am I missing something here ? > >> > >> This is one of the real issue behind the optional build-arch/build-indep > >> targets; since they are optional dpkg-buildpackage/buildds do not use > >> them. Therefore, you cannot rely on them as a maintainer (yet). > > [...] > > > > Agreed with all Niels comments. Your source package is fine; the issue > > is that dpkg-buildpackage (run by sbuild on the buildds) calls: > > > > debian/rules build > > debian/rules binary-arch > > > > when it should be running > > debian/rules build-arch > > debian/rules binary-arch > > > > I wrote a patch to fix this some time back, and it was discussed by the > > TC months ago. I guess it needs chasing up to get it applied. Once > > that's done, it will Just Work. > > buildd can make the decision to run build-indep, I am ok with it. > What I am not ok with, is when buildd are setup to run build-indep > rules, but do not respect B-D-I ! > That does not make any sense for me. It doesn't make any sense because it /is/ broken, but we are trying to rectify this. Hopefully for the next Debian stable release, we'll have a sane situation. I've also got a separate dpkg patch to introduce Build-Depends-Arch, so you will then be able to use Build-Depends for generic depends e.g. debhelper, and move the arch- and indep-specific deps into their own place. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011094829.gv28...@codelibre.net
Re: Symbols and C++ inline constructor
On Thu, Jan 05, 2012 at 11:46:26PM +0100, Thomas Weber wrote:
> Hi,
> I have a question about an inline constructor and debian/symbols.
> The code looks like this:
>
> class X {
>
> public:
> X() { some code };
> }
>
> According to http://gcc.gnu.org/onlinedocs/gcc/Inline.html, this means
> that the constructor is inlined.
Good question. IIRC inline is only a hint--it's not guaranteed to
be inlined if the compiler thinks it's more efficient not to. From
the symbols POV, what really matters is the content of the ELF
symbol table. If it's present then include it, otherwise don't.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120106001411.gk18...@codelibre.net
Re: Symbols and C++ inline constructor
On Sun, Jan 08, 2012 at 10:26:42AM +0100, Tobias Frost wrote:
> Just a general remark just came into my mind about the symbols
> dicssusion:
>
> Is is really *safe* to use inline methods as API in libraries?
Just trying to test this with the following code:
#include
class test
{
public:
inline
test():
v()
{
}
inline
test(std::string const& var):
v(var)
{
}
inline
~test()
{
}
private:
std::string v;
};
static test t;
static test t2("foo");
Compiling, linking and testing with
g++ -fPIC -finline -c -o test.o test.cc
g++ -shared -o test.so test.o
nm -C -D test.so
Oddly, the constructors are only used if I actually make use of them.
i.e. delete the "static test ..." at the end and compare. If they
are used, I do see a non-inlined function appear though, albeit a
"W" (weak) symbol whether or not I explictly have the "inline"
keyword in the sources. Possibly my example is too simple. I'm
most surprised about the functions only being compiled on use even
without the inline. Maybe I need to take them out of the class
definition and inline the separate functions.
So not all bad--if you use an inlined function you do appear to get
a symbol emitted.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`-GPG Public Key: 0x25BFB848 Please GPG sign your mail.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120108113805.gb9...@codelibre.net
Re: Lintian complaining about ldconfig in postrm-remove
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dominik Stadler <[EMAIL PROTECTED]> writes: > When running lintian, I always get the following warning: > > W: atleto: postrm-unsafe-ldconfig > N: > N: The postrm script calls ldconfig unsafely. The postrm must only call > N: ldconfig when given the argument "remove". > N: > N: Refer to Policy Manual, section 9.1.1 for details. > N: > > But I cannot find why the script should be wrong, Section 9.1.1. does not > really tell me why I should avoid this, but does not tell me why I am still > getting the warning. I am just calling ldconfig when "remove" is passed. I > also tested this on the commandline. > > case "$1" in >purge|upgrade|failed-upgrade|abort-install|abort-upgrade|disappear) > > ;; > >remove) > >/sbin/ldconfig This was (and maybe still is) a lintian bug. It can't cope with all the different ways of testing if $1 is "remove". FWIW, I changed the postrm in libgimpprint1 to do: if [ "$1" = "remove" ]; then ldconfig fi BTW, nowadays dephelper (dh_makeshlibs) adds the ldconfig call for you automatically, so you don't need to do it yourself (assuming you're packaging a shared library here). Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/SPKyVcFcaSW/uEgRAv4MAJwKxCR2cS6tTuG86zASO1Xsa1rGUgCgjgnM BODisNO74YEyLHdjVFdoZ90= =rwpS -END PGP SIGNATURE-
Policy query
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lintian gives me this error: E: cupsys-driver-gimpprint: depends-on-essential-package-without-using-version gzip N: N: The package declares a depends on an essential package i.e. dpkg N: without using a versioned depends. In general a package should not N: depend on essential packages but if it must do so, the depends should N: have a version string. N: N: Refer to Policy Manual, section 2.3.4 for details. N: Policy section 2.3.4 doesn't exist, and I can't see it in Section 7, either. Does this still apply, and if so, where is it in the Policy Manual? I'll remove the dependency next time I upload, but I'd like to know where the requirement comes from. Thanks, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQE/Smm3VcFcaSW/uEgRAqmoAKC+9bVIR6Qsn+bvOSlSibmFJT4ixgCgs9Pe sVd2cmPXCYXWDmM3qB1xI2M= =fotP -END PGP SIGNATURE-
Re: Policy query
Frank Lichtenheld <[EMAIL PROTECTED]> writes: > On Mon, Aug 25, 2003 at 08:55:53PM +0100, Roger Leigh wrote: >> E: cupsys-driver-gimpprint: >> depends-on-essential-package-without-using-version gzip >> N: >> N: The package declares a depends on an essential package i.e. dpkg >> N: without using a versioned depends. In general a package should not >> N: depend on essential packages but if it must do so, the depends should >> N: have a version string. >> N: >> N: Refer to Policy Manual, section 2.3.4 for details. >> N: >> >> Policy section 2.3.4 doesn't exist, and I can't see it in Section 7, >> either. Does this still apply, and if so, where is it in the Policy >> Manual? >> >> I'll remove the dependency next time I upload, but I'd like to know >> where the requirement comes from.> > > Policy, section 3.5 Thanks. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: UTF-8 in copyright files?
Colin Watson <[EMAIL PROTECTED]> writes: > Sarge systems support UTF-8 really quite well, though, with a tiny bit > of locales configuration. Even woody systems support them with only a > few unpleasant bugs. Testing this the other day with groff: using framebuffer utf-8 console and GNOME terminal with Bistream Vera Sans Mono. Neither can represent a UCS hyphen correctly! This is with LANG=en_GB.ISO-8859-1 and man -Tutf8, and LANG=en_GB.UTF-8. Is any special configuration required for a Unicode console? I noticed in particular that I needed to run unicode_start to put the console into UTF-8 mode. Can this be defaulted anywhere? In addition, are there any UCS fonts for the console? I'm currently using lat1-16.psf, but there doesn't appear to be an obvious UCS alternative. I'm quite confused as to how all the .psf, .acm, .sfm, and .uni files all fit together--surely with UCS, most of these become unnecessary (other than keyboard mappings)? Apart from that, I've noticed no brokenness so far. UTF-8 text really does look good! Regards, Roger (looking forward to UTF-8 support in GCC!) -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Why Katie thinks it's an NMU?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Magosányi Árpád <[EMAIL PROTECTED]> writes: > But Katie thinks that my latest two uploads were NMU. > The same is the case with zorp. > > What did I do wrong? What was the version number? The Debian revision number should only be one digit, not two (NMU) or three (binary NMU). Policy, §5.6.11 may be of some help, and the Developer's Reference, §5.11.4.1. Regards, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFAUkQoVcFcaSW/uEgRAnnAAJ41Qq0NGr9EBMDwu/XSGCT4MVgRSQCcCde7 lwrkOkSvZ0woxYSo2Ltkeo8= =lOuQ -END PGP SIGNATURE-
Re: Development packages.
Stephen Frost <[EMAIL PROTECTED]> writes: > We shouldn't be recommending providing staticlly linked libs for people > to use, even in the 'fast moving' case- if it's that fast then it > probably shouldn't be in Debian and that's just life. > > .la files shouldn't be included in anything, they're just plain broken. Even with static libraries? The .la does contain dependency information. I know that using pkg-config .pc files can eliminate this case, but not everything using libtool is using pkg-config yet. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Development packages.
Stephen Frost <[EMAIL PROTECTED]> writes: > * Matt Brubeck ([EMAIL PROTECTED]) wrote: >> Stephen Frost wrote: >> > We shouldn't be shipping or using static libraries. >> >> Why not? I know we shouldn't be linking to static libraries in our >> packaged software, but having the static libraries available is >> important for some end-users and local administrators. > > Pffft. Honestly, I think that claim of end-users and local > administrators using static libraries is rather dated and rarely the > case these days. I used a statically-linked binary just a few days ago. I needed to resize an NTFS partition on a newly-delivered system which came with Windows XP. In the event, I was able to get a statically linked binary, copy it onto a floppy and run this after booting from a rescue disk. So, it's very useful for rescue situations, where you can't rely on a whole suite of shared libs, or any installation at all. It's also useful when you want to provide something that "just work" with no extra dependencies. While proprietary/commercial software was the biggest user of this, it's also useful for free software. What if Joe Average would like to run my program which makes use of libstdc++, GTK+ 2.2 and GNOME 2.4? It's the least hassle way to achieve this. > Regardless, we shouldn't be using them and the end > users and local admins who actually need to link against things > statically can figure out the dependencies. Since nearly all -dev packages come with static libs and this is not forbidded (it's mentioned in Policy) I won't stop using them. I'll by happy to stop as soon as Policy forbids/discourages it. On a related note, I'd also be very happy if it was a requirement to build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip them. We could provide some mechanism to automatically strip binaries, surely? -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Development packages.
Andreas Metzler <[EMAIL PROTECTED]> writes: > On Mon, Mar 22, 2004 at 04:26:49PM +0100, Frank Küster wrote: [libtool brokenness] >> Yes, it did :-|. Could you point me to a documentation where I could >> read about these problems, and under what weird circumstances it will be >> a bug nevertheless if I don't install the *la files? > [...] > > Hello, > Basically the essence of the mess is #191425. If libfoo links against > libbar and application blah makes use of libfoo (but does not use > libbar) libtool will link the application against both libraries. How is this different to pkg-config: $ pkg-config --libs libglademm-2.0 -Wl,--export-dynamic -lglademm-2.0 -lgtkmm-2.0 -lglade-2.0 -lgdkmm-2.0 -latkmm-1.0 -lpangomm-1.0 -lglibmm-2.0 -lsigc-1.2 -lgtk-x11-2.0 -lxml2 -lpthread -lz -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 Whew! Yet in reality, -lglademm-2.0 would have sufficed... -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Development packages.
Steve Langasek <[EMAIL PROTECTED]> writes: > On Mon, Mar 22, 2004 at 09:59:34PM +, Scott James Remnant wrote: >> > pkg-config is a *far* worse offender than libtool. With libtool, we >> > have some hope of getting these things right in the near future; >> > pkg-config, OTOH, doesn't even know there *is* a difference between >> > static and shared libs, so can't be taught to handle them differently >> > without a lot of growing pains. Please don't add pkg-config to packages >> > that don't already have the misfortune of using it! > >> I've got half a mind, if pkg-config upstream haven't shown any signs of >> activity once I've finished fighting my current battles to start >> developing it further myself. > >> Giving it some idea of what's a dependency library and what's a 2nd (or >> even 3rd) level dependency would be nice, along with some "I'm linking >> statically" and "I'm cross-compiling" logic. > > From what I can tell, the .pc files already contain enough information > to distinguish between direct and indirect dependencies. If you were to take libs specified in the .pc, and those directly Required by it, that should be the minimum. Better still, you could just take "pkg-config --libs", and then manually construct the dependency tree. You can then just include the root(s) of however many unique dependency trees you find. Since pkg-config is already an ELF executable, there's no reason why it can't do it directly when you use --libs. The only issue I see is distinguishing between normal (dynamic) linking and static linking (where the old behaviour is still required). Scott, if you do find the time to look at this, I would be ecstatic! If you don't have the time, I'll try to fit it in myself, since this is my main peeve with pkg-config. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Development packages.
Alexander Winston <[EMAIL PROTECTED]> writes: > On Mon, 2004-03-22 at 20:54 +0000, Roger Leigh wrote: > >> On a related note, I'd also be very happy if it was a requirement to >> build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip >> them. We could provide some mechanism to automatically strip >> binaries, surely? > > I believe that this was discussed before and never really got off of the > ground because of the bandwidth issues involved. > > By the way, doesn't "-ggdb3" provide more verbose debugging information? Yes, or '-g3' which is equivalent. I find this essential when debugging inline C++ code, such as templates. I think -g3 -gdwarf-2 should be the shortest way to write it. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Development packages.
Stephen Frost <[EMAIL PROTECTED]> writes: > * Roger Leigh ([EMAIL PROTECTED]) wrote: >> I used a statically-linked binary just a few days ago. I needed to >> resize an NTFS partition on a newly-delivered system which came with >> Windows XP. In the event, I was able to get a statically linked >> binary, copy it onto a floppy and run this after booting from a rescue >> disk. >> >> So, it's very useful for rescue situations, where you can't rely on a >> whole suite of shared libs, or any installation at all. > > Boot Knoppix or similar from a CD. PCs today are more often installed > with CDs than floppies anyway. That's really a pretty poor reason. Consider this situation: New PC arrives. I only had an old Knoppix CD (freebie from UKUUG two years ago), which didn't have ntfsutils. I didn't have the means to download and burn a new ISO, or the time to mess about doing it. So the CD was out. I used the rescue initrd from a Fedora Core 1 CD, after downloading a statically linked ntfsresize (from the maintainers' site) and copying it to a floppy using Windows XP. Boot the rescue image, and run the statically linked binary directly from the floppy. It worked like a charm. After resizing, I set up the paritions and LVM2 prior to cloning a new install directly from the Debian unstable install of my laptop. >> It's also useful when you want to provide something that "just work" >> with no extra dependencies. While proprietary/commercial software was >> the biggest user of this, it's also useful for free software. What if >> Joe Average would like to run my program which makes use of libstdc++, >> GTK+ 2.2 and GNOME 2.4? It's the least hassle way to achieve this. > > Joe Average installs Debian which *handles* all of the dependencies. > Come on, this isn't even a reason to keep them. What about users who don't run Debian, or who don't run unstable. These are very common situations, and you can't expect everyone to install unstable just to run my program. I also don't expect every user to build over 30 libraries themselves. Not everyone lives on the bleeding edge. > Using [static libs] as an excuse to include .la files isn't valid > because .la files break other things. Examples, please? >> On a related note, I'd also be very happy if it was a requirement to >> build libraries with a miniumum of "-g -ggdb -gdwarf-2", and not strip >> them. We could provide some mechanism to automatically strip >> binaries, surely? > > This doesn't make a whole lot of sense. I certainly hope you're not > trying to say we should ship not-stripped *anything* by default. Yup. I'd like all my libs with debugging symbols by default. Since I spend all day (and night!) writing and debugging software, this would make a lot of sense (for me). Whether others would appreciate this is another matter ;-). Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: Development packages.
Stephen Frost <[EMAIL PROTECTED]> writes: > * Scott James Remnant ([EMAIL PROTECTED]) wrote: >> > But shipping .la files in non-dev packages should still be a hanging >> > offense. >> >> Plugins using libltdl probably need them ... though not until some of >> the more exotic ports come to fruition. >> >> "Debian Solaris" anyone? :o) > > I'm not 100% sure but I actually thought that's what OpenLDAP used > (libltdl) and it works just fine w/o the stupid .la files. Have you actually *used* libltdl yourself? For several reasons, it's often best (when dynamically loading modules) to load the .la file directly, and have libltdl do the magic of translating it to whatever.so for you. If you're writing your program to work on multiple platforms, this hides the issues you'll find: - You don't need to special case DSO extensions for every platform. Thus the package will work "out of the box" on every libltdl-supported platform. - This makes debugging and maintenance simpler and more reliable. - library conventions vary depending on the platform. Example: on Cygwin, DLLs are named cygfoo.dll, and live in /bin. The .la file would take care of this for me (I'd load /usr/lib/libfoo.la). You can do without the .la file, but IMHO it's too much hassle and causes more problems than it solves. If you want to use .so's directly, then just use libdl directly on Linux. For example, for Gimp-Print 5.0 (not yet released) I wrote a module loader that works in 3 modes: - libltdl [used when libdl is unavailable] - libdl[the default] - static [useful for debugging and static libs] Add a little configure magic to detect the best option, and you're all set. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: RFS: rlplot - generate publication quality graphs
James Stone <[EMAIL PROTECTED]> writes: >> >> I've had a look at it. Hm, it's not exactly what I hoped for (at least >> not at it's present stage of development), and since I think I'm not >> going to use it, I also won't sponsor it. > > I'm sorry to hear that. I agree it is still in quite an early stage of > development, but AFAIK it is the only program that can generate the type > of bar charts with error bars that I need.. Maybe openoffice one day..? Have you looked at GNU R? It can generate some very sophisticated graphs/charts--bar charts with error bars are just scratching the surface. There is also grace, which can also do error bars. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
libtool and building both shared and static libraries
Hi folks, With the current development version of Gimp-Print (not yet available in Debian), there are several libraries built: · libgimpprint (shared and static) · loadable modules (shared modules, but static copies are built to link with the static libgimpprintui) · libgimpprintui (shared and static) · libgimpprintui2 (shared and static) There are a few problems with this: 1. --enable-shared --enable-static builds everything both shared and static, but using either --enable=shared=foo,bar or --enable-static=foo,bar are mutually exclusive: everything not explicitly listed is built the other way; you can't have some built both ways. What I want is to build /everything/ both shared and static /except/ for libgimpprintui and libgimpprintui2. I want these static only. But I can't find a way to accomplish this with the above. Is this possible? A fixed list is not desirable--I would have to specify every single driver module, and these could vary with each release. 2. Some programs linked with libgimpprint are run during the build. These generate data such as PPDs (Postscript Printer Definitions) for the available printers. Unfortunately, if building both shared and static libraries, the programs will be linked dynamically and will use a prior version installed on the system in preference to the one just built. (This is when running through the libtool-generated wrapper script--it doesn't set LD_LIBRARY_PATH). Is there a portable way of doing this? This isn't an issue for Debian--we run the programs in the postinst and avoid the problems, but it's a problem for everyone else. 3. Some of the hassle could be avoided if I didn't insist on being able to build dynamic and static libraries during the same build. Although I didn't see a /requirement/ for providing a static copy in Debian Policy, it does seem to be the status quo. Does anyone actually use them, or are they a waste of space? Would anyone object if I ceased to provide a static libgimpprint? Many thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: ink and libinklevel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthijs Mohlmann <[EMAIL PROTECTED]> writes: > ink is a program which uses the libinklevel library to get the ink level > of printers. > > It's good to have this in debian. This program can used in many ways on > print servers to get the status of the printers and such things. Are you planning to work with other inklevel-monitoring programs such as mtink and escputil? How do you integrate with spoolers such as CUPS where the backends can read and log backchannel data? Thanks, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFBVbvqVcFcaSW/uEgRArlVAKCy8outHrt/I1rkgiLRRy8Mt78+pgCgjnwQ Xc+xt1DBAy1QU9TgJAcSIC8= =aSe4 -END PGP SIGNATURE-
Making a package with multiple binaries
I have made a package with debhelper and dh_make, which produces a single
binary deb. However, now I would like to make two binaries from the same
packages, identical except for that each is built with different options
to configure (one has support for the LPRng print spooler and one does
not).
I was advised to look at the sample rules files in
/usr/share/doc/debhelper/examples, but I am not quite understanding what
they do. I looked at the glib source, and could follow that, but I was
advised to use DH_OPTIONS instead of many separate rules and -p options to
debhelper scripts, but I fail to see how to run configure twice, with
different options in the build-stamp rule and then install both into the
right place in the install rule (I just get identical stuff pacakged in
two locations), and dh_gencontrol also breaks:
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
The dependency file is not output.
(The current copy (I took a lot of broken stuff out) of this is at
http://www-users.york.ac.uk/~rl117/linux/stcolortool-debpack.tar.gz)
Any advice or pointers to documentation appreciated (I could find little
about making this type of package).
Many thanks,
Roger Leigh
--
Roger Leigh ** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://www-users.york.ac.uk/~rl117/linux/
For GPG Public Key: finger [EMAIL PROTECTED] or see
http://pgp5.ai.mit.edu/pks-commands.html#extract
Re: Making a package with multiple binaries
Thanks for all the suggestions. I will try and get everything working later on today. Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://www-users.york.ac.uk/~rl117/linux/ For GPG Public Key: finger [EMAIL PROTECTED] or see http://pgp5.ai.mit.edu/pks-commands.html#extract
Re: Making a package with multiple binaries
Manu thanks for all your help, I am now successfully building multiple binaries! I used configure with VPATH to build and install with DESTDIR. However, there are a few things I would like to clarify: Is it ok to put a symlink in /usr/doc to link stcolortool to stcolortool-lprng? I modified the following target (from the debhelper rules.multi2 example) to depend on build and install, otherwise nothing would be installed. Is this acceptable (I am using DH_COMPAT=2)? binary-arch: build install $(MAKE) -f debian/rules DH_OPTIONS=-a binary-common I am getting strange errors from lintian: [EMAIL PROTECTED]:~/epson$ lintian -i stcolortool_0.3.1-0_i386.changes internal error: cannot open unpacked/debian/ directory: No such file or directory internal error: collect info debfiles about package stcolortool: No such file or directory N: Skipping check of source package stcolortool It still found a few bugs (no dh_strip and man-in-usr), but I always get this error even when the package is clean. Is the potato lintian broken? (I had no problems with the slink version). If I want the packages to be mutually exclusive, should I use Conflicts: as well as Replaces: (when I did not put in a Conflicts:, I could install both at once, seemingly, although one must have been overwritten). Many thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://www-users.york.ac.uk/~rl117/linux/ For GPG Public Key: finger [EMAIL PROTECTED] or see http://pgp5.ai.mit.edu/pks-commands.html#extract
Packaging unversioned shared libraries
I am having a problem when packaging a shared library (libgimpprint from CVS). It is normally named libgimpprint-.so e.g. currently libgimpprint-4.1.4.so, but I get errors when packaging (see below). However, if I change that naming to libgimpprint.so.4.0.0, I do not get these lintian errors. Is there any way to package non-versioned shared libraries? Apologies if this is a really dumb question: I am not entirely sure of what all of the shlibs fields do, and am using dh_makeshlibs to do it. The debianised source and i386 packages are available at: <http://www-users.york.ac.uk/~rl117/gimp-print> Thanks for any help, Roger Lintian output: E: libgimpprint: shlib-missing-in-control-file libgimpprint-4.1.4 usr/lib/libgimpprint-4.1.4.so N: N: The package contains a shared library, which is not listed in the N: shlibs control file. If this is intentional, please contact N: [EMAIL PROTECTED] about this so that this error gets included N: in the overrides file for Lintian. (With that, Lintian will ignore N: this bug in the future.) N: W: libgimpprint: unused-shlib-entry-in-control-file libgimpprint N: N: The shlibs control file contains an entry for a shared library that is N: not installed by this package. N: debian/libgimpprint/DEBIAN/shlibs: libgimpprint 4.1.4 libgimpprint -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ For GPG Public Key: finger [EMAIL PROTECTED] or see public keyservers.
Re: Packaging unversioned shared libraries
On Wed, Feb 14, 2001 at 11:44:31AM -0800, Sean 'Shaleh' Perry wrote: > > On 14-Feb-2001 Roger Leigh wrote: > > I am having a problem when packaging a shared library (libgimpprint from > > CVS). It is normally named libgimpprint-.so e.g. currently > > libgimpprint-4.1.4.so, but I get errors when packaging (see below). > > However, if I change that naming to libgimpprint.so.4.0.0, I do not get > > these lintian errors. Is there any way to package non-versioned shared > > libraries? > > this was a bug in lintian due to it not understanding the recent change in > library names from libfoo.so. to libfoo-.so. lintian 1.20.6 > works just fine: I have upgraded to the new version, and everything works with no problems. Thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ For GPG Public Key: finger [EMAIL PROTECTED] or see public keyservers.
Re: RFS: rlplot - generate publication quality graphs
James Stone <[EMAIL PROTECTED]> writes: >> >> I've had a look at it. Hm, it's not exactly what I hoped for (at least >> not at it's present stage of development), and since I think I'm not >> going to use it, I also won't sponsor it. > > I'm sorry to hear that. I agree it is still in quite an early stage of > development, but AFAIK it is the only program that can generate the type > of bar charts with error bars that I need.. Maybe openoffice one day..? Have you looked at GNU R? It can generate some very sophisticated graphs/charts--bar charts with error bars are just scratching the surface. There is also grace, which can also do error bars. -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
libtool and building both shared and static libraries
Hi folks, With the current development version of Gimp-Print (not yet available in Debian), there are several libraries built: Â libgimpprint (shared and static) Â loadable modules (shared modules, but static copies are built to link with the static libgimpprintui) Â libgimpprintui (shared and static) Â libgimpprintui2 (shared and static) There are a few problems with this: 1. --enable-shared --enable-static builds everything both shared and static, but using either --enable=shared=foo,bar or --enable-static=foo,bar are mutually exclusive: everything not explicitly listed is built the other way; you can't have some built both ways. What I want is to build /everything/ both shared and static /except/ for libgimpprintui and libgimpprintui2. I want these static only. But I can't find a way to accomplish this with the above. Is this possible? A fixed list is not desirable--I would have to specify every single driver module, and these could vary with each release. 2. Some programs linked with libgimpprint are run during the build. These generate data such as PPDs (Postscript Printer Definitions) for the available printers. Unfortunately, if building both shared and static libraries, the programs will be linked dynamically and will use a prior version installed on the system in preference to the one just built. (This is when running through the libtool-generated wrapper script--it doesn't set LD_LIBRARY_PATH). Is there a portable way of doing this? This isn't an issue for Debian--we run the programs in the postinst and avoid the problems, but it's a problem for everyone else. 3. Some of the hassle could be avoided if I didn't insist on being able to build dynamic and static libraries during the same build. Although I didn't see a /requirement/ for providing a static copy in Debian Policy, it does seem to be the status quo. Does anyone actually use them, or are they a waste of space? Would anyone object if I ceased to provide a static libgimpprint? Many thanks, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
Re: ink and libinklevel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthijs Mohlmann <[EMAIL PROTECTED]> writes: > ink is a program which uses the libinklevel library to get the ink level > of printers. > > It's good to have this in debian. This program can used in many ways on > print servers to get the status of the printers and such things. Are you planning to work with other inklevel-monitoring programs such as mtink and escputil? How do you integrate with spoolers such as CUPS where the backends can read and log backchannel data? Thanks, Roger - -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFBVbvqVcFcaSW/uEgRArlVAKCy8outHrt/I1rkgiLRRy8Mt78+pgCgjnwQ Xc+xt1DBAy1QU9TgJAcSIC8= =aSe4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Versioning prereleases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks, I believe that post-sarge it's possible to use '~' in version numbers? I am going to package a pre-release of gimp-print 5.0 for experimental and (later on) unstable. Currently, the upstream releases are versioned like this: gutenprint-5.0.0-beta2.tar.bz2 gutenprint-5.0.0-beta3.tar.bz2 gutenprint-5.0.0-pre1.tar.bz2 gutenprint-5.0.0-pre2.tar.bz2 gutenprint-5.0.0.tar.bz2 gutenprint-5.0.1.tar.bz2 ... When 5.0.0 comes out, I don't want the -beta and -pre releases to sort higher than it, and I'd rather not resort to extra ugliness in the version number. What would you recommend as the correct version numbers to use in the changelog for a smooth upgrade? Are there any examples? Thanks, 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.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCBrngVcFcaSW/uEgRArNxAKDbAOgHVYRshJpngdfUYOAA+MidGwCfS//n fb9+6/8ZM2A/k/KYkXPJN4s= =zCMe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Versioning prereleases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roger Leigh <[EMAIL PROTECTED]> writes: > I believe that post-sarge it's possible to use '~' in version numbers? > > When 5.0.0 comes out, I don't want the -beta and -pre releases to sort > higher than it, and I'd rather not resort to extra ugliness in the > version number. What would you recommend as the correct version > numbers to use in the changelog for a smooth upgrade? Are there any > examples? Thanks for all the ideas and examples, folks. I went with Goswin's suggstion, which I like the most. Unfortunately, lintian doesn't like my packages: [...] dpkg-deb: building package `gimp-print' in `../gimp-print_5.0.0~beta3-1_i386.deb'. dpkg-deb: building package `cupsys-driver-gutenprint' in `../cupsys-driver-gutenprint_5.0.0~beta3-1_i386.deb'. dpkg-deb: building package `libgutenprint-5.0.0-beta3-dev' in `../libgutenprint-5.0.0-beta3-dev_5.0.0~beta3-1_i386.deb'. dpkg-deb: building package `libgutenprint-5.0.0-beta3' in `../libgutenprint-5.0.0-beta3_5.0.0~beta3-1_i386.deb'. dpkg-deb: building package `libgutenprintui2-5.0.0-beta3-dev' in `../libgutenprintui2-5.0.0-beta3-dev_5.0.0~beta3-1_i386.deb'. dpkg-deb: building package `libgutenprintui2-5.0.0-beta3' in `../libgutenprintui2-5.0.0-beta3_5.0.0~beta3-1_i386.deb'. dpkg-deb: building package `escputil' in `../escputil_5.0.0~beta3-1_i386.deb'. dpkg-deb: building package `ijsgutenprint' in `../ijsgutenprint_5.0.0~beta3-1_i386.deb'. dpkg-genchanges -mRoger Leigh <[EMAIL PROTECTED]> dpkg-genchanges: including full source code in upload dpkg-buildpackage: full upload (original source is included) Now running lintian... E: gutenprint source: bad-version-number 5.0.0~beta3-1 E: libgutenprintui2-5.0.0-beta3-dev: bad-version-number 5.0.0~beta3-1 E: libgutenprintui2-5.0.0-beta3-dev: bad-version-in-relation depends: libgutenprintui-5.0.0-beta3 (= 5.0.0~beta3-1) E: libgutenprintui2-5.0.0-beta3-dev: bad-version-in-relation suggests: libgutenprint-5.0.0-beta3-doc (= 5.0.0~beta3-1) E: libgutenprintui2-5.0.0-beta3: bad-version-number 5.0.0~beta3-1 E: libgutenprintui2-5.0.0-beta3: bad-version-in-relation depends: libgutenprint-5.0.0-beta3 (>= 5.0.0~beta3) E: libgutenprintui2-5.0.0-beta3: bad-version-in-relation recommends: gutenprint-locales (>= 5.0.0~beta3-1) E: libgutenprint-5.0.0-beta3-doc: bad-version-number 5.0.0~beta3-1 E: libgutenprint-5.0.0-beta3-doc: bad-version-in-relation suggests: libgutenprint-5.0.0-beta3-dev (= 5.0.0~beta3-1) E: escputil: bad-version-number 5.0.0~beta3-1 E: escputil: bad-version-in-relation depends: libgutenprint-5.0.0-beta3 (>= 5.0.0~beta3) E: escputil: bad-version-in-relation suggests: gutenprint-locales (>= 5.0.0~beta3-1) [...] This is my version number: $ head -n 1 debian/changelog gutenprint (5.0.0~beta3-1) unstable; urgency=low The release was called gutenprint-5.0.0-beta3.tar.gz and unpacks into the same. I unpacked it, renamed to gutenprint-5.0.0~beta3 and repacked as gutenprint_5.0.0~beta3.orig.tar.gz. Is any of this wrong, or is lintian in error? Are there any real examples of '~' in use yet? Many thanks, 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.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCC7zJVcFcaSW/uEgRAgz3AJ9DAqP8hxUvYjBCKMj14qiJOXVoNwCfe0su tfJMeGRzzzwZrMXX5nbUPQc= =jRDz -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Versioning prereleases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adeodato Simà <[EMAIL PROTECTED]> writes: > * Roger Leigh [Thu, 10 Feb 2005 19:58:03 +]: > >> Are there any real examples of '~' in use yet? > > Not in the official archive. Anywhere else? >Goswin's sentence "But ~ isn't allowed for sarge, repeat NOT FOR > SARGE" really implies that ~ is not allowed for versions of > packages in the official Debian archive _until_ sarge releases. > > If you intend to make an official upload, you can't use ~. I'm uploading to experimental. Once tested, I may upload to sid with an RC bug to prevent migration to sarge. I obviously don't want untested beta code in sarge. - -- 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.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCC9xxVcFcaSW/uEgRAoT3AJ9d0YS7zcIFebiOnjZvuT2ekNQ3ygCfTTV7 K8oTBrNqRXCs6maJ6SlpLus= =tEjp -END PGP SIGNATURE-
Re: RFS2: check -- unit test framework for C
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Lemmen <[EMAIL PROTECTED]> writes: > a while ago i was looking for a sponsor for check, but unfortunately i > couldn't find one. so i try again ;) > > it's a very interesting package, lintian clean and builds under > pbuilder. shouldn't have many problems. the package is orphaned and > really outdated in debian, but people do use it (i even got mails when i > filed the ITA...) so i think it would be very usefull to have the new > version in debian. I took a look. I would suggest that you first make it lintian-clean (run "lintian -i uterm_xyz.changes"). The problems are fairly minor. 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.0 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCFRL1VcFcaSW/uEgRApJSAKC3oCPL8mk5jMiGpp41Cq0Q3BK4UwCfTVsd tSRIkALHKS92U+ShTrb8XJo= =IIoL -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stupid shebang tricks
On Wed, May 11, 2005 at 11:04:06PM +1000, Ben Finney wrote: > On 11-May-2005, martin f krafft wrote: > > also sprach Ben Finney <[EMAIL PROTECTED]> [2005.05.11.0307 +0200]: > > > To what extent should that be used? Is it reasonable to do it for > > > *any* shebang line? '#!/usr/bin/env make'? '#!/usr/bin/env bash'? > > > Debian standardises executable locations, so there is no need for > > lookup. > > The context of the '#!/usr/bin/env python' trick extends beyond Debian > though; the whole point is that a lookup will work in environments where > the location of the executable *isn't* the standard one. > > If we could safely assume our scripts would only ever be run on Debian > systems, we could dispense with a great many portability tricks. My solution, using perl scripts as an example, is to write [EMAIL PROTECTED]@ -w and use autoconf to generate the script for me, using AC_PATH_PROG([PERL], [perl]) and naming the script myscript.in, which is processed by configure to create myscript, where the top line now reads #!/usr/bin/perl -w This also allows any other configure substitutions to be made (version information, paths and file locations, configuration information etc.) This applies equally to python and any other scripting languages. Regards, Roger -- Roger Leigh Printing on GNU/Linux? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848. Please sign and encrypt your mail. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plotutils -- The GNU plotutils (plotting utilities) package
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Floris Bruynooghe <[EMAIL PROTECTED]> writes:
> Plotutils was orphaned quite a while ago (#279827). In the packages I
> created all outstanding bugs are closed. Also the packages now use
> dpatch to keep a clean upstream tree. They are available at
> http://www.soton.ac.uk/~fb102/Debian.
Your changelog has a spelling mistake ("postscrip"). More
importantly, it doesn't document all of your changes. We don't impose
penalties for more detailed descriptions, so feel free to be more
verbose. This is of great benefit to those who are not familiar with
the package. For example, you "use dpatch", but you could detail
exactly how you are using dpatch with a description of each patch.
What is debian/changelog.mine? You might want to take a more careful
look at the diff (read through it by hand; vim with syntax
highlighting is good for this), and remove any temporary or crufty
bits that shouldn't be there, and double check all changes.
- From my quick look at the diff, it looks like all of the autotools
stuff, and texinfo.tex and the info docs have been regenerated. This
was also in 4.2.1-12. If you didn't already, it might be a good idea
to regenerate them again with current tools to ensure they are
up-to-date.
Have you coordinated this with the QA team? The latest upload was
just 4 days ago. It's worth asking the developer who did that upload,
if you haven't already.
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.0 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>
iD8DBQFCgm7eVcFcaSW/uEgRAmLsAJ0V5Go7NAi6qfeJIIDkGdxTlcTTxgCgmN+q
TjCRimCWzS+8jKQQ1p9Uwtg=
=5XwC
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: plotutils -- The GNU plotutils (plotting utilities) package
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Floris Bruynooghe <[EMAIL PROTECTED]> writes: > On Wed, May 11, 2005 at 09:45:20PM +0100, Roger Leigh wrote: >> Floris Bruynooghe <[EMAIL PROTECTED]> writes: >> >> importantly, it doesn't document all of your changes. We don't impose >> penalties for more detailed descriptions, so feel free to be more >> verbose. This is of great benefit to those who are not familiar with >> the package. For example, you "use dpatch", but you could detail >> exactly how you are using dpatch with a description of each patch. > > I have detailed all (?) my changes now (from looking at my diff), I > haven't described every patch however. Is that really desirable? Yes. The purpose of the changelog is to inform everyone else (and remind you later) what changes you made. I also try to explain /why/ I made the changes, since this explains to others what the rationale and purpose of the change are. I often find myself reviewing changes I made months or years back, and having a good explanation really helps. See the xserver-xfree86 changelog for a good example. > There is always the dpatch-list-patches command. It seems ok to write > if you modify or add a patch, but seems a bit lengthy to describe the > ~13 patches which where already in the old .diff.gz and are now split > off. This is a one-off, due to the conversion to dpatch. 13 patch descriptions is not a lot to document. You are right in that they were already in the .diff.gz, but you are supposed to be describing the changes you made to the packaging, which naturally will include these files. >> What is debian/changelog.mine? You might want to take a more careful > > > Thanks, this'll learn me not to prepare a package in between two > lectures and decide it'll be fine. I'll take my time from now on. That's a very good idea. There really is no rush to do things. Your package will be in Debian for many months, maybe even years, so an extra few hours of checking and testing are well worth it in the grand scheme of things. [regenerating autotools] > So I was wondering, there must be a "proper" way of handling this. I > can't be the only one wanting to regenerate the autotools at build > time and keep a clean upstream tree. Did I miss something obvious? Providing you have the correct versions of the autotools, you should be able to run them, and have the changes included in the .diff.gz, like now. If you are having trouble, it may be best just to leave them. If it's not using the current versions of the autotools, and you know how to handle them, you could convert the package to use the current versions, and send the changes upstream (if not done in their development branch). >> Have you coordinated this with the QA team? > Why (and what) would I need to ask? The developer who did the > upload did not file an ITA and is doubtlessly buzzy with other > things. He only noticed, just like me, that the outstanding bugs > where easy to fix and did so. Not that I want to appear rude or so, > but I just don't see why that would be of needed. Well, it never hurts to let others know what you're working on, and cooperating and coordinating work with others is rather important. The developer who did the last upload will be somewhat familiar with the package, and may therefore be best suited to reviewing your work, and maybe even sponsoring it. 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.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFChgDxVcFcaSW/uEgRAivBAJ9J/Fa9C8fHL8IHBN334zaowujVbgCg2iYc +Qm+7pB9CbGdZVzHvuSaNkk= =CT7C -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help Requested for testing a Game on a PowerPC Architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miriam Ruiz <[EMAIL PROTECTED]> writes: > Latest version of the game Holotz's Castle crashed on powerpc due to endianess > problems ( http://bugs.debian.org/304715 ). According to upstream author this > is solved now, but neither he nor me have a powerpc availabe in which we can > test it, so we cannot be sure of it. > > The newest packages are available at: > http://156.35.156.136/inniyah/holotz-castle/holotz-castle_1.3.6-1.dsc > http://156.35.156.136/inniyah/holotz-castle/holotz-castle_1.3.6.orig.tar.gz > http://156.35.156.136/inniyah/holotz-castle/holotz-castle_1.3.6-1.diff.gz There are a number of problems with this source. The author does not enable any gcc warnings, so there are a number of problems with the code that need fixing. I've built the package with CFLAGS += -Wall, and put the build log here: http://people.debian.org/~rleigh/holotz-castle_1.3.6-1_20050603-1032 Once these are fixed, enable all the extra C++ warnings and fix those, too. This should flush out a /lot/ of problems. I would highly recommend using autoconf and automake, which makes changing the CFLAGS very simple. I had to change the compiler flags in all the Makefiles separately. > If I cannot find a machine in which I can test it, should I upload it to > Debian's repository and wait for bug reports? You can, but I'll test it at home tonight for you. However, until all the compiler warnings have been fixed, there may be other problems. 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.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCoCb0VcFcaSW/uEgRAjcYAKCy63+gLF/PA8lTNDzV/pybln2qBACfdjd/ aNi0qkv7o5i0NtAXbMr7siQ= =UbC2 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Help Requested for testing a Game on a PowerPC Architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Miriam Ruiz <[EMAIL PROTECTED]> writes: > Latest version of the game Holotz's Castle crashed on powerpc due to endianess > problems ( http://bugs.debian.org/304715 ). According to upstream author this > is solved now, but neither he nor me have a powerpc availabe in which we can > test it, so we cannot be sure of it. It Worked For Me™. I started a new game, and played for a few screens without problems. There wasn't any sound, though. - -- 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.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCoZiPVcFcaSW/uEgRAkn1AKCj8+Vs0Bq64LFNyeaYMwB+Ytf26gCg6KSv gnv/TizsFhHN0+Kp71Jbrz4= =/x+e -END PGP SIGNATURE-
Re: RFD/RFS: gtk+extra-2.0 -- A useful set of widgets for GTK+ 2.0
ucf' not empty so not removed. Removing libfontconfig1 ... Purging configuration files for libfontconfig1 ... Removing libxext6 ... Purging configuration files for libxext6 ... Removing libexpat1 ... Purging configuration files for libexpat1 ... Removing libx11-6 ... Purging configuration files for libx11-6 ... Removing libglib2.0-0 ... Purging configuration files for libglib2.0-0 ... Removing defoma ... Purging configuration files for defoma ... dpkg - warning: while removing defoma, directory `/etc/defoma' not empty so not removed. Removing file ... Purging configuration files for file ... Removing whiptail ... Removing libpopt0 ... Purging configuration files for libpopt0 ... Removing libfreetype6 ... Purging configuration files for libfreetype6 ... Removing libnewt0.51 ... Purging configuration files for libnewt0.51 ... Removing xlibs-data ... Purging configuration files for xlibs-data ... Removing libmagic1 ... Purging configuration files for libmagic1 ... Removing xfree86-common ... Purging configuration files for xfree86-common ... ** Finished at 20050615-1935 Build needed 00:00:03, 5932k disk space - -- 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.1 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iD8DBQFCsIFWVcFcaSW/uEgRAp0OAKDo32UkR59V18irdYCYvAFop9gtZACgh7YR pdCNTYHZqv8sBrr9/OEwIlk= =MYIi -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Making a package with multiple binaries
I have made a package with debhelper and dh_make, which produces a single
binary deb. However, now I would like to make two binaries from the same
packages, identical except for that each is built with different options
to configure (one has support for the LPRng print spooler and one does
not).
I was advised to look at the sample rules files in
/usr/share/doc/debhelper/examples, but I am not quite understanding what
they do. I looked at the glib source, and could follow that, but I was
advised to use DH_OPTIONS instead of many separate rules and -p options to
debhelper scripts, but I fail to see how to run configure twice, with
different options in the build-stamp rule and then install both into the
right place in the install rule (I just get identical stuff pacakged in
two locations), and dh_gencontrol also breaks:
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
The dependency file is not output.
(The current copy (I took a lot of broken stuff out) of this is at
http://www-users.york.ac.uk/~rl117/linux/stcolortool-debpack.tar.gz)
Any advice or pointers to documentation appreciated (I could find little
about making this type of package).
Many thanks,
Roger Leigh
--
Roger Leigh ** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://www-users.york.ac.uk/~rl117/linux/
For GPG Public Key: finger [EMAIL PROTECTED] or see
http://pgp5.ai.mit.edu/pks-commands.html#extract
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making a package with multiple binaries
Thanks for all the suggestions. I will try and get everything working later on today. Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://www-users.york.ac.uk/~rl117/linux/ For GPG Public Key: finger [EMAIL PROTECTED] or see http://pgp5.ai.mit.edu/pks-commands.html#extract -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
