Re: E helper-templates-in-copyright
Hi, Le samedi 24 sept. 2011 à 13:51:51 (+0200 CEST), Ole Streicher a écrit : Dear list, when I tried uploading my package, the server's lintian gave me an error that I did not have on my local system http://mentors.debian.net/package/wcslib: E: libwcs4: helper-templates-in-copyright The help text suggests that the copyright file is still (almost) a template. However, I think that I changed it according to the package's needs: 8 This work was packaged for Debian by: Ole Streicher deb...@liska.ath.cx on Wed, 14 Sep 2011 16:31:30 +0200 It was downloaded from http://www.atnf.csiro.au/people/mcalabre/WCS/ Upstream Author(s): ^ If there's only one author, why keep this? Maybe it is not the only thing to be changed to fix this lintian error, but that should already help. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110924115652.ga14...@kirya.net
Re: Please try expo.debian.net -- a replacement for mentors.debian.net
Hi Asheesh, Le mardi 26 juil. 2011 à 19:55:00 (+0200 CEST), Asheesh Laroia a écrit : Hi all people on debian-mentors, Debexpo is a replacement for http://mentors.debian.net/. I hereby request testers! It is of beta quality -- I think it works fully and has enough features to replace mentors.debian.net. Thanks for working on this. Looks very promising! On the package details page, it would be great if URL's could be clickable (Homepage, VCS-Browser). Also Lintian tags could be linked to their description on lintian.d.o I also think it is not necessary to show missing optional fields (eg. various VCS-* fields). It may also help to know whether the package is already in Debian (with a link to packages.d.o in order to know more about the history of the uploads) or if it is a new package. As from the maintainer personal package archive page, I understand that binary packages will be made publicly available? The page states 'deb ...' entries in sources.list. If so, I think it is a bad idea. Only source packages should be available to avoid people use this as a standard repository (I remember it used to be the case for mentors.d.n). Keep up the good work. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110726183736.gg7...@kirya.net
Re: New upstream version: nautilus-image-manipulator 0.3
Hi Emilien, Le jeudi 19 mai 2011 à 08:05:31 (+0200 CEST), Emilien Klein a écrit : Hi Mentors, I have released a new version of nautilus-image-manipulator. I have also packaged it for Debian and uploaded to the mentors server. No particular change, apart from the debian/changelog file, was made to the debian packaging files. I'll have a look at this updated package ASAP. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110519081125.ga11...@kirya.net
[Uploaded] Re: New upstream version: nautilus-image-manipulator 0.3
Le jeudi 19 mai 2011 à 10:11:25 (+0200 CEST), Julien Valroff a écrit : Hi Emilien, Le jeudi 19 mai 2011 à 08:05:31 (+0200 CEST), Emilien Klein a écrit : Hi Mentors, I have released a new version of nautilus-image-manipulator. I have also packaged it for Debian and uploaded to the mentors server. No particular change, apart from the debian/changelog file, was made to the debian packaging files. I'll have a look at this updated package ASAP. Uploaded. Do not hesitate to contact me directly next time. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110519170114.ge25...@kirya.net
Re: RFS: gtk2-engines-equinox
Le mercredi 04 mai 2011 à 08:36:18 (+0200 CEST), Maia Kozheva a écrit : I suppose I could. What about Hadret's original ITP, though? Perhaps I should contact him first? I wonder whether this ITP shouldn't have actually been an RFP, but yes, you should contact him first (CC'ing the bug report). Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110504183230.gf10...@kirya.net
Re: RFS: nautilus-image-manipulator
Hi Emilien, Le dimanche 01 mai 2011 à 15:12:48 (+0200 CEST), Emilien Klein a écrit : As for the packaging itself, I would still clean rules file by removing unneeded `find…' call and the override_dh_auto_build I removed override_dh_auto_build. However, I believe the 'find…' is needed because it removes the empty /usr/share/omf/nautilus-image-manipulator directory that gets created by python-distutils-extra. I thus left it. I don't get this empty directory when removing the complete dh_install override... Looking at the bug you reported against python-distutils-extra [0], I have checked the code and noticed the behaviour was actually fixed in revision 241 [1]. [...] Also, it might be good to add a note somewhere stating that nautilus should be restarted after the package was installed (and explain what the user should do) - this is from my experience with nautilus-open-terminal. Indeed, Nautilus needs to be restarted (which by the way is not handy when developing). Where should I add such a note? I see none such note in the description of nautilus-open-terminal. README.Debian seems the best place, though not all users look at this before reporting a bug ;) As for the application itself: what features does it bring compared to nautilus-image-converter? Sending by email can already be done by nautilus-sendextension. Actually sending the resized images by email is a feature that's not yet implemented. The only option to send for now is to send it to a remote file hosting site, which is not supported by nautilus-image-converter. Other features is zipping the resized images, and putting in subfolders. These are the features I concentrated on to get the first release out. More will follow. Thanks, I now understand your motivation and objectives. [...] I have also noticed a behaviour which should be changed: when resizing a small image to a greater size, it gets actually resized (ie. a 500x500 picture is resized to eg. 768x768). I would expect the pictures to be resized to smaller size only if the aim is to reduce their weight so that they can easily be sent eg. by email. Actually that's a feature, not a bug. I explicitly allow to resize up to 200% (if you use the scaling option) to accommodate some users wanting to increase the height and width of the images. If someone expresses that need, I'm OK with allowing them to do it even if it degrades the quality of the images... As a user, I would appreciate a warning when resizing means degrading the quality of a picture. [...] Please review the updated package. Please check this empty directory issue and try and write a small note about restarting nautilus, I'll then upload the package for you. Cheers, Julien [0] https://bugs.launchpad.net/python-distutils-extra/+bug/714891 [1] http://bazaar.launchpad.net/~python-distutils-extra-hackers/python-distutils-extra/debian/revision/241 -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501153657.gd19...@kirya.net
Re: RFS: nautilus-image-manipulator
Le dimanche 01 mai 2011 à 19:55:21 (+0200 CEST), Emilien Klein a écrit : Both done. New version uploaded, please check. Uploaded - you should now have received a confirmation the package should go through the NEW queue. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501193228.ga26...@kirya.net
Re: RFS: nautilus-image-manipulator
Hi Emilien, Le samedi 30 avril 2011 à 22:56:12 (+0200 CEST), Emilien Klein a écrit : Julien, Paul, Niels, Stefano, and the other mentors, Could one of you please review the latest changes in my package? I reviewed your package yesterday and was testing it. As for the packaging itself, I would still clean rules file by removing unneeded `find…' call and the override_dh_auto_build I would change the section of the package to gnome from graphics. Also, it might be good to add a note somewhere stating that nautilus should be restarted after the package was installed (and explain what the user should do) - this is from my experience with nautilus-open-terminal. The rest seems OK. As for the application itself: what features does it bring compared to nautilus-image-converter? Sending by email can already be done by nautilus-sendextension. Have you tried and talk with nautilus-image-converter upstream developer? It might be a good idea to improve existing code rather than starting a new project. I have also noticed a behaviour which should be changed: when resizing a small image to a greater size, it gets actually resized (ie. a 500x500 picture is resized to eg. 768x768). I would expect the pictures to be resized to smaller size only if the aim is to reduce their weight so that they can easily be sent eg. by email. You should add a warning when the 'resize in place' option is used: this option used without caution can cause data loss. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110501053841.ga2...@kirya.net
Re: RFS: nautilus-image-manipulator
Le jeudi 14 avril 2011 à 22:27:29 (+0200 CEST), Emilien Klein a écrit : Paul Gevers, Julien Valroff, [...] Regarding the automatic patches created, i was able to trace its creation: `python setup.py install` automatically rebuilds the i18n files. In doing so, it updates the .pot translation template IN the source files. This is OK the first time you create the package, no patch is added to the debian package. However, if you create the package a second time, since the .pot file has been modified with respect to the source tarball, the builder tools will create a patch, thinking that the change was made on purpose/manually. In order to address this, I added a command to override_dh_clean that extracts the .pot file from the .orig.tar.gz tarball and replaces the eventually modified .pot file in the source directory. That way, when cleaning the build environment, the .pot file is the same as what was shipped in the source tarball. This is the wrong approach: you cannot rely on the orig tarball being in ../ - also what would happen in case you have various orig tarballs there? eg. I use pbuilder, hence my tarballs are in ~/debian/tarballs… Why not simply try and avoid i18n files to be updated or, even easier, make a copy of the original .pot file and restore it in clean? Also, your package still doesn't use dh_python2 (while not a *must*, I think it is the better thing to do). Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110416070537.ga13...@kirya.net
Re: RFS: nautilus-image-manipulator
Le jeudi 14 avril 2011 à 22:27:29 (+0200 CEST), Emilien Klein a écrit : Paul Gevers, Julien Valroff, [...] Can you please check my updated package [1]? Thanks! I'll have a look during the week-end. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110415041033.gc7...@kirya.net
Re: RFS: nautilus-image-manipulator
Hi Emilien, Le samedi 09 avril 2011 à 00:05:35 (+0200 CEST), Emilien Klein a écrit : Hi Julien, Thanks for your answer, which I just read (I am not subscribed to the mentors mailing list) Then please, state it in your messages so that I (we) can CC you. I will update the package according to your comments. Question: do I need to continue replying to the list also, or should we continue this discussion off-list? Please keep this discussion on debian-mentors. Others may also have interesting comments. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110409051009.ga28...@kirya.net
Re: RFS: nautilus-image-manipulator
Hi Emilien, Le dimanche 20 mars 2011 à 11:04:02 (+0100 CET), Emilien Klein a écrit : Hi mentors, I'd appreciate if somebody could have a look at this package. Thanks! +Emilien 2011/2/9 Emilien Klein emilien+deb...@klein.st: Dear mentors, I am looking for a sponsor for my package nautilus-image-manipulator. * Package name : nautilus-image-manipulator Version : 0.2-1 Upstream Author : Emilien Klein (me...) * URL : https://launchpad.net/nautilus-image-manipulator * License : GPL 3 Section : graphics It builds these binary packages: nautilus-image-manipulator - Resize and send images from Nautilus I have had a look at your package, here are my first comments: * You have an unwanted patch in debian/patches which was automatically added by the 3.0 (quilt) source format * You should check your package against the latest Debian Policy (3.9.1) and update debian/control accordingly * You should use a private directory for your python module, eg. /usr/share/nautilus-image-manipulator/ - please have a look at this excellent tutorial [0]. You should also use dh_python2 I haven't checked more for now, but I'd be happy to go into details once you have fixed these first points. Cheers, Julien [0] http://wiki.debian.org/Python/Packaging -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110326070309.gb2...@kirya.net
Re: Git Package Versioning
Hi, Le dimanche 20 mars 2011 à 21:18:43 (+0100 CET), Chris a écrit : Can anyone point me in the direction of a appropriate package versioning scheme when packaging software taken directly from a git vcs? The best I have found is to use something like: latest_upstream_release+gitMMDD.githash You need the date as the git hash are not sorted, and the date alone doesn't make sense in case you need to package 2 snapshots at the same date. I use the abbreviated hash and get the last commit as follows: git log -1 --format='%cd.%h' --date=short | sed 's/-//g' Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110320204826.ga22...@kirya.net
Re: Git Package Versioning
Hi, Le dimanche 20 mars 2011 à 23:16:47 (+0100 CET), Stephen Kitt a écrit : On Sun, 20 Mar 2011 22:25:38 +0100, Joachim Wiedorn ad_deb...@joonet.de wrote: In this example, the Debian package version could be either 1.2.0+gitMMDD.githash-1, which could be read as everything in the 1.2.0 release plus all changes since, up to git hash ... on MMDD, It is indeed what I meant. or 1.2.1~gitMMDD.githash-1, which could be read as the 1.2.1 release currently being prepared, as of git hash ... on MMDD. Though it is perfectly correct, I try and avoid using this scheme: what happens if upstream releases eg. 1.2.1 Beta1 which I would normally version as 1.2.1~b1? Even if contact with upstream are good, the may change their mind. Take Firefox 4 which should have been released after the 1st RC… before they decide to release a 2nd RC. I think there's no universal answer to the original question, but just common sense and good use of `dpkg --compare-versions'. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110321053618.ga12...@kirya.net
Re: RFS: gnome-icon-theme-faenza
Hi, Le vendredi 18 mars 2011 à 22:54:48 (+0100 CET), Adnan Hodzic a écrit : On Fri, Mar 18, 2011 at 8:47 PM, Adam Borowski kilob...@angband.pl wrote: The icon for the icon theme itself is missing or invalid -- I get the Gnome logo instead of a directory icon. Fixed(?) Still the same issue (this is in gnome-appearance-properties, in the icons tab). Please take a look at the re-uploaded package, I double checked all the errors with different users machines and it seems to be working fine. I also made it 100% lintian clean this time. The debian/dirs file is useless and I'd remove comments in debian/rules. Your copyright file is yet to be improved to fulfill DEP5 requirements. Also, you state the icons are licensed under the GPL-3+ but the short name is GPL and I cannot find where you have found they could be distributed under a later version og the GPL. If you had this from upstream in an email, quote it in the copyright file. I also wonder whether it wouldn't be better to split the various themes in 3 different packages given the size of the unique package (13M). What do you think? Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110319073007.ga3...@kirya.net
Re: RFS: gnome-icon-theme-faenza
Le samedi 19 mars 2011 à 11:42:46 (+0100 CET), Adam Borowski a écrit : On Sat, Mar 19, 2011 at 08:30:08AM +0100, Julien Valroff wrote: I also wonder whether it wouldn't be better to split the various themes in 3 different packages given the size of the unique package (13M). For most other packages, it would be a good idea. For eye-candy for Gnome, we're talking about a 13M addition to multi-gigabyte system (minimal Gnome can be less, but if you have to trim, you'd install a lighter environment). I use GNOME but still try and not waste my disk space for things I do not use. The average icon theme for GNOME has an uncompressed size of +/- 10M while these faenza themes are more than 60M. % aptitude show ~n gnome-icon-theme | grep -e ^Package -e ^Uncompressed Size Package: gnome-icon-theme-suede Uncompressed Size: 2089 k Package: gnome-icon-theme-blankon Uncompressed Size: 3498 k Package: gnome-icon-theme-extras Uncompressed Size: 1053 k Package: gnome-icon-theme-gartoon Uncompressed Size: 9298 k Package: gnome-icon-theme-symbolic Uncompressed Size: 561 k Package: gnome-icon-theme-nuovo Uncompressed Size: 10.4 M Package: gnome-icon-theme-yasis Uncompressed Size: 10.9 M Package: gnome-icon-theme-dlg-neu Uncompressed Size: 16.7 M Package: gnome-icon-theme Uncompressed Size: 14.2 M Package: gnome-icon-theme-faenza Uncompressed Size: 63.6 M Thus, I'd say splitting would just cause confusion for users who would have to make a decision what to happen at apt level. A choice at the preferences dialog level gets a hint (the directory icon) and is instantly visible, at apt you have just a name. A meta package could help these users, eg. gnome-icon-themes-faenza while each theme has its own package (gnome-icon-theme-faenza, gnome-icon-theme-faenza-dark etc.) Of course, each package (short long) description should make it clear to users what is contained in each package. That is however just a proposal, I do understand your point of view as well. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110319114127.ga21...@kirya.net
Re: RFS: gnome-icon-theme-faenza
Le samedi 19 mars 2011 à 19:59:52 (+0100 CET), Adnan Hodzic a écrit : On Sat, Mar 19, 2011 at 8:30 AM, Julien Valroff jul...@debian.org wrote: Hi, Le vendredi 18 mars 2011 à 22:54:48 (+0100 CET), Adnan Hodzic a écrit : On Fri, Mar 18, 2011 at 8:47 PM, Adam Borowski kilob...@angband.pl wrote: The icon for the icon theme itself is missing or invalid -- I get the Gnome logo instead of a directory icon. Fixed(?) Still the same issue (this is in gnome-appearance-properties, in the icons tab). Ah, now I see what's the issue is. Ok, in package I just re-uploaded I added preinst and postinst which solves this problem. In preinst I forced removal of previous installation, which in my case worked and gave me the look of new icons. It was easier for me this way, instead of my previous try with dpkg-divert You don't have to take care of previous installations as this package is not (yet) part of Debian. You have also done it the wrong way as the code added to preinst will be run unconditionally, be it a first install or a package upgrade. But most importantly, *never* modify a user home directory. In that case, you remove files in /root or any arbitrary user home in case a user uses sudo and preserves $HOME: % sudo echo $HOME /home/julien postinst takes cares of the GNOME logo problem. Why not simply use dh_link? Your copyright file is yet to be improved to fulfill DEP5 requirements. Also, you state the icons are licensed under the GPL-3+ but the short name is GPL and I cannot find where you have found they could be distributed under a later version og the GPL. If you had this from upstream in an email, quote it in the copyright file. Ok, I moved all back to GPL. Even if this represents a problem I could get upstram to quote it under GPL3 as he seems as a very good cooperator and is eager to see Faenza in Debian. There is a misunderstanding. What I meant is that the COPYING file shipped in the tarball states that the theme is distributed under the GPL-3 but your original copyright file stated GPL version 3 *or any later version*, while, at the same time, the license shortname was GPL (should have been GPL-3+ to match the following license paragraph). More over, your copyright still doesn't fully respect the DEP5 spec: % config-edit -application dpkg-copyright -ui none File of type has a syntax error in configuration file: DpkgSyntax error: Invalid line 42 (missing ':' ?) : Faenza Icon Theme is licensed under the GPL. I also wonder whether it wouldn't be better to split the various themes in 3 different packages given the size of the unique package (13M). What do you think? I agree with what Adam said on this one: OK, that was just a proposal, I'm fine with a single package. BTW, I hadn't paid attention that some icons are shared between the 3 themes using symlinks (11,804 symlinks for 5,212 filesi, 4,443 of them being in Faenza, ie. both other themes overhead is inferior to 800 files…). You should also fix the following lintian warnings: I: gnome-icon-theme-faenza source: debian-watch-file-is-missing W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza/emblems/24/emblem-important.icon W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza-Dark/index.theme W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza-Darkest/index.theme W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza/emblems/22/emblem-important.icon W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza/emblems/48/emblem-important.icon W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza/emblems/scalable/emblem-important.icon W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza/emblems/16/emblem-important.icon W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza/emblems/32/emblem-important.icon W: gnome-icon-theme-faenza: executable-not-elf-or-script ./usr/share/icons/Faenza/index.theme Shouldn't the package depend on librsvg2-common for .svg files? Why do you buil-depend on debhelper = 7.0.50~? You don't use any dh_overrides hence = 7 should be enough. Your VCS-* fields seem to be wrong - please fix them or create the git repository in collab-maint before the package gets uploaded. Cheers, Julien -- .''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `'` http://www.kirya.net/ `- 4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110319212938.ga2...@kirya.net
Re: RFS: faenza-icon-theme
Hi Adnan, Le lundi 24 janv. 2011 à 04:09:00 (+0100), Adnan Hodzic a écrit : Dear mentors, I am looking for a sponsor for my package faenza-icon-theme. * Package name: faenza-icon-theme Version : 0.8-1 Upstream Author : Matthieu James matthieu.ja...@gmail.com * URL : http://tiheum.deviantart.com/art/Faenza-Icons-173323228 * License : GPL3 Section : gnome It builds these binary packages: faenza-icon-theme - Faenza Icon Theme As I use this icon theme, I had a quick look at your package, here are my comments. Why have you chosen to repack the upstream tarball? Your package doesn't contain the upstream changelog, nor the README which lists some known problems and might be useful for the end user. You might also want to ship the emesene theme as a separate package. Your package doesn't set the distributor-logo nor the start-here icon, which might be nice to have. In the description, Gnome should be written in uppercase: it is an acronym for GNU Object Model Environment. btw is this theme specific to GNOME or can it be used with other desktop environments? If so, you might want to check with the GNOME team whether your package should be renamed to follow a naming scheme (looking at what is already in the archive, it could be gnome-*-icon-theme or gnome-icon-theme-*). wrt copyright information: you state the icons are shipped under the GPL version 3 or later. As far as I could check, it is shipped under the GPL version 3 only. Also, your copyright file doesn't fully respect the DEP-5 format, check the output of the DEP-5 validator/parser [0]. Hope this helps. Cheers, Julien [0] http://ddumont.wordpress.com/2011/01/13/debian-copyright-dep5-parsereditorvalidatormigrator-is-released/ -- ,''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `' http://www.kirya.net/ `-4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124193117.ga26...@kirya.net
Re: Re: RFS: faenza-icon-theme
Le mardi 25 janv. 2011 à 00:08:16 (+0100), Adnan Hodzic a écrit : On 24.01.2011 20:31, Julien Valroff wrote: As I use this icon theme, I had a quick look at your package, here are my comments. Why have you chosen to repack the upstream tarball? I didn't see a reason why not to :-/ It's usually better to avoid repacking upstream tarball… It also saves you work when updating the package. You might also want to talk to upstream so that they change their tarball if you can think of something better. [...] Your package doesn't set the distributor-logo nor the start-here icon, which might be nice to have. I hardcoded start-here icon to Debian icon, both theme displays Debian start-here icons. I would prefer you do that either when building the package (in debian/rules) or after installing it (debian/postinst). Another alternative would be to patch the upstream installation script, and submit the patch to upstream. That might actually be the best thing to do provided you manage to write a script which can work for both installation methods (ie. by hand or through a package build). Cheers, Julien -- ,''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `' http://www.kirya.net/ `-4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110125060002.gb26...@kirya.net
Re: Debhelper: LDFLAGS
Hi, Le dimanche 19 déc. 2010 à 21:09:34 (+0100), Daniel Stender a écrit : If we are still talking about the gummi package, I just put export LDFLAGS=-Wl,--as-needed at top of debian/rules and the dpkg-shlibdeps warnings went away. Just like that? For some reason isn't working here ... Dos your package use libtool? If so, read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650 Cheers, Julien -- ,''`. Julien Valroff ~ jul...@kirya.net ~ jul...@debian.org : :' : Debian Developer Free software contributor `. `' http://www.kirya.net/ `-4096R/ E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101220054447.gb13...@kirya.net
Re: RFS: clipit
Le vendredi 12 nov. 2010 à 13:48:01 (+0100), Raphael Hertzog a écrit : Hi, On Fri, 12 Nov 2010, Cristian Henzel wrote: P.S. I find it odd that it includes the package even if there's no referece to it and I also use -Wl,--as-needed... Maybe -Wl,--as-needed is not smart enough to cover this case. Entirely dropping the -lpthread is the only way to fix this apparently. I haven't checked the package at all, but if it uses libtool, it might also be related to #347650 [0] which prevents -Wl,--as-needed to work as expected. Cheers, Julien [0] http://bugs.debian.org/347650 -- Julien Valroff jul...@kirya.net http://www.kirya.net GPG key: 4096R/258E26B1 E1D8 5796 8214 4687 E416 948C 859F EF67 258E 26B1 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101112125138.gc24...@kirya.net
Support for non UTF8 encodings
Hi, A user recently reported a bug[0] regarding localized messages from rkhunter not being correctly displayed with other encodings than UTF-8. This is simply caused by the translations being encoded in UTF-8. UTF-8 being the default encoding for new installations, I am not sure whether other encodings should absolutely be supported. Am I right? What do you think of it? Cheers, Julien [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571333 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1267194920.2491.19.ca...@gaia
Re: Support for non UTF8 encodings
Le vendredi 26 février 2010 à 17:45 +, Roger Leigh a écrit :
On Fri, Feb 26, 2010 at 04:14:27PM +, Roger Leigh wrote:
On Fri, Feb 26, 2010 at 03:35:20PM +0100, Julien Valroff wrote:
A user recently reported a bug[0] regarding localized messages from
rkhunter not being correctly displayed with other encodings than UTF-8.
This is simply caused by the translations being encoded in UTF-8.
UTF-8 being the default encoding for new installations, I am not sure
whether other encodings should absolutely be supported. Am I right?
What do you think of it?
[...]
That said, this doesn't look like this is what is happening in this
case. In this case, the localised messages are not being recoded
from UTF-8 to the locale charmap at runtime, and this is the cause
of the corrupted output. This is a bug. Localisation systems
such as gettext (what pretty much everything uses) will automatically
recode from the .po/.mo translation encoding to the locale encoding
('locale -k charmap'). If this isn't happening, rkhunter's
localisation is broken.
I can't see any evidence of a de translation in the source. I
can only see the Debian debconf translations in debian/po, and
some other type of translation in files/i18n (but no .de). That
directory does have two zh files (one for UTF-8, one other, maybe
BIG-5?). Looking at how rkhunter is doing its localisation
internally, it's just mapping to keys in this file, and there's
no recoding, which *is* buggy.
Personally, I'd just recommend that rkhunter should switch to
using GNU gettext, which can be called from shell scripts using
gettext(1), and will automatically do the necessary recoding.
I will suggest this to upstream development team, thanks for your
suggestion ;)
Cheers,
Julien
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1267207028.16283.0.ca...@athyr.kirya.net
Re: One time post-invoke hook
Le vendredi 06 novembre 2009 à 08:39 +0100, Julien Valroff a écrit : Hi Charles, Thanks for your answer. Le vendredi 06 novembre 2009 à 15:37 +0900, Charles Plessy a écrit : Le mercredi 04 novembre 2009 à 19:08 +0100, Julien Valroff a écrit : Hi, rkhunter recommends some packages, eg. unhide, which are configured after rkhunter, and hence after rkhunter postinst script is run. Hello Julien, if you can cooperate with the maintainers of packages like unhide, maybe you can arrange a dpkg trigger? (man 5 deb-triggers) You are right, I think that is the best method which could also be used by other packages so that the rkhunter database is only updated when packages are upgraded/installed. I already had a look to the triggers, but I am not sure to understand everything. In the rkhunter unhide example, rkhunter needs to declare a trigger. But where and how? unhide needs to declare its interest in this trigger in debian/triggers (interest trigger-name) Well, I think I have done the right thing: add a debian/triggers to both rkhunter and unhide containing: interest rkhunter-update-database In rkhunter postinst, I have added a triggered action which runs rkhunter --propupd However, if I install rkhunter (unhide being installed automatically by aptitude), nothing happens. If I reinstall unhide, the trigger is activated. It seems the trigger is not yet installed though rkhunter is configured before unhide. Cheers, Julien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: One time post-invoke hook
Hi, Le mercredi 04 novembre 2009 à 19:08 +0100, Julien Valroff a écrit : Hi, I am trying to address bug #544573 [1] against rkhunter which I maintain. rkhunter postinst script is used to call rkhunter --propupd which updates/creates its file properties database. rkhunter recommends some packages, eg. unhide, which are configured after rkhunter, and hence after rkhunter postinst script is run. Is there any way to add a temporary post-invoke hook so that the database is updated/created after all packages are configured? I have thought that adding a configuration file in /etc/apt/apt.conf.d in postinst would work, but as apt is already running, it won't consider that file until the next time it is run. Another mean would be to force packages like unhide to be configured before rkhunter (a kind of 'pre-recommends' dependency). Any hint for this? Cheers, Julien [1] http://bugs.debian.org/544573 As I had no answer, I take the leave to re-send this message. Cheers, Julien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: One time post-invoke hook
Hi Charles, Thanks for your answer. Le vendredi 06 novembre 2009 à 15:37 +0900, Charles Plessy a écrit : Le mercredi 04 novembre 2009 à 19:08 +0100, Julien Valroff a écrit : Hi, rkhunter recommends some packages, eg. unhide, which are configured after rkhunter, and hence after rkhunter postinst script is run. Hello Julien, if you can cooperate with the maintainers of packages like unhide, maybe you can arrange a dpkg trigger? (man 5 deb-triggers) You are right, I think that is the best method which could also be used by other packages so that the rkhunter database is only updated when packages are upgraded/installed. I already had a look to the triggers, but I am not sure to understand everything. In the rkhunter unhide example, rkhunter needs to declare a trigger. But where and how? unhide needs to declare its interest in this trigger in debian/triggers (interest trigger-name) Have a nice day as well Cheers, Julien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
One time post-invoke hook
Hi, I am trying to address bug #544573 [1] against rkhunter which I maintain. rkhunter postinst script is used to call rkhunter --propupd which updates/creates its file properties database. rkhunter recommends some packages, eg. unhide, which are configured after rkhunter, and hence after rkhunter postinst script is run. Is there any way to add a temporary post-invoke hook so that the database is updated/created after all packages are configured? I have thought that adding a configuration file in /etc/apt/apt.conf.d in postinst would work, but as apt is already running, it won't consider that file until the next time it is run. Another mean would be to force packages like unhide to be configured before rkhunter (a kind of 'pre-recommends' dependency). Any hint for this? Cheers, Julien [1] http://bugs.debian.org/544573 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
One time post-invoke hook
Hi, I am trying to address bug #544573 [1] against rkhunter which I maintain. rkhunter postinst script is used to call rkhunter --propupd which updates/creates its file properties database. rkhunter recommends some packages, eg. unhide, which are configured after rkhunter, and hence after rkhunter postinst script is run. Is there any way to add a temporary post-invoke hook so that the database is updated/created after all packages are configured? I have thought that adding a configuration file in /etc/apt/apt.conf.d in postinst would work, but as apt is already running, it won't consider that file until the next time it is run. Another mean would be to force packages like unhide to be configured before rkhunter (a kind of 'pre-recommends' dependency). Any hint for this? Cheers, Julien Please note I am not subscribed to the list, please CC me for any answer [1] http://bugs.debian.org/544573 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ozerocdoff
Le mercredi 15 avril 2009 à 18:13 +0200, Julien Valroff a écrit : Hi Rogério, Le mardi 14 avril 2009 à 21:08 -0300, Rogério Brito a écrit : Hi, Julien. I am not a DD, but I just saw your package. On Apr 14 2009, Julien Valroff wrote: * URL : http://www.pharscape.org/ozerocdoff.html The URL doesn't seem to be informative enough for an end user. PharScape is on the contrary *the* only valuable source of information for end users owning an Option USB WWWAN modem. I agree with you that some parts of the website might appear cryptic at first sight, but if you own such a modem, it really helps a lot. As for the descriptions, I have amended them slightly as follows: short description: temporarily disables ZeroCD for USB Option WWAN modem Long description: The new USB Option WWAN modem devices support a CDROM device, which holds the needed Windows driver to use the WWAN modem. . Therefore the firmware of the WWAN modem announces during the USB enumeration process to work as a virtual CDROM device with its vendor name ZOPTION. . This device is now called ZERO-CD. . ozerocdoff is a solution to switch off the ZERO-CD and allow the modem to be a used as a modem. Actually, I have completed the short description so that it states keywords such as Option and modem. I have corrected the grammatical errors in the long description, but haven't changed it as it seems clear to me. But as I use this piece of software, I would be glad to receive others' comments to improve it. Since this email, I haven't received any new comments. The new version was uploaded to mentors: - URL: http://mentors.debian.net/debian/pool/main/o/ozerocdoff - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/ozerocdoff/ozerocdoff_0.4-1.dsc Could someone upload this package for me if everything is correct for now? Cheers, Julien -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ozerocdoff
Hi Rogério, Le mardi 14 avril 2009 à 21:08 -0300, Rogério Brito a écrit : Hi, Julien. I am not a DD, but I just saw your package. On Apr 14 2009, Julien Valroff wrote: * URL : http://www.pharscape.org/ozerocdoff.html The URL doesn't seem to be informative enough for an end user. PharScape is on the contrary *the* only valuable source of information for end users owning an Option USB WWWAN modem. I agree with you that some parts of the website might appear cryptic at first sight, but if you own such a modem, it really helps a lot. As for the descriptions, I have amended them slightly as follows: short description: temporarily disables ZeroCD for USB Option WWAN modem Long description: The new USB Option WWAN modem devices support a CDROM device, which holds the needed Windows driver to use the WWAN modem. . Therefore the firmware of the WWAN modem announces during the USB enumeration process to work as a virtual CDROM device with its vendor name ZOPTION. . This device is now called ZERO-CD. . ozerocdoff is a solution to switch off the ZERO-CD and allow the modem to be a used as a modem. Actually, I have completed the short description so that it states keywords such as Option and modem. I have corrected the grammatical errors in the long description, but haven't changed it as it seems clear to me. But as I use this piece of software, I would be glad to receive others' comments to improve it. Cheers, Julien -- Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Rejoignez maintenant plus de 4 500 personnes, associations, entreprises et collectivités qui soutiennent notre action -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ozerocdoff
Hi Didier, Le mercredi 15 avril 2009 à 11:27 +0200, Didier Raboud a écrit : Julien Valroff wrote: Maybe there is another one further down. Also, lintian warns: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I: ozerocdoff source: debian-watch-file-is-missing P: ozerocdoff source: source-contains-prebuilt-binary ozerocdoff.o - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Grr I don't understand what I have done as I had to repack the sources to remove this binary. I do not understand neither why I wasn't warned by lintian on my build machine (I used svn-buildpackage -svn-lintian which gave no error nor warning!) Hi Julien, note that usb-modeswitch (the concurrent ;) ) also provides a prebuilt binary in the tarball and that the lintian warning is a pedantic one. Yes, that's right, that's why I haven't been warned by svn-lintian I hadn't paid attention to this when reading Rogério's message. I just overwrite this prebuilt binary in the building process. It voids the need for a orig.source repack. Well, I actually prefer repacking (that was my aim but just not uploaded the right orig.tar.gz to mentors.d.n yesterday) By the way, don't you think usb-modeswitch and ozerocdoff should conflict? Though they do not share files, they could cause issues when installed together - I haven't tested though as usb-modeswitch doesn't work with my hardware. Cheers, Julien -- Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Rejoignez maintenant plus de 4 500 personnes, associations, entreprises et collectivités qui soutiennent notre action -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ozerocdoff
Le mercredi 15 avril 2009 à 18:30 +0200, Didier Raboud a écrit : Julien Valroff wrote: Hi Didier, (…) By the way, don't you think usb-modeswitch and ozerocdoff should conflict? Though they do not share files, they could cause issues when installed together - I haven't tested though as usb-modeswitch doesn't work with my hardware. Cheers, Julien Hi, That's a good question. I don't have an opinion yet, but note that usb-modeswitch since 0.9.6-2 tries to be clever and provides a /e/u/rules.d/usb_modeswitch.rules which renders its manual launch useless by being run at plugin time. It has some glitches (aka there are different devices with same idVendor:idProduct which need different commands) but mostly work with 'some' configuration. I have tried it again and actually it worked fine, except it misses some HAL rules so that the system detects the modem as such (eg. for use with NetworkManager). usb-modeswitch.rules has no number and as such, no pre-defined precedence on other rules. It supposes that it will be the only one acting on those devices. Because I think that a Conflict is overkill, I would go on without Conflict and see what happens. If we (either on ozerocdoff or on usb-modeswitch) get bugreports that some devices are wrongly detected by usb-modeswitch and should better be used with ozerocdoff (or the opposite), we will jointly decide at that time (either by fixing the bug directly in the concerned package or by making them Conflict). What do you think ? Actually, I have already made ozerocdoff conlict with usb-modeswitch, but wanted to ask you before asking for the package to be uploaded but totally forgot in the meantime, sorry about this. Do you think I should remove this conflict? I do agree with your comment, but would personally rather bet on safety and make these packages conflict. What do other think? Cheers, Julien -- Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Rejoignez maintenant plus de 4 500 personnes, associations, entreprises et collectivités qui soutiennent notre action -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RFS: ozerocdoff
Dear mentors, I am looking for a sponsor for my package ozerocdoff. * Package name: ozerocdoff Version : 0.4-1 Upstream Author : Peter Henn supp...@option.com * URL : http://www.pharscape.org/ozerocdoff.html * License : GPL-2 Programming Lang: C Description : temporarily disables ZeroCD Section : net It builds these binary packages: ozerocdoff - temporarily disables ZeroCD The package appears to be lintian clean. The upload would fix these bugs: 516258 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/o/ozerocdoff - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/ozerocdoff/ozerocdoff_0.4-1.dsc I would be glad if someone uploaded this package for me. Cheers, Julien -- Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Rejoignez maintenant plus de 4 500 personnes, associations, entreprises et collectivités qui soutiennent notre action -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Pass argument from Pre-Install-Pkgs to Post-Invoke
Hi, I am currently working on my rkhunter package to improve the way its database is updated on package upgrade/install/removal. The aim is to only update file properties of the changed packages. To achieve this goal, I need to get the list of changed packages, which I do in a script invokef through Pre-Install-Pkgs. The file properties can however only be updated once the packages are installed, hence I need to run rkhunter --propupd on Post-Invoke. How could I pass the list of changed packages between my both scripts? For now, I use a temporary file (I cannot even use a random name). Is it the right way? Could this have any security issues? As a (better) alternative, is there a way to get the list of changed packages in Post-Invoke? Cheers, Julien -- Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Rejoignez maintenant près de 4 000 personnes, associations, entreprises et collectivités qui soutiennent notre action -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Pass argument from Pre-Install-Pkgs to Post-Invoke
Le dimanche 15 février 2009 à 21:15 +, Jörg Sommer a écrit : Hi Julien, Hi Jörg, Julien Valroff jul...@kirya.net wrote: The aim is to only update file properties of the changed packages. To achieve this goal, I need to get the list of changed packages, which I do in a script invokef through Pre-Install-Pkgs. The file properties can however only be updated once the packages are installed, hence I need to run rkhunter --propupd on Post-Invoke. How could I pass the list of changed packages between my both scripts? For now, I use a temporary file (I cannot even use a random name). Is it the right way? Could this have any security issues? I think this idea is fine. I don't have any other idea. As long as you save only the names of the packages in the file, you shouldn't open any security holes. Where do you save the file? In /var/lib/rkhunter? Yes, in /var/lib/rkhunter/tmp I only save the name of the changed packages. As a (better) alternative, is there a way to get the list of changed packages in Post-Invoke? You can search in dpkg's logfile /var/log/dpkg.log, but apt doesn't tell you this in the post-invoke hook. I have thought of this, but the issue is to be sure to get the list of changed packages for each time apt is run, and I think time is not precise enough (should I consider parsing dpkg.log and take the entries of the last 10 minutes? What if the machine is very slow or if apt is called twice in this time frame?) In the meantime, I came across two other issues that prevents me from reaching my goal: * rkhunter --propupd file feature will only work if the file is already registered in the file properties database. This means that if a package is installed, full db update should be run (or data added by an external script which I am reluctant to do for security and maintenance reasons). I will discuss with upstream to check what can be done in rkhunter to fix this. * I have no idea how to deal with watched files which are in the alternatives system. For now, I am able to compare the upgraded .deb contents and compare with a static list of watched files. Alternative files being symlinks, the post invoke script cannot detect them and will hence fail to update the file properties database. This is for example the case of unhide For the last point, I fear there is unfortunately a good solution at the moment. Cheers, Julien -- Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org Rejoignez maintenant près de 4 000 personnes, associations, entreprises et collectivités qui soutiennent notre action -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Different suggests/recomends according to architecture
Hi, I am the maintainer of the ajaxterm package. I have been provided a patch to allow use of psyco in ajaxterm only if available. I would like to ajaxterm to recommend or suggest this package, which is only available for i386, whereas ajaxterm is an arch:all package. Is there any way to specify this? Should I leave psyco anyway, and rely on apt to not try and install it on architectures where it is not available? Should I change my package to be arch:any (I guess no, just asking)? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Different suggests/recomends according to architecture
Hi Siegfried, Le vendredi 31 octobre 2008 à 18:24 +0100, Siegfried-Angel a écrit : Hi Julien, If I remember correctly, you can use the following syntax: python-psyco [i386]. This is only for build-depends. I think that can also be used for arch:any packages, but as arch:all packages are built only once, the dependencies would be set for the built architecture. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Different suggests/recomends according to architecture
Hi Adeodato, Le vendredi 31 octobre 2008 à 19:30 +0100, Adeodato Simó a écrit : * Julien Valroff [Fri, 31 Oct 2008 17:53:43 +0100]: Hi, I am the maintainer of the ajaxterm package. I have been provided a patch to allow use of psyco in ajaxterm only if available. I would like to ajaxterm to recommend or suggest this package, which is only available for i386, whereas ajaxterm is an arch:all package. Is there any way to specify this? Should I leave psyco anyway, and rely on apt to not try and install it on architectures where it is not available? Should I change my package to be arch:any (I guess no, just asking)? I think Recommending or, particularly, Suggesting packages that don't exist in certain arches is ok for arch:all packages, the story being that nobody notices that it doesn't get installed. If it was a Depends, and arch:all package would depend on psyco | not+i386, which would pull in type-handling on all !i386 arches. There is no point at all in doing that for Recommends, though: you want psyco just not installed, not random crap pulled in. :-) Thanks for your confirmation. I have just tried it on a local packages archive, and it seems to work ok with aptitude (--with-recommends). Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Different suggests/recomends according to architecture
Le vendredi 31 octobre 2008 à 14:33 -0500, Richard Laager a écrit : On Fri, 2008-10-31 at 18:35 +0100, Julien Valroff wrote: Le vendredi 31 octobre 2008 à 18:24 +0100, Siegfried-Angel a écrit : If I remember correctly, you can use the following syntax: python-psyco [i386]. This is only for build-depends. I think that can also be used for arch:any packages, but as arch:all packages are built only once, the dependencies would be set for the built architecture. Consequently, you can just convert it to an arch:any package to have this work. I've done this for some private packages I maintain for myself. I'm not sure if it's appropriate in this case or not, but it does work (on arch:any). The problem is that the source is really arch:all (python scripts), and I do not see the point in overloading the build daemons just for one dependency (recommends in that particular case). After testing, leaving python-psyco in Recommends: does not cause any issue for architectures where it is not available (tested on amd64), whereas it is well installed on i386 (with aptitude --with-recommends) Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sshfp - DNS SSHFP records generator
Hi Maximiliano, Le mardi 24 juin 2008 à 14:56 -0300, Maximiliano Curia a écrit : Hola Julien Valroff! El 23/06/2008 a las 21:01 escribiste: I've made several changes to your package, listed bellow: - I used the pristine tar.gz, as I don't see any reason not to. [...] I remember having read Daniel Baumann's recommendations [0] when taking the decision to remove the existing debian/ directory. There is no consensus. But if you modify the pristine source it's always a good idea to document the process in the debian/rules get-orig-source. I have decided to keep the pristine tarball. I guess upstream developers will accept quite easily to remove the existing debian directory from their next release if the application is uploaded into the official archive. - I created a patch that fixes some quirks in the Makefile (should be forward to upstream). - I created a patch that fixes some quirks in the manpage (should be forward to upstream). great, have you already forwarded these patches? No, being your RFS I believe you should contact upstream and send the patches. Done and accepted upstream - thanks for sending them. - I changed the debian/copyright file to include the same text as is presented in the source code. Maybe this file could be switched to the machine parsable format, what do you think? That would be great. Done. - I added the Homepage: field. Wasn't it already added? I have a version with this field, as well as the Vcs-* fields - I might have forgotten to upload this new version to mentors. I think it would be useful to add these Vcs-* fields once they have reached a definitive location. Done as well. I have added my personal (publicly accessible) repository. Should you need a write access, I can have a look to my configuration (I am not sure I remember exactly how this repository is set up). Ok, do the proposed changes and I'll review it again. The updated package has been uploaded to mentors.d.n: http://mentors.debian.net/debian/pool/main/s/sshfp The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/s/sshfp/sshfp_1.1.3-1.dsc Adding XS-DM-Upload-Allowed: yes would also be a good thing for me if you don't object to this idea. [...] I prefer to review the package before its uploaded, until they don't need my intervention. And then we can add the XS-DM-Upload-Allowed: yes. OK, I understand. I look forward to receiving your comments on the small updates. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sshfp - DNS SSHFP records generator
Hi Maximilano, Le lundi 23 juin 2008 à 14:59 -0300, Maximiliano Curia a écrit : Hola Julien Valroff! El 09/08/2007 a las 12:50 escribiste: Dear mentors, I am looking for a sponsor for my package sshfp. [...] I would be glad if someone uploaded this package for me. I had recently being using sshfp, so I believe it would be a useful addition to the archive. I am glad someone is interested in this package. I've made several changes to your package, listed bellow: - I used the pristine tar.gz, as I don't see any reason not to. The pristine tarball already has a debian/ directory. Keeping it makes the diff.gz harder to read, but I don't know if there is any consensus on this point. I remember having read Daniel Baumann's recommendations [0] when taking the decision to remove the existing debian/ directory. - I had removed the previous contents of debian/changelog, as the pre-debian packaging history is of little/no use. In that case, I totally agree. But it might be a good idea to keep previous entries in case they are useful to understand current packaging. - I removed the patch that replaced © by (c) in the manpage, as manpages now support utf-8 encodings. great - I changed packaging from cdbs to dh, as cdbs is too dificult to follow. I used dh instead of plain debhelper to keep the debian/rules files small and simple. Even though this increased debian/compat to 7. (not really needed, but I really don't like cdbs) - I added dpatch support and dependency. (as a replacement of simplepatchsys) It is a matter of taste, I have nothing against using debhelper. I have never used dh, but it looks quite nice (I still need to study this deeper when I have more time) - I created a patch that fixes some quirks in the Makefile (should be forward to upstream). - I created a patch that fixes some quirks in the manpage (should be forward to upstream). great, have you already forwarded these patches? - I changed the debian/copyright file to include the same text as is presented in the source code. Maybe this file could be switched to the machine parsable format, what do you think? - I added a debian/watch file (always a good idea to have one). it is indeed - I added myself as uploader. ok - I added the Homepage: field. Wasn't it already added? I have a version with this field, as well as the Vcs-* fields - I might have forgotten to upload this new version to mentors. I think it would be useful to add these Vcs-* fields once they have reached a definitive location. Adding XS-DM-Upload-Allowed: yes would also be a good thing for me if you don't object to this idea. - I upgraded the Standards-Version, no changes needed. The modified package can be fetch from: http://maxy.com.ar/debian/sshfp/sshfp_1.1.3-1.dsc Please review those changes and contact me when you feel that your package is good to be uploaded. I think everything is great, but still have a doubt about using the pristine tarball as orig.tar.gz What do other readers of [EMAIL PROTECTED] think of it? Would you be interested in co-maintaining this package? Not a lot of work anyway, but I could then benefit from your experience. Thanks again for having worked on this package Cheers, Julien [0] http://people.debian.org/~daniel/documents/packaging.html#debian-directory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Hi David, Le jeudi 03 janvier 2008 à 19:22 +0100, David Paleino a écrit : [...] .. $ svn status M src/GNOME_GThumb.h $ This isn't, obviously, optimal: I'd expect a FTBFS if this package gets uploaded, and I wouldn't know how to fix it, since I'm not able right now. Just a suggestion: why not copy the original file while building, and move the copy back to its original location in the clean rule? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Le dimanche 30 décembre 2007 à 08:50 +0100, David Paleino a écrit : Il giorno Sun, 30 Dec 2007 08:32:20 +0100 Julien Valroff [EMAIL PROTECTED] ha scritto: I have built the new release, but still an issue with libgthumb.so - gthumb can't find the library: $ ldd /usr/bin/gthumb | grep not found libgthumb.so = not found I attach the build log as there are many related Lintian warnings/errors s/Lintian/dpkg-shlibdeps/ ^^ Those warnings are because dpkg-shlibdeps sees many unneeded linkings. If I'm not wrong, there is a discussion on debian-devel about adding -Wl,--as-needed to LDFLAGS to avoid those warnings [1]. I mainly refer to the warnings refering to missing libgthumb.so as you have noticed below. However, on my system: $ ldd /usr/bin/gthumb | grep libgthumb libgthumb.so = /usr/lib/gthumb/libgthumb.so (0xb7ef9000) Are you sure you have the right package? What does $ dpkg -c package.deb | grep libgthumb return? Is libgthumb.so still a symlink? No, it is in /usr/lib/gthumb/libgthumb.so About the buildlog youo attached: at line 2527, libgthumb.so gets correctly installed into the tmp/ directory: /usr/bin/install -c .libs/libgthumb.so /tmp/gthumb-2.10.7/debian/tmp/usr/lib/gthumb/libgthumb.so This might be indicative though: dpkg-shlibdeps: warning: couldn't find library libgthumb.so needed by debian/gthumb/usr/lib/gthumb/gthumb/modules/libduplicates.so (its RPATH is ''). Note: libraries are not searched in other binary packages that do not have any shlibs file. To help dpkg-shlibdeps find private libraries, you might need to set LD_LIBRARY_PATH. and similarly for other libraries (happens also for me). So, we said that the shlibs file is useless, dpkg here suggests that it only searches into shlibs-providing packages. Should I make a symlink /usr/lib/libgthumb.so pointing to the real .so, and override package name doesn't match SONAME warnings, or...? Creating a symlink in /usr/lib does work: $ ldd /usr/bin/gthumb | grep libgthumb libgthumb.so = /usr/lib/libgthumb.so (0x2b6e5c45a000) That's what was done by the previous maintainer. I am not sure it is the right thing to do. What I don't understand is why it works for you and not for me. Don't you have a ligthumb.so file remaining in /usr/lib from a previous installation? I've just rebuilt the package, and libgthumb.so is correctly placed into /usr/lib/gthumb/. And, again: It is well installed now, but gthumb cannot find it in /usr/lib/gthumb So, I guess, is it probably a amd64-related/specific problem? Again, I am not an expert but I wouldn't understand why. The only particularity I am aware of is: /etc/ld.so.conf.d/x86_64-linux-gnu.conf stating: # Multiarch support /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Le dimanche 30 décembre 2007 à 10:02 +0100, David Paleino a écrit : Il giorno Sun, 30 Dec 2007 09:55:55 +0100 [...] This is kinda weird. It is, yes. Try removing (and purging, let's be sure) the package, deleting all of what you downloaded until now, dget -x the dsc file and recompile it. I'll do the same, and, if the case, reupload the package on mentors.debian.net. I have done it, and still the same issue. The timestamp of the latest changelog entry is Sat, 29 Dec 2007 21:40:26 +0100, is that correct? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Hi David, Le samedi 29 décembre 2007 à 19:16 +0100, David Paleino a écrit : Il giorno Fri, 28 Dec 2007 23:59:37 +0100 David Paleino [EMAIL PROTECTED] ha scritto: Dear mentors, I am looking for a sponsor for the new version 3:2.10.7-1 of the package gthumb, which I'm adopting. ... The upload would fix the ITA bug #457591 It would currently also close (I've updated the package available on mentors in the meanwhile): [...] Please consider uploading it :) I have built the package from the sources available on mentors, and gthumb cannot load: $ LANG=C gthumb gthumb: error while loading shared libraries: libgthumb.so: cannot open shared object file: No such file or directory Indeed, libgthumb.so is not part of the package: [EMAIL PROTECTED]:/tmp$ dpkg --contents gthumb_2.10.7-1_amd64.deb | grep libgthumb.so lrwxrwxrwx root/root 0 2007-12-29 19:37 ./usr/lib/gthumb/libgthumb.so - gthumb/libgthumb.so [EMAIL PROTECTED]:/tmp$ ll /usr/lib/gthumb/ total 948 drwxr-xr-x 3 root root 4096 2007-12-29 20:12 bonobo drwxr-xr-x 3 root root 4096 2007-12-29 20:12 gthumb -rw-r--r-- 1 root root 952630 2007-12-29 19:37 libgthumb.a -rw-r--r-- 1 root root 1730 2007-12-29 19:37 libgthumb.la lrwxrwxrwx 1 root root 19 2007-12-29 20:12 libgthumb.so - gthumb/libgthumb.so [EMAIL PROTECTED]:/tmp$ ll /usr/lib/gthumb/gthumb/modules/ total 924 -rw-r--r-- 1 root root 33614 2007-12-29 19:37 libduplicates.a -rw-r--r-- 1 root root 1803 2007-12-29 19:37 libduplicates.la -rw-r--r-- 1 root root 30304 2007-12-29 19:37 libduplicates.so -rw-r--r-- 1 root root 67110 2007-12-29 19:37 libjpegtran.a -rw-r--r-- 1 root root 1789 2007-12-29 19:37 libjpegtran.la -rw-r--r-- 1 root root 58824 2007-12-29 19:37 libjpegtran.so -rw-r--r-- 1 root root 99260 2007-12-29 19:37 libphotoimporter.a -rw-r--r-- 1 root root 1962 2007-12-29 19:37 libphotoimporter.la -rw-r--r-- 1 root root 78680 2007-12-29 19:37 libphotoimporter.so -rw-r--r-- 1 root root 103816 2007-12-29 19:37 libpngexporter.a -rw-r--r-- 1 root root 1810 2007-12-29 19:37 libpngexporter.la -rw-r--r-- 1 root root 70280 2007-12-29 19:37 libpngexporter.so -rw-r--r-- 1 root root 34566 2007-12-29 19:37 libsearch.a -rw-r--r-- 1 root root 1775 2007-12-29 19:37 libsearch.la -rw-r--r-- 1 root root 32848 2007-12-29 19:37 libsearch.so -rw-r--r-- 1 root root 150228 2007-12-29 19:37 libwebexporter.a -rw-r--r-- 1 root root 1810 2007-12-29 19:37 libwebexporter.la -rw-r--r-- 1 root root 97832 2007-12-29 19:37 libwebexporter.so Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gthumb (updated and adopted package)
Hi David, Le samedi 29 décembre 2007 à 21:29 +0100, David Paleino a écrit : Il giorno Sat, 29 Dec 2007 20:28:30 +0100 David Paleino [EMAIL PROTECTED] ha scritto: ... I must have missed it, let me check the source, I'll report as soon as I get something :) The package now is fully functional, I've also integrated a patch for yet another bug (#452929). Please consider testing it :) I have built the new release, but still an issue with libgthumb.so - gthumb can't find the library: $ ldd /usr/bin/gthumb | grep not found libgthumb.so = not found I attach the build log as there are many related Lintian warnings/errors - might be useful for you. Cheers, Julien gthumb_2.10.7-1_amd64.build.gz Description: GNU Zip compressed data
Re: RFS: gthumb (updated and adopted package)
Le dimanche 30 décembre 2007 à 08:30 +0100, Julien Valroff a écrit : Hi David, Le samedi 29 décembre 2007 à 21:29 +0100, David Paleino a écrit : Il giorno Sat, 29 Dec 2007 20:28:30 +0100 David Paleino [EMAIL PROTECTED] ha scritto: ... I must have missed it, let me check the source, I'll report as soon as I get something :) The package now is fully functional, I've also integrated a patch for yet another bug (#452929). Please consider testing it :) I have built the new release, but still an issue with libgthumb.so - gthumb can't find the library: $ ldd /usr/bin/gthumb | grep not found libgthumb.so = not found I attach the build log as there are many related Lintian warnings/errors s/Lintian/dpkg-shlibdeps/ ^^ - might be useful for you. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: omnibook - Linux kernel module for omnibook and Toshiba laptops
Dear mentors, I am looking for a sponsor for my package omnibook. * Package name: omnibook Version : 2:2.20070211+svn20071006-1 Upstream Author : Mathieu Bérard [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/omnibook http://omnibook.sf.net * License : GPL Section : misc It builds these binary packages: omnibook-source - Source for the omnibook driver This package contains the loadable kernel modules for the HP OmniBooks, Pavilions, Toshiba Satellites and some other laptops manufactured by Compal Electronics, Inc as ODM. The package appears to be lintian clean. The upload would fix these bugs: 445602 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/o/omnibook - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/o/omnibook/omnibook_2.20070211+svn20071006-1.dsc I would be glad if someone uploaded this package for me. Kind regards Julien Valroff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: sshfp - DNS SSHFP records generator
Hi Joerg, Le jeudi 09 août 2007 à 16:32 +0200, Joerg Jaspert a écrit : On 11106 March 1977, Julien Valroff wrote: [...] sshfp - DNS SSHFP records generator Whats the usage for the package that you can get by simply using ssh-keygen? ssh-keygen -r host.name [-f keyfile] [-g] see man ssh-keygen As explained in the ITP, it does basically the same, except that ssh-keygen is limited as it can only read entries from a key file. sshfp can read keys from a known_hosts file or use ssh-keyscan to retrieve public keys. It has also some more advanced features, like 'sshfp -s -a domain.com' which can retrieves all host keys from a given domain. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gconf-cleaner - GConf database cleaner
Hi Paul, Thanks for your comments. Le jeudi 09 août 2007 à 23:10 +1000, Paul Wise a écrit : On 8/9/07, Julien Valroff [EMAIL PROTECTED] wrote: http://mentors.debian.net/debian/pool/main/g/gconf-cleaner/gconf-cleaner_0.0.3-1.dsc Some minor issues: AUTHORS file doesn't need to be installed (debian/copyright covers it) Removed from the binary package. I must say I have hesitated as it was automatically added by dh_installdocs. As the copyright file is obvisouly present in all packages, couldn't we consider this as a bug in dh_installdocs? The NAME section of the manual page needs a synopsis line: gconf-cleaner - tool to clean gconf settings Done. I have removed the SYNOPSIS section - the short synopsis in the NAME section and the DESCRIPTION section should be enough, am I right? Don't forget to send the manual page upstream. Will do this. New package was uploaded to mentors.d.o: - URL: http://mentors.debian.net/debian/pool/main/g/gconf-cleaner - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/gconf-cleaner/gconf-cleaner_0.0.3-2.dsc Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: gconf-cleaner - GConf database cleaner
Le vendredi 10 août 2007 à 17:32 +1000, Paul Wise a écrit : On 8/10/07, Julien Valroff [EMAIL PROTECTED] wrote: AUTHORS file doesn't need to be installed (debian/copyright covers it) [...] I must say I have hesitated as it was automatically added by dh_installdocs. As the copyright file is obvisouly present in all packages, couldn't we consider this as a bug in dh_installdocs? That was probably CDBS, not dh_installdocs. I don't think it is a bug, because not everyone lists the upstream authors in the copyright file. You are right, but shouldn't they list them in the copyright file? ;-) I have removed the SYNOPSIS section - the short synopsis in the NAME section and the DESCRIPTION section should be enough, am I right? Read the man-pages manual page from the manpages package, SYNOPSIS is meant to be an overview of the command line options that are available. So, if there are any command-line options, re-add it and fix the content (I don't have a copy of -1, can't wait for the REVU mentors merge) No, gconf-cleaner has no command line option (that's why I had replaced the content by the short description, but hadn't thought this had to be in the NAME section). Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: sshfp - DNS SSHFP records generator
Dear mentors, I am looking for a sponsor for my package sshfp. * Package name : sshfp Version : 1.1.3-1 Upstream Authors : Paul Wouters [EMAIL PROTECTED] and Jake Appelbaum [EMAIL PROTECTED] * URL : http://www.xelerance.com/software/sshfp/ * License : GPL Section : net It builds these binary packages: sshfp - DNS SSHFP records generator The package appears to be lintian clean. The upload would fix these bugs: 413240 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/s/sshfp - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/s/sshfp/sshfp_1.1.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards Julien Valroff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mini-dinstall, repository signing and apt-get authentication
Le mardi 31 juillet 2007 à 12:51 -0400, Ian Zimmerman a écrit : Neil reprepro doesn't force these on you but it does not stop you Neil adding them later either. Ian OK, I'll take a look at reprepro. I did. reprepro still wants me to have a pool and dists subdirectories, at the very least. This just makes it more complicated to maintain, in particular to upload the debs. I don't think reprepro is the right tool for my job, either. Again, this is _not_ a mirror. It is just a bunch of debs (about 30 right now) that I build myself on a desktop machine, then upload to share with other client machines. Is _anyone_ else doing this? Seems like a natural thing to do. I do, and I use reprepro. And I think I have less than 30 packages in my repository! This tool is both easy and powerful, just as I like. Read carfeully the documentation and you will understand reprepro is not just a mirror tool, and uploads made by tools like dupload or dput are processed very easily directly by reprepro. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Time before closing an unreproducible bug
Le samedi 27 janvier 2007 à 12:06 +0200, Damyan Ivanov a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -=| Julien Valroff, 27.01.2007 10:47 |=- Hi, Is there any globally accepted consensus about when closing an unreproducible bug? #396653[0] was opened 86 days ago, and nobody can reproduce this bug, which was already downgraded from grave to important with the RMs' permission. I would like to close the bug to keep the BTS as clean as possible, but do not want to break established rules. Any hints? I'd mail the reporter and ask of (s)he has any news. Thanks to all for your answers. I have mailed again the reporter, and will follow Neil's suggestions as it is true that I haven't tested on amd64 (will try to find a machine). I will thus keep trying to reproduce the bug again, and won't close it. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Time before closing an unreproducible bug
Hi, Is there any globally accepted consensus about when closing an unreproducible bug? #396653[0] was opened 86 days ago, and nobody can reproduce this bug, which was already downgraded from grave to important with the RMs' permission. I would like to close the bug to keep the BTS as clean as possible, but do not want to break established rules. Any hints? Cheers, Julien [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396653 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why are the buildds able to find a Build-Dep on their own?
On Sat, Jan 20, 2007 at 02:05:55AM -0800, Steve Langasek wrote: On Sat, Jan 20, 2007 at 10:58:33AM +0100, Sven Hoexter wrote: while working on proftpd backport I've been stumbling about the fact that the proftpd package did not declare a build-dep on the libattr1-dev package. The package is clearly needed if you're going to build it by hand. I've been expecting the package to FTBFS on the buildds but the opposite happens and the pacakge is build correctly. Reading #400738 and #405981 (which were both about this issue) didn't help me either to understand it. Could someone please explain me why the buildds were able to build the package without explizitly knowing about the needed libattr1-dev build-dep? proftpd build-depends on libacl1-dev, which depends on libattr1-dev. And isn't it a good idea to declare a build-dep even in this case? proftpd would FTBS if libacl1-dev would drop its dependency on libattr1-dev. Is there a commonly accepted rule on these particular cases? Cheers, Julien signature.asc Description: Digital signature
Re: RFS: BMPx
Le dimanche 01 octobre 2006 à 17:03 +0300, Thierry Randrianiriana a écrit : Fixed, sorry 'libmp4v2-dev' missed in Build-Depends . libmp4v2-dev is not in the official archive! You must have got your copy from debian-multimedia.org So that the package builds fine, you have to remove mp4v2 support. Aslo, you might want to build your package in a clean chroot thanks to pbuilder to check the build-dependencies. Here are my other comments about the package: * I would consider changing the short description for something like highly interoperable media player (without article...) * Please add an extra-space before the Homepage: pseudo-header in debian/control * The copyright information are not clear to me, an dI think you missed quite a lot of copyrighted files in debian/copyright * You should not include empty doc files (NEWS and TODO) in your package * Your package misses man pages for some binaries (bmp-enqueue-uris-2.0, bmp-play-files-2.0, bmp-play-lastfm-2.0, binary-without-manpage, bmp2). As for bmp2, you can simply symlink to beep-media-player-2 As a side note, I find it quite misleading that the package (and the source tarball) is called bmpx whereas the main executable is /usr/bin/beep-media-player-2. Shouldn't the binary package be called beep-media-player-2 (whereas the source package remains bmpx)? Why do other think? Also, FAM is supported according to the README (ok, for the moment), I think it would be better to build against FAM, as gamin is considered obsolete in Debian (at least by the GNOME team), and a small number of packages depend on it (see apt-cache rdepends gamin libgamin0 python-gamin). Please note that I am not a DD, I cannot upload your package and may have missed a lot of things when reviewing your package... Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: webcam-server
Le dimanche 01 octobre 2006 à 21:04 +0200, Nico Golde a écrit : Hi, * Luca bedogni [EMAIL PROTECTED] [2006-09-23 14:21]: [...] * Package name: webcam-server Version : 0.50-1 Upstream Author : Donn Morrison * URL : https://sourceforge.net/projects/webcamserver/ The website says the last release was in 2004, is it still in development or is the development already dead? I had asked that question to Donn Morrison in November last year, here is his answer: From: Donn Morrison donn.morrison at gmail dot com To: Julien Valroff julien at kirya dot net Subject: Re: webcam_server Yeah I'm still maintaining it. I haven't had time to work on it lately but I plan to do a few things to it in the near future. By all means go ahead and build a debian package. I've been meaning to do this for a while. I had then decided to wait for a new release before working on the Debian package, but it is now almost one year old. However, some even older alternatives are in the archive - see camserv as an example, whose last release was done in 2002. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Relibtoolize
Hi, I am trying to update the fast-user-switch-applet package[1] to the latest release for GNOME 2.16. My sponsor asked me to relibtoolize the package, and until now, I got no problems using these[2] links[3] as guidelines. With the 2.16.0 release, however, I have some errors when running configure: ... /tmp/buildd/fast-user-switch-applet-2.16.0/./configure: line 2488: syntax error near unexpected token `0.35.0' /tmp/buildd/fast-user-switch-applet-2.16.0/./configure: line 2488: `IT_PROG_INTLTOOL(0.35.0)' ... When commenting the line 2488, there are other errors: ... /tmp/buildd/fast-user-switch-applet-2.16.0/./configure: line 23290: syntax error near unexpected token `maximum' /tmp/buildd/fast-user-switch-applet-2.16.0/./configure: line 23290: `GNOME_COMPILE_WARNINGS(maximum)' ... As the upstream uses autoconf 2.59, I have tried downgrading my autoconf package, without success. Is there something I could do to fix these issues? I am unfortunately not familiar with autotools... My relibtoolize.patch is available from https://svn.kirya.net/filedetails.php?repname=fast-user-switch-appletpath=%2Ftrunk%2Fdebian%2Fpatches%2F40_relibtoolize.patchrev=75sc=0 Thanks in advance for your help! Cheers, Julien [1] http://packages.debian.org/unstable/gnome/fast-user-switch-applet [2] http://people.debian.org/~keybuk/libtool-updating.html [3] http://people.dooz.org/~lool/debian/relibtoolize -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relibtoolize
Le dimanche 10 septembre 2006 à 11:11 +0200, Loïc Minier a écrit : Hi, On Sun, Sep 10, 2006, Julien Valroff wrote: ... /tmp/buildd/fast-user-switch-applet-2.16.0/./configure: line 2488: syntax error near unexpected token `0.35.0' /tmp/buildd/fast-user-switch-applet-2.16.0/./configure: line 2488: `IT_PROG_INTLTOOL(0.35.0)' ... When updating aclocal.m4, you probably dropped some macros. You can find out by comparing the outputs of the grep command in http://people.dooz.org/~lool/debian/relibtoolize before and after calling aclocal. This is usually a consequence of missing a -I flag to aclocal, or a broken upstream tarball (in this case, install the Debian holding the macros, here intltool). That was it! I had tried looking for the package containing the macros but couldn't find a good way to do it... and hadn't thought it could simply be intltool :-( Thanks for your help, I will submit you an updated package shortly. Should I target experimental although there are no new dependencies? The updated package installs and runs fine in unstable... Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] listen - A nice music player and manager for GNOME
Le mercredi 16 août 2006 à 21:24 +0200, Christoph Haas a écrit : [...] Looks reasonable. Although I probably hadn't changed the description strings myself in a patch. I have submitted my changes to upstream developer and hope he will include them in the next release. May you please check if it is ok on KDE? Perfect. Menu item present on KDE. Good ;-) Thanks, I totally forgot to include a menu entry, which is now done. I had to add a build-dependency on imagemagick to convert the PNG icon to an XPM icon. Since it's just a build-time dependency that's surely okay. Works nice. Uploaded. Let me know if you need subsequent sponsorship. Thank you very much for your help. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] listen - A nice music player and manager for GNOME
Hi Christoph, Thanks for your comments. Le mardi 15 août 2006 à 20:13 +0200, Christoph Haas a écrit : Hi, Julien... On Sunday 13 August 2006 13:51, Julien Valroff wrote: I am looking for a sponsor to upload the listen package. [...] I would be happy to receive your comments. The package looks good to me although I don't speak CDBS. I just wonder why there is no menu item showing up in KDE although a listen.desktop file is shipped. You also don't provide a 'menu' file so on KDE here there is no way to start the application without a shell. I do not use KDE, but the .desktop file shipped in the upstream tarball works on GNOME. I have improved it following Free Desktop's Desktop Entry Specification[1] and Desktop Menu Specification[2]. I used a patch for that. Unfortunately, I could not test the newly build package because I cannot install the new python package version (2.4.3-11) as I suffer from some python transition problems. May you please check if it is ok on KDE? Policy on menu files: http://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus Thanks, I totally forgot to include a menu entry, which is now done. I had to add a build-dependency on imagemagick to convert the PNG icon to an XPM icon. The newly built package is available at: http://kirya.net/~julien/pkg-listen/ Direct link to .dsc: http://kirya.net/~julien/pkg-listen/listen_0.4.3-1.dsc Anyone could also test on GNOME? Thanks! Cheers, Julien [1] http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-0.9.5.html [2] http://standards.freedesktop.org/menu-spec/latest/index.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFS] listen - A nice music player and manager for GNOME
Hi, I am looking for a sponsor to upload the listen package. listen is a nice music player and manager for GNOME, which supports mp3, ogg, mpc, ape, mp4 with Media library support, full drag drop, playlist management. Homepage: http://listengnome.free.fr/ License: GPL ITP: #356289 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=356289) Package sources and i386 binary: http://kirya.net/~julien/pkg-listen/ Direct link to .dsc: http://kirya.net/~julien/pkg-listen/listen_0.4.3-1.dsc I have built this package with pbuilder, and tested it on i386. It is lintian/linda error and warning-free. This software is very young and still suffers from small bugs, but I receive mail regularly asking me to update the status of my ITP. I thought a new upstream version will happen sooner, but seems the upstream developer wants to include some more features, delaying the release. I would be happy to receive your comments. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: serpentine -- An application for creating audio CDs
Le lundi 29 mai 2006 à 12:27 +0200, Sebastien Bacher a écrit : Le samedi 27 mai 2006 à 22:14 +, Sam Morris a écrit : I am searching for a sponsor for serpentine, a GNOME application for burning audio CDs. Hi, There is already an ITP about that package: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=286806 Julien Valroff [EMAIL PROTECTED] mailed me some time ago because he worked and I accepted to co-maintain the package with him since I maintain it for Ubuntu already. Did you contact him about the package? He did, and as his packge was much more complete than mine, I let him this package. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] ajaxterm: Web based terminal written in python
Hi, Le dimanche 28 mai 2006 à 14:24 +0200, Christoph Haas a écrit : Just checked the package. I wonder why the orig.tar.gz that you provide in your repository is different from the tarball available from the upstream's web site. Can you verify that? The upstream author has decided to apply the patches I have submitted but told me he was too lazy to change the version number. I have asked him to do this, and am sure he will accept. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] ajaxterm: Web based terminal written in python
Le dimanche 28 mai 2006 à 16:00 +0200, Christoph Haas a écrit : [...] Please have the upstream increase the version number on every change. It's confusing to have two files with the same version number containing different files. A release is a release is a release. :) I fully agree. Other than that: package is good for me. Uploaded. Thanks. Thanks a lot! I will revert shortly if the upstream developer accepts to release a new 0.6.1 or 0.7 version. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFS] nautilus-open-terminal: nautilus plugin for opening terminals in arbitrary local paths
Hi, I am looking for a sponsor for nautilus-open-terminal, a nautilus plugin allowing to open terminals in arbitrary local paths. * Package name: nautilus-open-terminal * Version : 0.6 * Upstream Author : Christian Neumair [EMAIL PROTECTED] * URL : http://manny.cluecoder.org/packages/nautilus-open-terminal/ * License : GPL * ITP : #310258 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310258 Signed source and i386 packages can be found on http://kirya.net/~julien/pkg-not/ I would be grateful if someone can review the package. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFS] ajaxterm: Web based terminal written in python
Hi, I am looking for a sponsor for ajaxterm: * Package name: ajaxterm Version : 0.6 Upstream Author : Antony Lesuisse [EMAIL PROTECTED] * URL : http://antony.lesuisse.org/qweb/trac/wiki/AjaxTerm * License : Public Domain (with some exceptions) Programming Lang: Python Description : web based terminal written in python ajaxterm is a web based terminal written in python and some AJAX javascript for client side. It can use almost any web browser and even works through firewalls. ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=366285 Signed source and i386 binary packages can be pulled from http://kirya.net/~julien/pkg-ajaxterm/ The package is lintian/linda error and warning free. Could someone review and upload the package if it appears to be ok? Thanks a lot in advance. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: fast-user-switch-applet: applet for the GNOME panel providing a menu to switch between users
Le samedi 25 mars 2006 à 12:18 +0800, Paul Wise a écrit : On Sat, 2006-03-25 at 00:35 +0100, Julien Valroff wrote: I am looking for a sponsor for fast-user-switch-applet, an applet for the GNOME panel providing a menu to switch between users. This package is now part of GNOME 2.14, and should thus be sponsored by a member of the GNOME team. Shouldn't you contact them directly? They probably even have a package already prepared in SVN. Their list is here: http://lists.debian.org/debian-gtk-gnome/ I contacted them before, and somebody told me I could keep my ITP and ask here for a sponsor, provided that I state clearly this is a GNOME package. I put them in copy just in case... Some comments: * debian/changelog: since this is the first debian release, probably best to strip it back to one changelog entry that closes the ITP. done. I have left the 'new upstream' entry. * debian/control: add the homepage in the manner described by the developers reference section 6.2.4 done * debian/compat: using version 4 would help people who may want to backport gnome 2.14 to sarge (and upload to backports.org) done * AUTHORS: redundant, no need to install it - debian/copyright contains that info done - is there a common way to tell cdbs which files to install? * README: please strip bits that are irrelevant for people using binary packages. Might want to ask upstream to split it into separate files I prefer leaving the entire file, as stripping the 2 irrelevant parts would almost mean rewriting the file - I will however ask upstream to split this file. * might also want to install HACKING done * debian/copyright: You seem to ignore some of the copyright notices in the .po files and even the source code?!! ./src/applet.c especially. Please do a proper debian/copyright file by using mc and grep to find all copyright info. done - I hope I have all of them. The updated package is available at: http://packages.kirya.net/debian/pool/main/f/fast-user-switch-applet/ Thanks a lot for your comments. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Linda warning: Shared object is linked with version 12 and 11 of libgnutls.
Hi, I am building package for fast-user-switch-applet[1] based on Ubuntu package. I get a linda warning: W: fast-user-switch-applet; Shared object /usr/lib/fast-user-switch-applet/fast-user-switch-applet is linked with version 12 and 11 of libgnutls. The binary object shown above links against 2 versions of the same shared library. This means your package may require conflicting packages to be installed at the same time, and is therefore uninstallable, or the binary may not work. This may also be ignored if versioned symbols are being used in both libraries. I installed the package and everything works fine, thus it seems I'm in the last situation. Is there anything I can do to avoid this, or should I simply override this warning? Thanks for your comments! Cheers, Julien [1] http://ignore-your.tv/fusa/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: fast-user-switch-applet: applet for the GNOME panel providing a menu to switch between users
Hi, I am looking for a sponsor for fast-user-switch-applet, an applet for the GNOME panel providing a menu to switch between users. Homepage: http://ignore-your.tv/fusa/ Licence: GNU GPL Copyright: James M. Cape [EMAIL PROTECTED] This package is now part of GNOME 2.14, and should thus be sponsored by a member of the GNOME team. My package is largely based on Ubuntu package for the previous release. It is linda and lintian error/warning free. You can find both signed sources and i386 binary package at: http://packages.kirya.net/debian/pool/main/f/fast-user-switch-applet/ Feel free to comment, especially on the description if not appropriate. Thanks a lot! Cheers, Julien signature.asc Description: Ceci est une partie de message numériquement signée
Re: RFS: fast-user-switch-applet: applet for the GNOME panel providing a menu to switch between users
Le samedi 25 mars 2006 à 00:35 +0100, Julien Valroff a écrit : Hi, I am looking for a sponsor for fast-user-switch-applet, an applet for the GNOME panel providing a menu to switch between users. Homepage: http://ignore-your.tv/fusa/ Licence: GNU GPL Copyright: James M. Cape [EMAIL PROTECTED] Forgot to mention ITP #304763 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304763) Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: nautilus-open-terminal - nautilus plugin for opening terminals in arbitrary local paths through nautilus
Hi, I am looking for a sponsor for nautilus-open-terminal, a nautilus plugin for opening terminals in arbitrary local paths through nautilus. Homepage: http://manny.cluecoder.org/packages/nautilus-open-terminal/ Copyright: Christian Neumair [EMAIL PROTECTED] Licence: GNU GPL ITP #310258 [ http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=310258 ] This is a very simple package which is quite with newer GNOME releases as 'open in terminal' shortcut on a click on the desktop was removed. Signed sources and i386 inary package can be found at: http://packages.kirya.net/debian/pool/main/n/nautilus-open-terminal/ I would appreciate your comments on this package, and would be grateful if someone accepts to upload it. Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Take over an ITP in absence of an answer from the bug owner
Le mar, 14 mar 2006, Paul Wise [EMAIL PROTECTED] évrivait : On Tue, 2006-03-14 at 07:09 +0100, Julien Valroff wrote: I am very interested in taking over fast-user-switch-applet package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304763) I will be there in a few days with an RFS ;-) IIRC, fusa is part of the upcoming GNOME 2.14, so the gnome packaging team might be already making a package of this or have plans to do it. Either way, I'd recommend you contact them for sponsoring and or group maintenance. Good catch! I will contact them tonight. Cheers, Julien
Take over an ITP in absence of an answer from the bug owner
Hi, I am very interested in taking over fast-user-switch-applet package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304763) I don't own the ITP which is almost one year old, and the owner hasn't (yet) answered my e-mail. Now I am wondering what to do if after a few other weeks/messages I get no answer. Thanks in advance for your advice! Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Take over an ITP in absence of an answer from the bug owner
Le lundi 13 mars 2006 à 20:19 +0100, Julien Valroff a écrit : Hi, I am very interested in taking over fast-user-switch-applet package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304763) I don't own the ITP which is almost one year old, and the owner hasn't (yet) answered my e-mail. Thanks for all your answers. I just sent a mail to [EMAIL PROTECTED] to change the owner of the ITP. I will be there in a few days with an RFS ;-) Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Python dependencies
Hi, I am preparing to package Serpentine (ITP #286806). I am quite lost regarding python modules dependencies: Serpentine depends on python dbus bindings, which exist as python2.4-dbus in Debian. However, the newer version also depends on Gstreamer 0.10 python bindings, which are only available for python 2.3 (python-gst0.10). According to #346491, python2.3-dbus will never be available. Thus, the only thing I see is filling a bug against python-gst0.10 so that it also provides python 2.4 bindings. Are there other possibilities I would have missed? Thanks in advance for your comments! Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python dependencies
Le dimanche 26 février 2006 à 12:34 -0600, Joe Wreschnig a écrit : On Sun, 2006-02-26 at 16:35 +0100, Julien Valroff wrote: Hi, I am preparing to package Serpentine (ITP #286806). I am quite lost regarding python modules dependencies: Serpentine depends on python dbus bindings, which exist as python2.4-dbus in Debian. However, the newer version also depends on Gstreamer 0.10 python bindings, which are only available for python 2.3 (python-gst0.10). According to #346491, python2.3-dbus will never be available. Thus, the only thing I see is filling a bug against python-gst0.10 so that it also provides python 2.4 bindings. Are there other possibilities I would have missed? Wait until the Python 2.4 transition? I really do not want to maintain three versions of a large module like python-gst. I fully understand! Given that I am told every other day that the Python transition will be real soon now, and NEW queue appears to be at least a week, this may even be faster than waiting for a new python-gst0.10 to pass NEW. I wasn't aware that this transition should happen so quickly! This is fully acceptable for me to wait for this optional package. Thanks for your answer Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] altermime: utility used to alter mime-encoded mailpacks (uploaded)
Le dimanche 01 janvier 2006 à 13:01 +0100, Christoph Haas a écrit : On Friday 30 December 2005 21:06, Julien Valroff wrote: However, the package was rejected as orig.tar.gz was not included in the upload. The package should be rebuild with dpkg-buildpackage -sa option. Do you need me to do that? No, no, that was my mistake. Building with old changelog entries (-v) and pbuilder made me forget to add the orig file (-sa). It should be fixed now. It seems to be ok now. Thanks again for helping. Happy new year! Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] altermime: utility used to alter mime-encoded mailpacks
Hi, Thanks for your comments. Le vendredi 30 décembre 2005 à 15:39 +0100, Christoph Haas a écrit : On Thursday 29 December 2005 11:11, Julien Valroff wrote: I'm looking for a sponsor for altermime: [...] According to the WNPP there is currently an ITP by David Moreno Garza [EMAIL PROTECTED]. Did you talk to him already? The ITP is over three months old though. Still nice to coordinate who's doing what. Actually, I did send this ITP, but my email client truncated the title, David corrected the title. Further thoughts: - don't mention debian/README.Debian in debian/altermime.docs It gets installed by dh_installdocs anyway. - still debian/altermime.docs: the README doesn't carry much useful information. Consider dropping it. - the README.Debian doesn't help much IMHO. If people find /usr/share/doc/altermime/README.Debian I believe they can also find /usr/share/doc/altermime/README That's right, I removed both README and README.Debian files. - the architecture is i386. Does it really not run on anything else? Changed to any. - you call debhelper scripts like dh_link but you don't set links. Drop those calls. As stated by Justin, I have already been advised to let dh_link, even if no links have to be set. Should I remove this call anyway? - the man page you ship mentions a LICENSE file which does not get installed Indeed, I didn't pay attention to that. I added LICENCE to debian/altermime.docs. I also removed the reportbug hook. I will build a new package if you think altermime can be uploaded. The changes can be viewed at: https://svn.kirya.net/comp.php?repname=altermimepath=compare%5B%5D=% [EMAIL PROTECTED][EMAIL PROTECTED] Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] altermime: utility used to alter mime-encoded mailpacks
Le vendredi 30 décembre 2005 à 18:54 +0100, Christoph Haas a écrit : On Friday 30 December 2005 18:39, Julien Valroff wrote: Thanks for your comments. As stated by Justin, I have already been advised to let dh_link, even if no links have to be set. Should I remove this call anyway? I believe Justin is right. So just leave it there. OK. I will build a new package if you think altermime can be uploaded. The changes can be viewed at: https://svn.kirya.net/comp.php?repname=altermimepath=compare%5B%5D=% [EMAIL PROTECTED][EMAIL PROTECTED] Looks good. Where can I get the diff.gz? http://packages.kirya.net/pool/main/a/altermime/altermime_0.3.6-11.diff.gz I removed LICENCE as Policy states that all licence information[1] should be in debian/copyright. I thus changed the man page to point to /usr/share/doc/altermime/copyright. Thanks again. Cheers, Julien [1] http://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFS] altermime: utility used to alter mime-encoded mailpacks (uploaded)
Le vendredi 30 décembre 2005 à 19:55 +0100, Christoph Haas a écrit : On Friday 30 December 2005 19:23, Julien Valroff wrote: I removed LICENCE as Policy states that all licence information[1] should be in debian/copyright. I thus changed the man page to point to /usr/share/doc/altermime/copyright. Good. Package appears to be clean now. Thanks for your contribution. Package is uploaded. Please get back to me if you need to have a new version uploaded. Thank *you* for your help. However, the package was rejected as orig.tar.gz was not included in the upload. The package should be rebuild with dpkg-buildpackage -sa option. Do you need me to do that? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[RFS] altermime: utility used to alter mime-encoded mailpacks
Hi, I'm looking for a sponsor for altermime: alterMIME is a small program which is used to alter your mime-encoded mailpacks as typically received by Inflex, Xamime and AMaViS. alterMIME can: * Insert disclaimers * Insert arbitary X-headers * Modify existing headers * Remove attachments based on filename or content-type * Replace attachments based on filename Homepage: http://www.pldaniels.com/altermime/ The licence terms are quite clear, and it seems clear that the package is DFSG free. If you feel it can be a problem, can someone help to speak with the legal team? Both source and i386 binary packages can be found at: http://packages.kirya.net/pool/main/a/altermime/ They are Linda/Lintian error and warning free. Of course, I will remove the hook meant to make reportbug usable without the BTS before the upload. I'm waiting for your comments. Thanks! Cheers, Julien signature.asc Description: This is a digitally signed message part
[RFS] freeloader: a nice Gnome download manager written in python and supporting torrents
Hi, I am looking for a sponsor for freeloader, a Gnome download manager that supports torrents, written by Steven Grafton. Homepage: http://www.ruinedsoft.com/freeloader/ The package is almost linda/lintian error free, except a warning caused by a python script without any she-bang line. I don't know if it is worth overriding this. I had to make use of dpatch because: * some modules checks failed if run without screen (build-dependencies are ok as I built the package with pbuilder) * the default shared data directory is /usr/shared/freeloader-0.3 (I just removed the version) Signed sources and i386 binaries: http://packages.kirya.net/pool/main/f/freeloader/ SVN: https://svn.kirya.net/listing.php?repname=freeloader Cheers, Julien signature.asc Description: This is a digitally signed message part
Re: [RFS] freeloader: a nice Gnome download manager written in python and supporting torrents
Le vendredi 16 décembre 2005 à 19:26 +0100, Clément Stenac a écrit : Hello, I am looking for a sponsor for freeloader, a Gnome download manager that supports torrents, written by Steven Grafton. I'm interested in sponsoring this package. I'll have a look at it tonight. Thanks The package is almost linda/lintian error free, except a warning caused by a python script without any she-bang line. I don't know if it is worth overriding this. I haven't yet checked, but as you use dpatch anyway, couldn't you patch this file too ? Added in SVN [1], I'm waiting for other comments before building another package. Cheers, Julien [1] https://svn.kirya.net/comp.php?repname=freeloaderpath=compare%5B% [EMAIL PROTECTED][EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: [RFS] freeloader: a nice Gnome download manager written in python and supporting torrents
Le vendredi 16 décembre 2005 à 19:52 +0100, Thijs Kinkhorst a écrit : Hello Julien, Hi! Many thanks for your feedback. Here's some more feedback, I hope it's useful. Added in SVN [1], I'm waiting for other comments before building another package. You must not install the reportbug hook if you're going to make the package part of Debian proper, since that will circumvent the BTS. That was clear. I added it as I already use this package (and thus make it available in my repository). I removed it. You might want to raise debhelper compatibility level in file 'debian/compat' to 5, since it's the most recent. Only drawback is that that version is not in sarge, it makes backporting a very tiny bit harder. Done. The debian/copyright file misses years, like this: Copyright 2005 Mr Potatohead. Done. Good example :-) In the man page you write This manual page was written for the Debian system by Julien Valroff [EMAIL PROTECTED].. Although not required, I find it good custom to add but may be used by others to it. Added. Your changelog doesn't close RFP bug #337598 (which would better have been retitled to an ITP by you). Done, just forgot to do it! Good luck with your package! Thanks! I will build a new package with your suggestions, as well as the comments I have just received from Clément. Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Packaging freeloader: problem with python gtk module dependency
Hi,
I'am currently packaging freeloader, a Gnome download manager written in
Python and supporting torrents (http://www.ruinedsoft.com/freeloader/),
but I have a problem with build dependencies.
According the homepage, requirements are:
+ Linux operating system (similar systems may work)
+ python 2.3 or 2.4
+ pygtk 2.6
+ 2 MB install space
+ GTK+ 2.6 or greater
+ BitTorrent python module version 3.4
My build-depends field in control file is:
debhelper (= 4.0.0), imagemagick (= 6), python (= 2.3),
python2.3-gtk2 (= 2.6), bittorrent (= 3.4)
I build the package successfully with debuild and dpkg-buildpackage, but
when using pdebuild in a a sid chroot, the configure script cannot find
python gtk module:
/.../
checking for python... (cached) python2.3
checking for main in -lpython2.3... (cached) no
checking for python2.3/Python.h... (cached) no
results of the Python check:
Binary: python2.3
Library: no
Include Dir: no
checking python module: pygtk... yes
checking python module: gtk... no
configure: error: failed to find required module gtk
make: *** [config.status] Error 1
pbuilder: Failed autobuilding of package
/.../
The test from the configure file for the gtk python module is:
echo $as_me:$LINENO: checking python module: gtk 5
echo $ECHO_N checking python module: gtk... $ECHO_C 6
python -c import gtk 2/dev/null
if test $? -eq 0;
then
echo $as_me:$LINENO: result: yes 5
echo ${ECHO_T}yes 6
eval HAVE_PYMOD_GTK=yes
else
echo $as_me:$LINENO: result: no 5
echo ${ECHO_T}no 6
eval HAVE_PYMOD_GTK=no
#
if test -n 1
then
{ { echo $as_me:$LINENO: error: failed to find required
module gtk 5
echo $as_me: error: failed to find required module gtk 2;}
{ (exit 1); exit 1; }; }
exit 1
fi
fi
I checked the packages I have installed on my development machine, but I
cannot see anything more than the build-depends.
When I launch python -v and try to import gtk module, all the objects
come from the /usr/lib/python2.3/site-packages/gtk-2.0/ directory, which
belongs to pythong2.3-gtk2 package.
Could it be linked to the chroot that does not have correct environment
and cannot find the correct path? If yes, how can I fix this problem?
Many thanks in advance for your comments.
Cheers
Julien
signature.asc
Description: This is a digitally signed message part
Re: Packaging freeloader: problem with python gtk module dependency
Hi, Thanks for your answer. Le samedi 05 novembre 2005 à 10:28 -0500, Roberto C. Sanchez a écrit : On Sat, Nov 05, 2005 at 09:22:06AM +0100, Julien Valroff wrote: Hi, I'am currently packaging freeloader, a Gnome download manager written in Python and supporting torrents (http://www.ruinedsoft.com/freeloader/), but I have a problem with build dependencies. According the homepage, requirements are: + Linux operating system (similar systems may work) + python 2.3 or 2.4 + pygtk 2.6 + 2 MB install space + GTK+ 2.6 or greater + BitTorrent python module version 3.4 My build-depends field in control file is: debhelper (= 4.0.0), imagemagick (= 6), python (= 2.3), python2.3-gtk2 (= 2.6), bittorrent (= 3.4) I am not sure about your build problem. However, your depends could use some work. Change python (= 2.3), python2.3-gtk2 (= 2.6) to either python2.3, python2.3-gtk2 (= 2.6) or to python (= 2.3), python-gtk2 (= 2.6) so that changes in the default Python version don't break your package. That's right. I have tried many different ways to be sure of my build dependencies. I reversed my changes for the second option. [...] If you post the sources for what you have done so far, we might be able to provide more help. You can check my anonymous svn repo at: svn://svn.kirya.net/freeloader/trunk (or via websvn at: http://svn.kirya.net/listing.php?repname=freeloaderpath=%2Ftrunk% 2Frev=0sc=0 ) Cheers, Julien signature.asc Description: This is a digitally signed message part
Re: Packaging freeloader: problem with python gtk module dependency
Le samedi 05 novembre 2005 à 16:36 +0100, Florian Ragwitz a écrit : On Sat, Nov 05, 2005 at 09:22:06AM +0100, Julien Valroff wrote: checking for python... (cached) python2.3 checking for main in -lpython2.3... (cached) no checking for python2.3/Python.h... (cached) no results of the Python check: Binary: python2.3 Library: no Include Dir: no You need python2.3-dev. Thanks for your help. Unfortunately, this doesn't help. I don't have this package installed on my dev machine. Cheers, Julien signature.asc Description: This is a digitally signed message part
Dependencies and debconf configuration
Hi,
As an exercise, I am trying to package as cleanly as possible bootsplash
3.2 and a few themes.
I use debconf templates for the configuration.
Main bootsplash package depends on a given theme package, which depends
itself to bootsplash. I really don't know if it is a good idea, as this
leads to a few problems:
The configuration of bootsplash needs to have at least one theme
installed, ie. when I run 'dpkg -i bootsplash.deb
bootsplash-theme.deb' (depending on the order the packages are
configured), it happens that bootsplash is configured before the theme
is installed: the user has to run 'dpkg-reconfigure bootsplash' by hand.
* Is there any possibility to force the order of
configuration/installation when installing several packages together?
* Or is it possible to call 'dpkg-reconfigure bootsplash' from the
bootsplash-theme {pre,post}inst files?
I'm quite sure that this option doesn't comply with the policy because
it would mean asking questions to the user in the postinst process. But
I cannot see any other mean to do that cleanly.
* The other way would be to make bootsplash-theme package _not_ depend
on bootsplash, I think it would force the theme to be installed before
the main bootsplash package is installed, is that right? But what would
then happen with aptitude that installs the recommended packages by
default?
Do you guys have an idea about this? I cannot find any package that I
can take as an example for this.
Many thanks in advance for all your comments/suggestions/answers.
Cheers,
Julien
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies and debconf configuration
Hi Steve, Thank you for your quick answer. Le dimanche 25 septembre 2005 à 01:06 -0700, Steve Langasek a écrit : On Sun, Sep 25, 2005 at 09:38:34AM +0200, Julien Valroff wrote: [...] * Is there any possibility to force the order of configuration/installation when installing several packages together? Yes: package dependencies. That is waht I supposed. * The other way would be to make bootsplash-theme package _not_ depend on bootsplash, I think it would force the theme to be installed before the main bootsplash package is installed, is that right? But what would then happen with aptitude that installs the recommended packages by default? If bootsplash requires a theme to be installed in order for its postinst to complete successfully, then bootsplash must depend on the theme and the themes must not depend on bootsplash. Thanks, it works, at least with dpkg (I still have to check how synaptic an aptitude behaves). But installing a theme without installing the bootsplash utilities is then possible, and totally useless. Don't you think this can mislead users? If the package's debconf config script *also* can't do the right thing before the theme is unpacked, then the config script should exit without attempting to set any debconf variables. I am not sure to understand what you mean. Could you please explain again? Cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dependencies and debconf configuration
Le dimanche 25 septembre 2005 à 12:38 +0200, Reinhard Tartler a écrit : On 9/25/05, Julien Valroff [EMAIL PROTECTED] wrote: But installing a theme without installing the bootsplash utilities is then possible, and totally useless. Don't you think this can mislead users? Tell them, they rather want bootspash than the theme ;) You are 100% right! I will do it this way. Many thanks for all your answers. cheers, Julien -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
man pages and symbolic links
Hi, I am building a package with several binaries, and would like to know if it is correct to build one unique man page for all the binaries, with symbolic links poiting to the real file? eg.: /usr/share/man/1/binary.1 - /usr/share/man/1/mainbinary.1.gz Then, 'man binary' would yield to the same result as 'main mainbinary'. dpkg-dev, for example, uses the same contents for several binaries (try man dpkg-genchangelog and man dpkg-gencontrol for example) but not symlinks. All the binaries options would of course be described in this unique man page. Many thanks in advance for your answers! Cheers Julien signature.asc Description: This is a digitally signed message part
RE: man pages and symbolic links
Hi, and thank you for your answer. Le mercredi 24 août 2005 à 12:13 +0200, jano kupec a écrit : Hi, i think you'll find the anwer here: http://www.debian.org/doc/debian-policy/ch-docs.html#s12.1 Sure, I haven't seen what is told about symlinks! However, it is not very clear that several binaries can 'share' the same man page. Considering the dpkg-dev example, I think it should be all right. i also agree that one man page and several symlinks is better idea You confort my choice then ;-) jano Julien -Original Message- From: Julien Valroff [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 24, 2005 12:04 PM To: debian-mentors@lists.debian.org Subject: man pages and symbolic links Hi, I am building a package with several binaries, and would like to know if it is correct to build one unique man page for all the binaries, with symbolic links poiting to the real file? eg.: /usr/share/man/1/binary.1 - /usr/share/man/1/mainbinary.1.gz Then, 'man binary' would yield to the same result as 'main mainbinary'. dpkg-dev, for example, uses the same contents for several binaries (try man dpkg-genchangelog and man dpkg-gencontrol for example) but not symlinks. All the binaries options would of course be described in this unique man page. Many thanks in advance for your answers! Cheers Julien signature.asc Description: This is a digitally signed message part
