Re: RFS: synconv
Hello again, On Sun, Dec 4, 2011 at 9:42 PM, Fernando Lemos fernando...@gmail.com wrote: On Sun, Nov 20, 2011 at 7:15 PM, Fernando Lemos fernando...@gmail.com wrote: Hello, On Fri, Nov 4, 2011 at 9:52 PM, Fernando Lemos fernando...@gmail.com wrote: Dear mentors, I am looking for a sponsor for my package synconv. * Package name : synconv Version : 1.1.1-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : https://github.com/fernandotcl/synconv * License : GPL-3+ Section : sound It builds those binary packages: synconv - rsync-like audio format transcoder To access further information about this package, please visit the following URL: http://mentors.debian.net/package/synconv Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/synconv/synconv_1.1.1-1.dsc It's been 16 days, and I'm still looking for a sponsor. Except for a lintian override (for a mispelling that's actually a command line option), this package is pedantically lintian clean. I'd be glad if someone could review and possibly upload it. It's been 2 more weeks, I'd be glad if someone took a look at this. Now it's been almost 2 months since my first message, I'm wondering if anyone would like to review this package for me: http://mentors.debian.net/package/synconv dget -x http://mentors.debian.net/debian/pool/main/s/synconv/synconv_1.1.1-1.dsc The package should be in good shape (it would be the third package I maintain in Debian). I followed DEP-5 (validated with config-edit) and used dpkg-buildflags to get hardened flags. The package is pedantically lintian clean, with an override for a typo that is, in fact, a command-line option. I'm fully aware of the undergoing boost 1.46 - 1.48 transition, and I have compiled synconv against 1.48 to make sure it won't be affected. Nevertheless, if it's a problem, I can wait for the transition to be over. Regards, -- 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/canvyna_qswjj2vf3v9bmhw7wbkq4fzm027pzgm6hadht5sg...@mail.gmail.com
Re: RFS: solarpowerlog (improved...)
Hello, On Sun, Jan 1, 2012 at 5:26 PM, Tobias Frost t...@coldtobi.de wrote: However, please go forward with the review of the package, and to ease things I'd appreciate if a DD steps forward and indicated his/her will to sponsor this package, to define clear goals and clear actions whats needed to get this package into debian and avoiding wasting effort by focused work. As a non-DD, here's a basic review: * There's trailing whitespace in debian/changelog, debian/rules and possibly other places as well (didn't check all files). * Your debian/changelog might be too verbose. You want to describe the changes since the last upload. Since it's a new package entering the repositories, you might want to use a single entry like Initial release (Closes: #1234). * I'd tweak the short description a bit. How about photovoltaic data logger instead? Take a look at the rsyslog short description for inspiration. * Get rid of debian/dirs. If you're installing to /usr/bin, you don't need to specify it [1]. * debian/rules has the sample header (Sample debian/rules that uses debhelper...) and some leftovers from sample comments. Get rid of them. * I only glanced over your rules file. Personally, I find short-form debhelper much easier to maintain and review, I'd highly recommend it. * There's a stray SEE ALSO section in your manual page. Take a look at man-pages (7) for further advice, there's a lot that could be improved in the manual page. Also, you probably want to submit it upstream so it's maintained in sync with the program it describes and can be easily used by people packaging the software for other distros. * You might want to enable hardening flags [2]. I didn't build or test the package. I tested the watch file, but as you described in the changelog, currently it doesn't work (not sure what would be the right thing to do in this case). Regards, [1]: http://www.debian.org/doc/manuals/maint-guide/dother.en.html#dirs [2]: http://wiki.debian.org/Hardening -- 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/canvyna8cgbabnko6uc-k8f6qvaeatn1mdxbnd7uvskzglse...@mail.gmail.com
Re: RFS: suckless-tools 39-1
Hello, On Tue, Jan 24, 2012 at 12:36 PM, Michael Stummvoll mich...@stummi.org wrote: I uploaded a new version of the suckless-tools package: * dropped st now, cause its maintained by the stterm-packe. * included sprop and lsx from the suckless-upstream into the package. * changed slock to not suid root but setgid shadow * changed to quilt sourceformat with multiple tarballs It would be fine if somebody can take a look at it. I'm not a DD and only did a shallow review, but it looks good to me. There are good alternatives to slock that use PAM (such as i3lock). Perhaps in the future you might want to drop slock entirely, I'm not sure how much inconvenience that would be. I noticed that some earlier reviews were all done in the BTS (precisely replies to your ITA, #647090). It would be nice if those reviews were Cc'ed to mentors, as I actually was in the middle of a review when I noticed some stuff had already been talked about there. :-) It would also be better if you posted the .dsc URL again, in special because you're not replying to the original e-mail that mentioned the URL. If someone wants to review it: http://mentors.debian.net/debian/pool/main/s/suckless-tools/suckless-tools_39-1.dsc Some more nitpicking: * The slock_shadow patch is not in DEP-3 format. * There's trailing whitespace in README.slock.Debian. * You might want to set more hardening flags (such as hardening+=all) to DEB_BUILD_MAINT_OPTIONS. * Typo in debian/changelog: Updatet. Thanks for working on this. Regards, -- 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/CANVYNa9eU2GiONBgGgNXfRc-Lh1gRx=jnoeg5+c1sdbnntw...@mail.gmail.com
Re: RFS: v8cgi (second try)
Hi, On Thu, Jan 26, 2012 at 5:44 AM, Ondřej Žára ondrej.z...@gmail.com wrote: v8cgi itself is implemented in C++ and has libv8 as its only dependency. It is developed at Google Code (http://code.google.com/p/v8cgi/) under New BSD Licence. Ubuntu packages are available from a Launchpad PPA (https://launchpad.net/~ondras/+archive/v8cgi). I'm not a DD, but the version in your PPA seems to be, unsurprisingly, a Ubuntu package. If you want to get it uploaded in Debian, the first step would be packaging and testing it in Debian unstable. Also, please mention the link to your .dsc file in your RFS message. Regards, -- 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/CANVYNa_jFUvsoUGKW+b+Cn2bYrxg59UErFFHfCh0mQAz=h8...@mail.gmail.com
Re: obsolete uploads to debian stable?
HI, On Sat, Feb 25, 2012 at 11:05 PM, Paul Elliott pelli...@blackpatchpanel.com wrote: Is there any archive where I can get obsolete superseded uploads to debian unstable? I need to get one for historical reasons. You mean something like http://snapshot.debian.org/ ? Regards, -- 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/canvyna9wx+bmokyswtk990tf4w22wngyofpl6bj4qqbu54f...@mail.gmail.com
Proper way to depend on an icon theme
Hello, I failed to find any documentation on how to properly depend on icon themes. After reading the fd.o icon theme specification[1], it looks like the specification doesn't cover what base icons must be present in a theme. That could mean that packages that use those specific icons need to depend on specific icon themes or provide their own icons, because there's no guarantee that any installed icon theme might come with the icons the package requires. Taking a look at some random examples in the repository, I see that network-manager-gnome depends specifically on gnome-icon-theme. That may be because only gnome-icon-themes are guaranteed to provide the necessary icons. On the other hand, the package arista depends on either gnome-icon-theme or 8 other specific icon themes. I can look at packages.d.o and check what packages provide the icons I need for the package I'm considering packaging, but this seems rather fragile. Is there anything else that can be done? If some basic icons could be guaranteed to exist, couldn't we abstract them into a virtual package? Pointers to references or any previous discussions are also greatly appreciated. [1]: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html Thanks in advance, -- 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/canvyna-uz56a0sa02kbbaiddf9p0mpvkas5n0j1q90n2nmu...@mail.gmail.com
Re: GraphLab Project
Hi, On Sat, Mar 3, 2012 at 6:32 PM, Mohammad Ali Rostami rostam...@gmail.com wrote: Dear All We are a group of students developing a software called GraphLab. GraphLab is a software framework to work on graphs and social networks. it consists of a graph library and a graph GUI. The library part is a framework designed for developing graph theory algorithms and testing graph conjectures. and the GUI part aimed to draw and visualize graphs and running algorithms on them. The program is based on plug-ins and extensions and provides a user friendly application platform to create scientific applications. By discussion in our group, we decided to put this software to the repository of Debian. Can anyone helps us to start with this issue? What are steps we should go through? Cool. Please follow the procedure described in the mentors FAQ: http://wiki.debian.org/DebianMentorsFaq#How_do_I_add_a_new_package_to_the_archive.3F Regards, -- 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/canvyna_6t3_8cgfov2ntryphw4bq-sbkbd8fbeof59fniym...@mail.gmail.com
Re: Proper way to depend on an icon theme
Hi, On Sat, Mar 3, 2012 at 11:22 PM, Paul Wise p...@debian.org wrote: On Sun, Mar 4, 2012 at 4:15 AM, Fernando Lemos wrote: [1]: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html I think you want this spec instead since it specifies icon names: http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html Yes, that's exactly what I was looking for. :-) If your package only uses icon names from this spec then I would suggest defining a fd-icon-theme (or similar) virtual package: http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt Then get lintian to check icon theme packages to make sure they Provide: fd-icon-theme. That would be perfect. Any tips on how to get this started? Should this be discussed in debian-devel, or perhaps debian-desktop? Thanks, -- 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/CANVYNa9MwV+FCLjqz4mgP+-OGF+FFqy-KjKSzng9y9-_dkb=_...@mail.gmail.com
Re: Proper way to depend on an icon theme
On Sun, Mar 4, 2012 at 9:08 PM, Paul Wise p...@debian.org wrote: On Mon, Mar 5, 2012 at 1:46 AM, Fernando Lemos wrote: That would be perfect. Any tips on how to get this started? Should this be discussed in debian-devel, or perhaps debian-desktop? The procedure is listed here: http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt Ah, damn, I somehow missed that... I was taking at the list, skipped the instructions, sorry. Your suggestion of debian-desktop is a good one, I would suggest you use that as a step 0 to get the right virtual package name to use before posting on debian-devel. Once the new virtual package is named and defined in virtual-package-names-list.txt then you will want to file a bug (with patch if you know perl) about it. The checks you probably want are: Provides the needed icon names for the fd.o icon naming spec but doesn't provide the freedesktop-icon-theme virtual package. Provides the freedesktop-icon-theme virtual package but is missing some icons. Depends on freedesktop-icon-theme, uses more icons than freedesktop-icon-theme but doesn't depend on a more specific icon theme. Other checks might be needed too, can't think of any more right now though. I think that's enough to get started. :-) Thanks once again, -- 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/canvyna8ojxpbsw2x6o+qxmprzjuj3gw58rb9f1l+jxjh6zy...@mail.gmail.com
Re: Request For a Review: python-mpd2/0.4.1-1 [ITP]
Hi, On Tue, Mar 20, 2012 at 3:26 PM, Geoffroy Youri Berret ef...@azylum.org wrote: Le 20/03/2012 17:00, Jakub Wilk a écrit : Your Replaces is versioned but Conflicts is not. This is awkward. What has changed in python-mpd 0.3.0 that Replaces is not needed anymore? Is the conflict with python-mpd going to be permanent, or do you plan removing the other package at some point? In the former case, priority of one of the packages should be extra. (Policy §2.5: “optional packages should not conflict with each other”.) First I thought python-mpd was abandoned, this is not true [0]. Then I guess what I should do is to not to set python-mpd2 as replacing python-mpd, just conflicting. Then I'm not sure about the control file. Priority: extra for the source package and Conflicts: python-mpd for python2 package only. Is that right? It looks like you originally intended to replace python-mpd with python-mpd2, eventually removing python-mpd from the archive and turning it into a transitional package or something like that. Have you discussed this with the current python-mpd maintainers? If so, report it in your RFS. If not, you'll have to go through that first. Forks that simply suffix 2 are a really poor idea. If the python-mpd2 project dies and later on python-mpd releases version 2.0, we get into an ugly and confusing situation (take a look at the RPM vs. RPM5 mess, for example). I recommend that you consider the following: * Is the python-mpd upstream unresponsive? It looks like Alexander will stop actively maintaining python-mpd soon, but he doesn't support the fork for a number of valid reasons that haven't been addressed in this RFS. * Does python-mpd2 have a reputable upstream? How long has it been maintained by this new upstream? It looks to me like it was just recently forked, and this is not a good sign. * Do all Python-based clients work with python-mpd2? Have you actually tested them? At first glance, it seems hasty to replace python-mpd with python-mpd2 now. If I were you, I'd try to address those concerns, letting the python-mpd2 upstream know about those concerns and doing some research on the reasons behind this fork and the consequences of replacing python-mpd. And, above all, please talk to the current python-mpd maintainers if you haven't done so yet. Unless they agree with this, you probably won't be able to proceed. Is there any reason for using a less liberal license for Debian packaging than the one upstream uses? The only reason is that I want to keep the package as free as possible. I did not see any reason to use the same license as upstream, is there? (policy or strong convention I'm missing) Yes, there is a very good reason. If you patch python-mpd2 and another maintainer in the future attempts to merge your contributions into the upstream project, he or she will be unable to do so due to the license conflict. So, unless you have a very good reason to use a more restrictive license for your contributions, I'd highly recommend that you keep the upstream license. Regards, -- 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/canvyna_on768-yq+ozbtf3mdd_mf+qn2qm7v70cuo+ndphg...@mail.gmail.com
Re: RFS: freefoam
Hi, On Thu, Mar 22, 2012 at 7:51 PM, Gerber van der Graaf gerber.vdgr...@gmail.com wrote: During the building on my box, the packages appeared to be lintian error free. Though, some warning / error messages showed up on the mentors site where the packages can be found, which I have commented. The That's a lot of lintian trouble... Make sure you're running lintian in a reasonable up-to-date sid install, and use lintian -i -I --pedantic. Regards, -- 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/canvyna-cngvws6c-cl7kxt_hkmsgharc-ckyw_c6zqlmtva...@mail.gmail.com
Re: Bug#659047: RFS: rpg - Readable Password Generator
On Sat, Apr 7, 2012 at 9:46 AM, Vladimir Stavrinov vstavri...@gmail.com wrote: ecosystem. Consider for instance that if one day you suddenly can not contribute anymore, somebody else will need to care of the package. Summed together, even removals takes time. It would be a nice behavior, if maintainer leaving Debian will take care about removal his own package after some period of inactivity. It's not just about that. Every package that goes into the archive results in a non-trivial increase in the amount of work for some other teams (the release team, the security team, the FTP masters, possibly more), not only for the package maintainer. Also, removing packages isn't always the answer. There are specific criteria that lead into removals[1], and even then you can't force maintainers to request removals before they leave Debian. You seem to have an overly simplified view of how the distribution works. Now, about the package in question. The alternative software currently in the repositories is apg, which seems very popular[2]. In order to get your package sponsored, you'll need to address some concerns. First, If you're proposing a different algorithm for password generation, have you looked into contributing the algorithm to apg? If not, why? Writing software from scratch is very often not the right solution, so you need to be prepared to explain to prospective reviewers and sponsors why you took that route. When you are the one trying to get the package sponsored, saying give it a shot yourself to prospective sponsors doesn't inspire confidence and won't cut it. Second, wouldn't it be better to let the software mature first, then consider packaging it? Several people in this thread pointed out problems with the software, and although you're active trying to address them (successfully or not), it's clear that there are issues that need to be ironed out. If the minimal amount of testing done by prospective sponsors reveals such problems, you might want to take a step back, make sure people use and report bugs on the software, and eventually get back to packaging it when it's in better shape. debian-mentors isn't about developing software. The software must be in a good shape and well tested before it can be packaged, otherwise uploading the package doesn't do the distribution any good. [1]: http://wiki.debian.org/ftpmaster_Removals [2]: http://qa.debian.org/popcon-graph.php?packages=apg Regards, -- 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/canvyna9aowfat0u2tu5q8yha-ra1mtg0wz5pj5cud8gpkhg...@mail.gmail.com
Re: Making packages available to Debian users (was: Bug#659047: RFS: rpg - Readable Password Generator)
On Sat, Apr 7, 2012 at 10:28 PM, Vladimir Stavrinov vstavri...@gmail.com wrote: On Sun, Apr 08, 2012 at 10:08:08AM +1000, Ben Finney wrote: barrier to entry there: Debian should be a coherent operating system Very good. But to keep system in coherent state You should not only build barrier on entry, but also remove packages that break such coherence. And this should be not only orphaned packages. I am using Debian for more then 10 years and know, it is big enough to include lot of garbage. As I understand it, being orphaned is not a required condition for removal, but rather an argument for removal[1]. You may believe we should consider removals more often, and that would be a valid concern, but it's not what is being discussed here. So I don't understand, why do You think my package is worse of those garbage and how it break coherence. That's nonsense. Once a package enters the archive, it's not trivial to get rid of it. It's thus reasonable that we want to make sure packages are in good shape for entry in Debian. It's also natural that we want to improve the quality of the distributed software over time. We have higher standards for packages entering the archive now, and that's great for the distribution. Instead, you should make these works available to people as Debian packages, but not argue for their inclusion *in* Debian until they have demonstrated a track record of being useful to numerous Debian users and What You mean? How to do this? And were this track record will be seen? It is already available as Debian packages on sourceforge. And what further? numerous Debian users will seek it there? It sound like demagogy. You don't need to package a software outside Debian as a precondition for inclusion in Debian. I think what Ben means is that Debian shouldn't be treated as a simple distribution channel. Remember that packaging for Debian is a way to contribute to Debian and its community. Although it brings exposure to the upstream projects as a side-effect, packaging for Debian is an end in itself. Please note I don't mean to infer the reasoning behind your desire to contribute to Debian. That's getting it backward. Instead, maintain them as publicly-available works, ensure their maintenance as distinct useful packages, and only then advocate for their inclusion in Debian. Hey, what do You talking about? I don't sell You elephant or space shuttle. It is only tiny shell script as simple as toy. As we already mentioned in the original thread, every single package uploaded to the archive brings a maintenance overhead that is not directly linked to the package maintainer. By comparing your package to a toy, you're grossly simplifying the consequences of the inclusion of a package that may not be fit for Debian. This way You can kill any desire to join Debian. I begin understand something. I remember, few Years ago one Japanese employer refuse accept me for only one reason, because I like Debian too much. Nobody here intends to discourage contribution. The review process is part of improving the quality of the packages we ship. Understanding and accepting that is key to getting your package sponsored. If your package doesn't adhere to our quality standards, it probably shouldn't be uploaded. I understand your frustration, but there's no way around the review process. [1]: http://ftp-master.debian.org/removals.html Regards, -- 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/canvyna_kko59bdfz1_gwuzhblvfpsxzbd5urvfzqsbpkpda...@mail.gmail.com
Re: Making packages available to Debian users
On Sat, Apr 7, 2012 at 11:20 PM, Vladimir Stavrinov vstavri...@gmail.com wrote: On Sun, Apr 08, 2012 at 11:48:27AM +1000, Ben Finney wrote: So I don't understand, why do You think my package is worse of those garbage and how it break coherence. I don't have a position one way or another on whether any of your packages is worse than others. I'm saying you are receiving resistance OK, but what about garbage? To be consistent, You should clean up it. Are You doing so? The fact that we right now may be shipping packages in bad shape (or whatever you call garbage) is no excuse to accept more packages in bad shape. Please accept the criticism you may receive, the review process won't go away. Regards, -- 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/canvyna9iaxkyjt9st0359zlqaa+gfrpo-jwsereibnrf5bo...@mail.gmail.com
Re: Help needed [Was: Bug#667325: plink: ftbfs with GCC-4.7]
Hi, On Sun, Apr 22, 2012 at 5:37 PM, Dmitry Nezhevenko d...@inhex.net wrote: As you can see, there is nested declaration here. It's wrong. Looks like this code was working due to some GCC bug. Other compilers forbids this too. To expand/clarify, this is not a nested declaration, but rather a redefinition of a variable that was declared in the same scope. Redefining variables in different scopes is fine. So if i were declared outside the scope of the for loop, this would be okay (this is called shadowing). Apparently, g++ up to 4.6 considered the scope of a variable declared in a for loop to be the outer scope, instead of the inner scope[1][2]. This explains the problem. [1]: http://gcc.gnu.org/gcc-4.7/porting_to.html [2]: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2288 Regards, -- 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/canvyna8uxb_qnzp8xkvnnjdndfquzfcnepvrzgkpzpe7ota...@mail.gmail.com
Re: mounting cdrom by ordinary program
On Sun, Sep 12, 2010 at 4:59 PM, Paul Gevers p...@climbing.nl wrote: Hi all, With upstream of daisy-player (ITP: #595292) I am working on getting a Daisy player for Daisy talking books into good shape. I am having concerns about the current hack of upstream to ensure the program is able to read from a cd. The upstream source contains one udev rule to create a daisy-player link to the cdrom device and in the run parameter it adds a line to /etc/fstab allowing everybody to mount the cdrom. When daisy-player is run without options, it tries to mount the device and plays from it. I don't believe this is the way to do it, but I have not found yet what is appropriate in this case. I would appreciate some hints to what to do to obtain the desired effect, i.e. that the program can automatically read from cdrom if present. Hey, UDisks (formely known as DeviceKit-disks) uses PolicyKit to authorize several operations on disks and optical media. It can be configured to allow any user to mount storage devices (ranging from USB drives to CDs and beyond) without root privileges. In fact, the Debian package (udisks) allows you to mount those devices without root privileges by default. You might want to take a look at the udisks-mount manual page. Hope this helps, -- 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/aanlktinxsafz7yzgbfb_vbmpzzhusrfgxobr5pztj...@mail.gmail.com
RFS: btag -- interactive command-line based multimedia tag editor
Dear mentors, I am looking for a sponsor for my package btag. * Package name: btag Version : 1.0.0-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : http://github.com/fernandotcl/btag * License : BSD Section : sound It builds these binary packages: btag - interactive command-line based multimedia tag editor The package appears to be lintian clean. The upload would fix these bugs: 594749 My motivation for maintaining this package is: I don't tag my music often, but when I do, it's a tedious task. btag makes it easier for me, and I think other people might be interested. Having the package in Debian would also mean more exposure to the project, and that's always welcome. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/btag - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/btag/btag_1.0.0-1.dsc I would be glad if someone uploaded this package for me. Kind regards Fernando. -- 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/aanlkti=h5u7uzv0ubpkvrryd-bjb1c+vjk1cvs7na...@mail.gmail.com
Re: RFS: btag -- interactive command-line based multimedia tag editor
Hey David, On Tue, Oct 5, 2010 at 2:10 PM, David Bremner brem...@unb.ca wrote: I'm not a DD, but hopefully this review can make it easier to sponsor your package. Thanks for your input, it's really appreciated. - It should be documented what extensions/formats are supported. I tried some m4a's and it didn't work. Probably this should be in the long description. You're right. I've adapted btag to use the list of supported extensions supplied by TagLib instead of using hardcoded file extensions. This means btag 1.0.1 should now support every format TagLib supports. I've updated the long description to reflect this. - The file LICENSE has one COPYRIGHT HOLDER in it that looks like it should be replaced. This is probably a minor thing to be reported to upstream. Indeed. I've fixed that upstream, it's fixed in 1.0.1 too. I've packaged 1.0.1 and uploaded it to mentors.debian.net. I'm still looking for an sponsor, so here's an up-to-date RFS template for the sake of completeness: * Package name: btag Version : 1.0.1-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : http://github.com/fernandotcl/btag * License : BSD Section : sound It builds these binary packages: btag - interactive command-line based multimedia tag editor The package appears to be lintian clean. The upload would fix these bugs: 594749 My motivation for maintaining this package is: I don't tag my music often, but when I do, it's a tedious task. btag makes it easier for me, and I think other people might be interested. Having the package in Debian would also mean more exposure to the project, and that's always welcome. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/b/btag - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/b/btag/btag_1.0.1-1.dsc I would be glad if someone uploaded this package for me. Kinds regards, Fernando. -- 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/aanlktinv9ewsams1yvx+x_bg4aagpqeq9jpew3sw6...@mail.gmail.com
Seeking advice on automounter-like daemon starting at boot
Hello, mentors I'm looking for some advice on my ITP[1]. udisks-glue[2] is a replacement to some of the functionality provided by halevt/ivman, but it uses udisks instead of HAL (HAL is not actively maintained anymore). So I'm trying to package it the same way halevt does it: providing simple automount support out of the box. So far, so good, it's working (but I have not uploaded it anywhere yet). But my concern is that running it as root might not be the best idea. halevt, for example, creates the user halevt and installs a HAL policy to allow the default config to automount devices via halevt-mount. udisks-glue doesn't need to do anything fancy like that because it uses PolicyKit for authentication and udisks is well integrated with PolicyKit (meaning you can run udisks --mount without root privileges out of the box). I could make udisks-glue run as another user (say, nobody), but that would mean that the default config would not be able to mount devices. That's because PolicyKit will only allow udisks to mount devices if the user is a local user (logged in to ConsoleKit via ck-launch-session, the PAM connector or GDM) or the root user. I *think* I could provide PolicyKit policies to allow an user created by udisks-glue to mount those devices without root privileges, but I have no idea where to look for examples on how this might be done. I also don't know if it's worth the effort. Any tips on how I should proceed? There's no other udisks automounters in Debian (there's a PPA package for [3], but it doesn't have an init script or a system-wide configuration file). I see the following options: a) Submit the package as it is, i.e., with udisks-glue running as root b) Run udisks-glue as root, but don't start the init script by default c) Get rid of the init script, but keep the system-wide configuration file d) Create an user udisks, add a PolicyKit rule to allow it to mount device files, use that for the init script (not even sure it's possible) Suggestions are greatly appreciated. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594746 [2] http://github.com/fernandotcl/udisks-glue [3] https://code.launchpad.net/~pitti/udisks-automounter/trunk Regards, Fernando -- 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/aanlktinrgdwwicju=ixqdjirjay42gj=eydqbrg_s...@mail.gmail.com
Re: Seeking advice on automounter-like daemon starting at boot
Hi Gustavo, On Mon, Oct 18, 2010 at 3:19 AM, gustavo panizzo gfa g...@zumbi.com.ar wrote: d) Create an user udisks, add a PolicyKit rule to allow it to mount device files, use that for the init script (not even sure it's possible) how would it leave the file permissions on the mounted filesystems? Would them be readable/writable by local users? i was referring to option D if the udisks user has plugdev (or something like that) as primary group and the filesystem is mounted with umask 220 it should work (if the local user is part of plugdev group) By default, not even an user in the plugdev group can mount with udisks --mount. You really need to have an active ConsoleKit session, it seems (see /usr/share/polkit-1/actions/org.freedesktop.udisks.policy). It might be possible to set up a policy to override this and make users in plugdev able to mount non-system devices, but that would be wrong in so many ways. As for the umask of the mounted filesystem, that's perhaps not so much of a problem. udisks --mount has an option --mount-options that can probably be used to supply options like umask=022. But still, the user running udisks --mount would need to have plugdev as its login group, and root obviously doesn't. That alone wouldn't solve the problem of running udisks-glue as root, either. The mount point is also determined by udisks, so it's not like I could (or even should) create it first and assign the right permissions. I don't even know if there would be a way to accomplish d) at all without introducing a major security hole. After all, it seems that a daemon such as udisks-glue, which ultimately relies on ConsoleKit for authorization (through udisks and then PolicyKit), isn't easily retrofitted into a structure that isn't session-aware. I'm leaning towards c) (keeping the configuration file around but not installing any init script). Would that be acceptable? Thanks in advance, -- 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/aanlkti=vanyqs4=j35_jpakrl6hjzgaje9ko9nbbe...@mail.gmail.com
Re: RFS: minidlna
Hi, 2010/10/15 Benoît Knecht benoit.kne...@fsfe.org: Dear mentors, I am looking for a sponsor for my package minidlna. I'm not a DD or a DM, but here's my (very superficial) review, as I'm mildly interested in this package. * It seems that you are missing Build-Depends on libavcodec-dev and libavutil-dev. * lintian -I is mosly clean, except for: I: minidlna: spelling-error-in-binary ./usr/bin/minidlna Psychadelic Psychedelic I believe that's really not a big deal, though (you might want to let upstream know anyways). Regards, -- 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/aanlktincsuxnx5tt9z9rxtra6bscd1khqz3=oqpab...@mail.gmail.com
Re: RF[CS]: ubiquity (mozilla extension) in Debian
On Tue, Oct 26, 2010 at 2:17 PM, Luca Falavigna dktrkr...@debian.org wrote: Il 26/10/2010 17.49, Gabriele Giacone ha scritto: I'd like to keep ubiquity, name chosen by upstream. And it's good because there are no packages named ubiquity in Debian. Derivatives can choose their own package names. Just to avoid some people complaining, I asked Ubuntu Archive Administrators to include ubiquity into their sync-blacklist list, so Ubuntu package won't be overwritten by accident. This has been just accomplished, so it's much safer using ubiquity as source name now. Anyways, wouldn't it be wiser to just rename the source package to ubiquity-extension for future proofing? Right now having the Ubiquity installer in Debian doesn't make much sense, but who knows. The Ubiquity installer actually predates the Mozilla project too. Renaming packages after they get into Debian is much more work. Regards, -- 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/aanlktik2r9vnzk2amfghq7sb8jlht1hfm_tsiyp0k...@mail.gmail.com
Re: RF[CS]: ubiquity (mozilla extension) in Debian
On Sat, Oct 30, 2010 at 2:31 PM, Gabriele Giacone 1o5g4...@gmail.com wrote: Given that you're interested in ubuntu packages, you could have learnt what happens if source package name already exists and how to manage that on ubuntu side: I guess blacklisting as requested by Luca then probably renaming to ubiquity-whatever. How about time spent doing that rename instead of writing to d-mentors? That harsh attitude towards people trying to help you certainly makes your request for sponsoring look really good. Well done. -- 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/aanlkti=cvnbrvhz8fbgh9qugejltowdzsxqv+kzjp...@mail.gmail.com
Re: RFS: fritzing
Hi, 2010/10/31 Enrique Hernández Bello ehbe...@gmail.com: This is your first release, and version 0.4.3b-1 makes sense to me as the first debian packaging released. If I don't increment the release number, I can't upload it to mentors repository. What do you suggest? What is the common way to version a pre-release package? Perhaps adding a suffix like ~mentors1? Hmmm why can't you? I'm pretty sure I did that last time. Just dput, it'll overwrite whatever was there. Regards, -- 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/aanlktimfni+p1qdikjszdv0zhqa6k3e2nvsh8zy30...@mail.gmail.com
Re: RFS: mediadownloader
Hey, On Mon, Nov 1, 2010 at 9:09 PM, Marco Bavagnoli lil.dei...@gmail.com wrote: One question: when and if the package will be clear, will I need to delete the old package ? Or just make version 1.4.2-2 ? Keep the version intact (1.4.2-1) and just dput it again. It'll overwrite the old package. Regards, -- 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/aanlktimeeozvhy_k3+bkx1=bvvxc3okfzskc4telz...@mail.gmail.com
Re: RFS: mediadownloader
Hi, On Tue, Nov 2, 2010 at 6:32 PM, Marco Bavagnoli lil.dei...@gmail.com wrote: I fixed most of the warning, but 1 of them and 1 information with a spelling error are still there. I run lintian -Ii on the .deb, as result I got this: W: mediadownloader: new-package-should-close-itp-bug Please fix this, it's quite simple. Your changelog should contain an entry (and generally only that entry) that says something like Initial release (Closes #1234) where 1234 is the number of the ITP bug report you filed in the BTS. I: mediadownloader: spelling-error-in-binary ./usr/bin/mediadownloader informations information It would be better to fix this. Just grep the source for informations, change it, make a quilt patch and warn upstream about the spelling mistake so that you can drop that patch in future releases. Regards, -- 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/aanlktim5fxewf88mbqrxnv1qwb0b2qhyherhyqjpd...@mail.gmail.com
Re: RFS: mediadownloader
Hey, On Wed, Nov 3, 2010 at 9:52 AM, Marco Bavagnoli lil.dei...@gmail.com wrote: the url on sf.net is this: http://sourceforge.net/projects/googleimagedown/files/ and source is named like mediadownloader_v1.4.2-src.tar.gz Is the watch file content correct ? Take a look at uscan(1), there are examples for SourceForge projects. Anyways, if it is working, you can use uscan do download the newest version (uscan --force-download). I: mediadownloader: spelling-error-in-binary ./usr/bin/mediadownloader informations information I found the spelling errors. I the about dialog window of the application, there is the GPL3 license text as in http://www.gnu.org/licenses/gpl-3.0.txt don't know if I can change it :) Well, the original license doesn't have the spelling mistake, so I guess you can correct it. Please let upstream know too. Regards, -- 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/aanlktima6sm3qic8_mtp-rkdjuulwsbwecaurzzsq...@mail.gmail.com
Re: RFS: wicd-client-kde
Hi, 2010/11/3 Iker Salmón San Millán sha...@esdebian.org: I also have a question. If we (me, mentors, sponsors, DD, upstream...) finally decide to change the name i guess i should send a new itp bug with the new name and close this one, shouldn't I? I believe you can just rename the ITP. Regards, -- 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/aanlktik-yjwlv=mcsyoupp1zepuckgiy5mwjtcytk...@mail.gmail.com
Re: Bug#602358: ITP: rtl8192ce-dkms -- Realtek RTL8192CE driver in DKMS format.
On Thu, Nov 4, 2010 at 2:13 PM, Reinhard Tartler siret...@debian.org wrote: is the fact that the package uses dkms relevant for the end user? it seems as an implementation detail of the package to me, so I'd suggest to drop that suffix. Not a good idea, seems like most (or all) DKMS packages current have the -dkms suffix (virtualbox-ose-dkms, blcr-dkms, nvidia-kernel-dkms, etc.). Regards, -- 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/aanlkti=dcpeqmohz+uktahe1axw=v4f0s6ru+ah0u...@mail.gmail.com
Re: RFS: wicd-client-kde
Hi, 2010/11/4 Iker Salmón San Millán sha...@esdebian.org: first i have to rename the ITP and i've been looking how to do it but i haven't found. Please read: http://www.debian.org/Bugs/server-control In short, write something like this to cont...@b.d.o: retitle 1234 RFP: My package here thanks You might want to set yourself as the owner of the bug entry as well if you aren't the owner. Regards, -- 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/aanlkti=utowguhgivca2=6zj9s_mj6jhz8gs=dyy5...@mail.gmail.com
Re: Dshield webhoneypot
Hi, Christian, On Tue, Nov 16, 2010 at 9:35 AM, w...@pohlcity.de wrote: [...] I already finished the package and tested it on my system. Now I'm in need of a sponsor to also test it, check it and upload it. Cool, please upload to http://mentors.debian.net/ or somewhere else and post the link so that others can review your packaging work. Regards, -- 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/aanlkti=3u35g79p-7wp8ocf=5oydipsy5zzanvv3-...@mail.gmail.com
Re: RFS: i2p
Hi, On Sun, Nov 21, 2010 at 7:20 PM, hungryh...@i2pmail.org hungryh...@i2pmail.org wrote: [...] Note: There is one lintian warning: W: i2p source: native-package-with-dash-version I think this warning appears because the .tar.gz doesn't have .orig in its name. I haven't been able to figure out how to get dpkg-buildpackage to put .orig in the name. Your package isn't supposed to be a native package, please see: http://wiki.debian.org/DebianMentorsFaq#WhatisthedifferencebetweenanativeDebianpackageandanon-nativepackage.3F Regards, -- 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/aanlktikzdaekogqtt-zqp88k-xwzq370e6wofba3e...@mail.gmail.com
Re: Package with complex dependencies -- where to start, where to end?
Hi Dave, On Tue, Dec 21, 2010 at 1:52 PM, Dave Mateer dave_mat...@ntm.org wrote: - The application will have very limited appeal -- it is implementing a specific workflow for our organization, whose users are spread out across the world. Most of the documentation I am reading assumes you are putting something into a standard Debian repository. Is that right, or should I set up some kind of local repository on our web server? Setting up your own repository is a good thing because you'll be able to simply tell your users to update to the current available version if needed. Most (if not all) steps you'll go through when packaging this application will be the same regardless of how you're going to make the packages available. - I have a dependency on Qt version 4.7.0+ (libqt4-core, libqt4-gui, libgt4-xml, etc.). The versions I need are in the experimental distribution. Making it work on an earlier version is not an option. There is at least one bug fix that, for performance reasons, will render our application useless pre-4.7. And we are taking advantage of some new APIs in 4.7 as well. How do I include this dependency? Is there something that says, it's OK to use the experimental distribution for this one? Or do I build it and package it myself, perhaps with a prefixed name (myapp-libqt4-core?) Also, we are building Qt from source with some configuration options (such as -plugin-sql-sqlite). Are those guaranteed to be in the official library once it becomes stable? How can one tell? Or do I just drop my own version of the binary library which I know will work into some private folder and be done with it? If so, what folder would that be? /usr/???/myapp, /opt/???/myapp Once Squeeze is out and the freeze is over (which will hopefully happen soon), some (or maybe most) stable software in experimental will be uploaded to unstable. Chances are that in a few weeks or months Qt 4.7 will hit unstable. If you need an specific version of Qt compiled with certain parameters, you can either include a copy of Qt in your source and build it together with your application, or created a custom Qt package (with a custom prefix or version) and specify a dependency on that custom package. Since this is not going to the official Debian repositories, you can relax the restrictions of the Debian Policy. - I also have a dependency on the ICU library, version 4.6. This is not even in the experimental distribution. So, the same questions apply. How to I include this dependency? Same thing, either create your own package or bundle it with your application, it's your call since it's a private package. - A high percentage (~50%) of our users will have to install from a CD; they will not have an internet connection at the time of install. It looks like once the packages are set up, I can use APTonCD and then provide instructions on making our CD a valid software source. Is that correct? It can be even simpler, I think you could just run dpkg -i /path/to/*.deb. Regards, Fernando -- 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/aanlktinqqyrb7wuyhixbbxdnlsnm+dvt_-uhybacc...@mail.gmail.com
Re: RFS: aescrypt
2011/1/16 mezgani ali hand...@gmail.com: What about README.Debian and README.source can i keep them empty and in the case when the tools comes with a readme.txt file ? [snip] Please make sure you read this (read it all if you haven't yet): http://www.debian.org/doc/maint-guide/ The things you are asking are documented there. Regards, -- 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/AANLkTim3hCMKS5f-amkW6r4eh+AXWyUF3qB7Bb6ijs3=@mail.gmail.com
RFS: udisks-glue
Dear mentors, I am looking for a sponsor for my package udisks-glue. * Package name: udisks-glue Version : 1.3.0-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : https://github.com/fernandotcl/udisks-glue * License : 2-clause BSD Section : utils It builds these binary packages: udisks-glue - associates udisks events to user-configurable actions The package is lintian pedantic clean, provides a decent manual page, uses source format 3.0 (quilt) and has DEP-5 formatted copyright (validated by libconfig-model-perl). The upload would fix these bugs: 594746 My motivation for maintaining this package is: HAL is probably going away sooner or later and so will tools that depend on it for automounting and similar use cases will be gone as well (halevt, ivman, etc.). udisks-glue can be a replacement for some uses of those tools. It's actively developed upstream and has seen a few releases already, with more planned. I'm upstream and I think others could benefit from this package. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/udisks-glue - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/udisks-glue/udisks-glue_1.3.0-1.dsc I would be glad if someone uploaded this package for me. Regards, -- 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/aanlktimknqxzmfaxitnnmay5zf-cy57mrg7alsnns...@mail.gmail.com
Re: Packaging Arbitrary Files
Hi, On Tue, Mar 29, 2011 at 3:56 PM, Aaron Todd tod...@gmail.com wrote: Thanks for responding! I've tried the conf.d file as well and it give me the same errors. In any case, I've have other custom config files that I am going to need to overwrite/customize so my main question still applies. How do I get past the overwrite issue. Don't even think about touching other package's files. For Apache, there's conf.d and other directories. Use those. You really can not do what you're trying to do the way you're describing, forget it, it's not going to happen. Regards, -- 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/AANLkTi=o_iub4R_xiV+2dhUQm+FpD=tvdbdxy7jfp...@mail.gmail.com
Re: RFS: udisks-glue
Hello, It's been a while, so this is my second try. Any comments would be really appreciated. Note you most likely want to use GDM in order to test this package for automounting (XDM, for example, won't create an active local ConsoleKit session without patching, which is required for mounting with udisks as non-root with the default configuration). TIA, On Fri, Mar 11, 2011 at 10:11 PM, Fernando Lemos fernando...@gmail.com wrote: Dear mentors, I am looking for a sponsor for my package udisks-glue. * Package name : udisks-glue Version : 1.3.0-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : https://github.com/fernandotcl/udisks-glue * License : 2-clause BSD Section : utils It builds these binary packages: udisks-glue - associates udisks events to user-configurable actions The package is lintian pedantic clean, provides a decent manual page, uses source format 3.0 (quilt) and has DEP-5 formatted copyright (validated by libconfig-model-perl). The upload would fix these bugs: 594746 My motivation for maintaining this package is: HAL is probably going away sooner or later and so will tools that depend on it for automounting and similar use cases will be gone as well (halevt, ivman, etc.). udisks-glue can be a replacement for some uses of those tools. It's actively developed upstream and has seen a few releases already, with more planned. I'm upstream and I think others could benefit from this package. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/u/udisks-glue - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/u/udisks-glue/udisks-glue_1.3.0-1.dsc I would be glad if someone uploaded this package for me. Regards, -- 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/AANLkTin0-seDAV5N3Aj7vw_DsTX4asau3c6_XFYt=y...@mail.gmail.com
Re: RFS: udisks-glue
Hi, 2011/3/30 Benoît Knecht benoit.kne...@fsfe.org: [...] I had a look at your package, and here are the small issues I noticed: - In debian/copyright, the Format header should contain the versioned DEP5 URL [1]. And you could avoid repeating the BSD-2-clause license text by using a standalone license paragraph. Also, you should not duplicate the Copyright line in the License header; this information is already in the Copyright header (I mean remove lines 10-11 and 38). I see, I'll fix that. [...] - You man page man/udisks-glue.1 contains a lot of information about the configuration file syntax; you might want to split into man/udisks-glue.1 for the command-line options, and man/udisks-glue.conf.5 for the configuration files (and reference each other in the SEE ALSO section). Speaking of sections, it's good practice to follow the section names given in man-pages(7) Sections within a manual page. That's an interesting idea. I'll update it upstream and patch the Debian package. Note you most likely want to use GDM in order to test this package for automounting (XDM, for example, won't create an active local ConsoleKit session without patching, which is required for mounting with udisks as non-root with the default configuration). Unfortunately I do not have a test system with GDM (or even X, for that matter) installed, so I didn't test it. It builds fine though, except for a few dpkg-shlibdeps warnings about useless linking (harmless, but you could look into it if you want). In fact, you can have udisks mounting stuff for you as non-root in the console too if you install libpam-ck-connector. :-) But nevermind. Thanks a lot for your review. In a couple days I hope to have some spare time to prepare a new upload. Regards, -- 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/AANLkTi=slksnfr90vyjc8h4wmvqtnascbee8pg8u7...@mail.gmail.com
Re: help creating a package (splitting a package and publishing it)
Hi, On Mon, Apr 18, 2011 at 8:17 PM, Reece Dunn mscl...@googlemail.com wrote: The project builds a shared library, two executables and provides development API headers. At the moment, the output is all built into one deb file. I want to break this up so that it complies with debian packaging rules but I am not sure how. Please see: http://www.debian.org/doc/maint-guide/ Do I need to add custom installation commands to the debian/rules file (in addition to what is provided by autotools)? If not, how do I get the shared library into the correct package? The document mentioned above explains it in detail, but most likely no, you don't need that. Do I need to become a Debian maintainer and upload the package to mentors.debian.net? The document mentioned above explains that too. You probably want to get it uploaded to mentors.debian.net so that it's easy for someone to review and upload your package for you. You can become the maintainer of a bunch of packages and not be a Debian maintainer. Or you may want to apply for the Debian maintainer role in the future when you're more used to the system and want to help out. Regards, -- 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/BANLkTin-Jx=xvb5+2haswp9bycyxhd_...@mail.gmail.com
Re: Request for sponsor: mactelnet
On 01.05.2011 02:06, Håkon Nessjøen wrote: I would really like for a DD to look at my package, and be my sponsor, as I am eager to begin as an active package maintainer. This is hopefully the first of many to come. I am no DD, so feel free to ignore my advises but I really like the idea of your package so I'd like to see it in Debian as well. Therfore I took a quick look on it. Here are some hints: Some other comments (non-DD review too): * In debian/rules, you probably want to get rid of the sample comments * In debian/rules, why exactly do you export DH_OPTIONS? * You might want to split the patches so it's easy to drop one of them individually when/if upstream accepts it (and you can then describe them better) * In debian-changes-0.3-1 you say Upstream changes introduced in version 0.3-1, but it doesn't look to me that all those changes are indeed upstream, you might probably push them upstream before you can claim they are upstream :-) * Check the Origin field in DEP-3, you might want to push the changes upstream and then point to the relevant commits using that field Regards, -- 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/BANLkTi,ryyaqi+srkg4es+5tm+e87...@mail.gmail.com
Re: Request for sponsor: mactelnet
2011/5/1 Håkon Nessjøen haakon.nessj...@gmail.com: On 1 May 2011 03:08, Fernando Lemos fernando...@gmail.com wrote: * In debian/rules, why exactly do you export DH_OPTIONS? This was added by the script, not me. So I have no idea. I don't think that's required, I don't remember dh_make ever doing that for me. Could be a different version, though. * You might want to split the patches so it's easy to drop one of them individually when/if upstream accepts it (and you can then describe them better) I don't know what you mean about splitting the patches, but if you are talking about the doc changes, they will be added upstream instead. What I mean is you currently have one big patch that does a lot of things. Instead, you should ideally have many small patches that do individual things (fixing specific bugs, implementing specific additional functionality). If you're doing those changes upstream, though, it's even easier, just get rid of the patches when you're done. You might want to review the section about quilt in the NM guide. * In debian-changes-0.3-1 you say Upstream changes introduced in version 0.3-1, but it doesn't look to me that all those changes are indeed upstream, you might probably push them upstream before you can claim they are upstream :-) That file, and more importantly, that line was added by the dpkg-source script. Not me. If you look at the changelog, I say no such thing. I see. You probably want to split the patches anyways, and use DEP-3 for bonus points (or just push them upstream). :-) * Check the Origin field in DEP-3, you might want to push the changes upstream and then point to the relevant commits using that field Origin (required except if Author is present) ? Author is indeed present. I'm not sure I understood you correctly. In DEP-3, the Origin field allows you to point to an upstream commit. Say you release 0.3, then find a minor issue and patch it upstream. You can package 0.3 in Debian and add a patch that points to that specific upstream patch through the Origin field: For patches backported/taken from upstream, it should point into the upstream VCS web interface when possible, otherwise it can simply list the relevant commit identifier (it should be prefixed with “commit:” in that case). For other cases, one should simply indicate the URL where the patch was taken from (mailing list archives, distribution bugtrackers, etc.) when possible. Regards, -- 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/banlktikzv96x4kaoe6yyomtlbz_xkbc...@mail.gmail.com
Re: RFS: minidlna (updated package and FTBFS fix)
2011/7/22 Kilian Krause kil...@debian.org: On Fri, Jul 22, 2011 at 12:36:51PM +0200, Benoît Knecht wrote: I am looking for a sponsor for the new version 1.0.21+dfsg-1 of my package minidlna. - dget http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.21+dfsg-1.dsc 1. Your upoad uses a tarball that's not identical to upstream's one. Please consider adding a get-orig-tarball target to debian/rules to verify what steps are required to generate it. Please take no offense, Benoît. But in such a case, Kilian, can you be sure the source hasn't been tampered with? I'd feel rather unconfortable otherwise. -- 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/CANVYNa-Jy6Fvvfn2k=yt6txkgz8d6-jhxwt_-+ednocckur...@mail.gmail.com
Re: RFS: minidlna (updated package and FTBFS fix)
2011/7/22 Benoît Knecht benoit.kne...@fsfe.org: Hi Fernando, Fernando Lemos wrote: 2011/7/22 Kilian Krause kil...@debian.org: On Fri, Jul 22, 2011 at 12:36:51PM +0200, Benoît Knecht wrote: I am looking for a sponsor for the new version 1.0.21+dfsg-1 of my package minidlna. - dget http://mentors.debian.net/debian/pool/main/m/minidlna/minidlna_1.0.21+dfsg-1.dsc 1. Your upoad uses a tarball that's not identical to upstream's one. Please consider adding a get-orig-tarball target to debian/rules to verify what steps are required to generate it. Please take no offense, Benoît. But in such a case, Kilian, can you be sure the source hasn't been tampered with? I'd feel rather unconfortable otherwise. I did tamper with the source, in the sense that I replaced the non-free icons.c file. This is documented in debian/copyright. I'm not sure what kind of tampering you're worried about, but you can easily check that no other file from upstream was modified. Again, no offense meant. I have no reason to believe anyone is acting in bad faith. Just to clarify, I find it concerning that we might be accepting source uploads that don't come straight from upstream and don't match what was released upstream. I'm relieved to hear that there is a way to ensure in your specific case that the source is the same as shipped upstream. I wish this was a requirement for new packages entering Debian. -- 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/CANVYNa_yUwOg58O5JjdF3Su75o3YNA4co48TkFK-=-h63+s...@mail.gmail.com
Re: Depends on -dev package
Hi, On Mon, Aug 22, 2011 at 12:59 AM, Paul Elliott pelli...@blackpatchpanel.com wrote: I quote from Debian Library Packaging guide 2. -DEV package dependencies The -DEV package would usually declare Depends: relationship on all -DEV packages for libraries that the library package directly depends upon, with the specific SONAME version that the library package is linked against. This includes libc-dev. [5] Does this mean that if my library has an include reference #include stdio.h in one of its .c or .h files, then my -dev package must have a depends line like this in its debian/control file: Depends: OTHER-STUFF, libc6-dev If that is the case, how come the the debian/control file for libtar_1.2.11-6 does not list such a dependancy? it includes stdio.h. You don't need to list explicity build-depend on anything already provided by build-essential. According to the policy[1]: Build-dependencies on build-essential binary packages can be omitted. There's even a lintian check for that. It's probably a bad idea to build depend on libc6-dev directly. [1]: http://www.debian.org/doc/debian-policy/ch-relationships.html#s-sourcebinarydeps Regards, -- 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/CANVYNa-8ttg=9A7=jwyolwpbte6rscv3mgp8dbt67pn+nv8...@mail.gmail.com
Re: email rejected bugs.debian.org
Paul, On Sun, Oct 23, 2011 at 9:34 PM, Paul Elliott pelli...@blackpatchpanel.com wrote: I tried to correct a ITP by sending email to 646...@bugs.debian.org but the email was rejected. Delivery to the following recipient failed permanently: 646...@bugs.debian.org Technical details of permanent failure: Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550-Blacklisted URL in message. (blackpatchpanel.com) in [black]. See 550 http://lookup.uribl.com. (state 18). This is a small family domain. I control it. It goes thru google email. only 2 accounts in domain. All the computers on it use linux. It is extremely unlikely any spam has ever been sent from this domain. Could someone white list this domain so that I can participate? That's not up to the list admins, it's a bigger issue. Use this to request delisting: http://lookup.uribl.com/ Regards, -- 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/canvyna9hfrz+hsemsd+lrdgpfqjm1y66p5dulijmavvdglh...@mail.gmail.com
RFS: synconv
Dear mentors, I am looking for a sponsor for my package synconv. * Package name: synconv Version : 1.1.1-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : https://github.com/fernandotcl/synconv * License : GPL-3+ Section : sound It builds those binary packages: synconv- rsync-like audio format transcoder To access further information about this package, please visit the following URL: http://mentors.debian.net/package/synconv Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/synconv/synconv_1.1.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Fernando -- 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/canvyna_ectj_jxk0avjuk3un420qy0_mw2-rgl3ph3unaex...@mail.gmail.com
Re: RFS: synconv
Hello, On Fri, Nov 4, 2011 at 9:52 PM, Fernando Lemos fernando...@gmail.com wrote: Dear mentors, I am looking for a sponsor for my package synconv. * Package name : synconv Version : 1.1.1-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : https://github.com/fernandotcl/synconv * License : GPL-3+ Section : sound It builds those binary packages: synconv - rsync-like audio format transcoder To access further information about this package, please visit the following URL: http://mentors.debian.net/package/synconv Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/synconv/synconv_1.1.1-1.dsc It's been 16 days, and I'm still looking for a sponsor. Except for a lintian override (for a mispelling that's actually a command line option), this package is pedantically lintian clean. I'd be glad if someone could review and possibly upload it. Regards, -- 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/canvyna_mvu4fmggfr_0e47q1zhm_r7pgsqyrdvd4jf1gw5j...@mail.gmail.com
Re: RFS: synconv
On Sun, Nov 20, 2011 at 7:15 PM, Fernando Lemos fernando...@gmail.com wrote: Hello, On Fri, Nov 4, 2011 at 9:52 PM, Fernando Lemos fernando...@gmail.com wrote: Dear mentors, I am looking for a sponsor for my package synconv. * Package name : synconv Version : 1.1.1-1 Upstream Author : Fernando Tarlá Cardoso Lemos fernando...@gmail.com * URL : https://github.com/fernandotcl/synconv * License : GPL-3+ Section : sound It builds those binary packages: synconv - rsync-like audio format transcoder To access further information about this package, please visit the following URL: http://mentors.debian.net/package/synconv Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/synconv/synconv_1.1.1-1.dsc It's been 16 days, and I'm still looking for a sponsor. Except for a lintian override (for a mispelling that's actually a command line option), this package is pedantically lintian clean. I'd be glad if someone could review and possibly upload it. It's been 2 more weeks, I'd be glad if someone took a look at this. Regards, -- 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/canvyna_9_e7njehecgafaxvfcxk08ydmcm-4ppnjcqu7mpk...@mail.gmail.com
Re: RFS: solarpowerlog
On Thu, Dec 22, 2011 at 10:17 AM, Artur R. Czechowski artu...@hell.pl wrote: On Thu, Dec 22, 2011 at 12:37:36PM +0100, Tobias Frost wrote: The one warning -- empty-debian-diff -- is emitted as I also keep the debian files in the git repository I use for development of solarpowerlog. Naturally the diff is empty in this case. If you are also the upstream developer and you are planning to always keep Debian package with released version in sync, you can consider making the package as a native package. Just to clarify, this piece of information is completely wrong. Quoting the mentors FAQ: You should only use a native Debian package when it is clear that the package would only ever be of use in Debian. Even if the software is currently only available in Debian, if someone could reasonably use the software on another distribution or on another operating system, then the package should be non-native. A few examples of normal packages are: libc6, apache, phpmyadmin. But lintian, dpkg and some other tools are purely developed for debian, and make no sense being released in another distribution. It's not a matter of choice. If your package is not Debian-specific, it can't and won't be uploaded as a native package. Now another big problem with your package is that it's using source package format 1.0. This is ancient, and for a new package entering the repositories, you should probably use format 3.0 (quilt). This would make your warning go away as well. Don't try to take shortcuts because you're upstream. When you're packaging your software, think of it as if you weren't the upstream author. Debian doesn't care if you're the upstream author or not, and the tools will complain if you try to take shortcuts. It's crucial to keep this in mind. Also, although I didn't review your package, I noticed that Vcs-* is pointing to your development repositories. It should instead point to the repositories where the Debian packaging is hosted (usually in Alioth), if it's managed by a VCS at all. Again, development and packaging are separate roles. One final piece of advice: please *read* the new maintainers' guide, the Debian policy and the mentors FAQ. This is all documented and very well explained. I don't mean to sound rude, but the fact that you're using format 1.0 and contemplating creating a native package for this is indicative that you might have missed simple stuff that's very well documented. Regards, -- 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/CANVYNa-R=58ojk1CuYc375PUuLBnc=cyw20n_bb-g+z-q0u...@mail.gmail.com
