RFS: google-gadgets
Dear mentors, I am looking for a sponsor for my package "google-gadgets". * Package name: google-gadgets Version : 0.10.3-1 Upstream Author : google-gadgets-for-linux Team <[EMAIL PROTECTED]> * URL : http://code.google.com/p/google-gadgets-for-linux/ * License : Apache 2.0 Section : misc It builds these binary packages: google-gadgets-common - Common files for QT and GTK+ versions of google-gadgets google-gadgets-gst - GStreamer Module for Google Gadgets google-gadgets-gtk - GTK+ Version of Google Gadgets google-gadgets-qt - QT4 version of Google Gadgets google-gadgets-xul - XULRunner module for Google Gadgets libggadget-1.0-0 - Google Gadgets main library libggadget-1.0-dev - Google Gadgets main development files libggadget-gtk-1.0-0 - Google Gadgets GTK+ library libggadget-gtk-1.0-dev - Google Gadgets GTK+ development files libggadget-qt-1.0-0 - Google Gadgets QT library libggadget-qt-1.0-dev - Google Gadgets QT development files The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/g/google-gadgets - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/g/google-gadgets/google-gadgets_0.10.3-1.dsc This package was previously rejected due to incomplete copyright file, this has been amended and the package updated to a new upstream version. I would be glad if someone uploaded this package for me. Kind regards Jack Coulter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: libmetalink
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear mentors, I am looking for a sponsor for my package "libmetalink". * Package name: libmetalink Version : 0.0.3-1 Upstream Author : Tatsuhiro Tsujikawa and the Launchpad Metalink team * URL : https://launchpad.net/libmetalink * License : MIT Section : libs It builds these binary packages: libmetalink1 - C library for parsing Metalink files libmetalink1-dev - Development files for libmetalink The package appears to be lintian clean. The upload would fix these bugs: 499159 The package can be found on mentors.debian.net: - - URL: http://mentors.debian.net/debian/pool/main/l/libmetalink - - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - - dget http://mentors.debian.net/debian/pool/main/l/libmetalink/libmetalink_0.0.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards Philipp Hagemeister -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEAREKAAYFAkkYwqMACgkQ9eq1gvr7CFxeNgCgkMMwCab1lCJPt3JaDAZNSDLe nVwAn0LEs0yAdNl6IPLFPVBMHPPl7JDY =jAGe -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: licencing doubts about APT
2008/11/9 Andre Felipe Machado <[EMAIL PROTECTED]>: > Sorry for my limited English skill. No problem, for many (most?) people here, English is not our native tongue. > I am not a licensing expert, so I _guess_ that as the source code was > licensed under a different one some years ago, it may "carry" some kind > of potential liability from that date, in an theoric situation of a > fork, for example. > Maybe, some source code from that date should have to be verifiable > compliant with the terms at that time. If none of the code in the Debian package is licensed under the Qt license, then the Qt license should not be included or referred to in the package. What other people do with forks is not your problem. They must license their fork in accordance with the license(s) of the exact code they fork from. > Could I post this issue at debian-legal? Yes, questions like this usually lives in debian-legal. Cheers, -- Jens Peter Secher. _DD6A 05B0 174E BFB2 D4D9 B52E 0EE5 978A FE63 E8A1 jpsecher gmail com_. A. Because it breaks the logical sequence of discussion. Q. Why is top posting bad? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: dekiwiki
Dear mentors, I am looking for a sponsor for my package "dekiwiki". * Package name: dekiwiki Version : 8.08.11123-1 Upstream Author : [EMAIL PROTECTED] * URL : www.mindtouch.com * License : GPLv2 Section : web It builds these binary packages: dekiwiki - a powerful opensource wiki which runs on Mono The package appears to be lintian clean. The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dekiwiki - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dekiwiki/dekiwiki_8.08.11123-1.dsc I would be glad if someone uploaded this package for me. Kind regards Mathieu OUDART -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: debconf questions
* Andreas Tscharner [Mon, 10 Nov 2008 11:31:42 +0100]: > If I execute the .config file, the expected screen (it's a note) is shown Hm, I thought you're not supposed to use debconf to display notes, and that NEWS.Debian is preferred. -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Death Cab For Cutie - Marching Bands of Manhattan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: wallpaper-tray (updated package)
Guido Loupias schreef: Alright. I will try to upload a -1 revision when I'm home. Revision uploaded. :) Kind regards, Guido Loupias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: wallpaper-tray (updated package)
2008/11/10 Sandro Tosi <[EMAIL PROTECTED]> > Hi Guido, > > On Mon, Nov 10, 2008 at 12:46, Guido Loupias <[EMAIL PROTECTED]> > wrote: > > 2008/11/10 Sandro Tosi <[EMAIL PROTECTED]> > > The changes I introduced in 0.5.5-1 and 0.5.5-2 have been applied > upstream. > > So in essence there are no changes (except for that 1 patch) to the > debian > > revision with respect to the upstream version. Hence the short list of > > changes. > > Ahhh now it's clear :D > > > The revised -1 revision wouldn't upload after I editted the changelog. It > > said there > > was nothing to upload because there were no changes. > > what tools give you error? dput/dupload or mentors.d.n? if dput, > remove *.upload, if mentors remove the previous upload first. > > > Am I understanding correctly then that in order for a revision to be > updated > > the previous revision has to be in the debian archive first? I recall two > > other > > mentors telling me that it is good practice to increment the debian > revision > > even if the archive only made it to mentors and never to the debian > > archives. > > Personally, I'm strong against their suggestion: having a new revision > for every single upload to mentors for even small fix requested by the > sponsor is really annoying and can generate confusion to the end users > reading the changelog: what if the ask "what changes from the latest > version I have installed on the system" and found 6 revisions each for > "added watch file"+"removed commented line from debian/rules"+"added a > ',' char to short description" or so is really really ugly. > > this is my opinion, their and mine being technical correct. Alright. I will try to upload a -1 revision when I'm home. > > I am a little confused now. > > Yeah, sorry about that :) each sponsor has its own set of rules, > characteristics or so he/she wants to see in a package he's gonna > sponsor, that's the reason for the differences in replies and > suggestion (still being correct both ways). Thanks for the explanation. I get it now. :) Kind regards, Guido Loupias
Re: RFS: ocropus (3nd try)
Hello Jeffrey,
On Sun, Nov 9, 2008 at 22:01, Jeffrey Ratcliffe
<[EMAIL PROTECTED]> wrote:
> I am looking for a sponsor for my package "ocropus".
I'm giving the package a look, and here are my comments:
- please remove "XS-DM-Upload-Allowed" field (that should be called
"DM-Upload-Allowed", since it's official now), since it's something
usually asked by the sponsor after he/she is comfortable with your
"autonomous" work.
- "Document" in short description should be uncapitalized: think at it
like is a
- I don't know if it's importa (but may exist some backoffice tool
that cares about uppercases), but I'd uncapitalize the email address
in the maintainer field
- please explain what OCR is in the long description, so that even
un-experienced users may understand what the package does
- in long description "OCRopus is development is sponsored by Google"
i think it's better "OCRopus development is sponsored by Google", what
about?
- you don't usually need "usr/bin" in debian/dirs (it's usually
created by install steps)
- what about include in debian/ocroscript.1 the options listed at
http://sites.google.com/site/ocropus/documentation ? consider the
situation where a user has no net connection and still wants to use
ocroscript. And repeating the long description in the manpage adds no
information to the users: please expand it to be usefull and please
forward then upstream (so that they can include in the next release).
- please add a debian/watch file, "man uscan" for examples
- since you claim to be "Standards-Version: 3.8.0" and using a patch
system, you have to add a debian/README.source explaining how you
patch the upstream source code (for a quilt example, take a look at
matplotlib package).
- patches have no documentation about what they do; dpatch added a "#
DP: " line where you can explain what the patch does (along with other
information like the patch author), do you mind add such information
(to be clear about the patch scope)?
- given that "debian/patches/distclean" added some files to be deleted
by upstream distclean target, and "clean: unpatch" this means that the
patch is removed before clean target in debian/rules is called, hence
invalidating the patch. One solution could be add another target:
clean: clean-patched unpatch
clean-patched: patch-stamp
- It's usually better depends on patch-stamp (or the exported quilt
variable, check man quilt) instead of patch, so please fix build-stamp
target
- you can merge the "rm -f" lines into dh_clean call (they do the same thing)
- do you need dh_installexamples and dh_install in binary-arch target ?
- please indent the "upstream authors" section in debian/copyright by
4 spaces, and expand (or remove) "... and several others."
- License section is indeed the copyright one
- please add the correct license section, referring to apache-2.0,
adding the apache license boilerplate (as visible in
./ocrocmd/version.h)
- since you claim that your packaging is gplv3, and so are the patches
you wrote, are you sure that those patches can be applied to
apache-2.0 source code? please check. That's the reason we usually
suggest to license the packaging under the same license as upstream
code.
- you completely missed to add information about "External Software"
in debian/copyright
- please check *every* source file: ./ocrocmd/version.h has a
different copyright year, and many others (2006-2008 seems to be the
right years); ./colib/nbest.h (and with it, many other) has different
copyright holder, and you have to list them in the debian/copyright
file; ext/lua/lua.h (and all the related files) has different
copyright holder and license: please add them too and check the
license is compatible with apache-2.0.
I can continue with many other files: please check the whole
upstream tarball, *every* files, (I exec, from the root level, "find .
-type f -exec less {} \;") and report all the copyright and license
information differing from the "main" ones and whether they are
compatible each other.
- lintian reports some warning:
$ lintian -I ../pbuilder/result/ocropus_0.2*changes
I: ocropus source: debian-watch-file-is-missing
I: ocropus: arch-dep-package-has-big-usr-share 10924kB 78%
what about creating a "ocropus-common" package to contain all those
architecture independent files?
Please reply in case of questions and once you have uploaded an
updated package to mentors (no need to bump revision).
Kindly,
--
Sandro Tosi (aka morph, Morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for Adopting Valknut
On Mon, Nov 10, 2008 at 12:07, Romain Beauxis <[EMAIL PROTECTED]> wrote: > Le Monday 10 November 2008 11:20:03 Sandro Tosi, vous avez écrit : >> > The other option would be to simply fix some bugs in 0.3.13 and bump the >> > Debian version for my first upload, but I'd hate to waste effort fixing >> > bugs that upstream may (I think probably) have fixed already. >> >> It depends if you want to see those bugs fixed for the lenny package: >> if so, upload a new Debian revision with the bugs fixed and ask >> release managers to unblock your package; > > Provided the bugs are considered RC (need to be fixed for lenny, severity > serious, grave or worse..), of course. yeah, thanks for clarifying :D There are even other corner situations: bugs can be even of priority "important" (IIRC) and can even not being reported yet; if checking the new upstream release you notice a fix for a really bad bug but the bug is still not reported, you might even evaluate to backport the patch to the current lenny version. Cheers, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: wallpaper-tray (updated package)
2008/11/10 Sandro Tosi <[EMAIL PROTECTED]> > On Mon, Nov 10, 2008 at 00:55, Guido Loupias <[EMAIL PROTECTED]> > wrote: > > Sandro Tosi schreef: > >> Does the changes you'd like to upload start from 0.5.5-1 up to > >> 0.5.5+svn7-1? If so, please merge all the changes listed in > >> debian/changelog into the latest entry (hence 0.5.5+svn7-1) and > >> reupload the package. > > > > Done. :) Uploaded under new revision 0.5.5+svn7-2. > > There was a full screen of changelog yesterday, and now only 6 > lines... are you sure you've done the right thing? The changes I introduced in 0.5.5-1 and 0.5.5-2 have been applied upstream. So in essence there are no changes (except for that 1 patch) to the debian revision with respect to the upstream version. Hence the short list of changes. > ... and more, why -2 revision? The revised -1 revision wouldn't upload after I editted the changelog. It said there was nothing to upload because there were no changes. > is -1 present in the debian archive? no, so please use -1 > (it's the first revision of that version). Am I understanding correctly then that in order for a revision to be updated the previous revision has to be in the debian archive first? I recall two other mentors telling me that it is good practice to increment the debian revision even if the archive only made it to mentors and never to the debian archives. I am a little confused now. Kind Regards, Guido Loupias
Re: GPG Keys
* Boyd Stephen Smith Jr. [Mon, 10 Nov 2008 03:14:53 -0600]: > I have two GPG keys, one for my laptop and one for my desktop. I've probably > got a third for my VPS, but I don't thinkn that's on the public keyservers > yet and I only use it so my local apt repository is signed. But, I digress. > mentors.d.n seems to want a single GPG key. I imagine that becoming a DD > would probably entail reducing my keys down to one (1) as well. > Unfortunately, I haven't found a good method for accessing a single private > key from the multiple computers I work in front of regularly. > Any suggestions on the best way to do that? In particular I've considered a > USB key, but I'd like it to be automatically mounted in a consistent location > so my always-running-when-I'm-there gnupg-agent (and kgpg) can find it. One option is to copy the .gnupg directory around, as Sandro mentioned (but only to secure systems; a VPS does not qualify). Another option is to use subkeys (http://fortytwo.ch/gpg/subkeys). This way you only have one main key, but portions of it live in different computers. Signatures made with the subparts (subkeys) are equally valid than if they'd be done with the main key. It is true that AFAIK you won't be able to put more than key in the Debian keyring, should you become a DD or a DM. HTH, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Johnny Cash - We'll Meet Again -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for Adopting Valknut
Le Monday 10 November 2008 11:20:03 Sandro Tosi, vous avez écrit : > > The other option would be to simply fix some bugs in 0.3.13 and bump the > > Debian version for my first upload, but I'd hate to waste effort fixing > > bugs that upstream may (I think probably) have fixed already. > > It depends if you want to see those bugs fixed for the lenny package: > if so, upload a new Debian revision with the bugs fixed and ask > release managers to unblock your package; Provided the bugs are considered RC (need to be fixed for lenny, severity serious, grave or worse..), of course. Romain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debconf questions
Dear Mentors,
I have two questions concerning debconf:
1) I have created a .config and a .templates
file according to the debconf user's guide by Joey Hess. If I execute
the .config file, the expected screen (it's a note) is shown, everything
is OK. I have also inserted dh_installdebconf in the rules file.
Now I hoped the Debian Magic would do all the tricks to show my screen
while installing, but nothing happened.
So, do I need to call the .config file "by hand"? And if yes: where? In
the postinst? Or somewhere else?
2) lintian complains about not having sourced the debconf library in
postinst. I have (following the user's guide) done this in the .config
file, before calling the actual debconf functions.
Which one is considered better?
TIA and best regards
Andreas
--
("`-''-/").___..--''"`-._
`o_ o ) `-. ( ).`-.__.`)
(_Y_.)' ._ ) `._ `. ``-..-'
_..`--'_..-_/ /--'_.' .'
(il).-'' (li).' ((!.-'
Andreas Tscharner [EMAIL PROTECTED] ICQ-No. 14356454
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG Keys
On Mon, 2008-11-10 at 03:14 -0600, Boyd Stephen Smith Jr. wrote: > mentors.d.n seems to want a single GPG key. I imagine that becoming a DD > would probably entail reducing my keys down to one (1) as well. No, it will require you to nominate one of your keys as the Debian key. Take a look at my keys - one is clearly commented "(laptop key)" - 0xA897FD02 - and I cannot upload to Debian using that key. My main key is the one on my desktop machine - 0x28BCB3E3. Decide now which of your keys is going to be the most secure (i.e. the secret key has only ever been on machines that haven't left your home). All other keys are deemed "replaceable". All portable machines and all "temporary" machines would only ever have one or more of these replaceable keys. I think two keys is a good arrangement for most Debian work because if the laptop is stolen or lost, I can still sign notification messages with my other key which has similar numbers of signatures on it and is similarly strong in terms of the web of trust. It is in the nature of laptops for them to be lost, so I use a "replaceable" key and keep another key for my home system. Check my emails in the archive, you'll find some signed by my main key (this one) and some by my laptop key - depending on where I was at the time. > Unfortunately, I haven't found a good method for accessing a single private > key from the multiple computers I work in front of regularly. Then don't. By all means copy the other secret keys around all your machines so that you can decrypt stuff (and even sign using your less secure keys on your secure machines) but keep your main key secure. When you want to take your secure key with you for a specific purpose, use: http://www.einval.com/~steve/docs/gpg-autofs.html > Any suggestions on the best way to do that? In particular I've considered a > USB key, but I'd like it to be automatically mounted in a consistent location > so my always-running-when-I'm-there gnupg-agent (and kgpg) can find it. See link above. Actually, what you might want is my adjustment of the link above that allows me to continue signing stuff with my laptop key when using the laptop and then on specific instances when I need the Debian key to upload a package directly from the laptop (whilst at DebConf etc.), I plug in my secure key and use it *only* to sign the package for upload, then remove the card and revert to the laptop key. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: is statistical data extracted from web DFSG compliant?
On Mon, 2008-11-10 at 10:06 +0800, Kov Chai wrote: > i am working on a Chinese input method engine [1,2]. This input method > engine is based on the statistical language model. We extract the > language model from a 150MiB corpus collected from some choosed > Chinese websites using a training algorithm. The extracted data -- the > language model -- does not contain any text from these websites. only > statistics for the frequencies of occurrence of given character > sequences are stored in a binary format. Then there is no copyright over the statistical data, only the statistical analysis tools. The creativity lies in writing the code that generates the data, not the data itself. Think of it like a piece of networking software, the creativity (and therefore the copyright) is in the design of the pipe, not what goes through the pipe. The binary file is not a problem in and of itself - the package must simply support modification of the binary and regeneration of a new binary should the old one get deleted or should the package be shown to have miscalculated some of the data. It is the support for modification that matters. > The upstream released both the data and the source code for > reading/writing such kind of binary file under dual license of CDDL > and LGPLv2.1 . So I believe this software (and data) is free. But I am > afraid that this package is not compatible to DFSG#2 in some sense. Am > I right? The data has to be capable of being regenerated / refreshed using the free software provided in the package (or some other free software). If there is a bug in the algorithm that miscalculates the frequency of one symbol, the package must still be capable of regenerating corrected data. Just because the required input data (the websites) cannot also be packaged does not mean that the generated data is not free. As long as a random user can use the package to update the binary file in the case of bugs, it meets DFSG requirements. Therefore, whether Debian should be expected to keep such large binary files on all the mirrors is a different question. How long does it take to generate the binary file? Could it be generated by the user? Does the package support reading the data from a proxy or from content on a regular filesystem? There are reasons why other packages can require access to specific websites but those packages do so to obtain data that has some copyright / creative input, e.g. a shared SVN repository, or where it is unreasonable to package the data along with the package. > Is there anyway to fix this? Is removing the non-free piece the only > way? I've put the explanation in README.Debian of this package. Statistical data has no copyright, it merely needs to generated and updated. The question is not about whether the data meets DFSG, the question is whether the data should be in the package in the first place. I would be tempted to package the free software that generates the stats data and let the user create the data after installation. I don't see why the mirrors should keep copies of such large amounts of generated data. It's a bit like packaging a TCP/IP client and bundling a generated block of packets as well. The data does not need to be distributed AFAICT, it would presumably need to be updated from time to time anyway. The data itself would appear to have no intrinsic value to the package beyond saving time for the user. Personally, I do not consider that a worthwhile excuse for taking up so much space on the Debian mirrors / DVD. It comes down to this: 1. The package must work with any binary file generated using the package itself (or dependencies), including files generated by any random user, with or without the original data file. That is a DFSG requirement. I would consider the package to be non-free if the package insists on going to specific websites directly - it *must* be possible to generate the statistical data from a local copy of the websites as well (i.e. offline) or via a proxy or via a completely arbitrary set of web content on the filesystem. 2. The data contains none of the original copyrighted data - the actual values in the data file are therefore completely arbitrary and any realistic permutation of the numbers could exist in the binary. 3. Re-generating the binary file after installation must not change the functionality of the package, it merely changes the data that it handles. 4. Given the above, there is no reason to package the data beyond saving time for the user. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: RFS: wallpaper-tray (updated package)
On Mon, Nov 10, 2008 at 00:55, Guido Loupias <[EMAIL PROTECTED]> wrote: > Sandro Tosi schreef: >> Does the changes you'd like to upload start from 0.5.5-1 up to >> 0.5.5+svn7-1? If so, please merge all the changes listed in >> debian/changelog into the latest entry (hence 0.5.5+svn7-1) and >> reupload the package. > > Done. :) Uploaded under new revision 0.5.5+svn7-2. There was a full screen of changelog yesterday, and now only 6 lines... are you sure you've done the right thing? What I was asking is to merge the entries (hence removing headers and footer from the "not uploaded" version into the latest one); and more, why -2 revision? is -1 present in the debian archive? no, so please use -1 (it's the first revision of that version), and confirm that the changelog lines present in the previous upload were not simply deleted. If so, please reintroduce them (I want a changelog documenting every changes you did from the current version in the debian archive to the proposed update). Kindly, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Advice for Adopting Valknut
Hello, On Mon, Nov 10, 2008 at 10:40, Boyd Stephen Smith Jr. <[EMAIL PROTECTED]> wrote: > I figured the first step would be to upload a new version to mentors.d.n, Ehm, the first step is to read the fundamental documentation: Debian policy, developers reference, new maintainer guide. You mat have already read those, but better be sure there sorry :) > closing some of the open bugs along the way. However, development has moved > forward since the last time Valknut was packaged, so I was considering moving > the Debian package up to the most recent release. It's usually better to follow upstream releases. > Unfortunately, the new project page ( http://wxdcgui.sourceforge.net/ ) is a > bit ambiguous about what version would be best to package. 0.3.13 is cited > as "old but stable" and is the current version packaged for Debian. 0.3.21 > is available as a tarball and hasn't seen bugs in almost two months and a > 0.3.22 pre-release is also available. > > The 0.4.x line appears to be a parallel release, perhaps the version reported > by the Qt 4 version. I'll contact the upstream maintainer about that. You might want to upload 0.3.x series to unstable and 0.4.x to experimental. > My thinking is that I should go ahead and package 0.3.21 for Debian, > forward-porting any Debian-specific patches and get it sponsored. Since > Lenny is in freeze, it will simply stay in Sid. Lenny can go stable with > the "old but stable" 0.3.13 unless something changes and a version bump is > needed. > > The other option would be to simply fix some bugs in 0.3.13 and bump the > Debian version for my first upload, but I'd hate to waste effort fixing bugs > that upstream may (I think probably) have fixed already. It depends if you want to see those bugs fixed for the lenny package: if so, upload a new Debian revision with the bugs fixed and ask release managers to unblock your package; it not, then simply package the next upstream release and upload to unstable. Kindly, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Maintainance w/ a DVCS
Hi Boyd. I've just learned how to use git + topgit + the git-buildpackage infrastructure. There are a couple of videos online from old debian conferences with possible workflows and many other blog posts. I think git a wonderful too (the learning curve can be a bit steep) to manage debian packages and git-buildpackage, cdbs and quilt make life very easy to maintain patches that are both debian specific or targeted to upstream in sinc with the upstrem development. this is definitely the RTFM you were looking for : http://vcs-pkg.org/ bye, p On Mon, Nov 10, 2008 at 03:50:55AM -0600, Boyd Stephen Smith Jr. wrote: > I'm thinking of adopting Valknut. As part of that, I imagine I'll put git > (or > some other DVCS) to work. I'll need to easily track upstream (a SVN repo) > and then have branches for stable fixes, unstable releases, and experimental > SVN snapshots... well... eventually. > > I'm soliciting suggestions as to what DVCS to use, and what Debian-specific > tools I might want to familiarize myself with when using that VCS. On top of > all that I wouldn't mind some suggestions of workflows that have worked well > for other maintainers using a DVCS. URLs appreciated. RTFM accepted, but > please let me know where the manual is at. > -- > Boyd Stephen Smith Jr. ,= ,-_-. =. > [EMAIL PROTECTED] ((_/)o o(\_)) > ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' > http://iguanasuicide.org/ \_/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GPG Keys
Hello, On Mon, Nov 10, 2008 at 10:14, Boyd Stephen Smith Jr. <[EMAIL PROTECTED]> wrote: > I have two GPG keys, one for my laptop and one for my desktop. I've probably > got a third for my VPS, but I don't thinkn that's on the public keyservers > yet and I only use it so my local apt repository is signed. But, I digress. > > mentors.d.n seems to want a single GPG key. I imagine that becoming a DD > would probably entail reducing my keys down to one (1) as well. > Unfortunately, I haven't found a good method for accessing a single private > key from the multiple computers I work in front of regularly. > > Any suggestions on the best way to do that? In particular I've considered a > USB key, but I'd like it to be automatically mounted in a consistent location > so my always-running-when-I'm-there gnupg-agent (and kgpg) can find it. you can copy .gpg/ dir from one system to others; it might not be the most secure way to do it, but it works. > One of the how-to-get-a-sponsor guides indicated that my GPG key needs to be > in the Debian web-of-trust (currently, it is in no web-of-trust). while this is encouraged, it is not needed to have your key in the "Debian web of trust" if you don't want to become a DD. > It's > relatively easy to confirm that I'm [EMAIL PROTECTED] -- we could do that > via email. it's not as easy as you might think... you can claim to be another person, for example stealing the other's email account. > If you'd prefer to see my passport and/or DL to confirm I'm Boyd > Stephen Smith Jr., we'll have to meet in person; who's closest to > Fayetteville, Arkansas, USA? take a look at https://nm.debian.org/gpg.php Kindly, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian Maintainance w/ a DVCS
I'm thinking of adopting Valknut. As part of that, I imagine I'll put git (or some other DVCS) to work. I'll need to easily track upstream (a SVN repo) and then have branches for stable fixes, unstable releases, and experimental SVN snapshots... well... eventually. I'm soliciting suggestions as to what DVCS to use, and what Debian-specific tools I might want to familiarize myself with when using that VCS. On top of all that I wouldn't mind some suggestions of workflows that have worked well for other maintainers using a DVCS. URLs appreciated. RTFM accepted, but please let me know where the manual is at. -- Boyd Stephen Smith Jr. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/ pgpWn84PtQN1o.pgp Description: PGP signature
Advice for Adopting Valknut
I figured the first step would be to upload a new version to mentors.d.n, closing some of the open bugs along the way. However, development has moved forward since the last time Valknut was packaged, so I was considering moving the Debian package up to the most recent release. Unfortunately, the new project page ( http://wxdcgui.sourceforge.net/ ) is a bit ambiguous about what version would be best to package. 0.3.13 is cited as "old but stable" and is the current version packaged for Debian. 0.3.21 is available as a tarball and hasn't seen bugs in almost two months and a 0.3.22 pre-release is also available. The 0.4.x line appears to be a parallel release, perhaps the version reported by the Qt 4 version. I'll contact the upstream maintainer about that. My thinking is that I should go ahead and package 0.3.21 for Debian, forward-porting any Debian-specific patches and get it sponsored. Since Lenny is in freeze, it will simply stay in Sid. Lenny can go stable with the "old but stable" 0.3.13 unless something changes and a version bump is needed. The other option would be to simply fix some bugs in 0.3.13 and bump the Debian version for my first upload, but I'd hate to waste effort fixing bugs that upstream may (I think probably) have fixed already. -- Boyd Stephen Smith Jr. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/ pgpBKrauRDL0G.pgp Description: PGP signature
GPG Keys
I have two GPG keys, one for my laptop and one for my desktop. I've probably got a third for my VPS, but I don't thinkn that's on the public keyservers yet and I only use it so my local apt repository is signed. But, I digress. mentors.d.n seems to want a single GPG key. I imagine that becoming a DD would probably entail reducing my keys down to one (1) as well. Unfortunately, I haven't found a good method for accessing a single private key from the multiple computers I work in front of regularly. Any suggestions on the best way to do that? In particular I've considered a USB key, but I'd like it to be automatically mounted in a consistent location so my always-running-when-I'm-there gnupg-agent (and kgpg) can find it. One of the how-to-get-a-sponsor guides indicated that my GPG key needs to be in the Debian web-of-trust (currently, it is in no web-of-trust). It's relatively easy to confirm that I'm [EMAIL PROTECTED] -- we could do that via email. If you'd prefer to see my passport and/or DL to confirm I'm Boyd Stephen Smith Jr., we'll have to meet in person; who's closest to Fayetteville, Arkansas, USA? -- Boyd Stephen Smith Jr. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/ pgpRSI1ooadoA.pgp Description: PGP signature
RFS: dbus-inspector
Dear mentors, I am looking for a sponsor for my package "dbus-inspector". Package name: dbus-inspector Version : 0.2.1-1 Upstream Author : Erich Schubert <[EMAIL PROTECTED]> URL : http://people.debian.org/~erich/dbus-inspector.tgz License : GPL Section : devel It builds these binary packages: dbus-inspector - Graphical tool to show the content of the DBus message bus The package appears to be lintian clean. The upload would fix these bugs: 461939 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/d/dbus-inspector - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/d/dbus-inspector/dbus-inspector_0.2.1-1.dsc I would be glad if someone uploaded this package for me. Kind regards -- --- Carlos Galisteo PGP_key::http://k-rolus.net/~cgalisteo/cgalisteo.gpg Key_Fingerprint::F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
