Re: RFS: weboob
On 2011-04-05 12:04:00 Christophe Benz wrote: boobank- Bank accounts console tool boobmsg- Read and post messages on websites from console havesex- Sexual life swiss-knife monboob- Email proxy for websites containing messages qboobmsg - Read and post messages on websites - Qt GUI qhavesex - Sexual life swiss-knife - Qt GUI wetboobs - Weather forecast search tool I can't help but think that these package names and descriptions might be offensive to parts of the Debian community. Would Debian really be serving it's users by including these packages as is? havesex and qhavesex could be renamed weboob-dating and weboob-qdating, since they are for dating sites in general and don't seem to have use during sexual acts, only for scheduling them. Some of the others can simply have a boob - weboob substitution done to them to make them less potentially offensive, IMO. I'm not sure this is the best forum to discuss this, and I could certainly be wrong. In an attempt to avoid a flamewar, I will endeavor to make this my last post in this thread. I believe I've said my piece. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: FAIL: Package purging left files on system:
On 2011-03-17 11:21:55 Mathieu Malaterre wrote: I am trying to fix the following errors on the dcmtk package: 0m18.3s ERROR: FAIL: Package purging left files on system: /var/lib/dcmtknot owned /var/lib/dcmtk/db not owned /var/lib/dcmtk/db is a special directory. This is the location where incoming DICOM files are stored on disk. So this directory should IMHO only be removed when the user really understand what it does. when and how should I remove this directory ? I'd follow existing practice on important data directories like this. Look at MySQL and PostgreSQL and see what their behavior is on a purge. Do they delete existing tablespace or not? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Help with mantis package
On Tuesday 22 February 2011 03:56:45 Michal Navratil wrote: i have been waiting for some time to see new 1.2.x branch package of the mantis bug tracking software in debian. I have also tried to contact responsible maintainers (as visible on the QA page) offering some help but probably some filter caought my email as no response had arrived. During last week i was trying to prepare package of the latest release (currently 1.2.4) on my own and finally today it seems to be working. I have briefly tested clean install and upgrade from the 1.1.8 version (with mysql DB) on my project and it looks working. Prepare a source package, upload to mentors.d.n and let us know it is available. At the same time, open a wishlist bug against the existing package and attach your patch (debian/ directory only, not the changes to the upstream tarball) to the bug. After the bug is filed, start the MIA process to determine if the maintainer is really missing. At the same time, there will likely be feedback on this list about further changes you might need to make to the package. After some period of time, if the maintainer is really MIA and your packaging is acceptable, one of the helpful DDs on the list can perform an NMU to get mantis 1.2 in the archive. Alternatively, the maintainer may be around but just not concentrating on your package--if they are amicable, a friendly NMU can be done by one of the DDs on the list. Most maintainers are appreciative of extra help, as long as it is done is such a way that their efforts aren't wasted. Establishing communication or documenting attempts to do so is key. HTH PS Please correct me if any of these instruction is incorrect or otherwise ill- advised. I've not have to go through this process, so I'm speaking from a position of theory and study, not practice and action. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: ncrypt
In 20110219150340.gp11...@melusine.alphascorpii.net, Alexander Reichle- Schmehl wrote: python-ncrypt - Python wrapper for OpenSSL [..] My motivation for maintaining this package is: Dropbox, another package which I plan to upload, depends on this package. Uhm... AFAIK dropbox used some lgpl libraries, and now we add openssl stuff? Did anyone checked, if that's okay license wise? LGPL + OpenSSL should be fine. It's GPL + OpenSSL that is a problem, since GPL required the combined work be available under the terms of the GPL and those are incompatible with one or two clauses in the OpenSSL license. LGPL makes fewer requirements on the programs that link with it with can be satisfied at the same time as the OpenSSL license. Basically, you have to take the minimum steps to allow your software to be linked against a compatible version of the LGPL code. NB: IANADD; TINASOODP. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Problem to create the orig tarball
On Wednesday 16 February 2011 09:12:20 fre...@free.fr wrote: What's the proper way to package a plug-in that require the application's sources to compile and both come in a separate tarball ? First, make sure it requires the full application sources, and not just some headers. If it just requires the headers, have the main application source package build two binary packages: $app and $app-plugin-dev (or something like that). Then, you can have the plugin source package build-depend on $app-plugin-dev. If it requires the full, possibly patched, but unconfigured sources, has the main application source package build two binary packages: $app and $app- source. Then, you can have the plugin source package build-depend on $app- source. If it requires some intermingling of the build process, then things get sticky. E.g. if the plugin requires that ./configure (or similar) is already run in the source tree before its ./configure (or similar) will work properly, the builds need to happen concurrently. In this case, you might be best served by using multiple .orig files in a single source package.[1] Of course that massive source package will build multiple binary packages $app, $app- plugin-$plugin. [1] This might actually not be fully supported, yet. I'm not sure about the status, but I believe 3.0 (quilt) source packages can handle it. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Init scripts as conffiles
On Tuesday 15 February 2011 15:16:27 Tony Houghton wrote: How about I file a wishlist bug for dpkg and apt for an option similar to purge but which only purges files which haven't been altered from the package's default? From what I understand, neither APT nor dpkg know if a file has been modified since it has been installed. Some packages ship with debsums, but not all. Neither the original .deb or any sort of exploded form is saved for the entire time a package is installed. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Init scripts as conffiles
On Tuesday 15 February 2011 16:44:49 Matt Zagrabelny wrote: On Tue, Feb 15, 2011 at 4:39 PM, Joey Hess jo...@debian.org wrote: Matt Zagrabelny wrote: I understand the difference between remove and purge and the reason to use both, but removing unmodified conf files seems like a win to me. Keeps the clutter down. You'll stop thinking this when apt decides to do an upgrade as follows: 1. remove foo (and its conffiles) 2. install bar 3. install foo That is one of the reasons for the current behavior, and temporarily removing a package is how apt deals with certian dependency issues. Renaming a package is another similar reason for the current behavior. 1. would remove the unmodified conf file 3. would install it Did I miss something? It might be different and incompatible with the conffile(s) (if any) you did save. For example, it might no longer #include (or similar) the conffile that was saved. I would support a --purge-unchanged option, it seems like it could be useful in certain circumstances. However, something like that couldn't be the default for the same reason --purge can't be the default. I'm not sure how such a state would be representing in dpkg. uninstalled, half-configured? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: installing an end user editable file
On Monday 14 February 2011 13:38:13 james frize wrote: However, I can't open a file from /usr/share via my python script That's wrong. Most of /usr/share should be world-readable. Perhaps you are installing your template with permissions that are too restrictive. I believe /usr/share files should mostly be 644. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: installing an end user editable file
In AANLkTikBeVcyM4H=0d3-xfu4pnihq9qkczp7mlae3...@mail.gmail.com, james frize wrote: Basically I'm copying over a text file that has a list of web links in, after the program is installed the file needs to be edited by the end user, so I'm trying to put the file in a place where a regular user would have permission to both read and write to the text file. Which user? All users? Should each user have a separate copy? Normally, per-user configuration files would be created by that user. An example could go into /usr/share/packagename where a user could copy it into their home directory. You could also install something into /etc/skel; the contents of this directory are normally copied into a new user's home directory when the user is created. Keep in mind that that while many Debian installations are effectively single- user, that Debian is designed to support multiple users and to move cleanly from having one real user to many real users. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: dtmfdial
In AANLkTi=uhilidk7kj-nctnfovj-roj2mic+6-ucbf...@mail.gmail.com, D S McNeill wrote: I have written a slightly improved version of dtmfdial that I would like to include in Debian. I have modified it to include an option to generate not only standard DTMF tones, but Blue box MF tones as well: I contacted the maintainer (Denis Briand) and received the following reply: thank you for your project. dtmfdial is orphaned because I haven't enough free time to maintain it, You can adopt it if you want and submit your blue box project to the Debian's mentors. I would appreciate any information on how to proceed. Much of that information is either contained within the FAQ http://wiki.debian.org/DebianMentorsFaq or linked from the FAQ, but I'm not entirely surprised that you missed that document. 1. You have improvements to an existing Debian package. Good. 1a. These improvements aren't debian-specific. Great! 1b. Contact the upstream project and start the process of getting your improvements accepted by the project. Be sure to post whatever you have somewhere public so there's a chance someone else might take the improvement and run with it even if your interest wanes. 1c. Interacting with upstream is one of the responsibilities of a maintainer, so best to get started now. It's also better for everyone if changes that aren't debian-specific get included upstream. 2. The current maintainer of the package has orphaned it. Bad. This means that the package is as close to dropped from Debian as packages get. The current maintainer is not only seeking someone to take over the maintainership, but they may not be giving the package as much attention as it needs. 3. If you are still interested, there's a lot of work and learning in front of you. At least scan the FAQ linked above, and read http://www.debian.org/devel/wnpp/ completely focusing on the O type under Removing entries. 4. Once that documentation is in order, it'll be time to dig into the packaging in earnest. Go back to the FAQ and read more, specifically focusing on the answer to How do I make my first package?. The documents that answer links to is invaluable, most notably the New Maintainers' Guide http://www.debian.org/doc/maint-guide/ and the Debian Policy http://debian.org/doc/manuals/developers-reference/index.en.html. 5. The packages entry on the PTS http://packages.qa.debian.org/d/dtmfdial.html and most of the links there will certainly be useful at some point in your maintainership. HTH I'm looking forward to seeing your RFS mail about dtmfdial. Also, be sure to use this list a a resource for answers to any specific packaging questions you have. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: update-rc.d and rare start/stop runlevels
In 20110126222650.ga26...@mea.homelinux.org, Mats Erik Andersson wrote:
I am packaging `downtimed`, a daemon for the recording of
system downtimes. Taking its purpose into account the obvious
start and stop runlevels are:
Default-Start : S
Default-Stop : 0 6
since the daemon should be running as long as ever possible.
However, update-rc.d disagrees vividly with me (and possibly
also insserv), since it prefers to call aloud
update-rc.d: warning: downtimed start runlevel arguments (2 3 4 5)
do not match LSB Default-Start values (S)
update-rc.d: warning: downtimed stop runlevel arguments (0 1 6)
do not match LSB Default-Stop values (0 6)
Am I in error, or is there a proper way of silencing these
warning messages?
How are you calling update-rc.d? These warning messages indicate to me that
update-rc.d is complaining that you've asked it to install S* links in
rc{2,3,4,5}.d and K* links in rc{0,1,6}.d but that the init script expects
something different, namely what you've listed in the script.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: update-rc.d and rare start/stop runlevels
In 201101261659.53734@iguanasuicide.net, Boyd Stephen Smith Jr. wrote: In 20110126222650.ga26...@mea.homelinux.org, Mats Erik Andersson wrote: start and stop runlevels are: Default-Start : S Default-Stop : 0 6 However, update-rc.d disagrees vividly with me (and possibly also insserv), since it prefers to call aloud update-rc.d: warning: downtimed start runlevel arguments (2 3 4 5) do not match LSB Default-Start values (S) update-rc.d: warning: downtimed stop runlevel arguments (0 1 6) do not match LSB Default-Stop values (0 6) How are you calling update-rc.d? I'm guessing you expect (update-rc.d downtimed defaults) to read the Default- Start and Default-Stop LSB headers and use those. No such luck. From man 8 update-rc.d: If 'defaults' is used then 'update-rc.d' will make links to start the service in runlevels '2345' and to stop the service in runlevels '016'. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: openteacher
In 20110117074140.ga16...@an3as.eu, Andreas Tille wrote: [Y]ou should NOT maintain the debian/ directory in the upstream source tree (for several reasons discussed several times before). That's not a problem. Release tarballs (including snapshots) should just not contain the debian/ directory. Older source formats produce a lot of noise when a debian/ directory is present in the orig.tar.gz. Even if 3.0 (quilt) ignores the debian/ directory, it is a bit misleading to users of source packages are not interested in details. In fact, if upstream wants to take an active hand in preparing policy- compliant and release-ready packages, it may be best to use upstream resources to manage the package. Contrary-wise, a half-baked debian/ directory, even if it only appears in the upstream VCS is not really useful to anyone. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFR: webalizer - web server log analysis program
In 4d307440.30...@debian.org, Thomas Goirand wrote: Exactly since when, a private email is an official document for a change of maintainership in Debian? What are RFA, O, and ITA for then? I think you are mistaking Gregor, it's not enough. It should be. The bugs types are for when communication needs to occur on a wider scale, particularly with the wnpp team. We don't *have to* add something a b.d.o for every bug fixed by upstream, or each lintian error / policy violation cleaned; we also don't *require* one for changes in package ownership. Now, seeing the activity of the package (and the fact it hasn't been maintained correctly by the past maintainer which more or less was MIA), I think that writing a new bug report giving one week for the old maintainer would be enough, but I don't think that we can avoid an ITA at least, just based on the pure fact that the old maintainer agreed privately! We need to keep things with a public record, otherwise we are risking take-overs. Well, if the old maintainer agrees, they should do the initial sponsorship. If for some reason they can't; the private email does need to be disclosed to (at least) the DD that does the actual sponsoring. We do need to respect the work of existing maintainers; part of that is not stealing a package from them. We do what is necessary to prevent that. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: liboauth (updated package)
In igpn0l$cej$1...@dough.gmane.org, Didier 'OdyX' Raboud wrote: Bilal Akhtar wrote: The upload would fix these bugs: 609963 you don't need to report bugs against your own packages: just fix the issues and get them uploaded. But feel free to. The BTS can be quite a resource for users. If your package gets hung in unstable (or experimental during freeze) and I encounter the bugs on my testing (or stable) system, the bug clearly points to the version I can pull in to alleviate my problem. There are a few other ways I've use the BTS as a reference, and I've seen to draw attention from potential sponsors here. Each bug generally takes up relatively few resources on b.d.o and UDD, so they are usually worth it. In this case your bug is just noise, though. The PTS http://packages.qa.debian.org/libo/liboauth.html automatically reports on lintian errors http://lintian.debian.org/maintainer/bilalakh...@ubuntu.com.html#liboauth (which links to a full report http://lintian.debian.org/full/bilalakh...@ubuntu.com.html), so the information was available elsewhere, and you reference the PTS reports in your sponsorship request, if you thought it was important. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Build-Depends-Indep, please review
In 20101120183255.gf12...@khazad-dum.debian.net, Henrique de Moraes Holschuh wrote: On Fri, 19 Nov 2010, Boyd Stephen Smith Jr. wrote: But hey, all the maintainer has to do is add 1, in words ONE, char to debian/rules. Just change build: to build%: and dpkg-buildpackage could use build-arch/indep targets instead of build. Aparently that is too much to ask. I volunteer to make /this/ fix to any package that is unmaintained or whose maintainer is unresponsive, *if* Debian will change policy to /require/ build- arch/indep and make dpkg-buildpackage use them instead of build sometime after the Squeeze release and before the Wheezy freeze. It can be done, but it must be done in at least two steps: 1. Make it SHOULD, start fixing packages. You don't have to wait for the SHOULD to start fixing packages, either. I'm not willing to manually test random packages for this breakage. What's the best way to get an automated process to report on the PTS or BTS the existence of build-arch and build-indep? Could it simply be a lintian test? Also, I thought it was already a SHOULD. 2. When almost everything is fixed, make it MUST. Whatever doesn't get fixed after that, gets axed from the next stable. My time was volunteered (in my last posting) *after* it becomes a MUST, but with some help I might be willing to put some time in as part of a DEP. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Debconf in non-interactive mode
In 20101120223808.ga15...@mea.homelinux.org, Mats Erik Andersson wrote: Question: Is there some mechanism I can use in the postinst script that lets me determine whether the upgrade is being conducted in non-interactive mode? First, you should *assume* non-interactive mode. To test for interactivity, you could try opening /dev/tty.[1] It's not perfect, but non-interactive processes should generally detach from their controlling terminal leaving them without a valid /dev/tty. Another option is to see if both stderr and stdin are ttys, which is how SUSv2 says a shell determines if it is interactive. If both those tests are true, you can be pretty sure that a user can be prompted (on stderr, blah) and you can get a response on stdin. If neither is true, you can be pretty sure user input is not forth-coming. If only one is true you can really be sure one way or the other. (Assume non-interactive, plz.) [1] On Linux, at least. I don't know if the kFreeBSD port has /dev/tty. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Build-Depends-Indep, please review
In 87y68p6tcx@frosties.localnet, Goswin von Brederlow wrote: Roger Leigh rle...@codelibre.net writes: On Fri, Nov 19, 2010 at 04:40:57PM +0100, Goswin von Brederlow wrote: David Kalnischkies kalnischk...@gmail.com writes: On Thu, Nov 18, 2010 at 19:25, Ø£Ø٠د اÙÙ ØÙ Ùد٠aelmahmo...@sabily.org wrote: On Thu, Nov 18, 2010 at 07:07:07PM +0100, Goswin von Brederlow wrote: And as discussed before policy disagrees with reality in this. Would you please elaborate ? Goswin likely refers to this thread: Buildd binary-indep http://lists.debian.org/debian-devel/2010/09/msg00590.html Message-id: 20100924204433.ga4...@apache.rbscorp.ru Buildds install only Build-Depends but not Build-Depends-Indep but still call the build target. In reality the build target must work with only Build-Depends installed contrary to what policy says. I do hope this mess can be sorted out after squeeze is released. Mandating build-arch and build-indep would be a good thing, IMHO. Don't count on it. This has been going on for years and years. The simple solution is to just declare the build-indep/arch targets required (maybe going via SHOULD to MUST) and then have dpkg-buildpackage just use them when sources have changed (or just use them and break things). Unfortunately this would make a lot of packages instantly RC buggy so people are afraid of doing that. And without mandating the targets and making Build-Depends-Indep actually usefull there is no incentive for maintainers to change the source. But hey, all the maintainer has to do is add 1, in words ONE, char to debian/rules. Just change build: to build%: and dpkg-buildpackage could use build-arch/indep targets instead of build. Aparently that is too much to ask. I volunteer to make /this/ fix to any package that is unmaintained or whose maintainer is unresponsive, *if* Debian will change policy to /require/ build- arch/indep and make dpkg-buildpackage use them instead of build sometime after the Squeeze release and before the Wheezy freeze. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Packaging free software with non-free data files
In aanlktikp6w9+oh3uhbd63ggz18irpfaqokvgxxcsq...@mail.gmail.com, Stefan Ott wrote: I have a small question: I would like to package a piece of software that, when first launched, downloads additional non-free data files which are needed to run. If these data files are the only ones that could possibly be useful, they are really part of the program, so they shouldn't be in a separate package and the package should go into non-free. If it's possible to use other data files usefully, but there's no DSFG-free data available, the program can go in contrib and Depend on the data in non- free. If there's DFSG-free data available, but the non-free data is still useful from some purposes, then DSFG-free data and program in separate packages in main and Suggest non-free data in non-free. (Gets a little stickier if the program doesn't support multiple data sets.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: hello
On Friday 15 October 2010 13:08:10 Luca Bertoletti wrote: Hello I'm italian linux users.I worked for erickson and I studied I.T at Università di Milano Bicocca. I know shell scripting and this programmation languages: pyton, perl, java, c, c++ and for the dbms sql languages. I want to know if I want to became an Debian developer how can I do? thanks for your attention Becoming a DD is not (directly) based on your curriculum vitae, but rather on the quality and amount of volunteer work done for Debian, particularly around packaging. I believe the New Maintainer's Guide is the current official reference for the process, but I don't have a link available. Anything further is based on my experience watching from the outside (IANADD) and my or may not be official (TINASOODP). Becoming a DD is about producing work that helps Debian grow, usually by increasing the number of available packages or (preferred) increasing the quality of existing packages. For some time, another DD will look over your work and perform the final upload to Debian, but you will share in the credit (or failure) of the work. Once you've produced enough, you'll be able to join the Debian network of trust and the project will start accepting work directly from you, which makes you a DD. As a volunteer project, there's always plenty of work to do, but you'll rarely get work assigned to you by someone else. Instead, you'll have to be self- directing and find place(s) you want to contribute. This list, as well as the mailing lists for each maintenance team, are good places to get your work reviewed and find a DD to perform in final upload, but not a place were you can get assignments. Assuming you use Debian, I recommend starting with the wnpp-alert and rc- alert tools. These tools will inspect a running Debian system to find installed packages with open bugs. You can then view these bugs via the web interface or receive more details on them via email. You can also manipulate the bugs via email. Eventually, you'll find a bug that you can address with your skills. If the package currently has a maintainer, work with them to address the bug. Oftimes, this will entail generating a patch and attaching it to the bug. If the maintainer is non-responsive, attaching a patch to the bug usually a good idea and might be a way to start the MIA process. If the package does not have a maintainer, prepare a new source package and use this list and/or a team list to get that package uploaded to Debian and continue to address bugs in that package. There are a number of tools that are helpful in preparing new (patches to) source packages, but they are fairly well documented, both on the Debian web site and in the mailing list archives. If you have specific questions, this list can generally answer them. Examples include: *-buildpackage, debhelper, lintian, piuparts, and pbuilder (and variants like cowbuilder). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Rescue Plan for apt-listbugs
In 87ocayo1en@anar.kanru.info, Kan-Ru Chen wrote: Goswin von Brederlow goswin-...@web.de writes: Paul Wise p...@debian.org writes: I would also suggest that before you push, either judicious use of git add -p for preparing commits into logical changes or use of git rebase -i after the fact to reorganise them into logical changes. Also, ensuring that each commit builds and passes any test suite helps folks doing bisects etc on the repo at a later date. I'm always unsure on how this is supposed to work. On the one hand you split up changes into many commits. On the other hand each commit should be functional so bisect works. Somehow the two ideas conflict in my head. No, you split up changes but keep it functional. If splitting a chunk breaks the functionality, then it means they are relevant and should be committed at once. as one not at once. as one ~= together at once ~= with little or no delay The goal is to have commits be as big as they need to be, but no bigger. If there is no proper subset of your commit that you can apply and have a working build, then your commit is just the right size to stand alone. E.g. If you add a new function, and fix up a few places to use the new function instead of copy-pasta, that should be two or more commits. E.g. If you change the API of a existing function, and fix up all the callers, that should be one commit. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Uploading during freeze time
In aanlktin9bpb_w2ftgpkfqpzzj7rwybzedsvjowqkr...@mail.gmail.com, Jordi Gutiérrez Hermoso wrote: I just realised, the packages I'm complaining about are essentially squeeze backports. That is, they're packages that the packager wishes could have gone into squeeze but can't because of the freeze, so they go into experimental instead. Would it make sense then to start $x-backports as soon as $x gets frozen? That makes a lot of sense to me. Heck, it might even useful before then; packages with lots of dependencies involved in separate transitions can take quite a while to move from unstable to testing. If a backport was provided built against the deps. in testing instead of unstable that had relatively few source package changes[1], you'd effectively get *more* testing of packages before they arrived in testing. [1] Sometimes a backport is just a matter of bumping the package version and building under a different chroot. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Uploading during freeze time
In aanlktimbzn8d2mekpxx6q1sa0hong21two0rhfkop...@mail.gmail.com, Jordi Gutiérrez Hermoso wrote: On 7 October 2010 14:06, Joachim Reichel joachim.reic...@gmx.de wrote: I guess what Christoph meant is the following: if you upload 1.45 to unstable you block this way for fixes to 1.44 in testing (and the RM will most probably not allow 1.45 to migrate to testing). You could upload 1.45 to experimental for now. This allows you to upload 1.44-2, -3, and so on which just fix RC bugs in 1.44-1, upload them to unstable and request a freeze exception. I've never really understood why Debian works like this. In this particular case, we *know* that the so-called experimental package is going to be even more stable than the testing package, because it's had many more bugfixes tested by upstream than tested by Debian. It seems silly to have to label it experimental. I disagree that *any* package based on a new upstream release is *known* to be less buggy than the existing package, even *before* it gets uploaded to unstable/experimental. (Exception: packages that have already been in a Debian derivative for some period of time before entering unstable/experimental.) Does it have to be this way? Why do fixes to testing have to go through unstable, even during freeze time? They don't. t-p-u exists for when the version in testing needs a fix, but migrating the package from unstable is troublesome. It is rather frowned upon though, since it means the update does not get the level of exposure that other updates receive. That's a bad thing; even very small fixes can inadvertently break a package for an entire architecture. (E.g. bug #595728, which isn't about t-p-u but rather the *stable* update process) Why does experimental become the new unstable during freeze time? Remember that the unstable name was chosen to indicate how often it is updated, not how well-tested the upstream software is. unstable is packages intended to be in the next release of Debian, as they are uploaded. If your package isn't intended for the next release of Debian, it shouldn't be in unstable. With the freeze on, you should be fairly sure you will get a freeze exception from the release team *before* you upload to unstable. experimental is packages not yet intended for any release of Debian, for whatever reason. It gets used as unstable+1 during the freeze, since there's no better place. Having an unstable+1 might work, but probably not; in any case, it would only be useful during a freeze AND you'd likely have to re-upload to unstable after the thaw anyway. (Continual automatic migration from unstable+1 to unstable is wrong semantically, and likely has some technical hurdles as well.) If a re-upload is required anyway, we might as well just use experimental as unstable+1 during the freeze, IMHO. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Uploading during freeze time
In aanlktikwokffmtyfhi-yy7j=_fx8_44wbcbu3vcc6...@mail.gmail.com, Jordi Gutiérrez Hermoso wrote: On 11 October 2010 12:11, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: In aanlktimbzn8d2mekpxx6q1sa0hong21two0rhfkop...@mail.gmail.com, Jordi Gutiérrez Hermoso wrote: Does it have to be this way? Why do fixes to testing have to go through unstable, even during freeze time? They don't. t-p-u exists for when the version in testing needs a fix, but migrating the package from unstable is troublesome. It is rather frowned upon though, since it means the update does not get the level of exposure that other updates receive. That's what I really don't get. So testing isn't for testing, unstable is for testing, and experimental is for unstable? So where do really crazy ideas go? Why do all the distros get pushed back one during freeze time? Testing *is* for testing. However, testing is not as unstable as unstable. The reason for this is simple: You can't test the functionality of a package if you can't install it. It is relatively easy for an upload to unstable to render at least one package uninstallable in unstable. The automated migration process is responsible for keeping all packages in testing installable. I hope that shows why testing and unstable have to be different versions. Since they need to be separated anyway, adding the 10-day (or so) grace period for major bugs to be identified before entering testing, allows testing be be much closer to the ideal. Packages are installed into the `testing' directory after they have undergone some degree of testing in unstable. They must be in sync on all architectures where they have been built and mustn't have dependencies that make them uninstallable; they also have to have fewer release-critical bugs than the versions currently in testing. This way, we hope that `testing' is always close to being a release candidate. http://www.debian.org/doc/FAQ/ch-ftparchives Remember that the unstable name was chosen to indicate how often it is updated, not how well-tested the upstream software is. Is that true? I've never seen an official reaffirmation of this oft-quoted idea, it merely seems to come from people who don't mind debugging or living with the bugs in unstable and therefore it's stable enough for me. The `unstable' directory contains a snapshot of the current development system. Users are welcome to use and test these packages, but are warned about their state of readiness. The advantage of using the unstable distribution is that you are always up-to-date with the latest in GNU/Linux software industry, but if it breaks: you get to keep both parts :-) http://www.debian.org/doc/FAQ/ch-ftparchives Some upstream projects do a lot of testing on their side and work closely with the Debian maintainer(s). When that is true, the package that gets uploaded to unstable is often less buggy than the package in testing (or even stable). The kid who breaks toys doesn't sound to me like the kid who changes too much. Unstable is too buggy for me. The sid name predates the current division of stable/testing/unstable. http://www.debian.org/doc/FAQ/footnotes.en.html#f2 During freeze time, shouldn't bugs should be fixed in testing, not in unstable? You freeze a distribution, you fix its bugs, and you release it, and while the six-month freeze is in effect, you can also have your broken toys playground if you want it. The freeze process is as you describe. What you don't seem to get is: The preferred way to fix bugs in testing to via automatic migration from unstable. This is to ensure a minimum quality of testing, so that users there can focus on testing packages, rather than suffering through breakages that the automated process can prevent. If a bug fix is high-quality, it won't have any issues passing the automated tests; if the bug fix is important, the urgency of the upload can be changed which reduces waiting time in unstable. In fact, if there are more automated tests you can think of, it wouldn't be bad for the bar between testing and unstable to be higher. I think CUT (constantly usable testing) is actually pretty close to reality once the system is installed; though, d-i and installer media are important, too. unstable is packages intended to be in the next release of Debian, as they are uploaded. Where next in this instance means current? What does experimental mean, then? No. The next release of Debian is codenamed squeeze. No release date has been set, but we are in the pre-release freeze. http://www.debian.org/releases/ experimental is packages not yet intended for any release of Debian, But that's now how it's used. It's used as not squeeze, but almost certainly wheezy Experimental is used for packages which are still being developed, and with a high risk of breaking your system. It's used by developers who'd like to study and test bleeding edge software. Users shouldn't be using
Re: Uploading during freeze time
On Monday, October 11, 2010 17:01:16 you wrote: On 11 October 2010 20:28, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: In aanlktikwokffmtyfhi-yy7j=_fx8_44wbcbu3vcc6...@mail.gmail.com, Jordi Gutiérrez Hermoso wrote: On 11 October 2010 12:11, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: It gets used as unstable+1 during the freeze, since there's no better place. So why not create a better place? Because of the limited utility, which I mentioned in the message to which you replied. First, it only has any use during a freeze. Only during a freeze ends up meaning six months or longer. You think that's a short time? It's one full Ubuntu release cycle! There's no reason Debian freezes must last six months or longer. Still, even at that rate, the Debian freeze time would be proportionally less than the time before a Ubuntu release where packages are not pulled from unstable. Squeeze: Development started 2009-02-15, Freeze started 2010-08-06, Release approximately 2011-02-06. Freeze as a percentage of cycle: ~25%. (I actually expect an earlier release; that date is based on being frozen for 6 months. If we release for Christmas, it is closer to 20%.) Maverick: Development started 2010-05-06, Freeze started 2010-06-24, Release 2010-10-10. Freeze as a percentage of cycle: ~80%. (This is based on when the automatic import from Debian unstable stops. Using the freeze date where release managers get involved, you still get ~40%. Using the last freeze date, you still get 20%.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: creating a manpage from a GFDL text
On Tuesday 05 October 2010 10:17:06 gustavo panizzo gfa wrote: i would like to create a man page for vavoom, based on a wiki page licensed as GNU Free Documentation License 1.2. What can i do? GFDL is not free for debian, and my pkg is for main. You could package the documentation in a separate -doc package that is in non-free and Suggest (or maybe Recommend) it from the core package. You could get the owners of the copyright to relicense the work. You could get debian-legal to review the licensing and see if this use of the GFDL is appropriate for main. Sometimes a license that is normally appropriate for main can be disallowed due to the interpretation of the copyright holder. (ISTR, Pine's license being like this.) It is possible the converse could be true as well. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Bug in frozen package - aim at backports/volatile?
In aanlktimup8b_ynec1kuc9p_g2wkq0rlthfz5ul9gc...@mail.gmail.com, Stefan Ott wrote: I have a small question: I'm aware that Debian is currently frozen, thus no new features can be added to squeeze. However, I maintain a package [1] (I'm also the upstream maintainer) which has an annoying but non-critical bug. The package is a parser for TV show episode information and one of the sources recently changed some minor detail in their data which messes up my tool's output. I just released a new upstream version [2] which fixes that bug (and that bug only) and don't really like the idea of shipping a buggy version of my package with squeeze, thus I'm wondering whether it's possible to have a fixed version included in squeeze (probably not) or if I should aim at squeeze-backports or volatile (since the package depends on volatile external data). If the upstream diff is small, it only fixes bugs, and the package a relatively few reverse-Depends, the chance the release team will allow the new package to enter testing is large. In any case, such a small, bugfix-only diff would be appropriate for unstable, even if it isn't ultimately approved for entering testing. The freeze before release is more of a slush compared to what happens after release. Imagine the consternation of releasing git-core in 5.0.6 for i386 with a grave bug that wasn't in 5.0.5 -- it can't be fixed in the core stable repository until 5.0.7 is released. (The fix is relegated to s-p-u, security, volatile, etc.) See bug 595728. :P -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: question about proprietary libraries
In 20100902092854.gr4...@vdg.blogsite.org, Julien Viard de Galbert wrote: Also I think I've read somewhere that no library really enter debian unless a program requires it. (which kind of makes sense). I mentioned this in another thread. I'm not sure if it is policy. I was imagining a C library, which has little end-user demand if there's no application that needs it. I can imagine a PHP library (e.g.) might be shipped because it is useful for users developing websites (e.g.). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Debian and Patents (was: Re: RFS: packagekit)
In aanlktimrba0hxth3kq-fik9g57m8iqbzcjf1f0ryy...@mail.gmail.com, Praveen A wrote: I was reading through the wiki and found this, * Debian does not include software that is encumbered by software patents. This statement is correct for Fedora, but we have many *known* patent encumbered software in our repos like mp3 codec, ffmpeg etc. So I think, this item can be removed. I thought the patent encumbered software was banned from the repos due to legal risk to SPI. I get my ffmpeg and mp3 stuff from the debian-multimedia repositories which, while good, are not official. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Package proposal for Jaxl - Jabber XMPP Client Library
On Monday 30 August 2010 20:16:02 Abhinav Singh wrote: I am author of the library and want to create a debian package for Jaxl library. http://github.com/abhinavsingh/JAXL Libraries generally only enter Debian when some existing application can use them. That said, this is a fine place for asking packaging questions even if there's no need for your package in Debian right now. Maintaining a DEB package outside of Debian is also good practice for when it is required in Debian. Still, like applications, the first step in a packaging a library is filing an ITP bug, or adopting an existing RFP bug and changing it to an ITP. (ITP = Intent To Package; RFP = Request For Package) Are there any pre-requisistes before Jaxl debian package can be accepted into stable repositories? Packages are rarely uploaded directly to the stable repositories. Security updates for existing packages in stable enter the security repository first. RC bug fixes for existing packages in stable enter the -proposed repository first. Both of these updates will be moved into stable with a point release. New packages only get into stable by being part of a release. That is, being in testing at the time a release is made. Packages get into testing by migrating from unstable, a mostly automated process based on dependencies and bug reports. For some period of time before a release there is a freeze. We are currently in the pre-Squeeze-release freeze. During a freeze the requirements for migrating from unstable are increased, requiring the release team to okay the migration in addition to the normal requirements. Packages can be removed from unstable (which triggers a automatic process to remove it from testing), but this is usually only done when the package is orphaned. Packages can be manually remove from testing, but this is generally limited to during a freeze, which the package is not ready for release, can't be supported throughout the lifetime of the release, or has RC bugs that the release team is unwilling to allow in the release and the maintainer is unwilling or unable to fix those issues before release. TL;DR: Prepare your package for unstable, it will migrate to stable eventually. We are in a freeze right now, so it will be a while before new packages are considered for stable. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: premake
In aanlktikukpyc4jvd5vb0vsmcunegz2kp5htdxuhxf...@mail.gmail.com, James Goppert wrote: I think I have corrected all olf the errors in the premake package. Please let me know if there is anything left to change. Same or different dget URL from your OP? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Default Configuration Issues
In aanlktimikr2k5c81xxj-r2bu0jsf5myg9ewmwelni...@mail.gmail.com, Paul Tagliamonte wrote: fluxboxes (or is that fluxboxii) Definitely not fluxboxii, unless it is a loan word from a language I am entirely unfamiliar with. It is probably fluxboxes (c.f. box - boxes) but it might also be fluxboxen (c.f. ox - oxen). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: premake
In aanlkti=g97z7x6oewd88eq9g7mm05rdw_qoecjeod...@mail.gmail.com, James Goppert wrote: Thanks. The package is just a build program, like make. I'm trying to build these packages on lenny. Guess that 's why my lintian didn't give those errors. I guess I'll have to run a sid virtual machine or something since taking my network to sid isn't an option. First, make sure you are running lintian against the .changes file, not against the .deb(s). That way, it can issue warnings for the source packaging and mismatches between the source packages and the binary packages. Second, most packages submitted to Debian should be built on a clean Sid (unstable) system, since they will be entering the archives there and because it is policy. Third, pbuilder (and variants like cowbuilder) make it very easy to build, maintain, and use a chroot environment for building packages and there are fairly well-documented ways of running your lintian test from within that chroot as well. Forth, the dependencies for the lintian package in sid can usually be satisfied with packages from current stable. When that's true you can use a (dpkg -i) run or modify your sources.list (adding Sid) and preferences files (pinning most of Sid to 99 or less, and lintian in Sid to 991 or more) to install Sid's lintian on a stable system. Fifth, thanks for the package, I hope you can clean it up and get it in Debian. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: restricting git commits to the debian subdirectory?
On Wednesday 23 June 2010 17:16:41 Eric Cooper wrote: I maintain both the upstream and Debian version of a program in a git repo, using upstream and master branches, git-buildpackage, etc. Occasionally I forget which branch I'm on and commit upstream changes to the master branch by mistake. Is there a way to tell git that when I'm on the master branch, I should only be allowed to commit files in the debian/ subdirectory? I suggest a pre-commit hook that checks your branch, then possibly checks your diff, then possibly rejects the commit. The example script checks all commits, but I think you should be able to determine what branch you are on with (git symbolic-ref HEAD). -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: notorious-women
On Thursday 17 June 2010 13:16:08 Bilal Akhtar wrote: Isn't this a sexist package? Sexist against women? Maybe. At the very least, notorious has a had a negative denotaion since the 1600s, and probably shouldn't be applied without good justification. I'd prefer a more neutral or positive term be used. Famous is probably sufficient. Sexist against men? Probably. Excluding quotes from this package on the sole grounds that they are from a male is the very definition of sexist. That said, I don't find it to be offensive sexism; it is simple categorization with no ulterior motives that I can imagine. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: notorious-women
On Thursday 17 June 2010 12:51:47 benoît tuduri wrote: Dear mentors, I am looking for a sponsor for my package notorious-women. There have been a number of replies each time you sent this message. Perhaps you are not receiving them. I am CC'ing you on this reply, in case you are not subscribed to the mailing list. I am doing this in direct violation of the Debian Mailing List Code of Conduct http://www.debian.org/MailingLists/#codeofconduct with the hope that it does not offend. Normally, replies to list are to be sent to the list *only*. If you would like all list postings, you can subscribe to the list; if you only want the replies to your messages you should explicitly request a CC in each message you send to the list, although it is possible that you do not get a CC for all messages you might be interested in. If you choose not to subscribe to the list, you should be sure to check the mailing list archives http://lists.debian.org/debian-mentors/ for any relevant message you might not have received before sending a post to the list. In fact the list archive can be a wealth of information, but it is easily forgiven to not read the whole thing -- it is rather large. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: A lot of pending packages
On Wednesday 09 June 2010 18:06:06 Lorenzo De Liso wrote: Il giorno mer, 09/06/2010 alle 22.44 +, Sune Vuorela ha scritto: A recommended strategy is to package some apps that are interesting enough to get some DDs to work with you, and then you can also most likely get them to look at other of your stuff. That's the most commonly situation, in this case, if the package will look OK it will be uploaded soon. But the problem is that the people can't find always free DDs to work with they. I don't think you are going to get a lot of traction for any proposal that removes a DD from the upload process. So, lack of free DDs will always be a potential issue. I suggest you encourage people to become a DD. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: A lot of pending packages
On Wednesday 09 June 2010 18:22:08 Lorenzo De Liso wrote: Il giorno mer, 09/06/2010 alle 18.12 -0500, Boyd Stephen Smith Jr. ha scritto: I don't think you are going to get a lot of traction for any proposal that removes a DD from the upload process. So, lack of free DDs will always be a potential issue. I suggest you encourage people to become a DD. I know few DDs which are busy and sometimes they can't sponsor packages. Become a DD would be great but without a previous work for debian I don't think you can become a DD. Am I wrong? You need someone to sponsor you, and usually they look at past experience with the Debian development process. That doesn't mean you have to get your pet package into Debian, but it does mean you have to show competency with preparing uploads to the archive. Also, technical competency is only part of being a DD. It's much more important to be able to work well with the current DDs, process, and upstream to make Debian and the software packaged as part of it better. I strongly suggest anyone interested in Debian packaging start with the wnpp- alert program; existing packages and DDs need plenty of help with what is already there. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: A lot of pending packages
On Wednesday 09 June 2010 20:54:28 you wrote: I for one would like to become a DD. For a simple reason: it is my OS of choice since years ago, so I want it to be its best for everybody. But I suffer the problems I mentioned. How many packages have you worked on for Debian? Maybe it is time to apply for DD privileges. Worst case scenario, you don't measure up now and you can apply again in 18 months. So my only visible activity on Debian is a few versions of a package. What is the way to go? Continue packaging and waiting for months (or even forever) to get it sponsored? Am I doing it wrong?! After you've asked for sponsorship here, don't stop being visible. Sure, give sponsors a little time to look at the package, but if you haven't gotten any response in a week or so, get more visible. 1. Reply to you original RFS with a new RFS. You don't need any new content, you just need to catch a sponsor that was unavailable last week and is available this week. If you've had (a) sponsor(s) before, make sure they get a CC on both. 2. Does the upload fix bugs? Are they recorded in bugs.d.o? If they haven't been reported, file one. Once the bug exists, add a note to it that indicates your new package fixes the bug and include the URL for your package. Is there a new upstream release and Debian isn't in a freeze? After some amount of time, that *itself* can become a (wishlist) bug. 3. Do you know any other users of your package? Have them test it for you and ask them to respond to your RFS with I use this package, and this version is better than the last. 4. Get on IRC. I think there's a #mentors on the Debian network, and there might be DDs on other channels that can provide extra quick turn-around or even more suggestions for visibility. 5. Search for DDs that might take an interest in your package. Usually this isn't DDs that maintain similar packages, but rather teams centered around a technology, role, or programming language. It is incredibly frustrating to do work and then find it ignored. Unfortunately, the Internet is a big place and the people that can give you kudos (or intelligently critique your work) are not already watching you. Be proud of your work (until told otherwise), show it to as much of the Debian community as you can. Now, it would get truly annoying if every new Debian packager did all of this every time they had anything to contribute, so give the original RFS at least a week to be looked at, and stop promoting for at least a week whenever you find a DD that will review (and possibly upload) your package. If you aren't obnoxious with your self-promotion, you'll eventually find someone to take enough time to look at your package and, most likely, reply with a laundry list of things you need to fix. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: License Question (from Newbie)
On Friday 14 May 2010 07:57:48 Anmol Sharma wrote: I was looking at RFP's (Bugs #446461 and #419730) for Frostwire, a free Limewire alternative. There is already an upstream Debian package (NOT Linitian clean of course) so I began poking around the source. What stumped me is the presence of a EULA.txt which adds a few more restrictions to the GPL . Also, there is an 'advertisement window' when the program is launched. So, can Frostwire be packaged? Yes. What you really mean is will can Debian distribute those packages as part of main (or at least, non-free). That's probably a question for debian-legal, but it depends *a lot* on the content of EULA.txt and how flexible upstream is about changing it. The advertisement window is not strictly forbidden, IIRC. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Taking over maintaining a package
On Wednesday 12 May 2010 16:03:24 danny.rodrig...@comcast.net wrote: Once i have permission to take over maintaining a package -- what do I do from there? Determine if the package is maintained in a VCS somewhere (probably alioth). If so, get (an alioth account and) write permissions to the VCS. Check out the latest version (HEAD) and also the last version uploaded to Sid. If not, download the source package from Sid. Subscribe to your package on the PTS. Find upstream. Introduce yourself on their communication medium of choice. See if any of the developers have feedback on the Debian package, especially if they use Debian but not your package. Start following development or at least release schedules. Does upstream have an new non-crashy version available? (This need not be a release, but it shouldn't be the tip of their development tree. If so, update the packaging to use upstream's new version. Run it through lintian (from Sid preferably, but the version from backports is usually good enough) and piuparts. For each complaint, either fix the packaging or be prepared to defend your decision not to. Update the changelog not only with the upstream version bump, but also any changes you made to satisfy lintian/piuparts. If not, you might not need to make a release right now. Study the packaging, perhaps alter it so it can build packages directly from the upstream VCS, for possible uploads to experimental. Check bugs.d.o for any issues. If you can fix them, do so, and record it in the Changelog. If they need to go upstream, forward them. If you have the skills, get involved in fixing upstream bugs, too; particularly the ones coming from the Debian BTS. Install the new package and become user 0. Confirm the package is ready to be shared, with others and upload to mentors. Fill out the template completely, send it over here and wait for a review. Once you've got something in Sid, check your bugs again. See if you can marked some as fixed in a particular version, or close some as invalid completely. Consider preparing a package for stable-updates if you can fix bugs affecting stable the risk is low. Consider preparing a package for backports. ... Anything I missed, -mentors? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Which how to for apt-get repository on CentOS?
On Tuesday 04 May 2010 23:18:13 Ignacio Valdes wrote: Hi all, Building an apt-get repository on CentOS. There seems to be many documents on apt-get repository building but they point to many different commands like apparently deprecated dpkg-scanfiles, reprepro and others. Which one is the correct one? -- IV For a simple repository, I used apt-ftparchive. If you are going to have multiple releases (e.g. lenny, sid), multiple sections (e.g. main, non-free), or a package pool, then it might be too simple a tool, however. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Update of package problems on web site
On Monday 03 May 2010 14:08:37 Holger Levsen wrote: I have filed #571695 to prevent dak from accepting such broken packages as kdebindings was to the archive. W.T.F. Who uploaded without installing the package? Surely 'package (= none), package ( none+~)' breaks apt-get and aptitude, too, right? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Specifying %{variable} in control file for use in post inst?
On Friday 30 April 2010 07:48:59 Ignacio Valdes wrote:
That is pretty much what I have been doing. But how about something as
simple as accomplishing this in postinst using the control file
variables?
echo The package: %{Package}-%{Version} is now installed.
How would one accomplish this in deb?
You wouldn't. It's a useless message. Drop it.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: Specifying %{variable} in control file for use in postinst?
On Friday 30 April 2010 11:12:57 Ignacio Valdes wrote:
So I am gathering that whereas it is repugnant to the dpkg design
scheme to do it, but for the sake of rpm reconciliation the thread
subject question: accessing control file values in postinst is not
simple to do other than with major changes like sed pre-processing and
such?
I wouldn't say it is repugnant, but the postinst scripts should generally be
able to be run independently of even having the control fields available.
I also wouldn't say that sed pre-processing at .deb build time is a major
change.
Is that the situation?
Yes, dpkg does not (currently) expose the control fields in the environment
that the {pre,post}{inst,rm} scripts are run.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: RFS: shtool (updated package)
On Tuesday 20 April 2010 09:13:56 Joachim Wiedorn wrote: Alexis Bienvenüe p...@passoire.fr wrote: lexgrog does not seem to accept multi-words command names in the NAME section: it does not accept shtool scpp because of the space (in fact the command name is not shtool scpp but shtool) In git they have made this solution: You can start git i.e. with: git checkout ... But the manpage must be started with: man git-checkout Or, (git checkout --help). This could be a solution for your manpage: shtool-scpp Agreed. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: new package lmfit: Levenberg-Marquardt least-squares minimization and curve fitting
In 4b8ba5f0.6040...@fz-juelich.de, j.wuttke wrote: I would greatly appreciate your help in adding lmfit to Debian. Today I created Debian packages, using dh_make and dpkg-buildpackage. Basically, everything went well; so I am confident that not too much work is required to make lmfit ready for Debian. A sponsor doesn't make the Debian package for you. A sponsor just uses their upload rights to add your finished package to Debian.[1] If you feel your package is ready for review, upload it to mentors.debian.net, fill out the RFS template there, and post to the list again. If this is your first package, expect sponsors to reply to the list with issues that need resolving before they upload. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ [1] As no Debian package is ever truly finished, you are responsible for all the normal DM tasks -- replying to the BTS, working with the security team, preparing new packages when upstream is updated, etc. signature.asc Description: This is a digitally signed message part.
Re: Joining Debian
On Monday 08 February 2010 15:26:49 Luis Pedro wrote: My name is Luis Pedro and I would like to join you all, and try to do something useful for free software. I am familiar with Linux, familiar with programming, but not much familiar with software development for Debian Linux. I followed some tutorials from Ubuntu, which is the son of Debian, about how to start... I have some notions but I feel like I need someone to guide me through development in Debian. Is anyone available? Links to some of my replies to previous, similar questions: http://www.mail-archive.com/debian-u...@lists.debian.org/msg544001.html http://www.mail-archive.com/debian-mentors@lists.debian.org/msg63936.html If you have specific questions ask them here or on IRC, you'll usually get a quick turn-around. If you don't, make an attempt at *some* task, and present your work. Trust me, any issues remaining will prompt your peers to correct you. :) -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: How to remove the relation between a file and a .deb package
In 4b698be6.10...@avelon-cetex.com, M. Frey wrote:
I'm using my own Debian .deb-packages for managing software updates on a
small numbers of embedded computers. So this question is about creating
my own .deb Packages. I hope you can help me, even if I'm not an
official debian package maintainer.
I got the Package A with the version 1.0 and 2.0. From version 2.0 on
it's not necessary to keep track of the file fileB.txt. But I want to
keep fileB.txt on the target system anyway.
Package A Ver. 1.0:
- fileA.txt
- fileB.txt
Package A Ver. 2.0:
- fileA.txt
If I install the new package A. DPKG will of course remove fileB.txt.
How can I prevent dpkg to remove fileB.txt?
You can't. It is owned by the installed package version and that won't
change.
Of course, I could manipulate the dpkg file list, somewhere in the dpkg
cache (file system). But how can I achieve the same effect within a
package - without manual manipulation on the target system?
Yeah, that's a horrible idea.
You should use a preinst or prerm to backup fileB.txt (files created by the
{pre,post}{inst,rm} scripts are considered owned by the package) to a
different file name during the time when dpkg would remove it and put it back
after the new package is installed.
Is there any key word in the control file? Or is there a special file,
which lists dependencies to delete?
No; No.
What happens if the same file is contained in two packages and one of
them gets removed?
dpkg will notice the packages conflict and not allow them to be installed at
the same time. (Assuming no Replaces dependency.)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: The use of epoch in version
On Thursday 28 January 2010 17:03:33 Mats Erik Andersson wrote: torsdag den 28 januari 2010 klockan 16:42 skrev Richard Laager detta: On Thu, 2010-01-28 at 23:04 +0100, Mats Erik Andersson wrote: Abondoning the tarball-in-tarball form of the orig.tar-file would change the upstream tarball that comes with the repackaged debian source, without changes to the upstream version IANADD (and I don't know what you're packaging), but I've always thought that epochs were supposed to be avoided unless absolutely necessary. Could you just get this change ready and wait to upload until the next upstream release? The last upstream release was made June 2004. Just an extraordinary slim chance that a new release will take place in anything but a midway distant future. I have presently five small patches and there will be at least two more. Perhaps I can get upstream interested again. If the upstream version is currently 1.2.3, and debian version is something like 1.2.3-4, how about releasing Debian version 1.2.4~repacked~1.2.3-1 with a new upstream tarball with version 1.2.4~repacked~1.2.3. You avoid using an epoch and can continue waiting on a real 1.2.4 from upstream. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: The use of epoch in version
On Thursday 28 January 2010 17:34:18 Ben Finney wrote: Boyd Stephen Smith Jr. b...@iguanasuicide.net writes: If the upstream version is currently 1.2.3, and debian version is something like 1.2.3-4, how about releasing Debian version 1.2.4~repacked~1.2.3-1 with a new upstream tarball with version 1.2.4~repacked~1.2.3. You avoid using an epoch and can continue waiting on a real 1.2.4 from upstream. That would give the impression that the source being packaged was “really” version 1.2.4 in some sense. I don't get the impression that's true here; the source is still version 1.2.3, just packaged in a different way. Assuming that's true, then I would append a conventional ‘.ds1’ or ‘.ds2’ etc. to the existing version, declaring the original source to be version ‘1.2.3.ds1’, to show it has been repackaged *and* should be considered later than ‘1.2.3’. Hence, the release would be version ‘1.2.3.ds1-1’. I figures the ~repacked~1.2.3 was probably enough of a tip off. Doesn't matter to me. Yours sort of works: b...@rei:~% dpkg --compare-versions 1.2.3.ds1-1 lt 1.2.4; echo $? 0 b...@rei:~% dpkg --compare-versions 1.2.3.ds1-1 lt 1.2.3.1; echo $? 1 Russ Allbery's is probably best: b...@rei:~% dpkg --compare-versions 1.2.3+real1-1 lt 1.2.4; echo $? 0 b...@rei:~% dpkg --compare-versions 1.2.3+real1-1 lt 1.2.3.1; echo $? 0 -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: On the htdig package
In 20100127104148.ga27...@mea.homelinux.org, Mats Erik Andersson wrote: Therefore I would appreciate a hint or two as regards to the use that Htdig finds within KDE-environments. Such knowledge would aid me in not polluting the system with new bugs after resolving any issues within Htdig. It it used by the help system to search and index all the installed help files. I think upstream should probably stop depending on it, and start using the Akonaki framework to handle those tasks. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: On intermediary deb-releases, their archiving.
On Thursday 21 January 2010 17:51:28 Mats Erik Andersson wrote: in trying to disect an RC-bug I find myself wanting to compare, using debdiff, two immediate successor packages, like this_1.20-15.dsc and this_1.20-16.dsc. However, for the particular package in question Lenny has 1.20-13.1 and both testing and unstable share 1.20-16. These are available from the standard mirrors. Is there some location where one could, with some luck, encounter also the intermediary packages that have been superseeded with time? Or are such packaged quickly pushed into oblivion? Normally, I'd recommend snapshot.debian.net, but I believe it ran out of space last year and can no longer provide this service. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Packaging
On Tuesday 17 November 2009 15:58:44 Juan Cruz wrote: Hi everybody, I'm new developing for linux. I'm developing a new application written on python, and i don't know how to make a .deb from it and how to upload my application to your repositories. I'll appreciate if somebody can help me. First, read the documentation. After that, if you have specific questions, we'd be happy to help. http://www.debian.org/doc/ is the portal to Debian documentation. You need to read the Debian New Maintainers' Guide and also look over the Debian Policy Manual and Debian Developer's Reference. The last two may contain some sections you can skip if they aren't relevant to your current package. If there's a python team (I think there is) you should probably work with them as well -- they may have even prepared python-specific policy documentation. TLDNR: RTFM N00B! -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Packaging
On Tuesday 17 November 2009 16:49:37 Francisco Rivas wrote: On Tue, Nov 17, 2009 at 11:23 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: TLDNR: RTFM N00B! is this necessary or are you kidding?.. :P Sorry, if it wasn't clear. I was just joking. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: About software from other distribution
On Tuesday 10 November 2009 10:39:58 Liang Guo wrote: Currently I'm using qspice, a Simple Protocol for Independent Computing Environments (SPICE) client as my console to connect to KVM. qspice is a utility from RedHat Enterprise Linux 5.4, and It is licensed under GNU GPLv2. qspice and related libraries can be downloaded from ftp://ftp.redhat.com/pub/redhat/linux/enterprise/5Server/en/os/SRPMS/ as SRPM format, may I package it for Debian ? It doesn't matter who upstream is, as long as the software is DFSG-free [1], the maintainer is willing to do the work, and it would be useful for Debian users [2] it can be considered for Debian. Even if it is not DFSG-free, it might be allowed in non-free. [1] In practice, patent or trademark claims could make something not DFSG-free even if the copyright holder uses a good license. Or, (ala PINE) the copyright holder could have an odd view of a normally acceptable license. [2] If there's already a package that fills the same role, your package might not be considered useful for Debian users. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: pidgin-skype
On Tuesday 03 November 2009 14:06:20 Patrick Matthäi wrote: Don Armstrong schrieb: $ dget -qux 'http://mentors.debian.net/debian/pool/contrib/p/pidgin-skype/pidgin-skyp e_0.1-1.dsc' $ strings pidgin-skype-0.1/icons/48/skypeout.png IHDR sBIT pHYs tEXtSoftware www.inkscape.org [...] This would mean, that it is created with inkscape, which could also save the files as svg. In this case, it would also mean the preferred form for modification is the inkscape native format. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: pidgin-skype
In 20091104001114.ga18...@kunpuu.plessy.org, Charles Plessy wrote: Le Tue, Nov 03, 2009 at 12:29:00PM -0800, Don Armstrong a écrit : You can deliberately destroy the source code of almost anything that we distribute in Debian. That doesn't change what the source code was. [And honestly, I'm not convinced that such deliberate destruction complies with DFSG §2 anyway.] If the Project is really serious about it, I have to declare a couple of RC bugs on some of my packages: I have sent manpages in Docbook and nroff format Upstream, and some of them discarded the Docbook source, since they are more comfortable editing the nroff source directly. At that point the nroff source may be the preferred form for modification. Basically you should include everything an isolated person might reasonably want in order to modify the software for their needs or the needs of others. It is a bit of a judgment call. If the Docbook is horribly out-of-date compared to the current nroff version, it wouldn't be the preferred form for modification. I would rather stick to the interpretation that the preferred form of modification is the one upstream uses, even if we think this is not optimal and we would prefer he had done another way. That's never been Debian's interpretation of the preferred form of modification. Hence the, *-firmware packages in non-free separated from the DSFG-free kernel in main. The final say goes to the maintainer(s) and, for new packages, the ftp- masters. However, violating the GPL (by not distributing the preferred from for modification) can be considered an RC bug (at the least) and may require your packages be moved to non-free for a release (at the least) or dropped from the repositories and their archives. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Lintian pickiness and packaging improvements
On Thursday 22 October 2009 22:37:54 Manoj Srivastava wrote: On Thu, Oct 22 2009, Raphael Geissert wrote: Manoj Srivastava wrote: I also think that style issues should not be a part of even Pedantic checks. If a package is using a different, and arguably better style, then lintian should keep its nose out. If there's a better style I guess nobody would object to consider recommend it or You are not getting it. Better is subjective. That's not always true. Better can be subjective, but it can also be objective. If a style scores better on all the metrics we care about that another style, it is objectively better. If a style has advantages over another, but the other does not have an advantage over the first, the first style is objectively better. You can have a dozen better styles, all contradictory. Are you planning on having checks that can never all be met simultaneously? That is what you get when you go for subjectively better styles. We shouldn't warn on subjectively better style, but be should warn on objectively poor style. Here is an excerpt from aptitude (lines edited to remove size and version info for email): --8---cut here---start-8--- i kernel-packageA utility for building Linux kernel related Debian packages. i module-assistant tool to make module package creation easier --8---cut here---end---8--- Frankly, I like the Package-Name: A short sentence with a period. way better. The front ends have never started to display the short descriptions as though they were noun phrases Neither of those are a sentence. The first lacks a verb (or verb phrase). The second also lacks a period and capital letter, but that actually makes it *easier* to use in an actual sentence, since it doesn't have to be modified to be used as a noun phrase. The first is clearly grammatically incorrect -- it can't be used unchanged in any grammatically correct structure. The second is not a sentence, but it is grammatically correct as it can be used unchanged in a grammatically correct structure. (In addition, it stands on its own as a noun phrase.) -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Lintian pickiness and packaging improvements
On Friday 23 October 2009 11:15:16 Manoj Srivastava wrote: On Fri, Oct 23 2009, Boyd Stephen Smith Jr. wrote: On Thursday 22 October 2009 22:37:54 Manoj Srivastava wrote: On Thu, Oct 22 2009, Raphael Geissert wrote: Manoj Srivastava wrote: I also think that style issues should not be a part of even Pedantic checks. If a package is using a different, and arguably better style, then lintian should keep its nose out. If there's a better style I guess nobody would object to consider recommend it or You are not getting it. Better is subjective. That's not always true. Better can be subjective, but it can also be objective. A packaging style, by definition, is subjective. I would not be called a style other wise. In our context style means a manner of doing things. They are *not* necessarily subjective (whatever that means) and they can be objectively analyzed and compared. If a style scores better on all the metrics we care about that another style, it is objectively better. If a style has advantages over another, but the other does not have an advantage over the first, the first style is objectively better. Given that we are talking about subjective issues to start with, the criteria for judging these are also subjective. The metrics are subjective, and the whole thing is hand waving and a wash of psuedo objectivity. Refuted above. There's nothing about the word style that implies the object it somehow outside the realm of reasoning and judgment. We shouldn't warn on subjectively better style, but be should warn on objectively poor style. I think that here objective and style is an oxymoron. Again, refuted above. Here is an excerpt from aptitude (lines edited to remove size and version info for email): --8---cut here---start-8--- i kernel-packageA utility for building Linux kernel related Debian i module-assistant tool to make module package creation --8---cut here---end---8--- Frankly, I like the Package-Name: A short sentence with a period. way better. Neither of those are a sentence. Shrug. I see it as I said: Package-Name: A short sentence with a period. While you correctly assert, somewhat pedantically, that A short sentence with a period. is not a sentence, I assert that it looks better. I state an objective fact, and am correct. You state a subjective opinion, and I disagree. (Yes, I'm being redundant on purpose.) The first lacks a verb (or verb phrase). The second also lacks a period and capital letter, but that actually makes it *easier* to use in an actual sentence, since it doesn't have to be modified to be used as a noun phrase. Irrelevant, seeing that in a decade and a half no one has done anything to take short descriptions into a sentence. I disagree. One has an objective advantage over the other -- it can be used in grammatically correct structures. Which one looks better is a subjective metric and shouldn't trump objective advantages. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: qemu-kvm (kvm)
On Friday 16 October 2009 10:52:26 Michael Tokarev wrote: There's a kvm package in debian, which is basically a modified qemu (system emulator) that supports virtualization extensions of modern CPUs. I maintain kvm package for my needs for a long time, in my local repository. I'm supporting users in kvm-dedicated IRC channel as well. And it's a real PITA to know that I have to refer to external repository (on my site) all debian users, because all their problems are resolved by upgrading to a new version which is not available in Debian. I wrote to debian kvm package maintainer several times, I submitted a bugreport against kvm long time ago, but never heard back. So now I'm requesting a sponsor to upload my packages into debian. If you are wanting to do a sponsored NMU (which is kind of odd), be sure you are very familiar with the NMU procedure http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu and the sponsorship process http://www.debian.org/doc/manuals/developers- reference/new-maintainer.html. The packages can be found here: http://www.corpit.ru/debian/tls/kvm/ I did not review your package. IANADD anyway. While at it, I applied to be a Debian Developer, to be able to maintain this and several other packages myself without a need for a sponsor. To be a Debian Developer, you need to be *very* familiar with a few documents: * Debian Reference * Debian Developer's Reference * Debian Policy Manual * Debian Menu System They are long and dense. You might want to start with some lighter introductions, but you cannot stop there: * Debian New Maintainers' Guide * Introduction to i18n Finally, there may be specific policy documents that apply to the package(s) you are most interested in. For example, maintainers of java-related packages should be familiar with the Debian GNU/Linux and Java FAQ. All of these documents are available from http://www.debian.org/doc/. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: NMU for libkarma (Rio Karma tools)?
On Wednesday 14 October 2009 15:42:21 Harald Dunkel wrote: On 10/12/09 07:02, Charles Plessy wrote: Fixing bugs is very welcome, especially RC ones. Actually, you can save time to fix more RC bugs by not fixing the less important ones in the packages that you try to rescue :) I still recommend to not include a new upstream release in the NMU you are proposing. Especially because the package is poorly maintained: the side effect of the NMU is to rescue the package from removal, so if nobody feels responsible for it, it is safer to not introduce changes that can introduce new bugs. Sorry to say, but this is counterproductive. AFAICS the new upstream version works better than the old one, and it includes almost all bug fixes done for Debian. If you suggest to ignore upstream's new version and add patches to the old version instead, just because the package maintainer is not interested anymore, then this leads to just another dead package. I want to do an NMU _because_ the package is poorly maintained. libkarma has to be rescued. There is no alternative to this package. There is a established procedure for taking maintainership for a package from a non-responsive maintainer. If you'd like to take maintainership, please start that process. In the meantime a suitable NMU should be prepared until (if) you become the maintainer. If you don't have time, I wonder if this is a good place for collab-maint to step in? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: multiple database support with dbconfig-common : metapackages ?
On Monday 28 September 2009 15:09:15 Jérémy Lal wrote: Instead of depending on : sqlite3 | postgresql-client | mysql-client, libdbd-sqlite3-ruby | libdbd-pg-ruby | libdbd-mysql-ruby as bugzilla, drupal, and others do, which i think is confusing the user; is it desirable to do as roundcube package, i.e. providing three metapackages ? Each package providing the correct dependencies for each db type. Then it would give : redmine depends on redmine-mysql | redmine-pgsql | redmine-sqlite IANADD, TINASOODP. As a user, I think you are on the right track here. The first set of dependencies would be satisfied by sqlite3 and libdbd-pg-ruby, which might leave redmine installed but completely non-functional. AFAIK, there's no way to express (pkg1 pkg2) | (pkg3 pkg4) without the intervening meta- packages. However, I am a bit surprised that you need to depend on both libdbd-pg-ruby and postgresql-client. Shouldn't libpq5 (desciprion: PostgrSQL client libraries), brought in as a dependency of libdbd-pg-ruby be enough of a client? postgresql-client is only the front-end binaries. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Problem with debian/rules
In cfb54190909080619y7b60afd4ucbdf6d9cfe0b9...@mail.gmail.com, Hai Zaar wrote: On Tue, Sep 8, 2009 at 3:49 PM, Mathieu Malaterremathieu.malate...@gmail.com wrote: nawk -f ../../.././libsrc/support/strval.awk \ role=declare outname=strvalc ../../.././libsrc/standard/strval.tpl strvalc.h nawk: cannot open /dev/tty for output (No such device or address) Wild guess: if you run build from chroot, then probably your /dev (under chroot) is not populated, thus awk can not access /dev/tty. Either that or your chroot is in a nodev mount point. Then the device will exist, but won't work. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: How to detect 32 or 64 bit at build time?
In 20090908085536.gb3...@jwilk.net, Jakub Wilk wrote: autoconf-build == DEB_BUILD_* (the machine the package is built *on*). autoconf-host == DEB_HOST_* (the machine the package is built *for*). autoconf-target should be irrelevant as long as you don't (cross-)compile compilers. Even then it shouldn't matter unless you are cross-compiling a cross-compiler. Normally a compiler will output executables for its host [the system it was built for; the system it is running on] but if it needs to output executables for a different system, you can specify the target [the system it's output is built for]. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: sqlkit
On Friday 04 September 2009 13:14:43 Alessandro Dentella wrote: On Fri, Sep 04, 2009 at 05:54:17PM +0200, Laszlo Boszormenyi wrote: necessary to depend on all SQL related Python support packages? Some may need it for PostgreSQL only and pulling in MySQL related packages is a bit of overkill. Consider an 'or' dependency of PostgreSQL and MySQL. I put only the 2 very popular ones, sqledit supports many more. At the beginning I just put postgres and mysql driver in 'Suggest' but I think that in front of a very limited disk saving we could just create a probelm to not expert users that could miss the explanation of what is missing: both of them are less than 0.5 MB once installed. So I'd really prefer to leave those 2 drivers as dependencies. Recommends, right? As a user it annoys me to no end when the packager Depends on something the system will work without; I end up having to roll my own packages to get the small footprint I desire. With recommends, newbie and novice users will get the packages, and one of the first things you learn in wrangling apt-get/aptitude is how to not install Recommends by default. Depends: $mysql_pkg | $postgres_pkg | $other_pkgs Recommends $mysql_pkg, $postgres_pkg, $other_pkgs is ideal, I'd think. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Issue with dpkg-shlibdepds
In 20090901055635.gc6...@glandium.org, Mike Hommey wrote: On Mon, Aug 31, 2009 at 04:03:06PM -0700, Joe Smith wrote: Another issue sprung up, though. What I need to be able to do now is have libngi3 (0.8) and libngi3 (0.9) installed at the same time. They don't share any binaries that are the same. Why would you want that, actually ? Most of the time, this is not something you'd want. If they are compatible, you don't even need that. If they are not compatible, then the SONAME should be changed, not the package name. However, changing the (binary) package name could possibly allow side-by-side installation of the old ABI and the new ABI. This may be desirable in the short term for any library. For the long-term, multiple source packages will probably be required. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: nautilus-dropbox
In 85c01b290909010539g4db763d2w52c90a1b68bc4...@mail.gmail.com, Kartik Mistry wrote: * debian/copyright: All images included in this package constitute data and are not licensed for you to use under the terms of the GPL. You may not use the images included in this package for any reason other than redistributing this package without first obtaining permission from Evenflow, Inc. You are explicitly forbidden from using these images in any other software package. I am not sure this is Ok with DFSG. Please check before putting it in package. Definitely not. The images are under a (restricted) redistribution-only license. They could be put into non-free, but they certainly can't reside in main. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Issue with dpkg-shlibdepds
First of all, TOFU is generally frowned upon as a posting style on technical mailing lists. Second, IANADD and TINASOTODP; I speak only for myself. On Tuesday 01 September 2009 08:55:45 Joe Smith wrote: We're making a set of interface libraries for use in cross-platform application development. We want to 100% guarantee that if an application is compiled against a particular version of the library, then it's guarateed to work indefinitely with the same level of functionality. I think this is an unreasonable goal. That said, even if it is to remain the goal it should be implemented through disciplined library development and a thorough test suite, not through the linker. You *should* use the linker to retain backward compatibility (symbol versioning) and you *should* use other technical means to detect ABI changes before a release. As such, we can't upgrade the libraries underneath or we risk regression. This is misguided. If there is a security issue in the library, it needs to be able to be fixed in one place without recompiling all the programs that use the library. Plus this way we can break binary compatibility without issue between versions. While I guess it makes the library user happy, it will not make the application developers or packagers happy. Also, having so many versions that appear incompatible to the linker when they are actually compatible defeats the purpose of shared libraries; applications are much less likely to share them. This increases both RAM and HD usage needlessly. The increased RAM usage can also cause longer run times indirectly as there are more cache misses. The other problem is that applications built against different versions can be installed at the same time, and thus different versions of the actual libraries themselves must also be installed at the same time. For this, I don't see how we can get around it with a single package name. You might be able to have a single source package, but most likely you will need a different source package for each version. The other option is to forget packaging altogether for the libraries and package them with each application instead, but it would be more work for the application developer to deal with that. It would also be more work for the security team. You might be able to use static linking, but that's generally frowned upon on Debian. Shipping the library along-side the application is also generally frowned upon. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Issue with dpkg-shlibdepds
On Tuesday 01 September 2009 12:54:21 Mike Hommey wrote: On Tue, Sep 01, 2009 at 07:45:53AM -0500, Boyd Stephen Smith Jr. wrote: In 20090901055635.gc6...@glandium.org, Mike Hommey wrote: On Mon, Aug 31, 2009 at 04:03:06PM -0700, Joe Smith wrote: Another issue sprung up, though. What I need to be able to do now is have libngi3 (0.8) and libngi3 (0.9) installed at the same time. They don't share any binaries that are the same. Why would you want that, actually ? Most of the time, this is not something you'd want. If they are compatible, you don't even need that. If they are not compatible, then the SONAME should be changed, not the package name. [C]hanging the (binary) package name could possibly allow side-by-side installation of the old ABI and the new ABI. It doesn't possibly allow it, it *does* allow it, since different ABIs *must* have different package and library names. If the library package also ships utility binaries or data[1], changing the binary package name would not allow side-by-side installation since the packages would still conflict. I was speaking in the general case. For this package, separate binary package names (and SO_VERSIONs) will all side-by-side installation. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ [1] For example, because they are/were too small to in a separate binary package. signature.asc Description: This is a digitally signed message part.
Re: Taking care of existing packages
In 20090821160945.gb22...@belanna.comodo.priv.at, gregor herrmann wrote: I just think we also have to keep in mind that the proverbial itch that new contributors are trying to scratch, i.e. why they want to help in Debian in the first place, is that they are missing a piece of software they use or would like to use. I'm not sure that's the most common itch anymore. I think more often it is that they want faster releases or bug fixes. Either that or continued availability of packages that are RFA, ITO, or O. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Upstream dedicated system and Debian adaptation
In 20090820120036.ga4...@portable.home.famille-guignard.org, Laurent Guignard wrote: I am the maintainer of a package (dhcp-probe [1]) which is an upstream dedicated software (Solaris dedicated). A function doesn't work on Linux system based and give the bug [2]. To solve this bug, i need detailled documentation about ioctl C function and SIOCGIFCONF and SIOCGIFADDR parameters of this function. The canonical reference for ioctl is http://www.opengroup.org/onlinepubs/009695399/functions/ioctl.html [registration required]. That does not cover SIOCGIFCONF and SIOGIFADDR, as those appear to be extensions, perhaps Solaris-specific. For Linux, the best documentation is probably man 2 ioctl, man 2 ioctl_list, and the glibc and/or kernel source. For the other Debian libcs/kernels, I do not know. [1] : http://packages.qa.debian.org/d/dhcp-probe.html [2] : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535361 -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Taking care of existing packages
In 20090820133354.gb2...@ime.usp.br, Rogério Brito wrote: The reason why I posted to both is that I see a trend in -mentors that many new contributors seem to create an artificial need as a reason to get their contributions in the distribution and choose to package a new program. Instead your first step should be running wnpp-alert and helping maintain a package you already have installed. If you are lucky enough to have nothing reported by wnpp-alert or just can't help there, rc-alert is also a good place to start. Both of these tools should be better publicized. New packages are fine, but there seems to be a constant need for more maintainers of the packages that already exist. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: libsockets++
In 1250657058.4171.63.ca...@salfrancl.ipigto.rimed.cu, Leinier Cruz Salfran wrote: - you add change license stuff in debian diff without any explanation I made one change in the license (debian/copyright): the openssl library exception did I made something wrong? i followed [1] The only entity that can change/amend the license of a piece of software is the copyright holder. You should get the upstream author to make this change and prepare a new upstream version that you can package. If upstream is resistant to releasing a new version for the licensing change, but are willing to amend the license, include some sort of witness (usually, an email) testifying to upstream willingness in the debian source package and then make the change -- preferably using a patch system, although that may be considered overkill if it is the only change you are making. [1] http://lists.debian.org/debian-legal/2004/05/msg00595.html -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: task-spooler
In 20090804100620.ga8...@shurick.s2s.msu.ru, Alexander Inyukhin wrote: Socket permissions are controlled by umask, but if security matters, a more sophisticated way of managing sockets should be used. Since task-spooler is intented for use in single user environment, I do not think this is a serious issue. Unfortunately, Debian is not limited to use as a single-user environment so you may need to revisit the security implications. At the very least, you may want to warn the administrator that it is not suitable for multi-user environments. Any reason task-spooler can't secure it's sockets the same way ssh-agent and/or gpg-agent secure theirs? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Automated package build-and-test tools for Debian package maintainers (was: pbuilder: The following packages have unmet dependencies)
In 87bpmvsux5.fsf...@benfinney.id.au, Ben Finney wrote: That is, if I'm maintaining packages for Debian and want to build and test them in an easy and automated manner, what tools are available (‘pbuilder’, ‘sbuild’, ‘cowbuilder’, …) and for each of them why would I choose that one? There's really only two that I know of. pbuilder (and variants: qemubuilder, cowbuilder, etc.) and sbuild. ISTR, sbuild is used on the buildds, but all my experience is with pbuilder. I find it incredibly flexible when needed but also very easy to get started with a minimum of documentation reading. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: task-spooler
In Tuesday 04 August 2009, you wrote: On Tue, Aug 04, 2009 at 09:52:23AM -0500, Boyd Stephen Smith Jr. wrote: In 20090804100620.ga8...@shurick.s2s.msu.ru, Alexander Inyukhin wrote: Socket permissions are controlled by umask, but if security matters, a more sophisticated way of managing sockets should be used. Since task-spooler is intented for use in single user environment, I do not think this is a serious issue. Unfortunately, Debian is not limited to use as a single-user environment so you may need to revisit the security implications. At the very least, you may want to warn the administrator that it is not suitable for multi-user environments. Any reason task-spooler can't secure it's sockets the same way ssh-agent and/or gpg-agent secure theirs? Actually, it can. It is just not the default behavior. User may override socket location via environment variables TMPDIR or TS_SOCKET. As with gpg-agent, this requires additional setup. Hrm, I'm not using any special GPG settings and my socket resides in /tmp/gpg-6qK7UK/S.gpg-agent; my ssh-agent is in a similar location. Creating socket with predefined name in user's home directory seems to be a better choice. Is there any policy rules about socket naming? I think secure-by-default would be the better choice. I don't know what kind of information is passed over the socket, but if it is in a (group/world) writable directory[1] or (group/world) readable/writable itself it is possible a local attacker could hijack the connection. As far as I know there is no policy. I'm not a DD and speak only for myself. I don't mean to hold up the sponsoring of the package if my issues don't bother the sponsors. Creating the socket as mode 600 in the user's home directory seems relatively safe, but isolating it in a mode 700 directory doesn't seem like a bad idea. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ [1] I suppose a user's home directory might be group writable, but that seems unusual. signature.asc Description: This is a digitally signed message part.
Re: git-buildpackage issues
In bf0c3b3f0908030548q79d2b647rfa40ee427d7a1...@mail.gmail.com, Mathieu Malaterre wrote: $ \rm -fr rsvndump $ mkdir rsvndump $ cd rsvndump $ git init Initialized empty Git repository in /home/mathieu/Perso/gdcm/Sandbox/debian-med/build-area/rsvndump/.git/ $ git-import-dsc --pristine-tar ../rsvndump_0.5.2.dsc Repository has uncommitted changes, commit these first: # On branch master # # Initial commit # nothing to commit (create/copy files and use git add to track) git-import-dsc will create/initialize the git repository if it doesn't already exist. Otherwise, the working copy must be clean, which means the most recent commit (.git/HEAD symref) matches the index and working copy (file system tree ignoring .git and pathnames matching a .gitignore entry). This can't happen with a just created/initialized git repository because it doesn't have a most recent commit. It has no commits; the .git/HEAD symref is invalid/missing. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: MUMmer patches and Artistic license.
In 20090728163525.gc31...@an3as.eu, Andreas Tille wrote: On Sun, Jul 12, 2009 at 10:50:10PM +0900, Charles Plessy wrote: This patch is a good idea -- fixed length buffers are rarely considered user-friendly. However, it is executed poorly; it's not ready for upstream in its current state. Hi, thank you for the comment. I will stop to apply this patch until a better solution is found. Quite late comment after working down my batch of unread mail: The patch was *not* *only* to avoid fixed length buffers - it was invented to stop mummer from *crashing*. In that case I recommend leaving the patch applied, opening a bug, and assigning it to me. I can re-write the patch to avoid having statements with side-effects inside assert() calls. I may be able to reply with a corrected patch later today. P.S. Please CC me if you drop debian-mentors, I am not subscribed to debian-med. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: MUMmer patches and Artistic license.
In 200907281303.42301@iguanasuicide.net, Boyd Stephen Smith Jr. wrote:
In 20090728163525.gc31...@an3as.eu, Andreas Tille wrote:
On Sun, Jul 12, 2009 at 10:50:10PM +0900, Charles Plessy wrote:
This patch is a good idea -- fixed length buffers are rarely
considered user-friendly. However, it is executed poorly; it's not
ready for upstream in its current state.
Hi, thank you for the comment.
I will stop to apply this patch until a better solution is found.
Quite late comment after working down my batch of unread mail:
The patch was *not* *only* to avoid fixed length buffers - it was
invented to stop mummer from *crashing*.
I may be able to reply with a corrected patch later today.
Attached is my new patch that removes the errors I saw in the original
patch. I welcome any comments on the new patch.
I've also attached a interdiff between the old and new patches for
reference.
In case anyone feels this work is copyrightable[1], I license my
contributions under the same license as the original patch.
P.S. Please CC me if you drop debian-mentors, I am not subscribed to
debian-med.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
[1] I don't.
Description: Dynamically allocates space for the strings, instead allocating a predefined size.
Origin: vendor : Debian
Bug: https://sourceforge.net/tracker/?func=detailaid=1215086group_id=133157atid=726404
Index: ./src/tigr/annotate.cc
===
--- ./src/tigr/annotate.cc
+++ ./src/tigr.orig/annotate.cc
@@ -10,6 +10,7 @@
*/
#include tigrinc.hh
+#include assert.h
#define FIELD_LEN 20
#define MAX_ALIGN 1
@@ -138,19 +139,26 @@ void Show_Alignment (char A [], long in
// Print the alignment between strings A [1 .. M] and B [1 .. N] .
{
- static int D [MAX_ALIGN] [MAX_ALIGN];
- static char Op [MAX_ALIGN] [MAX_ALIGN];
- static char Show_A [2 * MAX_ALIGN];
- static char Show_B [2 * MAX_ALIGN];
+ int **D, *D_buf;
+ char **Op, *Op_buf;
+ char *Show_A;
+ char *Show_B;
int Errors, Tmp;
long int i, j, Ct;
- if (M = MAX_ALIGN || N = MAX_ALIGN)
- {
-printf (\n *** Too long ***\n\n);
-fprintf (Gaps_With_Errors_File, %s %7s\n, Line, -);
-return;
- }
+ assert ( SIZE_MAX / (M+1) = (N+1) ) ;
+ D_buf = (int *) calloc ( (M+1)*(N+1), sizeof(int) ) ;
+ assert ( D_buf ) ;
+ D = D_buf ;
+ Op_buf = (char *) calloc ( (M+1)*(N+1), sizeof(char) ) ;
+ assert ( Op_buf ) ;
+ Op = Op_buf ;
+
+ assert ( SIZE_MAX 1 = (M+1) ) ;
+ Show_A = (char *) calloc ( 2*(M+1) , sizeof(char) ) ;
+ assert ( Show_A ) ;
+ Show_B = (char *) calloc ( 2*(N+1) , sizeof(char) ) ;
+ assert ( Show_B ) ;
D [0] [0] = 0;
Op [0] [0] = 'a';
@@ -229,5 +237,10 @@ void Show_Alignment (char A [], long in
putchar ('\n');
Ct -= WIDTH;
} while (Ct 0);
+
+ free ( D_buf ) ;
+ free ( Op_buf ) ;
+ free ( Show_A ) ;
+ free ( Show_B ) ;
return;
}
diff -u ./src/tigr/annotate.cc ./src/tigr.orig/annotate.cc
--- ./src/tigr/annotate.cc 2007-11-07 21:47:03.0 +0100
+++ ./src/tigr.orig/annotate.cc
@@ -146,12 +146,19 @@
int Errors, Tmp;
long int i, j, Ct;
- assert ( D_buf = (int *) calloc ( (M+1)*(N+1), sizeof(int) ) ) ;
+ assert ( SIZE_MAX / (M+1) = (N+1) ) ;
+ D_buf = (int *) calloc ( (M+1)*(N+1), sizeof(int) ) ;
+ assert ( D_buf ) ;
D = D_buf ;
- assert ( Op_buf = (char *) calloc ( (M+1)*(N+1), sizeof(char) ) ) ;
+ Op_buf = (char *) calloc ( (M+1)*(N+1), sizeof(char) ) ;
+ assert ( Op_buf ) ;
Op = Op_buf ;
- assert ( Show_A = (char *) calloc ( 2*(M+1) , sizeof(char) ) ) ;
- assert ( Show_B = (char *) calloc ( 2*(N+1) , sizeof(char) ) ) ;
+
+ assert ( SIZE_MAX 1 = (M+1) ) ;
+ Show_A = (char *) calloc ( 2*(M+1) , sizeof(char) ) ;
+ assert ( Show_A ) ;
+ Show_B = (char *) calloc ( 2*(N+1) , sizeof(char) ) ;
+ assert ( Show_B ) ;
D [0] [0] = 0;
Op [0] [0] = 'a';
signature.asc
Description: This is a digitally signed message part.
Re: RFS: deejayd (updated package)
In h49gnk$6n...@ger.gmane.org, Raphael Geissert wrote: Alexandre Rossi wrote: And the script doesn't correctly handle the case where the default file has been removed (it expects the vars to be always defined). The Xsession script doesn't handle an unset DEEJAYD_DISPLAYNAME and DEEJAYD_XAUTHORITY vars either. [ -r ] is evaluated to true. [ -r ] behaves correctly both with bash and sh on my lenny box. Not sure I understand what to do here. What I meant was that: $ foo=/foo/bar; [ -r $foo ] echo hello world Looks normal, assuming /foor/bar doesn't exist on your system. $ unset foo; [ -r $foo ] echo hello world hello world $ unset foo; [ -r $foo ] echo hello world nothing Both these are required behavior by SUSv2. In the first, you are passing 2 arguments to the '[' command, after removing the trailing ']' only one argument remains. In that case the '[' (or test) command is required to return 0 (succeed) if the argument is non-empty and return non-0 (fail) if the argument is empty. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Nomeclator of plugins
In 200907221847.44193@alaxarxa.net, Leopold Palomo-Avellaneda wrote:
I think I have not seen it in the Debian policies. I have a dual role in
one application: developer and co-maintainer. I would like to ask one
question that fits in both.
I'm in the bulmages project. It's a big piece of software with several
applications with libs and plugins. It's a cmake build project. The
plugins we have are lib.so. I add the properties (soname and version)
to the plugins as the project main properties. The packages consist in
several packages, etc.
The second, and it's my main question is about the nomenclature of the
plugins. The guy says that the Suse force to create a package -dev if you
have this kind of things (.so and symbolic links -.so.x.y.z). But I did a
package for some .so (-dev) of the software, but not for all. Do we have a
similar rule?
Something like that.
(IANADD)
A library package should install lib$SO_NAME.so.$SO_VERSION and be called
lib$SO_NAME$SO_VERSION.
The -dev package for that library should Depend on the library package,
install lib$SO_NAME.so as a symlink to the actual library (provided by the
library package), and be called lib${SO_NAME}-dev.
This allows multiple (major) versions of the library package to be
installed, so that package with binaries that haven't made the transition
can still run and Depend on the only version.
You might even consider making the SO_VERSION part of the lib*-dev package
name.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
In 20090719235708.gb22...@resivo.wgnet.de, Jonas Meurer wrote:
- in cryptdisks_{start|stop} only one device is setup anyway. here I
simply don't use set -e and check for the error code instead.
While I understand your goal here, I think you should try and accomplish it
while leaving the entire script set -e. It helps prevent errors from
cascading. Even if you are checking return values for everything now, you
might not be so disciplined with changes in the future.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: shell kung-fu with set -e, return codes and i/o redirection in while read ... loop
In 20090719114552.ga15...@resivo.wgnet.de, Jonas Meurer wrote: so second thought was to use return codes inside the while loop and check for them after the while loop. but that failed due to 'set -e' being set. therefore any return code != 0 caused the script to stop immediately instead of just exiting the while loop. If you use the command in an if/while/until statement, it can fail without terminating the script, even when the -e shell option is set. You might be able to use something like: while something; do if cmd_that_can_fail; then :; else # Just can check $? if you want # to know the exact return code. # Print a warning, but continue fi done only one issue remains that still doesn't work as expected: if handle_crypttab_line_start fails with a warning, it still returns 0 (success) as return code. That warning seems more like an error to me -- the function fails. unfortunately I don't see an option t change that one. in initscripts it would be fatal for handle_crypttab_line_start to exit with any return code != 0 as that would cause the whole initscript to stop instead of processing the remaining crypt targets. Using something like the above you should be able to try to mount the all entries, print a warning for each one that fails, and then return an appropriate code to indicate success/partial success/failure. \-- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: nzbget
In 79052f10907160827r1a56c6apa25dc910f42f5...@mail.gmail.com, Andreas Eriksson wrote: Everything seems to check out when running lintian, except the new-package-should-close-itp-bug thing, since there is no bug. I'm not sure how to create a bug like that, and would like some help with it. http://www.debian.org/devel/wnpp/ is the start page for that. If you have more specific questions, please let us know. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: MUMmer patches and Artistic license.
In 20090704120642.gh6...@kunpuu.plessy.org, Charles Plessy wrote: we have a patch in the Debian package mummer for which we lost origin and detailed description. I would like to forward it upstream, but I would prefer to know what it does before ;) Would somebody have a few minutes to throw an eye on it? It is in our SVN, and here is a copy: http://svn.debian.org/wsvn/debian-med/trunk/packages/mummer/trunk/debian/p atches/01sm_src_tigr.diff + assert ( D_buf = (int *) calloc ( (M+1)*(N+1), sizeof(int) ) ) ; + D = D_buf ; + assert ( Op_buf = (char *) calloc ( (M+1)*(N+1), sizeof(char) ) ) ; + Op = Op_buf ; + assert ( Show_A = (char *) calloc ( 2*(M+1) , sizeof(char) ) ) ; + assert ( Show_B = (char *) calloc ( 2*(N+1) , sizeof(char) ) ) ; Four out of these six lines are bugs waiting to happen. If NDEBUG is defined, the calls to calloc will be completely elided. Then you'll have a number of uninitialized pointers that are used here: D [0] [0] = 0; Op [0] [0] = 'a'; This patch is a good idea -- fixed length buffers are rarely considered user-friendly. However, it is executed poorly; it's not ready for upstream in its current state. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: non-native package versions
(IANADD; TINASOTODP.) In 135eeb1d0906300927x47149b60x74e8194e76a17...@mail.gmail.com, Juan Jesús Ojeda Croissier wrote: Hi :-) Before nothing, sorry for my mistakes about mount-systray ackage and the native and non-native packages. Your comments and the mentor's FAQ help me a lot. Well, I have one doubt about the version. What I understand from the policy[1] is that for the package mount-systray, the version should be something like: mount-systray-0.5.3-1 uptream version = 0.5.3 debian version = 1 But then lintian tells me I need a *.orig.tgz (which I haven't) or if I created a *.orig directory, then tells me the diff is empty and so on. $ pwd ~/my-new-package_0.4.5-1 $ cd .. $ cp -Rl my-new-package_0.4.5-1 my-new-package_0.4.5.orig $ rm -rf my-new-package_0.4.5.orig/debian Now, you'll have a non-empty diff. Remember, though, that 0.4.5-2 must be based on the same .orig.tar.gz and that you should avoid making changes outside of the debian directory in your .diff.gz. If any changes are required, use a patch system. I (or actually we - Guadalinex team) am upstream and we maintain the code with the debian files all together. I know that it's better not to do that and separate the code and the debian files, but, at least by now, we have that way. That happens. It's even appropriate for you to maintain a debian/ directory in your VCS. It should be kept out of the release tarball, but the build system can handle it even if it isn't. The thing is if I put the version like 'mount-systray-0.5.3debian1', which I have seen in some packages, lintian doesn't say a word. That would still be a native package by my reckoning, which is not what is appropriate for this package. [D]o I really need to separate the app code from the debian packaging files? isn't there another option? The other option is native packaging. However, I think we've already covered why that isn't appropriate for this package. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: non-native package versions
In 20090630183826.gf4...@hezmatt.org, Matthew Palmer wrote: On Tue, Jun 30, 2009 at 07:23:38PM +0100, Juan Jesús Ojeda Croissier wrote: On Tue, Jun 30, 2009 at 6:28 PM, Chow Loong Jinhyper...@gmail.com wrote: On Wednesday 01,July,2009 12:27 AM, Juan Jesús Ojeda Croissier wrote: [D]o I really need to separate the app code from the debian packaging files? isn't there another option? I guess we'll have to slit them :-/ You don't. You just have to release the tarball without it (the debian/ directory). I know of applications which have the debian/ directory in the upstream source code, but generate tarballs without them. The problem we have right now is that we don't really use tarballs for release our apps. Well, you're going to have to fix that before you can get a Debian upload, at any rate. Not really. The .orig.tar.gz could be a VCS snapshot. It just needs to be named appropriately and (preferably) be reproducible if lost. If upstream doesn't normally release tarballs, a get-orig-source target is virtually mandatory since this package would be very hard to maintain without it. You can't upload a VCS revision as a source package (yet). Is this a thinly-veiled reference to the new source package format? If it is, do you know of any page on the Internet that gives the status of this project? -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: mount-systray
In 135eeb1d0906250600y552b3c5du980a01d3e3d3e...@mail.gmail.com, Juan Jesús Ojeda Croissier wrote: On 24 jun, 21:40, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: In 135eeb1d0906241156q69cfcf9fqeb7bfbe733ddc...@mail.gmail.com, Juan Jesús Ojeda Croissier wrote: * The version numbering is for native package without reason. Well, this is a native package, I think. If you can think of *any* reason that openSUSE, Fedora, or Gentoo would want to use the software (albeit with different packaging) you should use normal (non-native) packaging. This software was created for a Debian-derived distribution (Guadalinex). Maybe it's possible to change the packaging or compile from the sources, but it wasn't the initial idea and it is not supported by us. It is software for a Debian-derived distributions. It doesn't matter if you thought about doing it, or if you support it. The is free software (right?), so someone could take it upon themselves to package and support it for a non-Debian-derived distribution. If that even makes sense, then the package should be a normal (non-native) package. Even if the package is quite Debian-specific, if it is possible to separate the packaging from the software there are other advantages to normal (non-native) packaging. Out of the 45 packages that start with apt, most of which would be fairly useless in a non-Debian-derived distribution, less than half are native. Using very rough methods, it looks like only 1044 out of 26923 packages available in main (stable+security+volatile+testing+testing- security+unstable+experimental) are native and I'll wager some of those could be usefully converted to normal packaging. Probably, if more distros (Debian, Ubuntu, LinEx, Molinux and others Debian-derived distributions) start to use it and we see other distros like to use it, we'll convert it into upstream project (maybe in GNOME) and the package will be changed into non-native one. Converting back and forth is even worse than being a native package. If there's a possibility that the package could be usefully converted into a normal (non-native) package in the future, that is reason *enough* to have it be a normal (non-native) package now. But by now we can't assure that the code itself will work in another distro. We haven't tried it, neither we have prepared it for supporting it. No one is asking you to. If you guys still see this as a non-native package, we'll change it, but IMHO, at least right now, it is a native package. No, it shouldn't be a native package. I'll admit that the rules are a bit subjective. However, I don't want to bother packaging for any other distribution right now is definitely *NOT* a reason to to make the package native. Normal (non-native) packaging is the default; you need a good reason to make the package native. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Adopting package
In d3150baf0906250848g107d1012k1a2196d7b1b84...@mail.gmail.com, Adrian Perez wrote: What's the content of the copyright file if I'm adopting a package? Same as for any other package and documented in policy. Do you have a specific question? It's the previous maintainer or myself whom is stated there? For the packaging copyright, it would be the previous maintainer for the years they maintained it and your copyright for the years you maintained it. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: mount-systray
In 135eeb1d0906241156q69cfcf9fqeb7bfbe733ddc...@mail.gmail.com, Juan Jesús Ojeda Croissier wrote: * The version numbering is for native package without reason. Well, this is a native package, I think. Maybe I'm wrong with the meaning of that but the sotfware was created for Guadalinex and it came with the packaging stuff. It not an upstream projects that we're packaging. Please, tell me if I'm wrong. You are wrong. :P To use native packaging instead of normal packaging, the software should be of virtually no possible use to non-Debian-derived distributions. If you can think of *any* reason that openSUSE, Fedora, or Gentoo would want to use the software (albeit with different packaging) you should use normal (non-native) packaging. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Creating a transition package for source and binary switching
In 200906200345.35499.peter.fritzs...@gmx.de, Peter Fritzsche wrote: The idea behind it is that the 3: can go away No, it can't. The part before the first colon is the epoch and it is assumed to be 0 for any package that doesn't have one. Therefore any version without an epoch will be considered to be a lower version (that 3:1.1-2) by dpkg and any higher-level tools, including apt. Once an epoch is in place, it is required to stay. That's one reason the should be avoided if possible. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: Packaging data for a CGI
In 20090620133708.gc1...@straylight.m.ringlet.net, Peter Pentchev wrote: On Sat, Jun 20, 2009 at 08:39:46PM +0800, Paul Wise wrote: On Sat, Jun 20, 2009 at 6:52 PM, Peter Pentchevr...@ringlet.net wrote: Your package should place the files into /usr/share/hoogle/www/. After that, it should either create a file in /etc/apache2/conf.d/ containing something like this (that's what phppgadmin does): Alias /hoogle /usr/share/hoogle/www/ Uhh, doesn't that mean the package will clobber /hoogle for every vhost on the server? Actually, it does Alternatively, you could put it as a file in /etc/apache2/sites-available. Then it can easily be enabled if the administrator desires, but it is disabled by default. Debian.README should document that fact, but experienced Apache 2.x on Debian administrators will find it right away. If it isn't appropriate to activate in any non-trivial environment, it might be better as /usr/share/doc/hoogle/apache.conf.example -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: package advices
In 4a389c05.3050...@gulfsat.mg, Rakotomandimby Mihamina wrote: Hi Still learning to package... ;-) I would like to make a package that I will install in a set of servers. Let's call it admins_ssh_keys As Ben mentioned this isn't a valid package name. Replace the underscores with hyphens and it's fine. This package is the set of public keys of admins in my department. I would like then to install admins_ssh_keys then it: a - creates the right users b - copies the public keys into each $USER/.ssh c - modifies sshd_config in a way that c1 - Password acces is disabled c2 - Only auth by Key is enabled d - puts the users in the right group (admin) e - depends on a set of packages usefull for our admins These goals can't be cleanly handled by the package manager. As such, it couldn't be an official Debian package. That said, if you'd like to (ab)use the package system to do this it is possible. I'd recommend against it, though. Mainly because packages need to be designed to be removed. In particular, a package *should* revert most (if not all) of the changes it makes during install if it is removed/purged. It's not clear that these actions can be cleanly reversed or even if they should ever be reversed. Instead, I think you might make a $org-admin-scripts package that contained (among other things) a script do make these changes that is run manually and Depends on all the tools required to do so. Then a second package $org- admin-tools that Depends on $org-admin-scripts and all the Debian packages your organization expects. The rest of my advice is for if you decide to make this a package, despite my and Ben's recommendations. Well... For a, b, c, and d: should it be just a post intallation action? I'd handle (a) in your preinst, and not remove the users as part of removing/purging/upgrading the package. This would leave users behind, but I think that's better than having the package remove users you (might have) created manually. Or, heaven forbid locking you out of the system by removing your only login path. (b), (c), and (d) would be part of your postinst. (b) can be applied with a simple append operation and reverted with a good sed. (c) is easy enough to apply with sed and append operations, but virtually impossible to revert. It's also a conffile handled by another package, so it's not really a good idea to have your package affect it. (d) is in the same boat as (a). You'd want to do it during install, but I'd decline to revert it even though it is easy to do so. Then when comes the time of upgrading this package (adding or removing an admin)... What advices would you give? If you really do want to maintain a set of user accounts with a package, allowing the package inst/rm commands to add, modify, and remove users, you *need* to have at least one administrator account that is not modified by the package, so if the package fails dramatically you can still get in to fix the system. Again, I'd recommend against it and instead have your $org-admin-scripts package contain $org-addadmin and $org-deladmin scripts that are installed to /usr/sbin. Whatever method you are using for mass package-installation should be able to handle mass script-running. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: [OT] C (was: QA uploads primer)
In 20090617085905.852619804zzh3...@mail.kalinowski.com.br, Eduardo M
KALINOWSKI wrote:
On Ter, 16 Jun 2009, Stefanos Harhalakis wrote:
Of course you need to look at the C spec to
claim that you understand C in depth (you did... didn't you?) and in
order to understand why
int n=1; int main() { n=n; printf(%d, n); }
will not output '1'
I couldn't figure why it wouldn't output 1, so I tried (with gcc
4.2.3) and it did print 1.
So I'm still curious why you say it would not work. Care to explain?
The 'n=n' statement is the most suspect statement. I suspected it might
have sequence-point issues, since it both reads and object and writes and
object. However, 6.5.2 which deals with sequence points in expressions does
not make this statement invalid because the prior value [is] read only to
determine the value to be stored.
While the footnotes are not normative, the standard does show a[i] = i as
a valid statement. Here's an example of using that statement to basically
do n=n:
int a = 0; void **i = i; int main() { a[i] = i; printf(%p, i); }
There may be other issues that affect the quoted code, but I don't see them
off-hand.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: [OT] C (was: QA uploads primer)
In 200906171751.13989@v13.gr, Stefanos Harhalakis wrote:
On Wednesday 17 June 2009, Eduardo M KALINOWSKI wrote:
On Ter, 16 Jun 2009, Stefanos Harhalakis wrote:
[snip]
Of course you need to look at the C spec to
claim that you understand C in depth (you did... didn't you?) and in
order to understand why
int n=1; int main() { n=n; printf(%d, n); }
will not output '1'
I couldn't figure why it wouldn't output 1, so I tried (with gcc
4.2.3) and it did print 1.
So I'm still curious why you say it would not work.
There was a typo. Instead of:
int n=1; int main() { n=n; printf(%d, n); }
it should be:
int n=1; int main() { int n=n; printf(%d, n); }
Hope this clears things.
Yeah, and I don't think you *have* to read the C standard to understand why
this doesn't work. Scoping rules are often covered in quick-start guides,
and they would include the statement that 'a local variable's scope begins
at the *start* of it's declaration and ends at the end of the containing
block' with the specific admonition that 'int n = n;' initializes n to
whatever value was at that location before n was initialized, leaving n with
an unknown, not well-defined value.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: [OT] C (was: QA uploads primer)
In 200906171857.57749@v13.gr, Stefanos Harhalakis wrote: Same thing for the trigraphs. puts(What??!); /* ;) */ -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: [OT] C (was: QA uploads primer)
In 200906171954.59429@v13.gr, Stefanos Harhalakis wrote:
On Wednesday 17 June 2009, Boyd Stephen Smith Jr. wrote:
In 200906171857.57749@v13.gr, Stefanos Harhalakis wrote:
Same thing for the trigraphs.
puts(What??!); /* ;) */
I meant that they are not very popular and that they are not covered in
most books or tutorials.
I know. I was attempting to make a joke by misusing a trigraph. (Per the
standard that would output What|\n.)
Thus, it is not obvious that this:
#includestdio.h
int main() { printf(??!??/n); }
may not output what the user expects (depending on the compiler)
Agreed.
or why this:
#include stdio.h
int main() { printf(%c\n, 123:2:); }
will properly compile and output 3
Those aren't trigraphs. They aren't substituted during phase 1 of
translation. They are only recognized as independent tokens, never (e.g.)
inside a string literal. They also stringify differently than the tokens
they can be substituted for.
Different stringification:
#define str(x) #x
int main() { puts(str(??!)); puts(str(:)); }
outputs |\n:\n not |\n[\n.
Parsed after phase 1:
#define gltk(x, y) x ## y
#define str(x) # x
#define estr(x) str(x)
int main() { puts(?? ! gtk2(, :) 1 gtk2(:, )); }
outputs ?!\n, not \n.
(GCC pukes on it saying : and : are not preprocessing tokens, but
that's non-conformant per 6.4.1.)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/
signature.asc
Description: This is a digitally signed message part.
Re: RFS: kabikaboo --lintian-clean? no.
In 4a394fad.1060...@shaw.ca, Dave Kerr wrote: Well the system e-mailed me back and said : --- Your package does not seem to be lintian clean. 'lintian' is a tool to verify if source package contain obvious packaging errors. These warnings/errors were found: W: kabikaboo source: native-package-with-dash-version N: N:Native packaging should only be used if a piece of software was written N:specifically to be turned into a Debian package. In this case, the N:version number should not contain a Debian revision part. N: N:Native source packages are sometimes created by accident. In most cases N:the reason is the location of the original source tarball. dpkg-source N:searches for this in ../package_upstream-version.orig.tar.gz. You should be using non-native packaging for your package. Fixing this is probably just an issue of renaming your .orig.tar.gz. If your package is version 1.0-1 you should be using package_1.0.orig.tar.gz not package_1.0-1.orig.tar.gz. In general the .orig.tar.gz name will not include the debian revision part of the non-native package version. I swear I was tricked by the lintian tool. Lintian is undergoing constant improvement. You should make sure and use the lintian version from Sid. You can use apt-pinning to get lintian from Sid while continuing to get other packages from stable/testing/whatever. If you are using pbuilder to build your package inside a Sid chroot (packages for uploading to unstable should always be built in a Sid environment), you can use a post-build hook to run Sid's lintian against the package. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
Re: RFS: iulib (2nd attempt)
In 30e395780906121522i273d74b8qe6bf4f35198e4...@mail.gmail.com, Jeffrey Ratcliffe wrote: Now it is not lintian clean. If I have the usr/lib/libiulib.so.0.0.0 libiulib.so.0 symlinks in libiulib0, then I get: W: libiulib0: non-dev-pkg-with-shlib-symlink usr/lib/libiulib.so.0.0.0 usr/lib/libiulib.so If I put them in the -dev, I get: E: libiulib0: ldconfig-symlink-missing-for-shlib usr/lib/libiulib.so.0 usr/lib/libiulib.so.0.0.0 libiulib.so.0 How do I fix this? The (unversioned, build-time use only) symlink libiulib.so - libiulib.so.0.0.0 needs to be in libiulib-dev package. The (major- versioned) symlink libiulib.so.0 - libiulib.so.0.0.0 needs to be in the libuilib0 package. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
