Re: Debian's birthday, 16th of august
On Tue, Aug 01, 2006 at 12:04:17PM +0200, Enrico Zini wrote: On Tue, Aug 01, 2006 at 10:55:31AM +0200, Filippo Giunchedi wrote: noi cosa si fa? una birra da qualche parte? 16 di Agosto è periodo di gavettoni. Ci si trova per una flamewar? :) hahah non sarebbe male, chi vuole puo' scendere (o salire) a rimini per una gavettonata filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: What a strange illusion it is to suppose that beauty is goodness. -- Lev Tolstoj signature.asc Description: Digital signature
Re: Debian's birthday, 16th of august
Ciao! On Tue, 01 Aug 2006 12:35:10 +0200, Filippo Giunchedi wrote: On Tue, Aug 01, 2006 at 12:04:17PM +0200, Enrico Zini wrote: On Tue, Aug 01, 2006 at 10:55:31AM +0200, Filippo Giunchedi wrote: noi cosa si fa? una birra da qualche parte? 16 di Agosto è periodo di gavettoni. Ci si trova per una flamewar? :) hahah non sarebbe male, chi vuole puo' scendere (o salire) a rimini per una gavettonata Tenendo conto che molto probabilmente non ci saro' (non e' semplice scendere da Ginevra per un gavettone...), proporrei torta di compleanno, gavettoni e Mao :-D Grazie, ciao, Gismo / Luca pgpDuBDuGvGJo.pgp Description: PGP signature
Re: dh_python and python policy analysis
On Mon, Jul 31, 2006, Manoj Srivastava wrote: 2.1. [5]XS-Python-Version: 2.2. [6]XB-Python-Version: Your document keeps mentionning these, even as requirements, but XB- isn't required for packages using python-support, and XS can be replaced by debian/pyversions. Is your document targetted at inclusion in the dev-ref? PS: I really don't see the point in cross-posting to debian-devel@, please either post to one or the other, thanks. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Roberto C. Sanchez [EMAIL PROTECTED] wrote: Not sure if I missed it, but you seem to claim a copyright but not give an explicit license. I imagine you meant to put it under GPL or a free version of the GFDL. Could you please clarify and also add it to the document? I couldn't care less whether this thing has a license or not, but if it gets one, I'm sure Manoj will *not* choose any variant of the GNU Free Documentation License. And nobody should do that, or encourage people to use this flawed license. Note that we have voted by a GR that the GFDL is acceptable under certain conditions - but not that it is a good license. It isn't. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Translated packages descriptions progress
On Mon, Jul 31, 2006 at 02:06:26PM +0900, Charles Plessy wrote: Le Sun, Jul 30, 2006 at 08:26:02AM +0200, Michael Vogt a écrit : 1. send a Mail to [EMAIL PROTECTED] with the subject 'GET 3 cs' (use cs da de eo es fi fr hu it ja nl pl pt_BR pt_PT ru sk sv_SE uk as langcode) Dear Michael, Hi Charles, how can we get description for specific packages? There are some pages of the debian web site, such as in the debian-med area [1], which contain package descriptions that have therefore have already been translated in some languages. I'm not that familiar with the ddtp server infrastructure, I was working on the apt client integration. Michael Bramer or debian-i18n will know :) Cheers, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ir-kbd-gpio.ko missing from kernel images
Le mardi 01 août 2006 à 17:40 +1200, David Shepherd a écrit : Hi All I'm trying to get the infra-red remote control working on my MythTV box and can't find the correct module (ir-kbd-gpio) So, can anyone tell me where I can find, or how I can compile the ir-kbd-gpio.ko module. It seems to have disappeared between versions 2.6.15 and 2.6.16. Maybe it was replaced by something else? -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Successful and unsuccessful Debian development tools
On Aug 01, David Nusinow [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. -- ciao, Marco signature.asc Description: Digital signature
Re: Translated packages descriptions progress
On Mon, Jul 31, 2006 at 12:47:05PM +0200, Martijn van Oosterhout wrote: On 7/30/06, Michael Vogt [EMAIL PROTECTED] wrote: As someone who has been loosely following this for a while and translated a few descriptions, I have a few little questions/comments: 1. The website you provide (http://ddtp.debian.net/) is extremely light on detail. It contains just the translations, nothing else. Something I've wished for is a link to a site provide translations of common technical terms, given they're not in the usual dictionaries. If that link got included in the email it'd be great. At the moment I'm using http://www.kde.nl/helpen/woordenlijst.html but even that's missing some common words. Thanks for this suggestion. We are aware of the fact that the ddtp website is a bit short on details right now. I hope one of the server admins can improve it a bit. 2. What's with the graph? It looks odd. Michael Bramer explained that there is currently a problem with the merging and that he is investigating. 3. There's some comments further in the thread about the review process not working, or something like that. What's up with that? The current ddtp.debian.net server is a intermediate solution that we hope to supersede with something based on a new debian-wide translation infrastrucutre (debian-i18n people, please correct me if I'm wrong here). This means that some commands are not working on ddtp.debian.net. Other than that, I'm glad there's progress. Getting translated descriptions is a really cool goal. I think we got a step closer, but there is still some work to be done. I'm sure the ddtp server admins will appreciate any help and I would appreciate any testing of the new apt code :) Thanks, Michael -- Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Le lundi 31 juillet 2006 à 21:10 -0500, Manoj Srivastava a écrit : Public modules are available for use in other Python scripts or modules using the import directive. They are installed in one of the directories /var/lib/python-support/pythonX.Y /usr/share/python-support Note that these two contain the same modules. The /usr/share directory isn't read by python, only the generated tree in /var is. The new python policy places certain requirements for packages that contain Python bits. 2.1. XS-Python-Version: 2.2. XB-Python-Version: These two are by no means requirements. XS-Python-Version is only a way to tell the packaging tools which versions to use, but you can also use debian/pyversions which is the recommended way as it doesn't pollute control files. XB-Python-Version is a way to generate metadata but it isn't necessary either. The same applies to all you've written about these fields. 2.3. Depends: Packaged modules available for the default Python version (or many versions including the default) must depend on python (= X.Y). If they require other modules to work, they must depend on the corresponding python-foo. They must not depend on any pythonX.Y-foo. For the packages to be consistent, the package should depend on all pythonX.Y-foo for the versions listed in Provides:. However, no packaging tool is currently able to generate this information. 2.4. Provides Packages with public modules and extensions should be named, or should provide, python-foo, if the package contains an extension for more than one python version. Also, for every version of python supported the package should provide pythonX.Y-foo packages. In fact, it should not provide this unless it has correct dependencies on all pythonX.Y-bar - but everyone is doing this wrong. 3.1.1.1. XS-Python-Version: This is a list of python versions supported by the package. This field can be a single version, or a set of ranges. This should be set to the list of python versions that the script can support, or all. If a script invokes /usr/bin/pythonX.Y, then XS-Python-Version should be set to X.Y. If dh_python isn't able to parse these headers (as it used to do in the old policy), I consider it a bug. 3.1.5. Public Extension Public extensions should be packaged with a name of python-foo, where foo is the name of the module. Such a package should support the current Debian Python version, and more if possible. Maybe a word on how public extensions and public python modules interact would be nice. Generally speaking, I don't find this document useful to the package maintainer. It focuses mostly on python-central's internals, which don't need to be fully understood by the maintainer, and which aren't useful if you don't use python-central. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Successful and unsuccessful Debian development tools
#include hallo.h * Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]: On Aug 01, David Nusinow [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) No, debootstrap is an important toy but but pbuilder is hyped too much. Eduard. -- Arzt: Gegen ihre Platzangst hilft unter Umständen auch eine Diät! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 10:06:05AM +0200, Eduard Bloch wrote: #include hallo.h * Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]: On Aug 01, David Nusinow [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. += piuparts That's a bold statement. Are you serious? (SCNR ;-) No, debootstrap is an important toy but but pbuilder is hyped too much. Not for me. I use pbuilder and piuparts many times every day. Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]: On Aug 01, David Nusinow [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) No, debootstrap is an important toy but but pbuilder is hyped too much. I think maintainers should really build and test their packages in clean sid chroots. It's not important Whether these are set up with debootstrap or any other method, and whether the handling is done with pbuilder, manually or with other tools. But it should be done, and since these are the only tools for the purpose I know of, and people don't like to do all by hand, I think they are in fact very important. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Successful and unsuccessful Debian development tools
Frank Küster [EMAIL PROTECTED] writes: Eduard Bloch [EMAIL PROTECTED] wrote: #include hallo.h * Marco d'Itri [Tue, Aug 01 2006, 09:53:21AM]: On Aug 01, David Nusinow [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) No, debootstrap is an important toy but but pbuilder is hyped too much. I think maintainers should really build and test their packages in clean sid chroots. It's not important Whether these are set up with debootstrap or any other method, and whether the handling is done with pbuilder, manually or with other tools. But it should be done, and since these are the only tools for the purpose I know of, and people don't like to do all by hand, I think they are in fact very important. There is also sbuild (which may be used with or without schroot to manage the chroot). I prefer it to pbuilder, but I may be a little biased ;-) -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please sign and encrypt your mail. pgpf7yeY9M6tH.pgp Description: PGP signature
(libraries) transition best pratices
Hi, a wiki page[0] has been created to list the transition best pratices for developers to follow while introducing new libraries versions (ABI/API incompatible). Feel free to add what's missing. thanks, filippo [0]: http://wiki.debian.org/TransitionBestPractices -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: Computer Science is no more about computers than astronomy is about telescopes. -- Edsger Dijkstra signature.asc Description: Digital signature
Re: Translated packages descriptions progress
On 8/1/06, Michael Vogt [EMAIL PROTECTED] wrote: I think we got a step closer, but there is still some work to be done. I'm sure the ddtp server admins will appreciate any help and I would appreciate any testing of the new apt code :) Sure. I was wondering where the code for ddtp server is. There's an alioth project, but it has nothing past the initial commit. Thanks in advance, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Roger Leigh [EMAIL PROTECTED] wrote: Frank Küster [EMAIL PROTECTED] writes: I think maintainers should really build and test their packages in clean sid chroots. It's not important Whether these are set up with debootstrap or any other method, and whether the handling is done with pbuilder, manually or with other tools. But it should be done, and since these are the only tools for the purpose I know of, and people don't like to do all by hand, I think they are in fact very important. There is also sbuild (which may be used with or without schroot to manage the chroot). I prefer it to pbuilder, but I may be a little biased ;-) Isn't sbuild usually using a permanently unpacked chroot which persists between different invocations of the tool? That's not what I'd call a clean chroot, although a skilled and concentrated person might do well with it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: Successful and unsuccessful Debian development tools
Frank Küster wrote: There is also sbuild (which may be used with or without schroot to manage the chroot). I prefer it to pbuilder, but I may be a little biased ;-) Isn't sbuild usually using a permanently unpacked chroot which persists between different invocations of the tool? That's not what I'd call a clean chroot, although a skilled and concentrated person might do well with it. This applies to the DSA version, which is used on the buildds. The sbuild package in debian however adds more features, like schroot support. With this, it can use schroot to create temporary, clean chroots from tarballs, block devices, create lvm snapshots on the fly and so on. I read Roger, that even xen support is planned. schroot is another very very useful tool. It gives me more or less instant access to clean chroots on lvm snapshots for experimenting, building, developing and testing. Greetings, Reinhard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Frank Küster wrote: Roberto C. Sanchez [EMAIL PROTECTED] wrote: Not sure if I missed it, but you seem to claim a copyright but not give an explicit license. I imagine you meant to put it under GPL or a free version of the GFDL. Could you please clarify and also add it to the document? I couldn't care less whether this thing has a license or not, but if it gets one, I'm sure Manoj will *not* choose any variant of the GNU Free Documentation License. And nobody should do that, or encourage people to use this flawed license. Note that we have voted by a GR that the GFDL is acceptable under certain conditions - but not that it is a good license. It isn't. Regards, Frank Thanks for the clarification. I was unaware of that. I just wanted to make certain that there were not any questions about it (the ability to derive from/modify Manoj's work). -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: Successful and unsuccessful Debian development tools
On Aug 01, Eduard Bloch [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) Yes. I do not use either and I think I have been doing serious Debian work so far. Building in chroots *hides* bugs. -- ciao, Marco signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
Reinhard Tartler [EMAIL PROTECTED] wrote: Frank Küster wrote: There is also sbuild (which may be used with or without schroot to manage the chroot). I prefer it to pbuilder, but I may be a little biased ;-) Isn't sbuild usually using a permanently unpacked chroot which persists between different invocations of the tool? That's not what I'd call a clean chroot, although a skilled and concentrated person might do well with it. This applies to the DSA version, which is used on the buildds. The sbuild package in debian however adds more features, like schroot support. With this, it can use schroot to create temporary, clean chroots from tarballs, block devices, create lvm snapshots on the fly and so on. I read Roger, that even xen support is planned. Ah, great. Good to know - this will probably require some reading and configuring, but it sounds it's worth it. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Bug#380999: RFH: mc -- midnight commander - a powerful file manager
Package: wnpp Severity: normal I request assistance with maintaining the mc package. I'm currently the only active maintainer for the mc package, and there's around 80 bugs to fix in the BTS. Most of the bugs are upstream, so the main tasks would be: - to check if the bugs in the BTS aren't already fixed - ask for more information when bugs are not reproductible - report the upstream bugs to the upstream BTS There's already a CVS on alioth to ease the collaboration on mc, http://alioth.debian.org/projects/pkg-mc/, but keep in mind that the current maintaining policy is to keep the number of Debian patches to mc as low as possible, to make upstream updates as easy as possible. So to sum up, joining the Debian mc team will be mainly a BTS job (so you don't even need to be an official Debian Developer). Cheers, Ludovic Drolez. The package description is: GNU Midnight Commander is a text-mode full-screen file manager. It uses a two panel interface and a subshell for command execution. It includes an internal editor with syntax highlighting and an internal viewer with support for binary files. Also included is Virtual Filesystem (VFS), that allows files on remote systems (e.g. FTP, SSH, SMB servers) and files inside archives to be manipulated like real files. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.27-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Building in chroots (was: Successful and unsuccessful Debian development tools)
[EMAIL PROTECTED] (Marco d'Itri) wrote: On Aug 01, Eduard Bloch [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) Yes. I do not use either and I think I have been doing serious Debian work so far. Building in chroots *hides* bugs. Of course. However, not building in chroots also hides bugs. Why do you think it's better to build in a chroot? I think a package should be built on the developer's system (which, hopefully, is a typical example for the environment were the package will be used and built), and in a clean chroot. It should be tested (in the sense of: Can it be installed? Does it run at all?) in a chroot, and also on the developer's system. Of course the amount of testing needed depends on the extent of the changes. But not testing at all in a clean environment isn't a good idea, at least with the packages that I work with. In particular because I frequently have locally changed configuration files, which may hide some bugs, too. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX/TeXLive)
Re: virtual packages `pinentry' and `pinentry-x11'
Tatsuya Kinoshita writes (Re: virtual packages `pinentry' and `pinentry-x11'): Hmm, I have not yet understand the policy 3.6: | All packages should use virtual package names where appropriate, and | arrange to create new ones if necessary. They should not use virtual | package names (except privately, amongst a cooperating group of | packages) unless they have been agreed upon and appear in the list of | virtual package names. Could anyone rephrase except privately, amongst a cooperating group of packages? When I wrote that I meant the situation where the maintainer(s) of the cooperating packages are the same people, or have discussed it with each other. The point is that we need to know what the virtual package name means. For the ones listed in policy the policy says what they mean. If you have a pile of obscure packages which no-one else cares about then you don't need to bother writing it down. If you have an intermediate situation then some communication between the various maintainers is needed. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
also sprach David Nusinow [EMAIL PROTECTED] [2006.08.01.0005 +0100]: Subversion, in conjunction with alioth, has risen dramatically in Debian to accomodate team-based maintainance. There are of course plenty of challengers, but subversion seems to beat them all. I'd be interested in your thoughts as to why subversion beats them all, in your perception. Thanks, -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system for years, we have thought that a million monkeys typing at a million typewriters would eventually produce the complete works of shakespeare. today, thanks to the internet, we know this is not true. signature.asc Description: Digital signature (GPG/PGP)
Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system emacs sucks, literally, not an insult, just a comment that it's large enough to have a noticeable gravitational pull... -- mercury on #debian-devel signature.asc Description: Digital signature (GPG/PGP)
Re: Successful and unsuccessful Debian development tools
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 01, David Nusinow [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. -- ciao, Marco Never used either one. I have cdebootstrap do create chroots, dchroot to use them, buildd/sbuild to test compile under true buildd conditions. Why would I want something else? Debootstrap couldn't even handle dependency resolving a while back. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots (was: Successful and unsuccessful Debian development tools)
#include hallo.h * Frank Küster [Tue, Aug 01 2006, 01:55:14PM]: [EMAIL PROTECTED] (Marco d'Itri) wrote: On Aug 01, Eduard Bloch [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) Yes. I do not use either and I think I have been doing serious Debian work so far. Argh, the smiley was there for a reason... Building in chroots *hides* bugs. Of course. However, not building in chroots also hides bugs. Why do you think it's better to build in a chroot? After all, I think after comparing pros and cons the bill will be even. But at much higher processing costs. I am sceptical about pbuilder because of it, and because it leads to too much thrust into the tool instead of thinking about possible consequences of changes. I think a package should be built on the developer's system (which, hopefully, is a typical example for the environment were the package will be used and built), and in a clean chroot. It should be tested (in I think it should be working in both, therefore I like the general concept of building in normal environment and uploading package as source trough the auto-builder. the sense of: Can it be installed? Does it run at all?) in a chroot, and also on the developer's system. Of course the amount of testing needed depends on the extent of the changes. Testing is not always enough to catch all possible bugs. Eduard. -- Ich bin sicher, käme Jesus heute, würde er von der Kirche nicht erkannt, sondern wahrscheinlich verfolgt und wieder zu Tode gemartert werden. -- Henry Miller -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 10:24:32AM +, Reinhard Tartler wrote: The sbuild package in debian however adds more features, like schroot support. With this, it can use schroot to create temporary, clean chroots from tarballs, block devices, create lvm snapshots on the fly and so on. I read Roger, that even xen support is planned. schroot is another very very useful tool. It gives me more or less instant access to clean chroots on lvm snapshots for experimenting, building, developing and testing. When I didn't know schroot could do this I wrote a script to do that myself: http://greek0.net/lvmchroot/lvmchroot_0.5-1.dsc It's geared towards creating and maintaining chroots on LVM logical volumes, creating snapshots as needed. It also takes care of creating the initial chroots on LVs, it can automatically upgrade them, etc. Plus they're better documented (IMHO) as schroot, for which I couldn't find any useful docs. If the schroot maintainers agree we could try to merge my stuff into schroot. Cheers, Christian Aichinger signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
Hi, martin f krafft wrote: Subversion, in conjunction with alioth, has risen dramatically in Debian to accomodate team-based maintainance. There are of course plenty of challengers, but subversion seems to beat them all. I'd be interested in your thoughts as to why subversion beats them all, in your perception. It is centralized, so you have an authoritative source and need not talk to the other team members to synchronize. Simon signature.asc Description: OpenPGP digital signature
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
On 8/1/06, martin f krafft [EMAIL PROTECTED] wrote: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. The only example I can think of is programs that use configure to include support for anything they can find installed. So you get different results depending on what's installed in the buildd. It's a bug in the packaging though, the maintainer should be doing --enable-* or --disable-* for every option. The point being that if you only build in a clean chroot you'll never notice the problem. That's how I understand it anyway, Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Hi, On Sun, Jul 30, 2006 at 09:39:26PM +0100, martin f krafft wrote: [...] While I already have a good selection, I am on the look for more. Do you know of a good example of a tool that has successfully shaped Debian development for a large number of people? Or do you remember a tool that tried but horribly failed? Those are much harder to find. :) snapshot.debian.net (still not-official but very usefull and of course PTS, ddpo and po-debconf. Bad tool as a translator, older debconf (previous po-debconf). My 2c, -- Pierre Machard [EMAIL PROTECTED] http://debian.org GPG: 1024D/23706F87 : B906 A53F 84E0 49B6 6CF7 82C2 B3A0 2D66 2370 6F87 signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
also sprach Pierre Machard [EMAIL PROTECTED] [2006.08.01.1501 +0100]: snapshot.debian.net (still not-official but very usefull This is very interesting, especially in the light of version control for packaging -- which could also make packages from the past accessible. Could you give me some insights, please, into how snapshot.d.n is useful? Don't get me wrong, I also find it useful, but mostly from the administrator perspective, I've not really used it as a developer. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system who's general failure, and why's he reading my disk? signature.asc Description: Digital signature (GPG/PGP)
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 03:31:26PM +0100, martin f krafft wrote: Could you give me some insights, please, into how snapshot.d.n is useful? Don't get me wrong, I also find it useful, but mostly from the administrator perspective, I've not really used it as a developer. Binary searching for what version some bug surfaced in; reproduction of upgrade bugs. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
On Tue, 2006-08-01 at 15:31 +0100, martin f krafft wrote: Could you give me some insights, please, into how snapshot.d.n is useful? Don't get me wrong, I also find it useful, but mostly from the administrator perspective, I've not really used it as a developer. I'm using it when porting security fixes to sarge. If the maintainer has fixed a security bug in sid, I download that version and the version before and can see right away what exactly he changed to fix the bug. Thijs signature.asc Description: This is a digitally signed message part
Re: Successful and unsuccessful Debian development tools
ti, 2006-08-01 kello 15:31 +0100, martin f krafft kirjoitti:
also sprach Pierre Machard [EMAIL PROTECTED] [2006.08.01.1501 +0100]:
snapshot.debian.net (still not-official but very usefull
This is very interesting, especially in the light of version control
for packaging -- which could also make packages from the past
accessible.
Note that source code version control does not always make it easy to
re-create the exact same binary package. If, for example, the package
uses debhelper, and the binary package that actually exist{s,ed} in
Debian was built with an older version of debhelper, re-building the
package from source now with a newer debhelper might not result in a
package that behaves in the same way. For example, the old version might
have not called an init.d script via invoke-rc.d, but the new one does.
This may make things more difficult to debug.
Could you give me some insights, please, into how snapshot.d.n is
useful? Don't get me wrong, I also find it useful, but mostly from
the administrator perspective, I've not really used it as
a developer.
I've used snapshot.d.n once or twice to look for when a problem due to
debhelper changes like described above changed its behavior.
--
When in doubt, use brute force.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 03:31:26PM +0100, martin f krafft wrote: also sprach Pierre Machard [EMAIL PROTECTED] [2006.08.01.1501 +0100]: snapshot.debian.net (still not-official but very usefull This is very interesting, especially in the light of version control for packaging -- which could also make packages from the past accessible. Could you give me some insights, please, into how snapshot.d.n is useful? Don't get me wrong, I also find it useful, but mostly from the administrator perspective, I've not really used it as a developer. I find it helpful when backporting. For example, back when package foo went from version 2.1-3 to 2.1-4, the dependency on package bar was changed from version 1.16 to 1.29. It can be instructive to look at the old versions of the packages to see what has changed. This is not official development since backports are not officially supported, but I know I occasionally backport packages for my own use. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: Digital signature
Re: Why does Ubuntu have all the ideas?
Quoting Holger Levsen ([EMAIL PROTECTED]): Hi, On Saturday 29 July 2006 08:43, Christian Perrier wrote: And get a very nice random theme for gdm, making the system different each time it's booted up. Very user friendly. I agree with Christian. Quite some people will be confused by this, and it's completly unnecessary to have a random theme as default. (Even if it does look more fancy for those who won't be confused.) To be fair with Ryan here, I seem to remember that he mentioned (maybe not in the bug report) that he would consider making a Debian theme the default...if one gets enough acceptance. So, someone has to come with a nice Debian theme for gdm..:-) signature.asc Description: Digital signature
Re: dh_python and python policy analysis
On Tue, 01 Aug 2006 09:55:39 +0200, Josselin Mouette [EMAIL PROTECTED] said:
Le lundi 31 juillet 2006 à 21:10 -0500, Manoj Srivastava a écrit :
Public modules are available for use in other Python scripts or
modules using the import directive. They are installed in one of
the directories
/var/lib/python-support/pythonX.Y /usr/share/python-support
Note that these two contain the same modules. The /usr/share
directory isn't read by python, only the generated tree in /var is.
Thanks, I'll explicitly make a note of that in that section.
The new python policy places certain requirements for packages that
contain Python bits.
2.1. XS-Python-Version: 2.2. XB-Python-Version:
These two are by no means requirements. XS-Python-Version is only a
way to tell the packaging tools which versions to use, but you can
also use debian/pyversions which is the recommended way as it
doesn't pollute control files.
Hmm. I'll remove mention of it, then. How exactly one
invokes packaging tools should not be in this document; which is
trying to be a specification more than a packaging guide.
XB-Python-Version is a way to generate metadata but it isn't
necessary either. The same applies to all you've written about these
fields.
The draft Python policy states:
,[ Section 2.3 ]
| Your control file should also have a line:
| XB-Python-Version: ${python:Versions}
| The python:Versions is substituted by the supported Python versions of
| the binary package, based on XS-Python-Version. (If you are not using
| dh_python you will need to handle this substitution yourself.) The
| format of the field XB-Python-Version is the same as the
| XS-Python-Version field for packages not containing
| extensions. Packages with extensions must list the versions
| explicitely.
`
http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html
Is the draft policy incorrect in this case? (The directive is
a should.)
2.3. Depends:
Packaged modules available for the default Python version (or many
versions including the default) must depend on python (= X.Y). If
they require other modules to work, they must depend on the
corresponding python-foo. They must not depend on any
pythonX.Y-foo.
For the packages to be consistent, the package should depend on all
pythonX.Y-foo for the versions listed in Provides:.
I'll add this note, thanks.
However, no packaging tool is currently able to generate this
information.
Well, that's all right. First we decide what is the right
thing to do, then we provide tools. Packaging tools are there to
assist us, after all, not to limit us.
2.4. Provides
Packages with public modules and extensions should be named, or
should provide, python-foo, if the package contains an extension
for more than one python version. Also, for every version of python
supported the package should provide pythonX.Y-foo packages.
In fact, it should not provide this unless it has correct
dependencies on all pythonX.Y-bar - but everyone is doing this
wrong.
Thanks, I'll try an go through to document to ensure I have
the specifications done correctly.
3.1.5. Public Extension
Public extensions should be packaged with a name of python-foo,
where foo is the name of the module. Such a package should support
the current Debian Python version, and more if possible.
Maybe a word on how public extensions and public python modules
interact would be nice.
I'd appreciate any suggestions.
Generally speaking, I don't find this document useful to the package
maintainer. It focuses mostly on python-central's internals, which
don't need to be fully understood by the maintainer, and which
aren't useful if you don't use python-central.
It is curious that you say that, since I have not yet looked
at pycentral, what you see here is derived ojnly from reading the
draft policy in detail and then reverse engineering what dh_python
does.
The motivation for this exercise was for me to be able to
understand what the desired requirements of the new python policy are
well enough to comply with them -- I prefer not using packaging tools
if I do not understand what they do and can't do it independently.
At this point, could you please point out the salient points
of divergence between python-central and python-support? From what I
am given to understand, these take public pure Python modules and
byte compile them for every avaialable version on the taarget
machine, and recompile as needed when new versions of python become
available.
Pointers to any packaging guyides using either tool would also
be appreciated.
manoj
--
If you can count your money, you don't have a billion dollars. Paul
Getty
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To
'Open Sourcing' Survey #2
Dear fellow developers, Thanks to everyone who has taken the time to complete our survey! Please see [0] for the initial call and background information. 0. http://lists.debian.org/debian-project/2006/07/msg00186.html We want to ensure a good representation of community views, and I was thus asked to send a second call for participation. http://www.calibre.ie/survey/index.php If you have not, please take five minutes to complete the survey. It really does not take longer, requires no login or cookies, and you can win a Nokia 770! Martin Krafft on behalf of Prof. Brian Fitzgerald, University of Limerick, Ireland signature.asc Description: Digital signature (GPG/PGP)
Re: Successful and unsuccessful Debian development tools
Christian Aichinger [EMAIL PROTECTED] writes: On Tue, Aug 01, 2006 at 10:24:32AM +, Reinhard Tartler wrote: The sbuild package in debian however adds more features, like schroot support. With this, it can use schroot to create temporary, clean chroots from tarballs, block devices, create lvm snapshots on the fly and so on. I read Roger, that even xen support is planned. Xen support is planned, but not for the immediate future. I'm waiting on its inclusion in the kernel, and a working powerpc32 port. So it's more of a medium- to long-term goal, unless there are any Xen fanatics who step up to do it sooner :) schroot is another very very useful tool. It gives me more or less instant access to clean chroots on lvm snapshots for experimenting, building, developing and testing. When I didn't know schroot could do this I wrote a script to do that myself: http://greek0.net/lvmchroot/lvmchroot_0.5-1.dsc It's geared towards creating and maintaining chroots on LVM logical volumes, creating snapshots as needed. It also takes care of creating the initial chroots on LVs, it can automatically upgrade them, etc. Plus they're better documented (IMHO) as schroot, for which I couldn't find any useful docs. A complete copy of the docs is here: https://alioth.debian.org/docman/?group_id=30471 I agree they aren't the most user-friendly in the world; some additional explanatory material would help a great deal. I think schroot has a slightly different focus, which would account for the differences. schroot focuses on allowing user access to, and maintainence of chroots. It plays no part in the initial chroot creation, or performing stuff like keeping them up-to-date. It delegates this to other tools, like debootstrap and the sbuild chroot tools (in /usr/share/sbuild). lvmchroot, on the other hand, assists with initial chroot setup, and snapshot creation but doesn't handle the chroot(2) stuff to allow user access. As a result, I think the two tools could complement each other nicely. I would be very happy to add additional helper scripts to schroot, and merge missing features. One thing we don't currently do is allow the user to specify the LVM snapshot name; it gets a UUID. Having this as an option would be nice. Some of the sbuild scripts could also be merged with lvmchroot, such as buildd.chroot. If the schroot maintainers agree we could try to merge my stuff into schroot. That would be really cool. We are part of the buildd-tools project on Alioth: https://alioth.debian.org/projects/buildd-tools/ so subscribing to the list would be a good first step. The current SVN is at svn://svn.debian.org/svn/buildd-tools/trunk/schroot 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 sign and encrypt your mail. pgpvazcFrBsYK.pgp Description: PGP signature
Re: Successful and unsuccessful Debian development tools
On Tuesday 01 August 2006 13:44, martin f krafft wrote: also sprach David Nusinow [EMAIL PROTECTED] [2006.08.01.0005 +0100]: Subversion, in conjunction with alioth, has risen dramatically in Debian to accomodate team-based maintainance. There are of course plenty of challengers, but subversion seems to beat them all. I'd be interested in your thoughts as to why subversion beats them all, in your perception. I know that this has somehow become a religious question. Recently when I looked for a co-maintainer I was told that we can agree on anything as long we we don't use subversion. So I spent several days to wade through the lots of documentation to learn about distributed revision control systems and found darcs, mercury (hg) and bazaar-ng (bzr) to be decent candidates for such an approach. And I currently use bzr to maintain a simple Debian package to gain some experience with it. It's nice and simple. However using distributed RCS is a pain in the kind of projects I work on with other people. Such a system might be great for people in the underground train who want to maintain their packages. But which maintainer does not have a permanent internet connection but enough electricity to operate a laptop for more than 2 hours? And to try out things I can just cp -a a directory tree and test something and perhaps copy files around. Why do I need to do a fancy branch to accomplish the same with more commands and try not to break my fingers when merging the branch? No offense intended - honestly - but the problem of passing patches/patchsets around between the maintainers is really a problem. In Subversion I know where the authoritative instance lies that is the master instance keeping the current state. If there is one superior maintainer who makes the repository available online to co-maintainers who are just allowed to send in patches - that might work well. But if several people are equally involved in a project this seems to quickly become a problem. I had tried distributed RCSs just because it's a more modern approach and because a number of developers and maintainers seem to find Subversion problematic. But if I group maintain a package and need to collect everybody's work before building and uploading a package that's just too hard. The bazaar-ng web site describes a few ways to pass the changes around (http://bazaar-vcs.org/BzrForCVSUsers) but I found neither one very appealing. I don't mind other team members working locally. But I need to get access to their changes ASAP to have them included in the next release/revision. So it appears to be a tradeoff. With distributed RCS you gain the freedom to develop everywhere as long as you have electricity. But you have the disadvantage that the way to commit changes to a central instance is all but automatic. I'll probably use bzr when I need to keep something revisioned without much fuss just to save the time for svnadmin create and a DAV share on my Apache. But for everything else I think I'll stay with Subversion. And while I haven't tried it I could imagine that SVK (the distributed addon to Subversion) might be what makes offline fellows happy. My 2¢... Christoph -- ~ ~ .signature [Modified] 1 line --100%--1,48 All
Re: Successful and unsuccessful Debian development tools
Simon Richter [EMAIL PROTECTED] writes: Hi, martin f krafft wrote: Subversion, in conjunction with alioth, has risen dramatically in Debian to accomodate team-based maintainance. There are of course plenty of challengers, but subversion seems to beat them all. I'd be interested in your thoughts as to why subversion beats them all, in your perception. It is centralized, so you have an authoritative source and need not talk to the other team members to synchronize. Simon It is very similar to alreay familiar cvs. It is also way easier to use first time than any of the others with the possible exception of git. For example trying arch for the first time gives you a major headache. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs?
martin f krafft [EMAIL PROTECTED] writes: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. Missing Build-Conflicts aren't found. Auto* scripts fail to run because they aren't installed. Users, Groups, dirs, binaries don't exist that would outisde which can influence configure. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Frank Küster [Tue, Aug 01 2006, 01:55:14PM]: [EMAIL PROTECTED] (Marco d'Itri) wrote: On Aug 01, Eduard Bloch [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. Are you serious? (SCNR ;-) Yes. I do not use either and I think I have been doing serious Debian work so far. Argh, the smiley was there for a reason... Building in chroots *hides* bugs. Of course. However, not building in chroots also hides bugs. Why do you think it's better to build in a chroot? After all, I think after comparing pros and cons the bill will be even. But at much higher processing costs. I am sceptical about pbuilder because of it, and because it leads to too much thrust into the tool instead of thinking about possible consequences of changes. Yeah. I always develope outside (or in an unclean) chroot and when I want to release I mangle the source through a clean chroot / buildd again for a final test. I think a package should be built on the developer's system (which, hopefully, is a typical example for the environment were the package will be used and built), and in a clean chroot. It should be tested (in I think it should be working in both, therefore I like the general concept of building in normal environment and uploading package as source trough the auto-builder. That won't test your binary-all target as small as that part is. the sense of: Can it be installed? Does it run at all?) in a chroot, and also on the developer's system. Of course the amount of testing needed depends on the extent of the changes. Testing is not always enough to catch all possible bugs. But not testing is a sure way to overlook them. :) Eduard. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
Thanks, Christoph, I think you argued a good case! I'll probably use bzr when I need to keep something revisioned without much fuss just to save the time for svnadmin create and a DAV share on my Apache. But for everything else I think I'll stay with Subversion. And while I haven't tried it I could imagine that SVK (the distributed addon to Subversion) might be what makes offline fellows happy. FYI: http://bazaar-vcs.org/BzrForeignBranches/Subversion -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system gates' law: every 18 months, the speed of software halves. signature.asc Description: Digital signature (GPG/PGP)
Bug#212049: She will love you more than any other guy
Hey man, told ok I had to send you this site, know I ordered a Gold package and these things work amazingly link! For real, their I've tried a bunch of other ones but they don't work- these ones are the real deal though inside. People see God every day they just don't recognize Him. many Check out the site for yourself: http://www.myrkuri.net/a/?137odfer345 Since we cannot get what we like, let us like what we can get. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
* martin f krafft [EMAIL PROTECTED] [060801 15:29]: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. Missing $(DESTDIR)s in Makefiles are an example. Especially when the install part was DESTDIRified, but the test before if the file is already there (as make install does not want to overwrite a config file) was forgotten. This leads to a corrupt package when build on a system where the package is already installed, i.e. is hidden away in any clean chroot. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs? (was: Successful and unsuccessful Debian development tools)
also sprach Bernhard R. Link [EMAIL PROTECTED] [2006.08.01.1701 +0100]: Missing $(DESTDIR)s in Makefiles are an example. Especially when the install part was DESTDIRified, but the test before if the file is already there (as make install does not want to overwrite a config file) was forgotten. This leads to a corrupt package when build on a system where the package is already installed, i.e. is hidden away in any clean chroot. This makes zero sense to me. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system eine schlechte sache erregt, eine gute verträgt viel kritik. -- charles tschopp signature.asc Description: Digital signature (GPG/PGP)
Re: dh_python and python policy analysis
On Tue, 1 Aug 2006 09:35:56 +0200, Loïc Minier [EMAIL PROTECTED] said: On Mon, Jul 31, 2006, Manoj Srivastava wrote: 2.1. [5]XS-Python-Version: 2.2. [6]XB-Python-Version: Your document keeps mentionning these, even as requirements, but XB- isn't required for packages using python-support, and XS can be replaced by debian/pyversions. I guess I do not understand enough about python-support, in that case. I was basing it off section 2.3 of the draft policy[1], which has inclusions of XB-Python-Version as a should directive. Could you point me to documentation on python-support, what it does, how to use it, and how it differs from python-central? Is your document targetted at inclusion in the dev-ref? Targeted for dev-ref, no. If python policy is ever going to be made into official Debian technical policy, then some kind of detailed specification PS: I really don't see the point in cross-posting to debian-devel@, please either post to one or the other, thanks. I think that this is of general enough interest to involve -devel; but I do not want to miss out Python folks who have given up on -devel, and this is of interest to Python packaging. So, in my opinion, cross posting for this is jusified as long as the discussion stays on topic. manoj [1] http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html -- Who cares if it doesn't do anything? It was made with our new Triple-Iso-Bifurcated-Krypton-Gate-MOS process ... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
On Tue, Aug 01, 2006, Manoj Srivastava wrote: Could you point me to documentation on python-support, what it does, how to use it, and how it differs from python-central? Well, python-support is documented at the expected /usr/share/doc/python-support and in the dh_pysupport man page. Perhaps the wiki page http://wiki.debian.org/DebianPython/NewPolicy is the best place where you can see how the two tools differ? -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Le mardi 01 août 2006 à 09:45 -0500, Manoj Srivastava a écrit :
Public extensions should be packaged with a name of python-foo,
where foo is the name of the module. Such a package should support
the current Debian Python version, and more if possible.
Maybe a word on how public extensions and public python modules
interact would be nice.
I'd appreciate any suggestions.
When there are both public extensions and public modules, both packaging
tools will handle them fine. With python-support, they are put
in /usr/{lib,share}/python-support/$package and will be symlinked
from /var/lib/python-support. The key point is to have them at the same
place, otherwise sometimes they won't work.
When there are only public extensions, packaging tools aren't needed at
all.
Generally speaking, I don't find this document useful to the package
maintainer. It focuses mostly on python-central's internals, which
don't need to be fully understood by the maintainer, and which
aren't useful if you don't use python-central.
It is curious that you say that, since I have not yet looked
at pycentral, what you see here is derived ojnly from reading the
draft policy in detail and then reverse engineering what dh_python
does.
This is because python-central's internals use the control file.
At this point, could you please point out the salient points
of divergence between python-central and python-support? From what I
am given to understand, these take public pure Python modules and
byte compile them for every avaialable version on the taarget
machine, and recompile as needed when new versions of python become
available.
Both tools have the same needs but they do it differently. This is
because python-central relies on special fields in the control file
while python-support relies on its own files and directories.
1. Information given by the maintainer about supported versions in
the source package: python-central uses the XS-Python-Version
field, while python-support uses debian/pyversions. For best
compatibility, both tools are able to use each other's data.
2. Place to store public modules: /usr/share/python-central
vs. /usr/share/python-support/$package.
3. Place to store public extensions: python-central keeps them in
place, in /usr/lib/pythonX.Y/site-packages, while python-support
moves them to /usr/lib/python-support/$package/pythonX.Y.
4. Information stored about supported versions in the binary
package: python-central uses XB-Python-Version - which is
mandatory in this case - while python-support uses either the
list of public extensions versions
in /usr/lib/python-support/$package or
the /usr/share/python-support/$package/.version file.
5. Information about which private extensions to bytecompile:
python-central will use all files ending in .py belonging to the
package, while python-support lists directories
in /usr/share/python-support/$package.dirs.
Pointers to any packaging guyides using either tool would also
be appreciated.
Python-support's README provides basic information on how to make a
package using it.
There's also a wiki page: http://wiki.debian.org/DebianPythonFAQ
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Why does Ubuntu have all the ideas?
Le dimanche 30 juillet 2006 à 08:36 +0200, Christian Perrier a écrit : To be fair with Ryan here, I seem to remember that he mentioned (maybe not in the bug report) that he would consider making a Debian theme the default...if one gets enough acceptance. Great! So, someone has to come with a nice Debian theme for gdm..:-) The ayo, debian, debian-dawn and debian-greeter themes all received very good feedback. Maybe we can organize an informal vote to choose which of them will become the default. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Successful and unsuccessful Debian development tools
Goswin von Brederlow [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 01, David Nusinow [EMAIL PROTECTED] wrote: Also, pbuilder and debootstrap are considered absolutely critical for serious work. That's a bold statement. -- ciao, Marco Never used either one. I have cdebootstrap do create chroots, dchroot to use them, buildd/sbuild to test compile under true buildd conditions. Why would I want something else? Debootstrap couldn't even handle dependency resolving a while back. I think that by debootstap David was including both normal and cdebootstrap. After all, cdebootstrap is mostly a port of debootstrap, although with some improvments. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
martin f krafft [EMAIL PROTECTED] writes: Thanks, Christoph, I think you argued a good case! I'll probably use bzr when I need to keep something revisioned without much fuss just to save the time for svnadmin create and a DAV share on my Apache. But for everything else I think I'll stay with Subversion. And while I haven't tried it I could imagine that SVK (the distributed addon to Subversion) might be what makes offline fellows happy. FYI: http://bazaar-vcs.org/BzrForeignBranches/Subversion Have you tryed it? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
also sprach Otavio Salvador [EMAIL PROTECTED] [2006.08.01.1804 +0100]: FYI: http://bazaar-vcs.org/BzrForeignBranches/Subversion Have you tryed it? Not productively. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system still looking for the glorious results of my misspent youth. say, do you have a map to the next joint? signature.asc Description: Digital signature (GPG/PGP)
Re: Successful and unsuccessful Debian development tools
martin f krafft wrote: also sprach David Nusinow [EMAIL PROTECTED] [2006.08.01.0005 +0100]: Subversion, in conjunction with alioth, has risen dramatically in Debian to accomodate team-based maintainance. There are of course plenty of challengers, but subversion seems to beat them all. I'd be interested in your thoughts as to why subversion beats them all, in your perception. I assumed he meant it in the sense that more teams seem to be using subversion on alioth than any other RCS. Ie, compare the list at http://svn.debian.org/ with http://arch.debian.org/ Of course there is probably less incentive to use alioth if using a distributed RCS, but my sense is that more projects in debian are using svn version control than any other RCS nontheless. -- see shy jo signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
also sprach Joey Hess [EMAIL PROTECTED] [2006.08.01.1907 +0100]: I'd be interested in your thoughts as to why subversion beats them all, in your perception. I assumed he meant it in the sense that more teams seem to be using subversion on alioth than any other RCS. Ie, compare the list at http://svn.debian.org/ with http://arch.debian.org/ Of course there is probably less incentive to use alioth if using a distributed RCS, but my sense is that more projects in debian are using svn version control than any other RCS nontheless. Yes, and I wanted to know why he thought that is the case. I believe Christoph has given a good account of the reasons. If you have anything to add, please do! -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system i like young girls. their stories are shorter. -- tom mcguane signature.asc Description: Digital signature (GPG/PGP)
Re: Successful and unsuccessful Debian development tools
martin f krafft [EMAIL PROTECTED] wrote: also sprach Pierre Machard [EMAIL PROTECTED] [2006.08.01.1501 +0100]: snapshot.debian.net (still not-official but very usefull This is very interesting, especially in the light of version control for packaging -- which could also make packages from the past accessible. [...] Not every package's source code is kept in a version control repository which is publically available. - Think qa-upload or adoption of an existing non-vcr package. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
martin f krafft [EMAIL PROTECTED] wrote: also sprach Joey Hess [EMAIL PROTECTED] [2006.08.01.1907 +0100]: [...] I assumed he meant it in the sense that more teams seem to be using subversion on alioth than any other RCS. [...] Yes, and I wanted to know why he thought that is the case. I believe Christoph has given a good account of the reasons. If you have anything to add, please do! Basic usage of SVN is quickly learned, especially if you know cvs. cu andreas -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
centralized bzr (Re: Successful and unsuccessful Debian development tools)
* Christoph Haas [Tue, 01 Aug 2006 17:33:15 +0200]: Hi, No offense intended - honestly - but the problem of passing patches/patchsets around between the maintainers is really a problem. In Subversion I know where the authoritative instance lies that is the master instance keeping the current state. If there is one superior maintainer who makes the repository available online to co-maintainers who are just allowed to send in patches - that might work well. But if several people are equally involved in a project this seems to quickly become a problem. I had tried distributed RCSs just because it's a more modern approach and because a number of developers and maintainers seem to find Subversion problematic. But if I group maintain a package and need to collect everybody's work before building and uploading a package that's just too hard. The bazaar-ng web site describes a few ways to pass the changes around (http://bazaar-vcs.org/BzrForCVSUsers) but I found neither one very appealing. I don't mind other team members working locally. But I need to get access to their changes ASAP to have them included in the next release/revision. Right, bzr is great when you have a designed person to integrate contributor's changes after review. But if you have a set of equal developers, bzr can be also used in a very similar way to Subversion, where all commits go to a central repository, and nobody has to collect them. It's just a matter of setting up a directory somewhere with the appropriate write permissions, and say This is our canonical archive, the uploader will include what it's in there, nothing more, nothing less. Then each developer can prepare a set of changes offline, do all the branching, merging, commiting and uncommiting (gotta love that) that they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools (That repository actually exists.) The only piece missing in this scheme is e-mail notification. I very much like how with Subversion it's trivial to set up a pkg-foo-commits list. Haven't figured out a nice way with bzr yet, suggestions welcome. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
* Adeodato Simó [Tue, 01 Aug 2006 20:31:37 +0200]: they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools Forgot to add that it can be even _identical_ to subversion, in the sense that you don't have to commit locally, and then push. Just make a checkout (refer to the bzr docs), and every commit you make will go to the main repo first, and if that succeeds, will be commited locally as well. Not that I'd particularly recommend that scheme, but it _is_ possible. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As scarce as truth is, the supply has always been in excess of the demand. -- Josh Billings -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 07:19:19PM +0100, martin f krafft wrote: Yes, and I wanted to know why he thought that is the case. I believe Christoph has given a good account of the reasons. If you have anything to add, please do! There's also the fact that well known teams like the installer and kernel teams use subversion. This makes it much easier for people looking for a template to follow to pick subversion. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
also sprach Adeodato Simó [EMAIL PROTECTED] [2006.08.01.1936 +0100]: Forgot to add that it can be even _identical_ to subversion, in the sense that you don't have to commit locally, and then push. Just make a checkout (refer to the bzr docs), and every commit you make will go to the main repo first, and if that succeeds, will be commited locally as well. This is what upstream calls bound branches, btw. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system obviously i was either onto something, or on something. -- larry wall on the creation of perl signature.asc Description: Digital signature (GPG/PGP)
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
Adeodato Simó [EMAIL PROTECTED] writes: Then each developer can prepare a set of changes offline, do all the branching, merging, commiting and uncommiting (gotta love that) that they want, and when they're done, do e.g.: % bzr push sftp://costa.debian.org/bzr/pkg-xiph/vorbis-tools We're using that for LTSP. But we're using it in our htdocs dir. How do you set this repository up? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: Successful and unsuccessful Debian development tools
On Tue, Aug 01, 2006 at 03:31:26PM +0100, martin f krafft wrote: Could you give me some insights, please, into how snapshot.d.n is useful? Don't get me wrong, I also find it useful, but mostly from the administrator perspective, I've not really used it as a developer. Testing of various upgrade paths, especially useful to check whether ld reported upgrade bugs are still valid or not. Cheers. -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Centralized darcs (was Re: centralized bzr)
On Tue, Aug 01, 2006 at 08:31:37PM +0200, Adeodato Simó wrote: Right, bzr is great when you have a designed person to integrate contributor's changes after review. But if you have a set of equal developers, bzr can be also used in a very similar way to Subversion, where all commits go to a central repository, and nobody has to collect them. It's just a matter of setting up a directory somewhere with the appropriate write permissions, and say This is our canonical archive, the uploader will include what it's in there, nothing more, nothing less. I would say that this goes for darcs as well, but even more. Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. I think it would work even nicer. -- John
Re: Successful and unsuccessful Debian development tools
also sprach Thijs Kinkhorst [EMAIL PROTECTED] [2006.08.01.1537 +0100]: Could you give me some insights, please, into how snapshot.d.n is useful? Don't get me wrong, I also find it useful, but mostly from the administrator perspective, I've not really used it as a developer. I'm using it when porting security fixes to sarge. If the maintainer has fixed a security bug in sid, I download that version and the version before and can see right away what exactly he changed to fix the bug. This shouldn't need snapshot.debian.net, right? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system oxymoron: micro$oft works signature.asc Description: Digital signature (GPG/PGP)
Re: Why does Ubuntu have all the ideas?
On 8/1/06, Josselin Mouette [EMAIL PROTECTED] wrote: Le dimanche 30 juillet 2006 à 08:36 +0200, Christian Perrier a écrit : To be fair with Ryan here, I seem to remember that he mentioned (maybe not in the bug report) that he would consider making a Debian theme the default...if one gets enough acceptance. Great! Sure. So, someone has to come with a nice Debian theme for gdm..:-) The ayo, debian, debian-dawn and debian-greeter themes all received very good feedback. Maybe we can organize an informal vote to choose which of them will become the default. I think we have a parallel discussion going on with the pkg-xfce, pkg-kde and pkg-gnome teams that hopefully we will end in a online meeting really soon. Christian, i haven't mailed you but if you're interested let me know and i'll forward the messages for you. regards, -- stratus
Re: Centralized darcs (was Re: centralized bzr)
On Tue, 01 Aug 2006, John Goerzen wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. Which would also be a far superior way to deal with centralized bzr. It protects the repository against screwups on the developer's local bzr package (he might be running an alpha version, for example :P), and it provides a central point of control, which is interesting *when dealing with centralized repositories*. Heck, we could adopt even the signed-of-by/acked-by workflow from the Linux kernel where desired... I think it would work even nicer. Agreed. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs (was Re: centralized bzr)
also sprach John Goerzen [EMAIL PROTECTED] [2006.08.01.2055 +0100]: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. This feature is in development for bzr, called the smart server. Just for completeness. John, are you actually using the workflow you describe for maintenance of Debian packages? Single or team maintenance? Could you elaborate a bit? -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system life moves pretty fast. if you don't stop and look around once in awhile, you could miss it. -- ferris bueller signature.asc Description: Digital signature (GPG/PGP)
Re: Centralized darcs (was Re: centralized bzr)
On Tue, Aug 01, 2006 at 09:06:19PM +0100, martin f krafft wrote: This feature is in development for bzr, called the smart server. Just for completeness. John, are you actually using the workflow you describe for maintenance of Debian packages? Single or team maintenance? Could you elaborate a bit? I do use darcs for almost all of my Debian packages. You can find my darcs repositories at http://darcs.complete.org/debian/ In darcs, every working copy is a repository, and a branch is just a get, and a commit to the canonical location is just a merge (darcs push). I've been using darcs push, which sends the patch over ssh, instead of the e-mail thing since I am the only committer to my repos. But sending a GPG-signed patch bundle can be as easy as darcs send and David Roundy has posted recipes for processing those on the server. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Tue, Aug 01, 2006 at 05:36:07PM -0300, Otavio Salvador wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. The only bad thing I know about darcs, for my kinda of use, is the miss of file permission recoring. That's annoying for packaging and like. It is a bit annoying, but --set-scripts-executable does the right thing in about 97% of cases. That can be made the default quite easily. diff also doesn't preserve permissions, so some are using debian/rules anyway. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Recursive Dependency Disease reminder and freetype status
I just finished updating the page http://wiki.debian.org/FreetypeTransition . If your package is listed there, it has a bug: either a missing build-dependency, or recursive dependency disease. We've made a lot of progress, but there are still nearly 200 packages with unneeded and damaging dependencies on libfreetype6. Not to mention the packages with inappropriate recursive dependencies on other packages! libaudio2 is another common excess dependency. For a reminder about recursive dependency disease, see http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html. In the interests of making Debian's dependencies less fragile, I'm bringing this topic up again, since I figure everyone's forgotten about it. If you haven't checked your packages for bogus dependencies, please do so. (Most of the time, a dependency on libfoo without a build-dependency on libfoo-dev indicates either recursive dependency disease or a missing build-dependency. There are rare exceptions; but if you've got *lots* of dependencies like this, you *definitely* have recursive dependency disease.) If you maintain a library which offers a .pc file for pkg-config (or offers a similar tool), please fix it. I will file occasional bugs as I spot them, but given the sheer number of cases, I thought a reminder to all Debian Developers was a better move. If you have difficulty fixing this for your package, I believe several people including me are happy to help. -- Nathanael Nerode [EMAIL PROTECTED] Theocracy, fascism, or absolute monarchy -- I don't care which it is, I don't like it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why does Ubuntu have all the ideas?
Christian, i haven't mailed you but if you're interested let me know and i'll forward the messages for you. I'm not interested more than being sure that our users do get a predictable (and hopefully nice) environment..:-) In short, just keep this bug report posted, that'll be enough. signature.asc Description: Digital signature
Re: Centralized darcs
John Goerzen [EMAIL PROTECTED] writes: On Tue, Aug 01, 2006 at 08:31:37PM +0200, Adeodato Simó wrote: Right, bzr is great when you have a designed person to integrate contributor's changes after review. But if you have a set of equal developers, bzr can be also used in a very similar way to Subversion, where all commits go to a central repository, and nobody has to collect them. It's just a matter of setting up a directory somewhere with the appropriate write permissions, and say This is our canonical archive, the uploader will include what it's in there, nothing more, nothing less. I would say that this goes for darcs as well, but even more. Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. The only bad thing I know about darcs, for my kinda of use, is the miss of file permission recoring. That's annoying for packaging and like. Besides that, darcs rocks. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house.
Re: Two versions of pan in etch?
Søren Boll Overgaard wrote: Essentially, what it boils down to is this: Would it be prudent to include two separate versions of pan in etch (perhaps named pan and pan2)? This should be avoided where possible; if they share a common code base it's quite likely that discovered security problems need to be fixed in both source packages. Cheers, Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
John Goerzen [EMAIL PROTECTED] writes: On Tue, Aug 01, 2006 at 05:36:07PM -0300, Otavio Salvador wrote: Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. The only bad thing I know about darcs, for my kinda of use, is the miss of file permission recoring. That's annoying for packaging and like. It is a bit annoying, but --set-scripts-executable does the right thing in about 97% of cases. That can be made the default quite easily. diff also doesn't preserve permissions, so some are using debian/rules anyway. Indeed but that can make thing broke due the wrong permission of upstream files, iff you use darcs to maintain those fixes mixed with changes for packaging. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
On Tue, Aug 01, 2006 at 06:12:34PM -0300, Otavio Salvador wrote: diff also doesn't preserve permissions, so some are using debian/rules anyway. Indeed but that can make thing broke due the wrong permission of upstream files, iff you use darcs to maintain those fixes mixed with changes for packaging. It's true that it *can* happen, but it rarely *does* happen, and when it does, there are easy workarounds. I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381073: ITP: jabbin -- Jabber client with Jingle VoIP support
Package: wnpp Severity: wishlist Owner: Andrew Donnellan [EMAIL PROTECTED] * Package name: jabbin Version : 2.0 Upstream Author : Stefano Grini [EMAIL PROTECTED] * URL : http://www.jabbin.com * License : GPL Programming Lang: C++ Description : Jabber client with Jingle VoIP support Jabbin is a Jabber instant messaging client based on Psi. It includes support for the Jingle protocol, used to provide Voice over Internet Protocol (VoIP) services. Jabbin is compatible with the voice protocol used by Google Talk (http://talk.google.com). -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7 Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Centralized darcs
John Goerzen [EMAIL PROTECTED] writes: On Tue, Aug 01, 2006 at 06:12:34PM -0300, Otavio Salvador wrote: diff also doesn't preserve permissions, so some are using debian/rules anyway. Indeed but that can make thing broke due the wrong permission of upstream files, iff you use darcs to maintain those fixes mixed with changes for packaging. It's true that it *can* happen, but it rarely *does* happen, and when it does, there are easy workarounds. Indeed. I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Well, it's a bit different point of view. I use both ways of doing that. Sometimes is good to have the patches as files to make easier to merge with upstream ... -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: centralized bzr (Re: Successful and unsuccessful Debian development tools)
On Tue, 2006-08-01 at 19:44 +0100, martin f krafft wrote: also sprach Adeodato Simó [EMAIL PROTECTED] [2006.08.01.1936 +0100]: Forgot to add that it can be even _identical_ to subversion, in the sense that you don't have to commit locally, and then push. Just make a checkout (refer to the bzr docs), and every commit you make will go to the main repo first, and if that succeeds, will be commited locally as well. This is what upstream calls bound branches, btw. Well, we call them 'checkouts' :). bound branches is somewhat of an internal description. We implemented checkouts to be a precise workflow match for what you get from SVN/CVS - a branch shared between developers with the system ensuring you have merged everything. If you have a situation where a shared branch is what you want, and you like bzr in other respects... I would recommend trying checkouts. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Centralized darcs (was Re: centralized bzr)
On Tue, 2006-08-01 at 14:55 -0500, John Goerzen wrote: On Tue, Aug 01, 2006 at 08:31:37PM +0200, Adeodato Simó wrote: Right, bzr is great when you have a designed person to integrate contributor's changes after review. But if you have a set of equal developers, bzr can be also used in a very similar way to Subversion, where all commits go to a central repository, and nobody has to collect them. It's just a matter of setting up a directory somewhere with the appropriate write permissions, and say This is our canonical archive, the uploader will include what it's in there, nothing more, nothing less. I would say that this goes for darcs as well, but even more. Darcs has a nice way of pushing patches via e-mail, with GPG signatures even. These can be processed in an automated way on the server, verified against, for instance, the Debian keyring, and then applied to the repository. I think it would work even nicer. Its somewhat indirect though. bzr has an equivalent system too (called pqm) which accepts GPG-signed merge requests and applies them to the repository. FWIW. Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part
Re: Centralized darcs
also sprach John Goerzen [EMAIL PROTECTED] [2006.08.01.2247 +0100]: I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? I agree, dpatch co seem to be more accessible: they are files you can touch; they're not an abstract concept (branch) which you can work with, but which is not tangible. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system a qui sait comprendre, peu de mots suffisent. -- intelligenti pauca signature.asc Description: Digital signature (GPG/PGP)
Re: Building in chroots hides bugs?
On Tue, Aug 01, 2006 at 05:37:58PM +0200, Goswin von Brederlow wrote: martin f krafft [EMAIL PROTECTED] writes: also sprach Marco d'Itri [EMAIL PROTECTED] [2006.08.01.1221 +0100]: Building in chroots *hides* bugs. Uh, what? Please give an example. Missing Build-Conflicts aren't found. Auto* scripts fail to run because they aren't installed. Users, Groups, dirs, binaries don't exist that would outisde which can influence configure. If a package failts to build from source in a chroot environment, it will fail to build on the autobuilders, and should thus be considered RC buggy. Neil -- gwolf bah Germans. You just put 100 DDs in one country and then they all become friends of each other. signature.asc Description: Digital signature
Re: Centralized darcs
* John Goerzen ([EMAIL PROTECTED]) wrote: On Tue, Aug 01, 2006 at 06:12:34PM -0300, Otavio Salvador wrote: diff also doesn't preserve permissions, so some are using debian/rules anyway. Indeed but that can make thing broke due the wrong permission of upstream files, iff you use darcs to maintain those fixes mixed with changes for packaging. It's true that it *can* happen, but it rarely *does* happen, and when it does, there are easy workarounds. I do use darcs to track patches against upstream. I really don't understand the whole cdbs/dpatch/whatever thing -- why use a hack to manage your patches when you could use a real VC tool that does it better? Amen to that. (although I use svn) -- Eric Dorland [EMAIL PROTECTED] ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Successful and unsuccessful Debian development tools
Stuff deleted I have cdebootstrap do create chroots, dchroot to use them, buildd/sbuild to test compile under true buildd conditions. Why would I want something else? I'm not sure I know, but now that I know about this pair, I will certainly look into it. After that, if I can answer your question, I'll get back to you ;-) I mainly wanted to say thank you, not only to Goswin, but to the rest of you who have helped to turn this list back into something readable! Thank You! Thank You! Thank You! Debootstrap couldn't even handle dependency resolving a while back. Things change. (See above) MfG Goswin Luck, Dwarf -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Recursive Dependency Disease reminder and freetype status
On Tue, Aug 01, 2006 at 04:28:10PM -0400, Nathanael Nerode wrote: I just finished updating the page http://wiki.debian.org/FreetypeTransition . If your package is listed there, it has a bug: either a missing build-dependency, or recursive dependency disease. We've made a lot of progress, but there are still nearly 200 packages with unneeded and damaging dependencies on libfreetype6. FWIW, freetype upstream took pains to restore ABI compatibility with previous versions of libfreetype6. So there is no urgent need for addressing this particular library dependency anymore. The general problem, that packages on the whole use tools that result in greedy linking, is an ongoing one of course. But to ever make any real headway we need to get better practices adopted by upstreams -- both of the individual packages, and of the helper tools they use which encourage this behavior. In the freetype case, for instance, upstream deemed it impossible to change the soname at all because the gratuitous linking problem was too widespread. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Building in chroots hides bugs?
Martijn == Martijn van Oosterhout [EMAIL PROTECTED] writes: Martijn The only example I can think of is programs that use Martijn configure to include support for anything they can find Martijn installed. So you get different results depending on Martijn what's installed in the buildd. It's a bug in the Martijn packaging though, the maintainer should be doing Martijn --enable-* or --disable-* for every option. The point Martijn being that if you only build in a clean chroot you'll Martijn never notice the problem. In my experience these bugs generally occur when a user installs a library that I have never used/heard of before - as such I generally miss them regardless of the build environment. Even if I did happen to have that library accidently installed for the build - I probably wouldn't notice that there is a minor (perhaps obsolete) feature enabled with no corresponding build-depends. -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted spandsp 0.0.2pre26-1 (source i386 all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Aug 2006 06:27:47 +0100 Source: spandsp Binary: libspandsp-dev libspandsp1 libspandsp-doc Architecture: source i386 all Version: 0.0.2pre26-1 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Tzafrir Cohen [EMAIL PROTECTED] Description: libspandsp-dev - Telephony signal processing library libspandsp-doc - Documentation for the spandsp signal processing library libspandsp1 - Telephony signal processing library Closes: 376249 377374 Changes: spandsp (0.0.2pre26-1) unstable; urgency=low . * New upstream release. * Added get-orig-source target. * Removed unneeded and buggy nommx.dpatch (Closes: #376249, #377374) Files: 4d9833c506114760c2394c7322f8cf20 896 libs optional spandsp_0.0.2pre26-1.dsc 2b28a75b1d7c49616534bd7264317241 1417752 libs optional spandsp_0.0.2pre26.orig.tar.gz e4622595c8bae24baadf2f7308d5d252 3363 libs optional spandsp_0.0.2pre26-1.diff.gz 74cbf8523d39415b717849150cabee29 597300 doc optional libspandsp-doc_0.0.2pre26-1_all.deb 7e8bc6530f876553b25fa3c7e4c5c8c1 174676 libs optional libspandsp1_0.0.2pre26-1_i386.deb 3f09dceda5178b1e5b673ec56e92d20e 259762 libdevel optional libspandsp-dev_0.0.2pre26-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzuc9oCzanz0IthIRAh2hAJ95WD2QSLxC3ZHXn6lpF/nHLfeLwACeMIQe XrsDyzMH8fVNpfW0/1+ZQZ0= =Tr8r -END PGP SIGNATURE- Accepted: libspandsp-dev_0.0.2pre26-1_i386.deb to pool/main/s/spandsp/libspandsp-dev_0.0.2pre26-1_i386.deb libspandsp-doc_0.0.2pre26-1_all.deb to pool/main/s/spandsp/libspandsp-doc_0.0.2pre26-1_all.deb libspandsp1_0.0.2pre26-1_i386.deb to pool/main/s/spandsp/libspandsp1_0.0.2pre26-1_i386.deb spandsp_0.0.2pre26-1.diff.gz to pool/main/s/spandsp/spandsp_0.0.2pre26-1.diff.gz spandsp_0.0.2pre26-1.dsc to pool/main/s/spandsp/spandsp_0.0.2pre26-1.dsc spandsp_0.0.2pre26.orig.tar.gz to pool/main/s/spandsp/spandsp_0.0.2pre26.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted ksubtile 1.2-5 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 29 Jul 2006 12:46:34 +0200 Source: ksubtile Binary: ksubtile Architecture: source i386 Version: 1.2-5 Distribution: unstable Urgency: medium Maintainer: Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] Changed-By: Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] Description: ksubtile - subtitle editor for KDE Closes: 379822 Changes: ksubtile (1.2-5) unstable; urgency=medium . * Dropping re-libtoolizing at build time, instead updating libtool with a patch. (Closes: #379822). Files: b138ee909a4f197caf60dbeba847febb 698 kde optional ksubtile_1.2-5.dsc f69064d97b7ff6ed0a7471cf13cefe65 247569 kde optional ksubtile_1.2-5.diff.gz eadc581fda76ba0620b74223927595ff 246204 kde optional ksubtile_1.2-5_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzuZ6ipBneRiAKDwRAqIjAJ96dv6B0tBvIAYYEiiPumpHxwNicwCfUKYo PElG5iR2fItvkYnD4pDGOkM= =jMSF -END PGP SIGNATURE- Accepted: ksubtile_1.2-5.diff.gz to pool/main/k/ksubtile/ksubtile_1.2-5.diff.gz ksubtile_1.2-5.dsc to pool/main/k/ksubtile/ksubtile_1.2-5.dsc ksubtile_1.2-5_i386.deb to pool/main/k/ksubtile/ksubtile_1.2-5_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted kdbg 2.0.4-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 29 Jul 2006 14:19:18 +0200 Source: kdbg Binary: kdbg Architecture: source i386 Version: 2.0.4-2 Distribution: unstable Urgency: medium Maintainer: Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] Changed-By: Ana Beatriz Guerrero Lopez [EMAIL PROTECTED] Description: kdbg - graphical debugger interface Closes: 379811 Changes: kdbg (2.0.4-2) unstable; urgency=medium . * Dropping re-libtoolizing at build time, instead updating libtool with a patch. (Closes: #379811). Files: a440076ae872789c8de0d510527759a5 651 devel optional kdbg_2.0.4-2.dsc 2a9be43e2020c1f0af0e4a69bde2c4b0 48211 devel optional kdbg_2.0.4-2.diff.gz db04ebee8fa7f8181c28fcad6a06d655 291586 devel optional kdbg_2.0.4-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzuepipBneRiAKDwRAuxtAJ4tpQCWfXyPuX+6gRQF0GmOvB/JQACghcu0 J2WvLiXJUIJY0JwUHV8RCWA= =dk5k -END PGP SIGNATURE- Accepted: kdbg_2.0.4-2.diff.gz to pool/main/k/kdbg/kdbg_2.0.4-2.diff.gz kdbg_2.0.4-2.dsc to pool/main/k/kdbg/kdbg_2.0.4-2.dsc kdbg_2.0.4-2_i386.deb to pool/main/k/kdbg/kdbg_2.0.4-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted zaptel 1:1.2.7-2 (source all i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Aug 2006 06:29:39 +0100 Source: zaptel Binary: libtonezone1 zaptel-source zaptel libtonezone-dev Architecture: source all i386 Version: 1:1.2.7-2 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Mark Purcell [EMAIL PROTECTED] Description: libtonezone-dev - tonezone library (development) libtonezone1 - tonezone library (runtime) zaptel - zapata telephony utilities zaptel-source - Zapata telephony interface (source code for kernel driver) Closes: 378864 Changes: zaptel (1:1.2.7-2) unstable; urgency=low . * Copying Makefile as before to the source package, Copying some extra files now needed for building (Closes: #378864) Files: 30f67419b42acd844873922df47306f2 942 comm optional zaptel_1.2.7-2.dsc 2fd312a6ffa4abaa78b5128db12a4a96 140307 comm optional zaptel_1.2.7-2.diff.gz e39bc8d8e64b5075cf9b97a9de7ff09a 923442 devel optional zaptel-source_1.2.7-2_all.deb f70a082ea908e57300719750447a15cd 156676 comm optional zaptel_1.2.7-2_i386.deb 7c2a484aed6d0f4aaf8301fe242486b8 22124 libs optional libtonezone1_1.2.7-2_i386.deb efbb032ef6408a00d685cf5efd2f25ea 23166 libdevel optional libtonezone-dev_1.2.7-2_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzudMoCzanz0IthIRAlIuAJ9zNdkYmkT7faQ/q7MH/dYn1UdSmACcCglR xLJXeSnLk7YdX5iErBUVijA= =Zw7p -END PGP SIGNATURE- Accepted: libtonezone-dev_1.2.7-2_i386.deb to pool/main/z/zaptel/libtonezone-dev_1.2.7-2_i386.deb libtonezone1_1.2.7-2_i386.deb to pool/main/z/zaptel/libtonezone1_1.2.7-2_i386.deb zaptel-source_1.2.7-2_all.deb to pool/main/z/zaptel/zaptel-source_1.2.7-2_all.deb zaptel_1.2.7-2.diff.gz to pool/main/z/zaptel/zaptel_1.2.7-2.diff.gz zaptel_1.2.7-2.dsc to pool/main/z/zaptel/zaptel_1.2.7-2.dsc zaptel_1.2.7-2_i386.deb to pool/main/z/zaptel/zaptel_1.2.7-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted statdataml 1.0.9-3 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Aug 2006 07:30:44 +0200 Source: statdataml Binary: octave-statdataml r-cran-statdataml Architecture: source amd64 Version: 1.0.9-3 Distribution: unstable Urgency: low Maintainer: Debian QA Group [EMAIL PROTECTED] Changed-By: Michael Ablassmeier [EMAIL PROTECTED] Description: octave-statdataml - GNU Octave package for XML-based data exchange r-cran-statdataml - GNU R package for XML-based data exchange Closes: 379479 Changes: statdataml (1.0.9-3) unstable; urgency=low . * QA Upload * Add r-cran-xml to Build-Depends (Closes: #379479) Kudos to Luca Bruno * Add missing binary-indep Target to debian/rules * Conforms with Latest Standards Version 3.7.2 Files: 8b8e0ea35839c637a61aff7f4522930d 738 math optional statdataml_1.0.9-3.dsc 14ba3887a0f4b2fa7f282a9ded3a58dc 5344 math optional statdataml_1.0.9-3.diff.gz 87f4c3db359233e376834f8a78342a7a 150512 math optional r-cran-statdataml_1.0.9-3_amd64.deb 16eafb83e55bad1bce75e1b013b7336a 27956 math optional octave-statdataml_1.0.9-3_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzuwjEFV7g4B8rCURAhJJAKCc4lRyuhMq7Nob5Ogrgsyb9WWwQgCdGRTz clXayeUx2LOOcL+JEOEPP5w= =iDZi -END PGP SIGNATURE- Accepted: octave-statdataml_1.0.9-3_amd64.deb to pool/main/s/statdataml/octave-statdataml_1.0.9-3_amd64.deb r-cran-statdataml_1.0.9-3_amd64.deb to pool/main/s/statdataml/r-cran-statdataml_1.0.9-3_amd64.deb statdataml_1.0.9-3.diff.gz to pool/main/s/statdataml/statdataml_1.0.9-3.diff.gz statdataml_1.0.9-3.dsc to pool/main/s/statdataml/statdataml_1.0.9-3.dsc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted njplot 0.20060606-2 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Aug 2006 08:07:30 +0200 Source: njplot Binary: njplot Architecture: source i386 Version: 0.20060606-2 Distribution: unstable Urgency: low Maintainer: Andreas Tille [EMAIL PROTECTED] Changed-By: Andreas Tille [EMAIL PROTECTED] Description: njplot - [Biology] A tree drawing program Closes: 380633 Changes: njplot (0.20060606-2) unstable; urgency=low . * Added desktop files (thanks to Charles Plessy) Closes: #380633 Files: 9bda460cf6c362c4753283b6847012b7 674 science optional njplot_0.20060606-2.dsc ca3ddb9e4152a3b00fcbcca2ed4ac8fe 7975 science optional njplot_0.20060606-2.diff.gz f0b53e4ed967b2e62b7465b826d43f6c 48610 science optional njplot_0.20060606-2_i386.deb Url: http://pbil.univ-lyon1.fr/software/njplot.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzvBOYDBbMcCf01oRAtd1AJoDqAqB85QIg+btoIz6cUOxoezXnACZAcCG xQQrVAY1t1i74cAAosIvy9c= =zKDq -END PGP SIGNATURE- Accepted: njplot_0.20060606-2.diff.gz to pool/main/n/njplot/njplot_0.20060606-2.diff.gz njplot_0.20060606-2.dsc to pool/main/n/njplot/njplot_0.20060606-2.dsc njplot_0.20060606-2_i386.deb to pool/main/n/njplot/njplot_0.20060606-2_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted usplash 0.3c (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 31 Jul 2006 23:56:26 +0200 Source: usplash Binary: usplash Architecture: source i386 Version: 0.3c Distribution: unstable Urgency: low Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: maximilian attems [EMAIL PROTECTED] Description: usplash- Userspace bootsplash utility Closes: 380618 Changes: usplash (0.3c) unstable; urgency=low . * debian/usplash.postinst: Readd rm_default_artwork for migration from ubuntu. * Add 03-bogl-no-PAGESIZE.patch. (closes: 380618) Files: 81ad7bf2876c8158b229a53323ecdece 630 misc optional usplash_0.3c.dsc a09a5be86c8c7ebb40fbcc345240a0f3 136865 misc optional usplash_0.3c.tar.gz 654ec24c5c015bc1b1b8243f33ea43ec 40818 misc optional usplash_0.3c_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzvI/20zMSyow1ykRAi6uAJ4g9yWgL/Q2GSQ9xfCL4hxXi78CRgCghA6n UjQvhhblEUTGRkZXSpHgriQ= =ISn9 -END PGP SIGNATURE- Accepted: usplash_0.3c.dsc to pool/main/u/usplash/usplash_0.3c.dsc usplash_0.3c.tar.gz to pool/main/u/usplash/usplash_0.3c.tar.gz usplash_0.3c_i386.deb to pool/main/u/usplash/usplash_0.3c_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted pitivi 0.10.1-2 (source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Aug 2006 08:15:16 +0200 Source: pitivi Binary: pitivi Architecture: source all Version: 0.10.1-2 Distribution: unstable Urgency: low Maintainer: Loic Minier [EMAIL PROTECTED] Changed-By: Loic Minier [EMAIL PROTECTED] Description: pitivi - non-linear audio/video editor using GStreamer Changes: pitivi (0.10.1-2) unstable; urgency=low . * Build-depend on gstreamer0.10-gnonlin, thanks Sebastian Dröge. Files: e784d56f751bfe5a715e08f02c0e37fe 851 gnome optional pitivi_0.10.1-2.dsc 263b8ce2f012d89e35756238999a 2804 gnome optional pitivi_0.10.1-2.diff.gz ee92c951a89dd2eb43d7b85b5f8649b1 106306 gnome optional pitivi_0.10.1-2_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzvKh4VUX8isJIMARAi6rAKCCoC6uD56fXw5yP4ZgX/cMA2encwCdEaYi JqbDT97F3cWXLmujYjbkLVY= =5Xrw -END PGP SIGNATURE- Accepted: pitivi_0.10.1-2.diff.gz to pool/main/p/pitivi/pitivi_0.10.1-2.diff.gz pitivi_0.10.1-2.dsc to pool/main/p/pitivi/pitivi_0.10.1-2.dsc pitivi_0.10.1-2_all.deb to pool/main/p/pitivi/pitivi_0.10.1-2_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted rsrce 0.2.2 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 26 Jul 2006 03:54:33 +0200 Source: rsrce Binary: rsrce Architecture: source amd64 Version: 0.2.2 Distribution: unstable Urgency: low Maintainer: Debootloaders miBoot Maintainers Team [EMAIL PROTECTED] Changed-By: Jeremie Koenig [EMAIL PROTECTED] Description: rsrce - editor for Macintosh resource forks Closes: 379878 Changes: rsrce (0.2.2) unstable; urgency=low . * Improve the manual page. * Add some command line options to allow for '#!/usr/bin/rsrce -ef' scripts. * A bug prevented file to be read on big-endian architectures; fix provided by Piotr Krysiuk. (closes: #379878) Files: 4f204bb408f96a32a1bd30e067744fa4 685 otherosfs optional rsrce_0.2.2.dsc 1231b2af766541c1d3a5ec54d7317783 19695 otherosfs optional rsrce_0.2.2.tar.gz 568db963b809dbddf487ca63511d26d1 16470 otherosfs optional rsrce_0.2.2_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzvoIzWFP1/XWUWkRAiSKAKCAdI/JPRkcSxq3D3wf8UIRMS8HVQCfQGpj fQt0jV93T8UBcr/WlT1TB7Y= =xG4V -END PGP SIGNATURE- Accepted: rsrce_0.2.2.dsc to pool/main/r/rsrce/rsrce_0.2.2.dsc rsrce_0.2.2.tar.gz to pool/main/r/rsrce/rsrce_0.2.2.tar.gz rsrce_0.2.2_amd64.deb to pool/main/r/rsrce/rsrce_0.2.2_amd64.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted libapache-mod-musicindex 1.1.1-1 (ia64 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 31 Jul 2006 23:30:17 -0700 Source: libapache-mod-musicindex Binary: libapache-mod-musicindex libapache2-mod-musicindex mod-musicindex-common Architecture: source ia64 all Version: 1.1.1-1 Distribution: unstable Urgency: low Maintainer: Thibaut VARENE [EMAIL PROTECTED] Changed-By: Thibaut VARENE [EMAIL PROTECTED] Description: libapache-mod-musicindex - Browse, stream, download and search through MP3/Ogg/FLAC files libapache2-mod-musicindex - Browse, stream, download and search through MP3/Ogg/FLAC files mod-musicindex-common - Common files for mod-musicindex Closes: 379567 Changes: libapache-mod-musicindex (1.1.1-1) unstable; urgency=low . * Fix data passing from client to server (Closes: #379567) Files: ff3b8a9416c1320fe006bf099316e53d 790 web optional libapache-mod-musicindex_1.1.1-1.dsc fb632edb74821cbbabfa26bf0552586a 460096 web optional libapache-mod-musicindex_1.1.1.orig.tar.gz 768cc7f8744db840d32d76656e7e16c1 7342 web optional libapache-mod-musicindex_1.1.1-1.diff.gz 629d43c8aefdd9df551fc8028b0233d5 42512 web optional libapache-mod-musicindex_1.1.1-1_ia64.deb 43a0a330c85c0ed5f621628fdf9fc3c3 41042 web optional libapache2-mod-musicindex_1.1.1-1_ia64.deb 8d423ae0276e9b22b3d527d2be438f40 28322 web optional mod-musicindex-common_1.1.1-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFEzv4uHjLD2rfS8GMRAqzaAJ9ebs9655i5EkkFUQ8bsvixUeyKcACglBzj Hr/GVznuQRq0VivK/7svfxA= =2ic9 -END PGP SIGNATURE- Accepted: libapache-mod-musicindex_1.1.1-1.diff.gz to pool/main/liba/libapache-mod-musicindex/libapache-mod-musicindex_1.1.1-1.diff.gz libapache-mod-musicindex_1.1.1-1.dsc to pool/main/liba/libapache-mod-musicindex/libapache-mod-musicindex_1.1.1-1.dsc libapache-mod-musicindex_1.1.1-1_ia64.deb to pool/main/liba/libapache-mod-musicindex/libapache-mod-musicindex_1.1.1-1_ia64.deb libapache-mod-musicindex_1.1.1.orig.tar.gz to pool/main/liba/libapache-mod-musicindex/libapache-mod-musicindex_1.1.1.orig.tar.gz libapache2-mod-musicindex_1.1.1-1_ia64.deb to pool/main/liba/libapache-mod-musicindex/libapache2-mod-musicindex_1.1.1-1_ia64.deb mod-musicindex-common_1.1.1-1_all.deb to pool/main/liba/libapache-mod-musicindex/mod-musicindex-common_1.1.1-1_all.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted iaxmodem 0.1.14.dfsg-1 (source amd64)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 1 Aug 2006 09:07:22 +0200 Source: iaxmodem Binary: iaxmodem Architecture: source amd64 Version: 0.1.14.dfsg-1 Distribution: unstable Urgency: low Maintainer: Debian VoIP Team [EMAIL PROTECTED] Changed-By: Julien BLACHE [EMAIL PROTECTED] Description: iaxmodem - software modem with IAX2 connectivity Changes: iaxmodem (0.1.14.dfsg-1) unstable; urgency=low . * New upstream release. Files: 1fd7f5a849c7009b72ec75e6b35c05b2 776 comm optional iaxmodem_0.1.14.dfsg-1.dsc 4b059cf3fb443713723b500f9360a364 2005386 comm optional iaxmodem_0.1.14.dfsg.orig.tar.gz dc25f5062950d2e524203dc2a82c5cf0 5776 comm optional iaxmodem_0.1.14.dfsg-1.diff.gz 47d25c752d9edceed81236ed94a29a3b 183338 comm optional iaxmodem_0.1.14.dfsg-1_amd64.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzv7bzWFP1/XWUWkRAuCVAJ98/cyFghXSanmqPRT7Bp5TZuDJ1gCgqfLK 6+wjq5tFVlQFl+LERp4KHe0= =G5Q1 -END PGP SIGNATURE- Accepted: iaxmodem_0.1.14.dfsg-1.diff.gz to pool/main/i/iaxmodem/iaxmodem_0.1.14.dfsg-1.diff.gz iaxmodem_0.1.14.dfsg-1.dsc to pool/main/i/iaxmodem/iaxmodem_0.1.14.dfsg-1.dsc iaxmodem_0.1.14.dfsg-1_amd64.deb to pool/main/i/iaxmodem/iaxmodem_0.1.14.dfsg-1_amd64.deb iaxmodem_0.1.14.dfsg.orig.tar.gz to pool/main/i/iaxmodem/iaxmodem_0.1.14.dfsg.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted gst-plugins-bad0.10 0.10.3-3 (source i386)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 31 Jul 2006 16:38:12 -0500 Source: gst-plugins-bad0.10 Binary: gstreamer0.10-plugins-bad Architecture: source i386 Version: 0.10.3-3 Distribution: unstable Urgency: low Maintainer: Joe Wreschnig [EMAIL PROTECTED] Changed-By: Joe Wreschnig [EMAIL PROTECTED] Description: gstreamer0.10-plugins-bad - various GStreamer plugins Closes: 379867 Changes: gst-plugins-bad0.10 (0.10.3-3) unstable; urgency=low . * debian/rules: * Enable v4l2src. (Closes: #379867) * Force disabling of MusicBrainz. * Allow FAAD=enable environment variable to override build options. * README.Debian: Explain how to get FAAD support. Files: d5dcb25084908ed9f87ad28d5b8bed9b 795 libs extra gst-plugins-bad0.10_0.10.3-3.dsc 7edba5070a4e4653de0f8858fcd66451 7359 libs extra gst-plugins-bad0.10_0.10.3-3.diff.gz e7794a51c7a7145db4917fea127e357d 538004 libs extra gstreamer0.10-plugins-bad_0.10.3-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEzv5gTFkUq7Drx3cRAunMAJ4uYw9+m5z8B+qmyZfNKHDFV3/o3QCgnA5K mnw3/rNNNgkR2/oiPdlhw5A= =abV9 -END PGP SIGNATURE- Accepted: gst-plugins-bad0.10_0.10.3-3.diff.gz to pool/main/g/gst-plugins-bad0.10/gst-plugins-bad0.10_0.10.3-3.diff.gz gst-plugins-bad0.10_0.10.3-3.dsc to pool/main/g/gst-plugins-bad0.10/gst-plugins-bad0.10_0.10.3-3.dsc gstreamer0.10-plugins-bad_0.10.3-3_i386.deb to pool/main/g/gst-plugins-bad0.10/gstreamer0.10-plugins-bad_0.10.3-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
