Bug#672268: RFS: kde-gtk-config/2.0-1 [ITP] -- KDE configuration module for GTK+ 2.x and GTK+ 3.x style selection
Le samedi, 2 juin 2012 16.56:10, vous avez écrit :
2) Handling of the transition
I just tested with a clean user: the current kde-config-gtk-style creates
one .gtkrc-2.0-kde while your new kde-config-gtk-style creates one
.gtkrc-2.0-kde4 that is a symlink to .gtkrc-2.0 . You should probably
cope with
04_no_kde4_in_configfile.diff in src:kcm-gtk and make sure any changes
put there by kcm-gtk is kept gracefully.
Done.
Sorry, but no. I just tested and it doesn't work.
With the attached .gtkrc-2.0-kde as created by the current src:kcm-gtk, when
entering the dialog of src:kde-gtk-config, the dialogs don't show Raleigh
nor DejaVu Sans 9, but oxygen-gtk and Bitstream Charter 12 (and Emacs
for the GTK3 theme). That's not what I'd call any changes there are kept
gracefully.
I'll upload this package [0] when user changes setup by kde-config-gtk-style
2:0.5.3-1 are kept and converted (if needed) by kde-config-gtk-style 3:2.0-1.
That's rather easy to test…
Cheers,
OdyX
[0] But feel free to find another sponsor.
# This file was written by KDE
# You can edit it in the KDE control center, under GTK Styles and Fonts
include /usr/share/themes/Raleigh/gtk-2.0/gtkrc
style user-font
{
font_name=DejaVu Sans
}
gtk-theme-name=Raleigh
gtk-font-name=DejaVu Sans 9
signature.asc
Description: This is a digitally signed message part.
Bug#672268: RFS: kde-gtk-config/2.0-1 [ITP] -- KDE configuration module for GTK+ 2.x and GTK+ 3.x style selection
(Hereby ignoring the tone of your private ping) Le mercredi, 16 mai 2012 23.23:02, Boris Pek a écrit : Great! Could you look on the package now? Yeah. I took a look. 1) Versioning So, what I wrote before about the version is not completely true: bumping the epoch is not _strictly_ needed as 2:0.5.3-1 from src:kcm-gtk would sort before an 2:2.0-1 from src:kde-gtk-config. That said, I think that bumping the epoch would be a clear indication that the source for this package changed so is not necessarily bad. I'll leave that decision up to you. 2) Handling of the transition I just tested with a clean user: the current kde-config-gtk-style creates one .gtkrc-2.0-kde while your new kde-config-gtk-style creates one .gtkrc-2.0-kde4 that is a symlink to .gtkrc-2.0 . You should probably cope with 04_no_kde4_in_configfile.diff in src:kcm-gtk and make sure any changes put there by kcm-gtk is kept gracefully. As a general rule, make sure that any bug fixed in kcm-gtk (by its patches or by its code) is not re-introduced by src:kde-gtk-config. Other than that, it looks fine but at least 2) ought to be fixed. Cheers, OdyX -- 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/201205312219.19134.o...@debian.org
Bug#667506: RFS: install-debian/2.1.3 [NEW] -- command line installs Debian system non-interactively
Vladimir; Le mercredi, 4 avril 2012 20.38:45, Vladimir Stavrinov a écrit : ...). I do not think it is suitable for Debian. Great! Debian installer is not suitable for Debian! Debian already has one component named the Debian Installer [0,1], which is the official way to install Debian hosts. [0] http://www.debian.org/devel/debian-installer/ [1] http://packages.qa.debian.org/d/debian-installer.html I think having both the official Debian Installer `debian-installer` package and a completely new package (not suitable for generic installations) being named `install-debian` confusing (to say the least). So, without even taking a look at your `install-debian` package, I would certainly not upload it as is (hence agreeing with Ansgar' +wontfix tag), purely for name clashing reasons. (Note that I'm not judging the quality of your software, only its naming). Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Bug#667506: RFS: install-debian/2.1.3 [NEW] -- command line installs Debian system non-interactively
Le mercredi, 4 avril 2012 21.24:08, Vladimir Stavrinov a écrit : On Wed, Apr 04, 2012 at 09:11:03PM +0200, Didier Raboud wrote: Debian already has one component named the Debian Installer [0,1], which is As usual, I was not satisfied with it and hence wrote my own installer Have you reported your insatisfaction (think: bugreports)? By the way, from the description on install-debian's homepage: It should be started from within Live CD, Network Boot or from any bootable media, other then Your system disk. That's how debian-installer currently works It fully supports software RAID. … as does d-i. You can change defaults and most settings with command line options and configuration variables. Do you know that you can preseed the Debian Installer to do exactly that? All settings if not defined in config file or as command line options, will b set to it's defaults either as constant values or evaluated from running system. d-i preseed can set the priority of questions, hence getting sane defaults for most things. By default it chooses largest disk for installation. d-i can do that too. If there are more then one such disk of the same size, it makes RAID array. d-i can do that too. Partitioning scheme supports separate partition for /boot, and separate logical volumes for root filesystem, /usr, /var, /tmp and /home. Also there are option to install system into single pre-mount point. In this case partitioning and mounting every part leave on Your own. d-i can do that too. This script installs only bit more packages then base system includes. The main purpose is to get bootable system. After booting new system You can install everything what You want. That's what d-i does too. So, what does install-debian better than what the debian-installer does? Or what does it that debian-installer doesn't? purely for name clashing reasons. (Note that I'm not judging the quality of your software, only its naming). I think it is hard to confuse debian-installer with install-debian as well as up and down. But if it is only reason preventing upload, I agree to rename it. Please, give me Your suggestions. Given the above, try d-i-d-nih-kit-2.0-ng . Cheers, OdyX P.S. That was my last mail to this bugreport: I won't sponsor install-debian so I'm not the one to convince. signature.asc Description: This is a digitally signed message part.
Re: RFS: mobile-broadband-provider-info (updated package)
Paul Wise wrote: This is why I think packaging it at all is possibly a bad idea since people running Debian stable/oldstable will always have old information. It would be better if the software that uses it were to be responsible for downloading it periodically. I respectfully disagree. If we take that path, then we might as well allow usb-modeswitch to download its latest modeswitching strategies for the 3G dongles that need one. Oh and usb-modeswitch could then also update its binary too as anyone wants the latest anyway. Having that type of data packaged and uploaded to our archive puts trust on its contents. You don't get any close to that level of trust with programs that download random stuff from the Internet for their uptodatedness; especially when the random stuff is critical for the Internet access (as mobile-broadband-provider-info can be). In fact, I would be suprised if our Stable Release Managers were to refuse updates of such data packages. Cheers, OdyX -- 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/jalh95$kqe$1...@dough.gmane.org
Re: RFS: jabber-querybot
On Wed, 23 Nov 2011 08:06:09 +0100, Marco Balmer wrote: Good point! I changed upstream and built a new version: http://mentors.debian.net/debian/pool/main/j/jabber-querybot/jabber-querybot_0.0.5.1-1.dsc * d/postinst: removed * File installed to /etc/jabber-querybot Hi Marco, unfortunately, there are things you should change before I can upload: - according to debdiff between the version currently in unstable and this version, you changed the 0.0.4-1 changelog entry; which you should really not (unless there is a good reason; in which case you should mention it in the changelog entry for the to-be-uploaded version) - you have to cleanup after the faulty postinst that reached the archive in jabber-querybot 0.0.4-1 (and I plea guilty for this). If you just drop the postinst without making sure the symlink that it added is properly removed, then it will end up with that situation: $ ls -la /etc/jabber-querybot/ total 12 drwxr-xr-x 2 root root 4096 Nov 23 09:42 . drwxr-xr-x 43 root root 4096 Nov 23 09:37 .. lrwxrwxrwx 1 root root 50 Nov 23 09:38 Querymodule.pm - /usr/share/doc/jabber-querybot/examples/Testbot.pm -rwxr-xr-x 1 root root 2133 Nov 23 06:33 Querymodule.pm.dpkg-new So you probably need a preinst that checks the version you are upgrading from, tests the symlink and removes it in case it still exists. Then, at unpacking phase, the correct Querymodule.pm file will get unpacked at its correct place. Cheers, OdyX -- 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/65b94463e22662bc604cab826cb22...@raboud.com
Re: RFS: jabber-querybot
On Wed, 23 Nov 2011 11:52:05 +0100, Marco Balmer wrote:
On Wed, Nov 23, 2011 at 10:46:42AM +0100, Didier Raboud wrote:
unfortunately, there are things you should change before I can
upload:
- according to debdiff between the version currently in unstable and
this version, you changed the 0.0.4-1 changelog entry; which you
should really not (unless there is a good reason; in which case you
should mention it in the changelog entry for the to-be-uploaded
version)
I was not able to find the place I changed log entry for 0.0.4-1.
How can I show this with debdiff?
With something like:
$ apt-get source jabber-querybot/unstable
$ dget -x
http://mentors.debian.net/debian/pool/main/j/jabber-querybot/jabber-querybot_0.0.5.1-1.dsc
$ debdiff jabber-querybot_0.0.{4,5.1}-1.dsc | grep -A 10
'jabber-querybot (0.0.4-1)'
- you have to cleanup after the faulty postinst that reached the
archive in jabber-querybot 0.0.4-1 (and I plea guilty for this). If
you just drop the postinst without making sure the symlink that it
added is properly removed, then it will end up with that situation:
So you probably need a preinst that checks the version you are
upgrading from, tests the symlink and removes it in case it still
exists. Then, at unpacking phase, the correct Querymodule.pm file
will get unpacked at its correct place.
I just fixed this and added d/preinst:
http://mentors.debian.net/debian/pool/main/j/jabber-querybot/jabber-querybot_0.0.5.1-1.dsc
Quoting myself extensively in the preinst is not needed. Additionally,
you forgot the checks the version you are upgrading from in the
postinst. The advantage of doing this explicitely is that the code gets
run once for each user and then can be removed in the unstable version
when jabber-querybot reaches stable (as users are mandated to upgrade
from stable to stable releases...). See
http://wiki.debian.org/MaintainerScripts for clear graphs.
IMHO, the check you are doing in the preinst is not sufficient; what if
Random Joe has set up a symlink named
/etc/jabber-querybot/Querymodule.pm that points to his user directory
(for whatever reason)? Then with this preinst, you are not preserving
his changes. So you have to test if the user is both upgrading
(information is in $1) and is doing so from a version smaller than
0.0.5.1-1 (as it's the first version that introduces the fix)
(information is in $2). Then, to be on the safe side, you also have to
check that the symlink you want to remove indeed points to the place you
had setup in the faulty postinst. In that case only you can safely
remove the symlink.
If both this and the changelog issue are fixed properly, then I will
upload. :-
Cheers,
OdyX
--
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/fb664b215088f59da3604fb77f618...@raboud.com
Re: RFS: jabber-querybot
On Wed, 23 Nov 2011 15:21:38 +0100, Marco Balmer wrote: - d/preinst: Implemented according to your remarks. Almost there! :- == your code == if [ -L /etc/jabber-querybot/Querymodule.pm ] \ [ $1 = upgrade ] \ [ $2 = 0.0.4-1 ]; then if ls -l /etc/jabber-querybot/Querymodule.pm | grep -q \ /usr/share/doc/jabber-querybot/examples/Testbot.pm; then rm /etc/jabber-querybot/Querymodule.pm fi fi == /your code == With your current code, the link type will be tested at each run of the preinst. In fact, your lazy evaluation checks things in reverse order: first the link, then the version, then are we upgrading?; where it's probably more efficient to test things in the reverse order (as the lazy evaluation will stop as soon as possible). Furthermore, you take the output of ls as granted and check its content with grep; that's not very efficient (and error prone; what if I had setup that symlink to /home/me/stuff/usr/share/doc/jabber-querybot/examples/Testbot.pm ?) And the preinst will only work when upgraded from _exactly_ 0.0.4-1; what if jabber-querybot exists (in derivatives, binary rebuilds, etc) in versions bigger than that but still smaller than 0.0.5.1-1 ? For this, dpkg --compare-versions is usually used, as it provides clean = = operators, for this purpose. What about that snippet? (which I wrote with inspiration from my local /var/lib/dpkg/info/*.preinst e.g.) == proposal == case $1 in upgrade) if dpkg --compare-versions $2 lt 0.0.5.1-1; then if [ -L /etc/jabber-querybot/Querymodule.pm ] [ `readlink /etc/jabber-querybot/Querymodule.pm` = /usr/share/doc/jabber-querybot/examples/Testbot.pm ]; then rm /etc/jabber-querybot/Querymodule.pm fi fi ;; esac == /proposal == Cheers, OdyX -- 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/dc51fddf8ea3de6a9801efe467910...@raboud.com
Re: RFS: jabber-querybot
And now finally taking care of the install step too: this is needed if someones installs jabber-querybot 0.0.4-1, uninstalls it (the symlink doesn't get removed) and then installs 0.0.5.1-1. On Wed, 23 Nov 2011 16:15:51 +0100, Didier Raboud wrote: Or now with the -ef suggestion (way nicer!): On Wed, 23 Nov 2011 16:04:20 +0100, Didier Raboud wrote: What about that snippet? (which I wrote with inspiration from my local /var/lib/dpkg/info/*.preinst e.g.) == proposal 3 == case $1 in upgrade|install) if dpkg --compare-versions $2 lt 0.0.5.1-1; then if [ /etc/jabber-querybot/Querymodule.pm -ef /usr/share/doc/jabber-querybot/examples/Testbot.pm ]; then rm /etc/jabber-querybot/Querymodule.pm fi fi ;; esac == /proposal 3 == -- 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/1c5a009875074f9fa19aa52801f2e...@raboud.com
Re: RFS: jabber-querybot
Or now with the -ef suggestion (way nicer!): On Wed, 23 Nov 2011 16:04:20 +0100, Didier Raboud wrote: What about that snippet? (which I wrote with inspiration from my local /var/lib/dpkg/info/*.preinst e.g.) == proposal 2 == case $1 in upgrade) if dpkg --compare-versions $2 lt 0.0.5.1-1; then if [ /etc/jabber-querybot/Querymodule.pm -ef /usr/share/doc/jabber-querybot/examples/Testbot.pm ]; then rm /etc/jabber-querybot/Querymodule.pm fi fi ;; esac == /proposal 2 == -- 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/493ef0271300df90a8930c05eca4c...@raboud.com
Re: RFS: jabber-querybot
Le mercredi, 23 novembre 2011 16.30:11, Marco Balmer a écrit : Finaly I implemented your proposal 3. Learned a lot today! Thanks to all. Uploaded. . -- OdyX signature.asc Description: This is a digitally signed message part.
Re: RFS: jabber-querybot
On Tue, Nov 22, 2011 at 01:56:48PM +0100, Jakub Wilk wrote: What is the purpose of the postinst script? It looks like it's violating policy 12.3, 10.7.2 and 10.7.3. Thanks Jakub for the heads'up (given that the postinst is in unstable, you might want to reportbug that…) This package in every case need hands on from the user. The only purpose of postinst is: User get back a correct error message from the package binary instead of a perl compilation error. Do you have a have suggestion? Either: - make sure no error happens if no file exists under /etc/jabber-querybot/, - make sure that the error message is meaningful, - make sure the process is well-documented, - install that file (instead of symlinking) under /etc/jabber-querybot Cheers, -- OdyX -- 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/20221833.13975.o...@debian.org
Re: RFS: jabber-querybot
Le mercredi, 9 novembre 2011 14.01:17, Marco Balmer a écrit : Dear mentors, I am looking for a sponsor for my package jabber-querybot. I would be glad if someone uploaded this package for me. Uploaded; thanks for your work! (I'm not sure I would have written the postinst that way, but it looks fine so.) Cheers, -- OdyX signature.asc Description: This is a digitally signed message part.
Re: RFR: wader, a ModemManager replacement
Alex Chiang wrote:
wader-core - alternative D-Bus service for managing modems
Long description:
A drop-in replacement for modemmanager and alternative implementation of
the ModemManager API, with extensive support for many UMTS devices,
simple plugin system for supporting new devices, robust USSD stack,
multipart SMS, MMS reception, extensible AT engine, handles binary SMS
cleanly, and can provide a Python shell to interact with a device during
runtime. .
If your 3G device does not work well with ModemManager, you may wish to
try wader-core as an alternative.
Hi Alex,
Without looking at the contents of this package, but after reading trough
the #492875 ITP bug, I still can't see a complete enough answer to what
does it do that _can't_ be done in modemmanager ?
So, let's ask again: ;-)
What does wader{,-core} do that can't be done in modemmanager?
Cheers,
OdyX
--
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/j9s1r0$6dr$1...@dough.gmane.org
Re: RFS: aspsms-t
Le vendredi, 4 novembre 2011 17.17:34, Marco Balmer a écrit : I had to read some documentation how to split packages. So here are my new version. Aspsms-t is splittet into aspsms-t and libaspsms-perl package. dget -x http://mentors.debian.net/debian/pool/main/a/aspsms-t/aspsms-t_1.3.0-1.dsc I would be glad if you can review again and give me feedback. Thx Hi Marco, and thanks for your work towards packaging aspsms. unfortunately, I have never packaged anything perl'ish and don't intend to (for now, eh…), so I really think you should try to find a more perl'ish sponsor, hence CC'ing debian-perl@l.d.o. Sorry again, and cheers, -- OdyX signature.asc Description: This is a digitally signed message part.
Re: RFS: fadecut
Le lundi, 17 octobre 2011 16.17:32, Marco Balmer a écrit : Dear mentors, I am looking for a sponsor for package: * Package name: fadecut Hi Marco, and thanks for your continuous work both upstream-wise and for the packaging of fadecut in Debian. I would be glad if someone uploaded this package for me. I just built it and although it built correctly (buildlog attached), I think there are some things that should be changed: There are many mkdir: cannot create directory `/sbuild-nonexistent': Permission denied those indicating that the build process tries to access /home, which it should really not. Also ./fileprocessing.sh: line 34: /sbuild- nonexistent/.fadecut/profiles/fctest_fileproc_mp3: No such file or directory And all-in-all, it seems that make test fails or doesn't do anything useful within the buildprocess; it really should. Cheers, -- OdyX fadecut_0.1.1-1-amd64-20111020-1422.gz Description: GNU Zip compressed data signature.asc Description: This is a digitally signed message part.
Re: RFS: jabber-querybot
Le vendredi, 14 octobre 2011 11.40:16, Marco Balmer a écrit : Dear mentors, I am looking for a sponsor for a my new debian package: * Package name: jabber-querybot Hi Marco, and thanks for this new package, indeed probably useful to have in Debian ! Now on for the review: * the debian/copyright file seems to be aspsms-t's . :-) And you should use the versioned shortname for the GPL (e.g. GPL-2+, as in http://dep.debian.net/deps/dep5/#AEN462 ). You can drop the name from the liense paragraph and then copy-paste it to your various debian/copyright files. * I don't find the long description particularly descriptive as it basically tells us Jabber bot framework for Perl (does Perl need Jabber bots ?), from swissjabber (hi there !), now opensource (if it's in Debian (main), it's freesoftware, so this doesn't add much value), simple and nice piece of code (that's entirely subjective). Additionally, the short description is read as jabber-querybot is a Modular xmpp/jabber bot. So is jabber-querybot an actual bot or a framework to write bots? I think a think-trough and rewrite of both descriptions would be good, while keeping [DP§3.4] in mind. * As jabber-querybot was never in Debian, you should merge the initial changelog entries in order to only have one when the package enters NEW. While this is mostly a taste reason, I think it's pretty much common-practice to only have and keep changelog entries for versions that have actually reached the Debian archive. If you do upload those packages to other archives, then it might make sense to name those differently from unstable. And make sure to remind your sponsoree to use the -v option of dpkg-genchanges in order to have the ITP bug referred in the changes file. (So short version of that is: would be good although not necessary if it comes with a nice rationale.) Cheers, OdyX [DP§3.4] http://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions signature.asc Description: This is a digitally signed message part.
Re: RFS: aspsms-t
Le vendredi, 14 octobre 2011 11.31:25, Marco Balmer a écrit : Dear mentors, I am looking for a sponsor for a my new debian package: * Package name: aspsms-t Hi Marco, and thanks for this new package, indeed probably useful (too) to have in Debian ! So here's my review: * debian/copyright: same remark as jabber-querybot's: you probably want to use GPL-2+, otherwise OKay. * Again (and sorry, eh…), I don't find the descriptions of tremendous quality: e.g. the first paragraph of the long description is not even a sentence; the rest is more descriptive of technical internals than tool caracteristics. As machine administrator, when reading the description, I want to know what this package does as a whole; details of transaction numbers for delivery notifications are probably more suitable in documentation than in description. * Library splitting: Not knowing much of perl (you should maybe contact [pkg- perl] to get better opinions), I wonder if the bunch of files under /usr/share/perl5/ASPSMS/ would not be best suited in a separate libaspsms-perl package, don't know. Cheers, OdyX [pkg-perl] http://pkg-perl.alioth.debian.org/ signature.asc Description: This is a digitally signed message part.
Re: RFS: fadecut
Le jeudi, 20 octobre 2011 17.30:40, Marco Balmer a écrit : Thanks Didier for checking my package. Make test (testing suite) runs not proper at the moment. I disabled it and re-uploaded the package: http://mentors.debian.net/package/fadecut Thanks; uploaded ! Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Using dh to build 1 binary package with different configure options
Gergely Nagy wrote: If you're using short form dh, this would be one way to do it: override_dh_auto_configure: install -d debian/build-gtk2 cd debian/build-gtk2 ../../configure --with-gtk2 install -d debian/build-gtk3 cd debian/build-gtk3 ../../configure --with-gtk3 override_dh_auto_build: cd debian/build-gtk2 make cd debian/build-gtk3 make override_dh_auto_install: cd debian/build-gtk2 make install \ DESTDIR=$(CURDIR)/debian/pkg-gtk2 cd debian/build-gtk3 make install \ DESTDIR=$(CURDIR)/debian/pkg-gtk3 And from this point on, it's just standard dh. I'm doing it slightly differently, using the --builddirectory parameter of dh: -- debian/rules abstract - override_dh_auto_configure: o_d_auto_conf_a o_d_auto_conf_b o_d_auto_conf_a: mkdir -p build-a dh_auto_configure --builddirectory=build-a -- \ --with-a-specifics o_d_auto_conf_b: mkdir -p build-b dh_auto_configure --builddirectory=build-b -- \ --with-b-specifics -- debian/rules abstract - Then mimick this at least in : override_dh_auto_build override_dh_auto_install override_dh_auto_test And add rm -rf build-* to override_dh_auto_clean. -- 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/j22puu$88a$1...@dough.gmane.org
Junior packaging tasks within the Debian Printing Team
Dear prospective maintainers, As packaging in teams and work on specific areas of Debian is often (and rightly so) preferred to one-shot pet-package sponsoring, I would like to propose 4 relatively easy packaging tasks. The global goal of those packaging tasks are: * to make sure Debian provides more printer drivers (this eliminates the need for hand-installation of drivers) * to offer low-barrier entry-points for newcomers to packaging; * to get new blood onboard the Debian Printing Team and in Debian in general. For all the following packages; those are the common tasks: * Make sure to have an ITP filed, and have the eventual RFPs renamed correctly. * Check their DFSG-freeness. * Packages have to be checked against latest Policy, so eventually updated. (lintian -ivI --pedantic with explained and reasonable exceptions is a good goal.) * Packaging is preferably done in git, under collab-maint. Bonus points if the history of the package is reflected in the packaging repository. (master/upstream/pristine-tar git workflow is preferred). === Merge two drivers back to Debian === Currently, two drivers have been available in Ubuntu but got never synced to Debian: m2300w pxljr For these two, the following additional tasks have to be handled (first): * Contact the current Ubuntu maintainers to ask them if they would be interested in (co-)maintaining the package directly in Debian. === Package two drivers for Debian === Currently, two drivers have been added to recent new foomatic-db entries: rastertosag-gdi c2esp For those, the packaging has to be done from scratch. === Feedback and upload === For those 4 packages, I will happily provide feedback on packaging techniques, processes, etc. More globally, I will make sure to mentor the person taking the challenge and guide him/her until the package gets out of NEW (including sponsoring the package; of course). I will also happily mentor and sponsor subsequent uploads of those packages. === Candidate ? === Anyone willing to get involved in making Debian better on the long term (having DM and/or DD statuses in sight is good), ready to maintain said packages on the long-term, with reasonable preliminary knowledge of the Debian Policy, packaging techniques and git usage can apply. (If you think you don't qualify, then don't be shy and apply anyway!) A candidate owning or having access to a printer needing the given driver is a big bonus; of course. Please answer to debian-print...@lists.debian.org mentioning the package(s) you would like to care about and/or talk to me over IRC in #debian-printing on irc.debian.org. Looking forward for collaboration, cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: RFS: uthash (updated package)
Bastian Blywis wrote: Dear mentors, unfortunately I got no replies to my RFS so I am trying again and give some additional information as motivation. Sponsoring the uthash package should be hassle-free because: (…) Hi Bastian, Is this the package: http://mentors.debian.net/debian/pool/main/u/uthash/uthash_1.9.3-1.dsc ? If it is that package, I have some questions (un-ordered, written as things went under my radar): 1) Why is the README file modified directly ? You should use a patch system (quilt or dpatch) for this purpose lintian: uthash source: direct-changes-in-diff-but-no-patch-system README 2) Is there a reason you are choosing source format 1.0 ? (I'm not insisting on changing to 3.0, but no reason is mentionned in the debian/changelog.) 3) Have the intermediate upstream versions been uploaded somewhere ? Your debian/changelog mentions several versions targetted to unstable, but I can't see those have been uploaded to the Debian archive. Usually (and I will insist on that), each entry in debian/changelog corresponds to one upload to the Debian archive. 4) the bashism you mention is _very_ easily fixed by s,/bin/sh,/bin/bash, (possibly using the patch system you need to start using to fix 1) ) I don't see a reason not to fix it: it is shipped in the examples of your package and will fail when run by the user. 5) you did several un-documented changes to your package: you changed your e-mail address, you bumped the Standards-Version, you updated the description, you converted the package from 3.0 (quilt) to 1.0 (eh, see 2) above), you dropped the manpage, … All those changes _have_ to be documented in the debian/changelog file. If you fix 1), 3), 4) and 5) and explain 2) to me, I would be happy to sponsor this package for you. Cheers, OdyX -- 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/ir575h$rbr$1...@dough.gmane.org
Re: Bizzar error with dpkg-buildpackages
Michelle Konzack wrote: Can I use e.g.: 1.20-29 - unstable (source included) 1.20-29b1 - stable/squeeze 1.20-29b2 - oldstable/lenny I was thinking there could be an upgrade problem later if I use this or is there a special naming scheme for multi-release? (I know, there was a discussion some years ago, but I do not know its result) Policy documents this, but… You can use the ~ character as indicator of sorts before. And using release codenames is often clearer (see e.g. the requirements for backports or stable updates. In your case 1.20-29 - unstable 1.20-29~squeeze1 - stable/squeeze 1.20-29~lenny1- oldstable/lenny 1.20-29~lenny1 1.20.29~squeeze1 1.20-29 Note that this works because squeeze sorts alphabetically after lenny. Now that we will release Wheezy, it will get harder to choose release codenames (as they should [for convenience] sort after wheezy). Cheers, OdyX -- 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/ing1qm$5ru$1...@dough.gmane.org
Re: RFS: ulatencyd - Daemon to minimize latency on a linux system using cgroups (2nd try)
On Sunday 13 March 2011 20:45:46 Alessandro Ghedini wrote: Ping? The new version of the package (0.4.10) is on mentors.d.n: - URL: http://mentors.debian.net/debian/pool/main/u/ulatencyd - Source repository: deb-src http://mentors.debian.net/debian unstable main - dget http://mentors.debian.net/debian/pool/main/u/ulatencyd/ulatencyd_0.4.10-1. dsc Cheers Hi Alessandro, sorry for my big delays, I didn't thought copyright review would be that boring… :-) Anyway, as I found no more comments to your package, I just uploaded it to the NEW queue, where it will sit in some moments. Regards, OdyX N.B. For future uploads, you can contact me directly (without CC'ing - mentors), I'd be glad to sponsor future uploads for you. signature.asc Description: This is a digitally signed message part.
Re: RFS: usb-modeswitch (updated package) - Done
Didier 'OdyX' Raboud wrote: Dear mentors, I am looking for a sponsor for the new version 1.0.2-1 of my package usb- modeswitch. madduck uploaded it. Thanks ! Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: mount-systray
Juan Jesús Ojeda Croissier wrote: Dear mentors, I am looking for a sponsor for my package mount-systray. * Package name: mount-systray Version : 0.5.2 Upstream Authors : Roberto Majadas telem...@openshine.com, Alvaro Peña a...@openshine.com * URL : http://launchpad.net/mount-systray * License : GPL-2 or later Section : gnome It builds these binary packages: mount-systray - Systray applicacion for umount devices easy Hi Juan, in debian/control: * your short description doesn't sound english. I'd write as something like System tray application to mount and unmount devices easily. * the field XSBC-Original-Maintainer is non-sense for Debian (in Ubuntu, it mentions the original Debian Maintainer for the package, which _you_ will be. * Your Standards version is outdated. Other things: * The package was in Ubuntu Jaunty but isn't anymore. Why and why would you like to include it in Debian now? * The version numbering is for native package without reason. * You are uploading to jaunty which does not exist in Debian. * Your README.Debian is empty. Finally, your package seems to be intended to be uploaded to Ubuntu but went to Debian somehow. Actually, I don't give any chance for it to be uploaded - read the docs and correct at least all the above glitches, make it pass lintian -iI and come back with a fixed package. Regards, Didier Raboud -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS (take 2): libapache2-mod-authz-unixgroup
Hai Zaar wrote: The author has responded and added copyright, but not released another version for it, so its currently only in SVN trunk: http://code.google.com/p/mod-auth-external/source/detail?r=62# Can I just add this as a patch to a current release? If necessary, I would rather be clean and go for a 3.2.3+svn62-1 Or bug upstream again for a 3.2.3.1 or 3.2.4 release. Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug 510765 won't appear as closed
Rodrigo Gallardo wrote: Can someone help me understand why 510765 keeps on appearing on liferea's bug page? It's been closed in all the relevant versions, and the little graph on the left shows nothing but green boxes, but everything (the bts, the pts, my qa page) show liferea as having 1 open rc bug. Hi, AFAIK, the correct way of closing bugs is a mail to #-cl...@bugs.debian.org or #-d...@bugs.debian.org. By making a versioned done- (Version: 123-1 as first line), you can also tell from which version the bug is fixed. Regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ozerocdoff
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. I just overwrite this prebuilt binary in the building process. It voids the need for a orig.source repack. Best regards, Didier -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFS: ozerocdoff
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. 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 ? Best regards, OdyX -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Compiled easter egg in a arch:all package
Bertrand Marc wrote: Hi mentors, I'm currently trying to package PlayOnLinux (see ITP #485149) and there is one lintian error remaining. The program is written in python and bash, and is therefore arch:all. But upstream added an easter-egg in C in the archive, and a built version of the easter-egg. That is why I get this last lintian error : arch-dependent-file-in-usr-share. I have contacted upstream about this, and they say the easter-egg is not really important and is not part of the program. How would you handle this easter-egg ? Should I simply remove the built version ? Should I build it and make PlayOnLinux arch:any ? I guess the second solution would be a waste of buildd time, isn't it ? Regards, Bertrand Hi, Why not splitting the package in a playonlinux-common (arch:all) which would contain everything and a playonlinux (arch:any) which would contain the easter egg ? This would be sort of a tank to kill a fly, but if the easteregg is fine. :) For the buildds time, wine is in any case only packaged for i386 and amd64. Bye, OdyX N.B. I am not a Mentor. -- Swisslinux.org − Le carrefour GNU/Linux en Suisse − http://www.swisslinux.org -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
