Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Wed, 18 Jan 2012, Adam Borowski wrote: Anyway, I don't think closing RFS bugs manually would be big hassle to sponsors. An additional manual step that takes time, is error-prone and brings nothing new: if the upload fails somehow, the sponsor will be the first to get notified. Personally, I always notify the sponsoree when I proceed with the upload. It would be relatively trivial to add the CC to nnn-done at this point. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119083953.ge7...@rivendell.home.ouaza.com
Re: RFS: jbigkit
Hi Michael, Thanks for working on this package ! On Thu, Jan 19, 2012 at 7:04 AM, Michael van der Kolff mvanderko...@gmail.com wrote: Dear mentors, I am looking for a sponsor for my package jbigkit. * Package name : jbigkit Version : 2.0-9+1 Upstream Author : Markus Kuhn mg...@cl.cam.ac.uk * URL : http://www.cl.cam.ac.uk/~mgk25/jbigkit/ * License : GPL Section : libs ... dget -x http://mentors.debian.net/debian/pool/main/j/jbigkit/jbigkit_2.0-9+1.dsc For some reason I cannot get it to build on my machine: $ dpkg-buildpackage -rfakeroot -us -uc dpkg-buildpackage: export CFLAGS from dpkg-buildflags ... make[2]: Leaving directory `/tmp/jbigkit-2.0/pbmtools' install -d /tmp/jbigkit-2.0/debian/tmp/usr/lib install -s -m 644 libjbig/.libs/*.so.*.*.* libjbig/.libs/*.a /tmp/jbigkit-2.0/debian/tmp/usr/lib install -m 644 libjbig/.libs/*.la /tmp/jbigkit-2.0/debian/tmp/usr/lib ldconfig -n /tmp/jbigkit-2.0/debian/tmp/usr/lib make[1]: ldconfig: Command not found make[1]: *** [install] Error 127 make[1]: Leaving directory `/tmp/jbigkit-2.0' dh_auto_install: make -j1 install DESTDIR=/tmp/jbigkit-2.0/debian/tmp returned exit code 2 make: *** [binary] Error 29 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Same goes from my pdebuild setup: make[2]: Leaving directory `/tmp/buildd/jbigkit-2.0/pbmtools' install -d /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib install -s -m 644 libjbig/.libs/*.so.*.*.* libjbig/.libs/*.a /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib install -m 644 libjbig/.libs/*.la /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib ldconfig -n /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib make[1]: ldconfig: Command not found make[1]: *** [install] Error 127 make[1]: Leaving directory `/tmp/buildd/jbigkit-2.0' dh_auto_install: make -j1 install DESTDIR=/tmp/buildd/jbigkit-2.0/debian/tmp returned exit code 2 make: *** [binary] Error 29 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 E: Failed autobuilding of package I: unmounting /var/cache/pbuilder/ccache filesystem I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/cache/pbuilder/build//4760 and its subdirectories As a side note, I would also simplify the debian/changelog file, and maybe mention bug #466427 in it. -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CA+7wUswch939n5H47hB7U6TzGskk0J+R_dU-=subo+c1jpo...@mail.gmail.com
Re: RFS: jbigkit
Sorry, ubuntu blesses me with a greater $PATH. I'm substituting /sbin/ldconfig in the latest upload... What do you mean by simplify debian/changelog? Cheers, Michael On Thu, Jan 19, 2012 at 8:12 PM, Mathieu Malaterre mathieu.malate...@gmail.com wrote: Hi Michael, Thanks for working on this package ! On Thu, Jan 19, 2012 at 7:04 AM, Michael van der Kolff mvanderko...@gmail.com wrote: Dear mentors, I am looking for a sponsor for my package jbigkit. * Package name : jbigkit Version : 2.0-9+1 Upstream Author : Markus Kuhn mg...@cl.cam.ac.uk * URL : http://www.cl.cam.ac.uk/~mgk25/jbigkit/ * License : GPL Section : libs ... dget -x http://mentors.debian.net/debian/pool/main/j/jbigkit/jbigkit_2.0-9+1.dsc For some reason I cannot get it to build on my machine: $ dpkg-buildpackage -rfakeroot -us -uc dpkg-buildpackage: export CFLAGS from dpkg-buildflags ... make[2]: Leaving directory `/tmp/jbigkit-2.0/pbmtools' install -d /tmp/jbigkit-2.0/debian/tmp/usr/lib install -s -m 644 libjbig/.libs/*.so.*.*.* libjbig/.libs/*.a /tmp/jbigkit-2.0/debian/tmp/usr/lib install -m 644 libjbig/.libs/*.la /tmp/jbigkit-2.0/debian/tmp/usr/lib ldconfig -n /tmp/jbigkit-2.0/debian/tmp/usr/lib make[1]: ldconfig: Command not found make[1]: *** [install] Error 127 make[1]: Leaving directory `/tmp/jbigkit-2.0' dh_auto_install: make -j1 install DESTDIR=/tmp/jbigkit-2.0/debian/tmp returned exit code 2 make: *** [binary] Error 29 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Same goes from my pdebuild setup: make[2]: Leaving directory `/tmp/buildd/jbigkit-2.0/pbmtools' install -d /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib install -s -m 644 libjbig/.libs/*.so.*.*.* libjbig/.libs/*.a /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib install -m 644 libjbig/.libs/*.la /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib ldconfig -n /tmp/buildd/jbigkit-2.0/debian/tmp/usr/lib make[1]: ldconfig: Command not found make[1]: *** [install] Error 127 make[1]: Leaving directory `/tmp/buildd/jbigkit-2.0' dh_auto_install: make -j1 install DESTDIR=/tmp/buildd/jbigkit-2.0/debian/tmp returned exit code 2 make: *** [binary] Error 29 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 E: Failed autobuilding of package I: unmounting /var/cache/pbuilder/ccache filesystem I: unmounting dev/pts filesystem I: unmounting proc filesystem I: cleaning the build env I: removing directory /var/cache/pbuilder/build//4760 and its subdirectories As a side note, I would also simplify the debian/changelog file, and maybe mention bug #466427 in it. -- Mathieu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cafbbo2t7+pvy6bjsk-buwn4u94bbsdfw2detpxytz6kyufb...@mail.gmail.com
Re: RFS: couriergrey (3rd)
Hi! Marco Balmer ma...@balmer.name writes: Fixed/uploaded all of your remarks, may you have a look again? Thank you! By the way I've added Vcs-Git and Vcs-Browser fields and fixed a bug in packaging. I had another look, at long last, and spotted a thing or two: * [minor] There's a thinko in debian/README.Debian: disabled at default should be disabled by default, at least that's how I usually use the phrase, but I'm not a native speaker, and I might very well be mistaken. * [major] The package doesn't build twice in a row. The second time it fails with: , | make[1]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1' |dh_auto_build | [...] | Making all in man | make[3]: Entering directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1/man' | generating couriergrey.8 from couriergrey.8.in | /bin/bash: line 3: couriergrey.8.in: No such file or directory | mv: cannot stat `couriergrey.8.tmp': No such file or directory | make[3]: *** [couriergrey.8] Error 1 | make[3]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1/man' | make[2]: *** [all-recursive] Error 1 | make[2]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1' | make[1]: *** [all] Error 2 | make[1]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1' | dh_auto_build: make -j1 returned exit code 2 | make: *** [build] Error 2 | dpkg-buildpackage: error: debian/rules build gave error exit status 2 ` This seems to happen because upstream deletes the couriergrey.8 file upon make clean, but fails to ship couriergrey.8.in to support regenerating it. That would be a DFSG violation, as part of the source is not shipped - thankfully, that source is restorable, because the only thing the Makefile changes is the VERSION string. You might wish to notify upstream about this problem, but it can be fixed without a new upstream release, in my opinion. Other than this, the package looks fine, and I'll upload once the build issue is fixed (and this time, it won't take months to review the update, I promise!). -- |8] -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87obu0aux5.fsf@algernon.balabit
Re: RFS: ipset
I must apologize you, Pierre but I have to CC you because we need your
suggestions.
I reckon you're aware that your package conflicts with
xtables-addons-common?
At this time, my ipset binary still conflicts as the
xtables-addons-common also provides the binary in the same path.
My concern is that overlapping is a big source of problems.
Imagine one have ipset installed - he/she won't be able to use modules
provided by xtables-addons without uninstalling ipset first, etc.
I agree with you.
IMO, if the next release (1.41) of xtables-addons will not build
ipset, so, ipset package should set the Conflicts to only for
xtables-addons-common (= 1.40) then no conflicts any more.
This may work if we agree not to build ipset in the next xtables-addons
release and sponsor your package at the same time.
Please bring Pierre (the main xtables-addons maintainer) to the discussion and
CC to me as well.
As mention above, I already CC Pierre.
I'm not sure the intentions of the xtables-addons upstream that not to
build the ipset-genl
as default as in the version 1.41 but IMO, it's unnecessary to
maintain ipset module in the separate place
other than in the recent mainline kernel. Despite, It's still
necessary for the xtables-addons to support
the old kernels.
Or setup the alternatives which users could select by him/her self.
I don't like this idea because it is not an alternative but the very same
thing provided by two different packages. This should not be. :)
Ok, forget it.
Or ipset source package should build only libipset{2,-dev} and leave
the ipset utility in xtables-addons as before.
But I respect your and xtables-addons maintainer team's decision.
Any suggestions ?
I hope you'll excuse me if I stay away from suggestions for some time.
This discussion needs expertise of someone more experienced than me - a
someone familiar with resolution of conflicts between packages.
We need comments from DDs.
Personally I think this decision requires me to thoroughly review your package
and prepare new xtables-addons. I'm overwhelmed with work for next several
weeks so I hardly will be able to do so soon.
Besides, I think you need to demonstrate the benefits of having separate
package for ipset. I'm not sure how/why this is better (if it is) or if it's
worth troubles to do for the marginal benefit, if any.
IMO, the ipset package will gain the benefits only when the upstream
of xtables-addons discontinue
to merge the ipset as they mention in the changelog and the ipset
package would be preferred at that time.
Have you considered joining the xtables-addons packaging team?
I'll happy if I could. :)
It appears to me that introducing your package would imply work for many
people and careful coordination just for the sake of providing the same thing
we already have in a slightly different manner.
Having said that, I'm not against the idea. Maybe it will be better - I just
don't understand the benefits given the overhead for the transition period.
What makes you think it worth the effort?
I think, it's a choice for the users. In some cases, users want to use
only ipset,
they could definitely install ipset package without the needs to install any
further kernel modules that they don't use. (no needs to run m-a on
new kernel upgrade or
no needs to wait the DKMS to compile the kernel modules)
Despite, if the xtables-addons still build ipset that it's not a problem as both
packages are conflicted and could not install in the system at the same time.
Thus, the users who want to use the modules in the xtables-addons
could still use
the ipset as well in this case.
Any suggestions ? (Pierre, DDs)
Best regards,
Neutron Soutmun
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAMQP0snNAL+aSOCiCy=sw7hrmwfm+gxwpi+zqva6+ht8-fv...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? The webpage only very vague says: You can upload your package to this server (through special tools like 'dupload' or 'dput') and after a few checks it will be stored in our repository. What are these few checks?! So, given the first statement above, alioth may not be the best example, but its a .org machine that is already subject to this potential problem and it seems to get along just fine. For example, www space could potentially be used to host non-distributable files, and no one is really actively checking for that. I don't recall if new users have to agree to the DMUP when they create their alioth account, but that could be a solution to the problem (on alioth as well as for mentors); perhaps with some additional wording for this type of hypothetical misuse. Alioth users do not need to agree on the DMUP or any code of conduct on that matter. Talking with Jörg in IRC yesterday about this topic I got the impression, we'd need kind of a NEW queue processing for new, unknown uploads which should be used as an ingress filter to new packages. While I was kind of expecting this answer, I do not see the possibility to implement that in the near future. That approach lacks both, code support in mentors and a list of willing people to process Mentors NEW queues. However I agree with Jörg, that that's the only clean and feasible approach in the long time perspective. Answering zobel's question: Packages which are uploaded to mentors are being tested very rudimentary. We're basically testing the package for consistency (e.g. all files present, checksums match, ..., probably very similar to what dak does) and we're running Lintian on the package, but we're not using any Lintian auto-rejects as we're kind of an archive where packages are supposed to be broken from that perspective. We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Note that alioth as a .org machine can even be used as a mentors alternative today: e.g. http://alioth.debian.org/~gilbert-guest/unstable. Right. But I think having one bad example is a poor rationale to get yet another. :) Also, I would imagine that at some point someone will automate it so that RFP bug closure causes a removal of the mentors package. Thus as bugs are closed out over time, anything non-distributable will just go away. Additionally, give reviews to outright close bugs that they find in such a situation so it goes away more immediately. Right. Currently I have code in beta-testing which removes packages from mentors which are announced by dak to be accepted into unstable. Ultimately this is a rather hypothetical concern and as such deserves to be treated more on a case-by-case basis; rather assuming there is going to be a lot of abuse leading the discussion toward a strong a priori solution (in this case rejecting officialization of mentors). The problem is existing in theory, but not a real problem. This does not mean it couldn't happen. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPF/32AAoJEMcrUe6dgPNtBzkP/Aol7bC9NwurdC3gQOCNWtlx nFQhUs+Omzb7ojZBQsW8eO3j86Cxk7XECq9Sxbbz60K5d/+jEhTDUOk8PkijWWni DTLbXwvtrcKnzBg5/gQyFH3Gtj4XYdfEwCiPsLhVHaAAemxL0DalIV3/o+yMjYze Mhs9ssQIGgYj1wA8Kw8UYwn24hJGphzpCNGixs4XVl/y2XE68QlKoQr6d4aqkG3P MVHh+tjpB8cIulS5tDhlCfbsw+a0ufi9rNMRJdkbeP/cyQlNXe0Bh3dDMxZ5EyR6 8qPp6yTU1FuPlht/VXOLXpHnpY+cayQG2pPmq1vqoZacuByiSJpjxPfFRFEvCBZd jHxrgkEGeUmRE8dZBg1fgmmZ33FKcyzJKckmBuzVNmVb/cx2cph+TjBlI1+4gzEz F6rD/UWCSX8FDthxisClUAgAPf3lM9CtokkIVGY0a7brlQVaA7fZSTWb034OML/r Goo2VbVjGgnCVwlICJfhQQbriXcbGVsv7A40rKfYY/fMukBiXKez3J7McidXxSSb +ErknNDM/0bNT5MMR05ZYR/44Q/crlb/QfFjKE/fiPgsnzvRw6mmTvm9EGnreLbl f6MXk8DBLC7xjpqAe7yx3SmciXNb/pY4/fSu8F3s+Y9WcOX8E5DulKw7wW1Pbt4D Tx5P7b7mxJ2Iob6bDYQ/ =pwr9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f17fdf6.3050...@toell.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? The webpage only very vague says: You can upload your package to this server (through special tools like 'dupload' or 'dput') and after a few checks it will be stored in our repository. What are these few checks?! So, given the first statement above, alioth may not be the best example, but its a .org machine that is already subject to this potential problem and it seems to get along just fine. For example, www space could potentially be used to host non-distributable files, and no one is really actively checking for that. I don't recall if new users have to agree to the DMUP when they create their alioth account, but that could be a solution to the problem (on alioth as well as for mentors); perhaps with some additional wording for this type of hypothetical misuse. Alioth users do not need to agree on the DMUP or any code of conduct on that matter. Talking with Jörg in IRC yesterday about this topic I got the impression, we'd need kind of a NEW queue processing for new, unknown uploads which should be used as an ingress filter to new packages. While I was kind of expecting this answer, I do not see the possibility to implement that in the near future. That approach lacks both, code support in mentors and a list of willing people to process Mentors NEW queues. However I agree with Jörg, that that's the only clean and feasible approach in the long time perspective. Answering zobel's question: Packages which are uploaded to mentors are being tested very rudimentary. We're basically testing the package for consistency (e.g. all files present, checksums match, ..., probably very similar to what dak does) and we're running Lintian on the package, but we're not using any Lintian auto-rejects as we're kind of an archive where packages are supposed to be broken from that perspective. We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Note that alioth as a .org machine can even be used as a mentors alternative today: e.g. http://alioth.debian.org/~gilbert-guest/unstable. Right. But I think having one bad example is a poor rationale to get yet another. :) Also, I would imagine that at some point someone will automate it so that RFP bug closure causes a removal of the mentors package. Thus as bugs are closed out over time, anything non-distributable will just go away. Additionally, give reviews to outright close bugs that they find in such a situation so it goes away more immediately. Right. Currently I have code in beta-testing which removes packages from mentors which are announced by dak to be accepted into unstable. Ultimately this is a rather hypothetical concern and as such deserves to be treated more on a case-by-case basis; rather assuming there is going to be a lot of abuse leading the discussion toward a strong a priori solution (in this case rejecting officialization of mentors). The problem is existing in theory, but not a real problem. This does not mean it couldn't happen. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPF/36AAoJEMcrUe6dgPNtZVcQALOR4EnExDlShgFOBa3azu37 T69tcGgFwPVCp1NfgMj9Tl6zYw+CAaGX2Vbwx1iJE5YEftQJvYWJAE+zUnOqimFF 2KjFk+xEU0mO4l4B5P+4vrUznGYTnBa4V/EFTNQLhOW1kOaTSQZ738i401/m6bHx X/li0ozLjyrgLVpEn6D84X832CrfbwdLKVyqf212HfmALT/32J9N/0/PRE/ZpaFI nouadIV4T70kqSHdbVJy7l3IAsnmSb2VeJXIH6HLdzc6cbKt2BQCru5DuYIk6g4K DWshRynLbLoMKQKLpulQ15dNFLhxE4lKCbp8NXbnqHujlJQW/ys9bKfRfRHf7dY+ 51wcTcT9D5p5QdvELfB6TK1vdJwoOanR/HTGcKR57+P4p8vR2NMMGJLtO6+ge6Ho YTafOCEj0d4no13dIc7/Wys/30rV1u3H/kD9X4egtwWjKBYNA6mKC6zbN9A41ym4 Nx9oi1qKazfc9E810kxv67FrKpC2TezOnikckoK8E1gZNSJ2X6NSOh2yWfwTSjfc abxhSimgYl9I/liimh9xL15d8LRxRJqsOdHrI6gK2zc7HtJG6hEOqg/4JPKQP7mQ CC4njf7XdmW8JM+tj6YzghIEJyUXO+jlYPyxinOmoQiN78+eDsF0GKyPPyRvktML HQav5Y1JkyaaPN05/bAt =lwHK -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f17fdfa.1040...@toell.net
Re: RFS: cavez of phear (console game)
On 18 January 2012 19:00, Jakub Wilk jw...@debian.org wrote: * Håkon Nessjøen haakon.nessj...@gmail.com, 2012-01-18, 12:37: Did you upload the updated package to mentors? I did now. Just out of curiosity, is there a reason that GPL-2+ and GPL-3+ paragraphs are formatted differently in d/copyright? How differently? I just found texts to the corresponding licenses. What drew my attention is that one of them uses quotes, and the other one `' quotes. There are more minor differences, though. But never mind. Fixed the quoting. I had problems finding templates for the short copyright notice in d/copyright with the debian file information etc. So I just took the only one I found for GPL3+. -- Håkon
Re: RFS: jbigkit
* Michael van der Kolff mvanderko...@gmail.com, 2012-01-19, 20:19: What do you mean by simplify debian/changelog? Well, your changelog has currently 11 entries. For an initial upload a single one would be more typical. (Also, lintian would tell you then that you forgot to close the ITP bug.) -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119113349.ga2...@jwilk.net
Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 19.01.2012 05:54, Michael Gilbert wrote: On Wed, Jan 18, 2012 at 7:43 AM, Arno Töll wrote: On 18.01.2012 08:40, Raphael Hertzog wrote: Dear DSA, do you think it's possible to have a CNAME mentors.debian.org pointing to mentors.debian.net? It's currently not hosted on a .d.o machine but AIUI the mentors.debian.net admins are interested to move it to DSA-managed host at some point. as a maintainer of mentors.d.n I can confirm our interest to make mentors an official Debian service at some point. However, we are not in a hurry to do so immediately and I believe that's something which needs consensus among developers before we can seriously consider that. What consensus (and from whom) is required here? If I interpret things correctly, the DSA team [0] is the group that need to make the call. So lets start that discussion with them (well its already started with the CC's). DSA is the team which makes a DNS CNAME record, or provides a hosting facility. In my interpretation they are not making facts by that. Making mentors.debian.net a .org makes the project official part of Debian, just like any other core team, e.g. ftp-master, security team, release team and so on. That's not something which should be decided without consensus among Debian Developers and, perhaps, a DPL which delegates some people to a mentors task. Thus, I am sending this mail to -devel again. Maybe anyone wants to raise the voice on that matter. Moreover, we're lacking Debian Developers interested to join our team which is sort of a prerequisite to integrate a team into Debian's organizational structure. I am not a DD quite yet, but I'm finishing the NM process right now, and as soon as I'm done, I will be very happy to join this team. I would hope there are quite a few other existing DDs willing to be officially part of the team as well. Is there a list of the current official members? mentors.debian.net went through several generations of developers who coded parts of it. These days only me (in NM too, but no DD yet) and Asheesh Laroia (paulproteus) made notable code contributions in the recent past. I provided Paul Wise (pabs) a root shell last week but I guess his interest in participation is mostly front-desk-like, e.g. he helps people in #debian-mentors or writing to our support address who had technical problems. I'd be more than happy finding _anyone_ interested to work on our (Python/Pylon/sqlalchemy) code base. We have really long todo list. Anyway, I think if we can get people behind this, we would want to make it happen quickly, then the mentors.debian.org psuedo-package would be available, and we could straightforwardly implement the bug-based RFP process. That's the plan, but again: tracking sponsor requests as bugs, and integrate mentors.debian.net into Debian are unrelated problems. Any proposal can be implemented without touching the status-quo of the other. The term contributor conveys a much more welcoming message as it says this is the place where I can go to learn about start making contributions to debian, and this is where we can go to help people become contributors. That's the problem. A contributor can have many roles in Debian, it is overbooked just like terms such as DSA and maintainer (albeit zack suggested to come over the latter problem). That said, I don't mind any other, better name than debian-mentors or mentors.debian.tld, but contributor probably isn't. YMMV. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPGALvAAoJEMcrUe6dgPNt8poQAIN14n/rxWcax7NQsYraW73c 2AILwLMuW3N8YKi4iri7+C+l7hCbWwA81yxQbVIZWx1bnOohN3PSKPAle4hO/L3X 19z4U3/4kq/r8T3YfS3wC39UX6MpI1VkfBhvF8Kr+qULo9t+Lra9l75ZI1L1BkEX obdrkLGEbv0jVoc6b3lhGiFLpTHusUOp80/huAADI4ZG8c1vPO5+WeCh70CtEG80 W2tlgefHN4HP0c/h8J3QCR/fGdx/KVTWd6Ggh6gySs3unhz4sF8kA+jcBAyYZfvY vyeZ13rcgL41Q772JnbndtDAghTCRmeuiVdqsYlCvG3+raFt0l3nqWeIGHhK6ySW b5Gd+LBmsrWQvrBDLid83bF1IhlyOdNFfv5T3jQeaOnAJMcijgWsnWin7UpzGJC/ l+GWfuOjvrTsaxz82bIwsqycTJvwfqPCq/8qEUJjxKpvjxEGZWz4YN2hgkX4qOD9 8osFtkyn7AeWuNlEt2G4AuWkwTcOJte9Et1qvAsm7C2qrFsS7D1NYQr+XhJqJb8T 7zdtg1gdYmPbvt8HE9oWJqJuE2XN7pQo81AshBHoWGtOcFSz3J+NSRnAERSZPlg5 kvMSdEDUfLzu75l5IqVJ4pL4ZfMfDOXjuPk/FaJlJPw4IBSsj/vK/WIYnoBfnhKm j96Vy09UryEzazWEQ7T9 =dVDg -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f1802ef.7050...@toell.net
Re: RFS: cavez of phear (console game)
* Håkon Nessjøen haakon.nessj...@gmail.com, 2012-01-19, 12:30: Did you upload the updated package to mentors? I did now. Just out of curiosity, is there a reason that GPL-2+ and GPL-3+ paragraphs are formatted differently in d/copyright? How differently? I just found texts to the corresponding licenses. What drew my attention is that one of them uses quotes, and the other one `' quotes. There are more minor differences, though. But never mind. Fixed the quoting. I had problems finding templates for the short copyright notice in d/copyright with the debian file information etc. So I just took the only one I found for GPL3+. Thanks. I took the liberty of bumping timestamp in the chanelog and uploaded the package. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119115010.gb2...@jwilk.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi! Am 19.01.2012 12:26, schrieb Arno Töll: On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? [..] We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. diff.gz/debian.tar.gz could still be accessible to all, so non-DDs could still at least do (limited) reviews. And with a proper get-orig-source rule (or a way on mentors to provide a link to the source tarball?) even full reviews by non-DDs would be possible. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f180554@schmehl.info
Re: RFS: couriergrey (3rd)
Dear Gergely, On Thu, Jan 19, 2012 at 10:44:22AM +0100, Gergely Nagy wrote: I had another look, at long last, and spotted a thing or two: * [minor] There's a thinko in debian/README.Debian: disabled at default should be disabled by default, at least that's how I usually use the phrase, but I'm not a native speaker, and I might very well be mistaken. I am not native too. And your advice sounds better to me. * [major] The package doesn't build twice in a row. The second time it fails with: , | make[1]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1' |dh_auto_build | [...] | Making all in man | make[3]: Entering directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1/man' | generating couriergrey.8 from couriergrey.8.in | /bin/bash: line 3: couriergrey.8.in: No such file or directory | mv: cannot stat `couriergrey.8.tmp': No such file or directory | make[3]: *** [couriergrey.8] Error 1 | make[3]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1/man' | make[2]: *** [all-recursive] Error 1 | make[2]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1' | make[1]: *** [all] Error 2 | make[1]: Leaving directory `/home/algernon/ext-src/debian/sponsor/couriergrey-0.3.0.1' | dh_auto_build: make -j1 returned exit code 2 | make: *** [build] Error 2 | dpkg-buildpackage: error: debian/rules build gave error exit status 2 ` This seems to happen because upstream deletes the couriergrey.8 file upon make clean, but fails to ship couriergrey.8.in to support regenerating it. That would be a DFSG violation, as part of the source is not shipped - thankfully, that source is restorable, because the only thing the Makefile changes is the VERSION string. You might wish to notify upstream about this problem, but it can be fixed without a new upstream release, in my opinion. I had contact with the upstream author and he gave me a workaround for the moment. He will fix it in the next upstream release. Other than this, the package looks fine, and I'll upload once the build issue is fixed (and this time, it won't take months to review the update, I promise!). So I uploaded a patched version to mentors.debian.net: dget -x http://mentors.debian.net/debian/pool/main/c/couriergrey/couriergrey_0.3.0.1-1.dsc I would be glad if you or someone else uploaded this package for me. -Marco signature.asc Description: GnuPG Signature
Re: How mature is Pkg-format 3.0 (git), yet?
* Adam Borowski kilob...@angband.pl [120119 02:29]: On Wed, Jan 18, 2012 at 03:47:11PM +0100, Goswin von Brederlow wrote: There is a lot of different opinions about wether the format is sane at all. A problem with the basic idea/design of 3.0 (git) as opposed to the maturity of the implementation. It is strictly better than 3.0 (quilt). For every set of tree+patches representable by quilt, you can produce a shallow git repository that contains exactly the same bits of data and nothing more. This depends how you define better. A source format is my eyes a way to communicate with our users and the overall comunity. A source format that only has the advantage of not caring if modifications to the upstream source are not easily reviewable[1] and makes it harder for the overall community to see our part[2] is not better. It is worse. To avoid me repeating too much, see also http://lists.debian.org/debian-devel/2011/09/msg00484.html Bernhard R. Link [1] If you have a set of disjoint modifications or of modifications that do not need some additional magic merging is trivially translateable to a quilt series. [2] I once for some package looked what changes other distributions had, never had I had that many different VCSes installed. Even if upstream uses some vcs, there surely will be some day a better one comes out or upstream changes for other reasons, so not even using the same as upstream helps to avoid that. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119115652.ga28...@server.brlink.eu
Re: RFS: bluefeather 0.40-1
Youhei SASAKI uwab...@gfd-dennou.org wrote: The following packages are ready to be uploaded (I also verified the points listed on http://wiki.debian.org/Teams/Ruby/RubyExtras/RequestingSponsorship). Could you please sponsor them? Vcs-Svn: svn://svn.debian.org/svn/pkg-ruby-extras/trunk/bluefeather Vcs-Browser: http://svn.debian.org/wsvn/pkg-ruby-extras/trunk/bluefeather source: bluefeather packages: - bluefeather The request was sent at 25 Feb 2011, roughly a year ago. I think someone who has knowledge about ruby can help review and sponsor? -- Regards, Aron Xu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAMr=8w58Bs0=cy2khqxfu+qb83mi66tnsocjt_vj9vgvcdm...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 19.01.2012 12:58, Alexander Reichle-Schmehl wrote: Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. I am not sure if that's the right message to send to people. We want and push anyone, including non-sponsors to review packages. We believe everyone can learn from other people's packaging styles - for good or not. There are quite a lot of people doing reviews and look at packages. Your workaround complicates handling with source packages to non-developers a lot, and even developers can be scared off by that requirement. A substantial problem in our whole approach is to attract Debian Developers to sponsoring again. If we're complicating access to packages, that's sort of counterproductive. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPGBkSAAoJEMcrUe6dgPNtktkQAJgd5tO5/s7SwV2ELK/XvUKm 78OXDbx8i3L7lct90WgDle/YHOceVNhYrd1aEJ8a1hfHwe62/+F7RZHva6qA54KV tSHWhvd3IfilMTkQHxYkXRjs9Am3Atlrwe8hzh1URnB/MvYIPtZdGfzKENU0Aaz+ NfEVujVwj5zdztZ2Xv5zwynumUzKiPeSjCT9J0RSReOc29ZdH62GuY0MgTMzHgL0 SUapmfnNh5QKNENTG5cZsMWkELULd8oi3hpyf3UE/uqXaA7qHQTFSgQRft15KmKD VDJIUWUsRb70+2jLdhdSZsbNgFvO4jDn+g+8cqPvDIY72WGxMrt4ReO4gg+h8uaQ d0VkALe8V7TlkQiCiREDN5tLue8gt5//jMAwvTXafFGFDvpgJwKfOCBDfYD1nkFl InXvX+A2B6MIzALYEaVcmbhqxJx9kENKXh365DXo56vlx0782KWll5WmU+dG+2fa LMl5JFz9QVggQCF6+Ho+epYvXjXuy1Ujj8OZDp7mqrDrZs2dW1bjMfaZ4hp3ckcZ XR73sBVTjf9mbeTECIlytPTsIc4F5m3XmxoQqaUUS9Thg4FHCq1YbMVUBD48RfJ9 6GGzZgJBe+qKRc94M5V1seIf5OTOzqoS8+fUi27e/js77GY+XhfOEmZQEQN77zUs FNMIsWbl0DJVzRoE2Pn8 =xLxH -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f181912.8020...@toell.net
RFS dhcp-probe
This mail is sent with good email address instead of lguignard2000 [AT] yahoo.fr Dear mentors, I am looking for a sponsor for my package dhcp-probe. * Package name: dhcp-probe Version : 1.3.0-10 Upstream Author : Irwin Tillman network...@princeton.edu * URL : http://www.net.princeton.edu/software/dhcp_probe/ * License : GPL Section : net It builds those binary packages: dhcp-probe - network DHCP or BootP server discover To access further information about this package, please visit the following URL: http://mentors.debian.net/package/dhcp-probe Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/d/dhcp-probe/dhcp-probe_1.3.0-10.dsc I would be glad if someone uploaded this package for me. Kind regards, Laurent Guignard signature.asc Description: This is a digitally signed message part
RFS: suckless-tools 39-1
Hi mentors, I am looking for a sponsor for my fresh adopted package suckless-tools. * Package name: suckless-tools Version : 39-1 Upstream Author : Serval (look at the projects in the URL for more info) * URL : http://tools.suckless.org/ * License : MIT Section : x11 It builds this binary package: suckless-tools - simple commands for minimalistic window managers which installs follow binaries: * dmenu: dynamic menu is a generic menu for X. * lsw: Lists the titles of all running X windows to stdout, similar to ls(1). * slock: Simple X display locker that locks the X session. * st: Simple terminal implementation for X. * sselp: Simple X selection printer that prints the X selection to stdout. * ssid: Simple setsid replacement. * swarp: Simple X warping tool to warp the mouse pointer to a given position. * tabbed: Simple generic tabbed fronted to xembed aware applications. * wmname: wmname prints/sets the window manager name property of the root window similar to how hostname(1) behaves. I fixed serval bugs listed in BTS and updated dmenu and lsw to the current upstream-release. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/suckless-tools Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/suckless-tools/suckless-tools_39-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Michael Stummvoll -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f181f55.7080...@stummi.org
Re: RFS: suckless-tools 39-1
Wow, thanks for that work. Michael Stummvoll mich...@stummi.org wrote: Hi mentors, I am looking for a sponsor for my fresh adopted package suckless-tools. * Package name: suckless-tools Version : 39-1 Upstream Author : Serval (look at the projects in the URL for more info) * URL : http://tools.suckless.org/ * License : MIT Section : x11 It builds this binary package: suckless-tools - simple commands for minimalistic window managers which installs follow binaries: * dmenu: dynamic menu is a generic menu for X. * lsw: Lists the titles of all running X windows to stdout, similar to ls(1). * slock: Simple X display locker that locks the X session. * st: Simple terminal implementation for X. * sselp: Simple X selection printer that prints the X selection to stdout. * ssid: Simple setsid replacement. * swarp: Simple X warping tool to warp the mouse pointer to a given position. * tabbed: Simple generic tabbed fronted to xembed aware applications. * wmname: wmname prints/sets the window manager name property of the root window similar to how hostname(1) behaves. I fixed serval bugs listed in BTS and updated dmenu and lsw to the current upstream-release. To access further information about this package, please visit the following URL: http://mentors.debian.net/package/suckless-tools Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/suckless-tools/suckless-tools_39-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Michael Stummvoll -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f181f55.7080...@stummi.org
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi! Am 19.01.2012 14:22, schrieb Arno Töll: Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. I am not sure if that's the right message to send to people. We want and push anyone, including non-sponsors to review packages. We believe everyone can learn from other people's packaging styles - for good or not. There are quite a lot of people doing reviews and look at packages. Your workaround complicates handling with source packages to non-developers a lot, and even developers can be scared off by that requirement. A substantial problem in our whole approach is to attract Debian Developers to sponsoring again. If we're complicating access to packages, that's sort of counterproductive. Well, don't take it wrong: Mentors is a very usefull service, it was a just an idea which might allow you to become mentors.debian.org. As said, I don't think there's a problem distribute .dsc and diff.gz/debian.tar.gz files. (which still allows a limited review.) About the orig tarball... Well, in many cases it's available somewhere else for download already. So maybe mentors could have a Get tarball here entry where sponsorees can place an URL. (No security risk; you can sill verify if the sponsorees and the downloaded tarball match.) And then it's only a minor step to a dget-mentors-Script (or maybe a patch for dget to automatically take a look at the url field, when downloading from mentors). Granted, not a really good solution, but doable. Best regards, Alexander -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f18290d.3070...@schmehl.info
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Tue, Jan 17, 2012 at 10:59:14PM +0100, Ansgar Burchardt wrote: SUMMARY === We plan to ask for the creation of a new pseudo-package debian-mentors or mentors.debian.org [3] (contact: debian-mentors@lists.debian.org) in Debian's bug tracking system (the name is still subject to change). A workflow for handling sponsoring requests is proposed below. It is based on an earlier discussion on the debian-mentors list[1]. This is a really smart, simple and good idea to use the BTS. I sometimes just keep the RFS packages which get no replies marked as unread in mutt for keeping a track on this and try to help people (not that much recently, duties in real life don't give that much time for me), but if this idea gets to be implemented I am sure we'll have a better panorama of the packages that need to be uploaded. On the other hand I found just great the REVIEWING packages section. This is a key for attracting more contributors, because the sponsoring process can be really frustrating sometimes. In addition, the confirmed tag is really nice because it allows others with no upload rights to start doing revisions and that will facilitate (in some cases of course) the work of the ones who have upload rights and will help themselves because they will learn more about the Debian Policy. I know my mail does not contribute in some sense to this proposal, but I just felt the *need* of writing how great I found it. On the other hand, I don't find as a hassle the fact that sponsors have to close the reports manually. DRIVERS === Ansgar Burchardt Jakub Wilk Arno Töll gregor herrmann Congratulations to the $DRIVERS :) Regards, -- Muammar El Khatib. Linux user: 403107. Key fingerprint = 90B8 BFC4 4A75 B881 39A3 1440 30EB 403B 1270 29F1 http://muammar.me | http://proyectociencia.org ,''`. : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119151507.ga32...@ihacku.debian.org
Re: Packaging proprietary software
Can someone recommend me a Debian's binary package for use as an example to create mine? Have you tried with the checkinstall command? P.S. I believe that Debian supports and helps with packaging open source software, not closed source and proprietary software.
Re: Packaging proprietary software
On Thu, Jan 19, 2012 at 10:37 AM, Savvas Radevic vice...@gmail.com wrote: Can someone recommend me a Debian's binary package for use as an example to create mine? Have you tried with the checkinstall command? That's not really a sustainable - there's no reason to resort to such hacks, even though you disagree with someone's choice to use nonfree software. There are plenty of examples of packages that are nonfree, but produce fairly sane .debs To answer the OP's question - I'm personally not sure, but I know that there are some policies related to doing it right. It might require a fairly hacked rules file, but I think it's doable. There are a bunch of DDs working on the contrib/non-free section of the archive. Perhaps they could weigh in :) P.S. I believe that Debian supports and helps with packaging open source software, not closed source and proprietary software. And thus spake the wiki: debian-mentors is for the mentoring of new and prospective debian developers. Almost any question relating to Debian development is potentially on-topic for d-mentors. Although there are other lists which deal with most aspects of developing for Debian, they're often pretty hard core and can be daunting. If you think your question might be a little newbie for the hardcore developers on debian-devel, then it's probably a good fit for -mentors. Cheers, Paul -- All programmers are playwrights, and all computers are lousy actors. #define sizeof(x) rand() :wq -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cao6p2qq7yf5tjbgqrs-u5punbfpr0vc9m3d8hgkugu28ucb...@mail.gmail.com
Re: RFS: OpenCPN navigation (ITP #538067)
On Monday 16 January 2012 09:09:27 Hamish wrote: Hi, Hi, (just to summarize the log from IRC session, we had) It's been 5 weeks without response, and no luck finding a sponsor on IRC, so I'll try a repeat posting. :-) Yeah, a lot of effort has been put into making this packaged properly (as seen from the ITP bug), but the package is in very specific niche and possibly only few interest is provoked amongst DDs, of course the lack of free time is also a blocker, and last bu not least the whole thing is quite complex. As a measure of end-user interest in this program, downloads in the last 12 months have averaged about 500/day from the sourceforge d/l site. http://sourceforge.net/projects/opencpn/files/stats/timeline?dates=2006-10- 26%20to%202011-12-31 the most visible issues, so far: * modified embedded copies of external projects - nmea (for the main app - okay; and each plugin, why so?), iso8211, gdal. Maybe all these modifications are justified, as seen from the ITP, this is best to be sorted out. * unrelated (wrt Debian archive) binary files (like vc_redist.exe, visual studio redistributable) are found the the upstream tarball, also removed by you in the dfsg tarball. Both of these could be documented within the 'Comment' field of DEP-5, mentioning the reason for removal and modification. It is good to have them carefully put together, so that they are traceable at least; these of course might be solved one way or another in the future versions. Next, * long package descriptions should be impoved, and in my opinoin to the point where a person with a driver license could be comfortable to read and understand it :) For instance: the bullet list of bullet of features, should have more explanations; you cold add a sentence or two about the Route handling facility. * get-orig-source, or have a look at DevRef - 6.7.8.2. - Repackaged upstream source - to at least ease the fetching of your dfsg tarball from alioth. * to put dfsg in the version number or not? yes, ...+dfsg-1. Hamish wrote: You'll notice our source tarball is labeled dfsg. This is because there were some included DLLs to help build the MS Windows version of the program which we didn't need/want for the Linux build, the source code itself is untouched. Paul Tagliamonte wrote: Is the source included for those DLLS? No. They are 3rd party; specifically Nullsoft's NSIS installer, http://nsis.sourceforge.net/License and Microsoft's VisualC++ runtime redistributable. NSIS is permissive FOSS; vcredist is free as in beer. Without even considering the unused source-avail-at-sourceforge NSIS, I'm pretty certain that free-as-in-beer anything is not allowed to be uploaded within src.tar.gz files, so it needs to be repacked anyway. so it comes down to a trivial adjustment: If pbuilder cares that the exact tarball filename matches the version in the changelog file it is trivial to edit it in I would leave that to the DD uploader to adjust or not as they see fit. For me building with `debuild -i -uc -us -b -j6` there is no issue. aside: Anyone know the redistribution terms for vcredist_x86.exe ? MS's download site does not make it obvious and I guess you have to actually install it to get the EULA. - Can a GPL'd Windows program validly ship it as part of the install, or must it be left as a why does it fail with Error 14001? FAQ on the project's homepage? Whatever, we don't need vc_redist.exe in Debian archive -- at least 300 mirrors will have some disk space trashed for no good reasons. -- pub 4096R/0E4BD0AB people.fccf.net/danchev/key pgp.mit.edu -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201201191740.52905.danc...@spnet.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello again, for the record, as we talked in IRC: On 19.01.2012 15:30, Alexander Reichle-Schmehl wrote: Well, don't take it wrong: Mentors is a very usefull service, it was a just an idea which might allow you to become mentors.debian.org. I didn't take it so. I fully appreciate any suggestions which are doable to us. I do also respect Zobel's requirement to make sure, we allow access to distributable packages only which is only fair. As said, I don't think there's a problem distribute .dsc and diff.gz/debian.tar.gz files. (which still allows a limited review.) Discussing the idea, I pointed out, you can still hide non-distributable files in debian.tar.gz if you really wanted to, in times on 3.0/quilt. That pretty much rules out this idea, sadly. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPGD9lAAoJEMcrUe6dgPNtmTgQAIOZmq9qJ5vHRAWn9CirMPu3 9ti0tzBmkVNf9QgMTJBNTyFw9U/ty5XmIUn1kfw45fqV5LE06nbHLrE4NAwD02Tl X7P3lLv0dwgG0cPXUl960K8durHEfMogNIffwf2jNgSvf9yReHG3sOjDZDXgilGu UZfNX4gsLhzX6FzZLkozr7jFBZ+fz/QA8IztPSDYeaBOV520E5OzpNWtRUtK9Ms8 wvBQoHoYHtO5LjEno96XlJeoSKNMm7AuMMZo01Fwm7kP3+PGx81q2U8jgv8LQEBg aN50ZJhO9qxD/mX1qpE++hSzGdgwyWFWAKscMFkcZuPkeY+/r257reu9/VHAC+Fc BwTycahomMdTmhxbiM9VMqzoqRLcIjy6L5tb1E/gyACPQi8QN7qAGJ8/n/eroDUm +xaHN4KMT40IGtqRX0Yz0BxHUQcPAmscOsNrTY3pvdztav2ipCLA+i7hGfvbYe4c 5lzR/j5i90X72yEy9BTq6d6EZIhVI7tbNfEuy69i+SKfEbRvXLtT4hHWGTaCc69S XSp/MiAzNUVb+PdpR32KWHJoLILKdJiXKBjq8Sj/QCv15mh/B3EAD+FS6mAk5+Wp 2Aep5w5kZqSouvO7h0eaAp6Un3081s5AUO+xMbu1J0Nj0KUkNRdd8PccJ/uFvtMT ZPMBu1GbJ5vETW85SC6d =WP2z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f183f65.9060...@toell.net
Re: RFS: ipset
On Thu, 19 Jan 2012, Dmitry Smirnov wrote:
I reckon you're aware that your package conflicts with
xtables-addons-common?
At this time, my ipset binary still conflicts as the
xtables-addons-common also provides the binary in the same path.
My concern is that overlapping is a big source of problems.
Imagine one have ipset installed - he/she won't be able to use modules
provided by xtables-addons without uninstalling ipset first, etc.
ipset is distributed separately upstream, it has its own life upstream
(and git tree, etc), and all the functionality it requires is already
upstream (kernel). Related functionality (iptables) is also upstream.
I'd actually ask why should ipset be packaged together with the rest of
the stuff in xtables-addons, which is composed mostly of stuff that did
not achieve upstream (as in kernel/iptables) inclusion yet for whatever
reason?
IMO, if the next release (1.41) of xtables-addons will not build
ipset, so, ipset package should set the Conflicts to only for
xtables-addons-common (= 1.40) then no conflicts any more.
This may work if we agree not to build ipset in the next xtables-addons
release and sponsor your package at the same time.
...
Or setup the alternatives which users could select by him/her self.
I don't like this idea because it is not an alternative but the very same
thing provided by two different packages. This should not be. :)
Indeed. alternatives are not for this kind of use.
Or ipset source package should build only libipset{2,-dev} and leave
the ipset utility in xtables-addons as before.
That's a Bad Idea[tm]. Very bad, in fact.
I hope you'll excuse me if I stay away from suggestions for some time.
This discussion needs expertise of someone more experienced than me - a
someone familiar with resolution of conflicts between packages.
We need comments from DDs.
Here is one DD commenting, with his I do use this stuff at work hat on,
and 10 years experience both as a Debian developer and sysadmin:
IMO it should be shipped separately, it has a separate life upstream and
it has been mainlined in the kernel and iptables side so it is now an
standard feature of an up-to-date Linux-based system.
Personally I think this decision requires me to thoroughly review your
package
and prepare new xtables-addons. I'm overwhelmed with work for next several
weeks so I hardly will be able to do so soon.
I feel we could well wait a few weeks to get this done properly.
Besides, I think you need to demonstrate the benefits of having separate
package for ipset. I'm not sure how/why this is better (if it is) or if it's
worth troubles to do for the marginal benefit, if any.
To me, a separate ipset package does have advantages:
1. Ease of backporting.
2. No need to install stuff not yet ready/accepted on the kernel
upstream/ipstables upstream to get standard stuff (ipset) to work.
ipset is the kind of utility you install on routers and firewalls,
where the less unused stuff, the better.
3. Reflects the reality upstream.
It does have an one-time drawback: the work required to remove/disable
ipset from xtables-addons*.
What makes you think it worth the effort?
Well, FWIW, I do think it is worth the effort. In fact I have a half-done
ipset package somewhere, which apparently I won't have to finish and take
care of now that someone else stepped up to do it :-p
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120119160813.gb9...@khazad-dum.debian.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Alexander Reichle-Schmehl alexan...@schmehl.info writes: Am 19.01.2012 12:26, schrieb Arno Töll: On 19.01.2012 05:32, Michael Gilbert wrote: Second concern i have here is that (AFAIK) everyone can upload everything to mentors.debian.net. Which would mean we then would/could distribute non-distribiteable material under the debian.org domain. How can this issue be resolved? [..] We're not doing any license checks, although pabs was pushing use of automated license checks. We're aware of that problem, but we're not having any implementation right now. Yet we're deleting packages where we notice they're not distributable (i.e. not even non-free). Yes, that's a post-publishing removal. Hmmm... What about making the orig tarballs only accessible from Debian machines? In theory only sponsors need it, and sponsors have access to these machines. Possibly stupid idea, but.. what if an ftp-master trainee or someone similar would preview packages uploaded to mentors? [*] I might be mistaken, but the amount of NEW stuff isn't all that huge, and this review would concentrate on distributability alone, so would be fairly fast in most cases. This would introduce a noticable delay to uploaded packages (in the meantime, the package could be made available from .d.o hosts or so, would anyone want to review the package before it leaves mentors-NEW). On the other hand, having done a preliminary license check at the time it was uploaded to mentors, that note could be passed on to ftp-masters once the package hits the real NEW, thus, reducing their work a little. This way, mentors.d.o gets licence review, the work to be done once the package enters NEW gets reduced, the package would be available to DDs before the license check, to everyone else too afterwards - pretty much everyone wins! -- |8] [*]: Search this email's headers for an answer to a question that's bound to be asked. -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8762g7bqyj.fsf@algernon.balabit
RFS: python-gnatpython [third try]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package python-gnatpython. * Package name: python-gnatpython Version : 54-1 Upstream Author : AdaCore sa...@adacore.com * URL : http://forge.open-do.org/projects/gnatpython * License : GPL-2+ and GPL-3+ Section : python It builds those binary packages: python-gnatpython - python framework to ease development of test suites python-gnatpython-doc - python framework to ease development of test suites (examples) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-gnatpython Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-gnatpython/python-gnatpython_54-1.dsc This new package is a build dependency for the polyorb package. I would be glad if someone uploaded this package for me. It is my first python package and I have followed most advices from Jakub Wilk [1] and Simon Chopin [2] thanks to them. After the following lintian command : lintian --pedantic -EI python-gnatpython_54-1_amd64.changes the package still presents the following I/P comments : I: python-gnatpython source: debian-watch-file-is-missing P: python-gnatpython: no-upstream-changelog P: python-gnatpython-doc: no-upstream-changelog P: python-gnatpython-doc: example-unusual-interpreter usr/share/doc/python-gnatpython-doc/examples/echo_testsuite/run-test #!gnatpython Since there isn't any changelog in upstream and the source are only available under a subversion repository I don't know how to fix the first three comments. And since the fourth is a P comment and present in an example I don't think it's worth the work to fix it. Kind regards, Grave Xavier [1] http://lists.debian.org/debian-python/2011/09/msg00078.html [2] http://lists.debian.org/debian-mentors/2012/01/msg00396.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8YRJUACgkQVIZi0A5BZF5i+gCfefMLZ/2vs3F7ZF8pTuZnhWs4 P6MAn0ETrV/SWSE4qKyIxAww5vAqlFjv =A6m1 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f184495.3070...@ipno.in2p3.fr
Re: RFS: ipset
On Thu, Jan 19, 2012 at 10:08 AM, Henrique de Moraes Holschuh
h...@debian.org wrote:
On Thu, 19 Jan 2012, Dmitry Smirnov wrote:
I reckon you're aware that your package conflicts with
xtables-addons-common?
At this time, my ipset binary still conflicts as the
xtables-addons-common also provides the binary in the same path.
My concern is that overlapping is a big source of problems.
Imagine one have ipset installed - he/she won't be able to use modules
provided by xtables-addons without uninstalling ipset first, etc.
ipset is distributed separately upstream, it has its own life upstream
(and git tree, etc), and all the functionality it requires is already
upstream (kernel). Related functionality (iptables) is also upstream.
I'd actually ask why should ipset be packaged together with the rest of
the stuff in xtables-addons, which is composed mostly of stuff that did
not achieve upstream (as in kernel/iptables) inclusion yet for whatever
reason?
IMO, if the next release (1.41) of xtables-addons will not build
ipset, so, ipset package should set the Conflicts to only for
xtables-addons-common (= 1.40) then no conflicts any more.
This may work if we agree not to build ipset in the next xtables-addons
release and sponsor your package at the same time.
...
Or setup the alternatives which users could select by him/her self.
I don't like this idea because it is not an alternative but the very same
thing provided by two different packages. This should not be. :)
Indeed. alternatives are not for this kind of use.
Or ipset source package should build only libipset{2,-dev} and leave
the ipset utility in xtables-addons as before.
That's a Bad Idea[tm]. Very bad, in fact.
I hope you'll excuse me if I stay away from suggestions for some time.
This discussion needs expertise of someone more experienced than me - a
someone familiar with resolution of conflicts between packages.
We need comments from DDs.
Here is one DD commenting, with his I do use this stuff at work hat on,
and 10 years experience both as a Debian developer and sysadmin:
IMO it should be shipped separately, it has a separate life upstream and
it has been mainlined in the kernel and iptables side so it is now an
standard feature of an up-to-date Linux-based system.
Personally I think this decision requires me to thoroughly review your
package
and prepare new xtables-addons. I'm overwhelmed with work for next several
weeks so I hardly will be able to do so soon.
I feel we could well wait a few weeks to get this done properly.
Besides, I think you need to demonstrate the benefits of having separate
package for ipset. I'm not sure how/why this is better (if it is) or if it's
worth troubles to do for the marginal benefit, if any.
To me, a separate ipset package does have advantages:
1. Ease of backporting.
2. No need to install stuff not yet ready/accepted on the kernel
upstream/ipstables upstream to get standard stuff (ipset) to work.
ipset is the kind of utility you install on routers and firewalls,
where the less unused stuff, the better.
3. Reflects the reality upstream.
It does have an one-time drawback: the work required to remove/disable
ipset from xtables-addons*.
What makes you think it worth the effort?
Well, FWIW, I do think it is worth the effort. In fact I have a half-done
ipset package somewhere, which apparently I won't have to finish and take
care of now that someone else stepped up to do it :-p
Thanks for your comments Henrique, they make sense.
Also, it would be great to have this stuff ironed out for the Wheezy
freeze (perhaps coming in June.)
-Matt Zagrabelny
--
This space was intentionally left blank as to not advertise to you
what cellular provider nor what iDevice was used to send you an
email.
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CAOLfK3UR96CPEuvKfYxAuZqCYuU=vfkzhkpmfjd6ocvffjg...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. stuff isn't all that huge, and this review would concentrate on distributability alone, so would be fairly fast in most cases. Might be fast, but it's also boooring. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119165845.ga8...@jwilk.net
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Arno Töll deb...@toell.net writes: On 19.01.2012 15:30, Alexander Reichle-Schmehl wrote: As said, I don't think there's a problem distribute .dsc and diff.gz/debian.tar.gz files. (which still allows a limited review.) Discussing the idea, I pointed out, you can still hide non-distributable files in debian.tar.gz if you really wanted to, in times on 3.0/quilt. That pretty much rules out this idea, sadly. Also, even without worrying about malice, unified diffs include substantial portions of the original code. If the original code is not redistributable, the unified diff of a patch is going to be a derivative work in most cases and also won't be redistributable. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87vco7effz@windlord.stanford.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Jakub Wilk jw...@debian.org writes: * Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87r4yvefcq@windlord.stanford.edu
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Thu, Jan 19, 2012 at 10:07:01AM -0800, Russ Allbery wrote: Jakub Wilk jw...@debian.org writes: * Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. ...which means that a signed SC DMUP would suffice. To be honest, I don't even see the how mentors being on debian.net instead of debian.org actually does a difference legally. Both domains belong to SPI and are maintained but Debian people -- granted, maintenance is technically different but, standing in front of a judge, I don't think anyone would actually care whether you set a CNAME or asked DSA to do it. Yes, the machine actually holding the data is outside DSA's reach, but then again, it's a DD with his DD hat on who decided to set the CNAME to offer a service for people interested in Debian. IANAL though. And we don't need to discuss the merit of debian.net here. My actual point is in the way shorter half sentence above. Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
Hi, I'm generally not a big fan to overuse the BTS for stuff it wasn't really designed for. This tends to result in complex processes that are difficult to follow for newcomers. For example, the wnpp bugs are often misformed, or people don't follow the right process. * Integration into UDD bug search[2] [2] http://udd.debian.org/bugs.cgi It might be better to write a separate cgi for that, to add more specific logic. For example, you could easily split the list with: - new packages - new uploads for existing packages - packages already uploaded (RFS that should be closed) - RFS that couldn't be parsed Note that UDD bugs data is only refreshed every ~6 hours (but this might change soon as DSA is looking into replacing the machine with a newer one). Lucas -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119182739.ga12...@xanadu.blop.info
Re: RFS: bluefeather 0.40-1
Hi, Sorry for late response. At Thu, 19 Jan 2012 20:22:00 +0800, Aron Xu happyaron...@gmail.com wrote: Youhei SASAKI uwab...@gfd-dennou.org wrote: Vcs-Svn: svn://svn.debian.org/svn/pkg-ruby-extras/trunk/bluefeather Vcs-Browser: http://svn.debian.org/wsvn/pkg-ruby-extras/trunk/bluefeather source: bluefeather packages: - bluefeather The request was sent at 25 Feb 2011, roughly a year ago. I think someone who has knowledge about ruby can help review and sponsor? Still working, there are some kinds of problem about spec-tests using Ruby1.9.1. I contact upstream author and wait response. Currently, package is transition SVN to Git. Vcs-Git: git://git.debian.org/pkg-ruby-extras/ruby-bluefeather.git Vcs-Browser: http://git.debian.org/?p=pkg-ruby-extras/ruby-bluefeather.git;a=summary Best Wishes, --- Youhei SASAKI uwab...@gfd-dennou.org uwab...@debian.or.jp GPG fingerprint: 4096/RSA: 66A4 EA70 4FE2 4055 8D6A C2E6 9394 F354 891D 7E07 -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87hazrbkj0.wl%uwab...@gfd-dennou.org
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
* Lucas Nussbaum lu...@debian.org, 2012-01-19, 19:27: I'm generally not a big fan to overuse the BTS for stuff it wasn't really designed for. This tends to result in complex processes that are difficult to follow for newcomers. For example, the wnpp bugs are often misformed, or people don't follow the right process. The big difference is that nobody reads the wnpp bug traffic. But debian-mentors (or whatever the pseudo-package will be eventually called) bug traffic will land on this mailing list. Malformed bug titles will be promptly corrected, people don't following the process will be educated. :) * Integration into UDD bug search[2] [2] http://udd.debian.org/bugs.cgi It might be better to write a separate cgi for that, to add more specific logic. For example, you could easily split the list with: - new packages - new uploads for existing packages - packages already uploaded (RFS that should be closed) - RFS that couldn't be parsed Or we could write a bot that would usertag the bugs appropriately. Then you could use normal BTS view rather than UDD. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120119190233.ga1...@jwilk.net
Re: RFS: OpenCPN navigation (ITP #538067)
George Danchev wrote: * long package descriptions should be impoved, and in my opinoin to the point where a person with a driver license could be comfortable to read and understand it :) For instance: the bullet list of bullet of features, should have more explanations; you cold add a sentence or two about the Route handling facility. fair enough, as long as searchable keywords such as S-57 remain so apt-cache search can find it. if it helps I put together an extended overview page for it which could be reused: http://live.osgeo.org/en/overview/opencpn_overview.html (bits of that scraped from the opencpn.org website were with explicit written permission) * get-orig-source, or have a look at DevRef - 6.7.8.2. - Repackaged upstream source - to at least ease the fetching of your dfsg tarball from alioth. passing my first try at that off to Anton as I'm heading off to sea in a few minutes.. Hamish wrote: aside: Anyone know the redistribution terms for vcredist_x86.exe ? MS's download site does not make it obvious and I guess you have to actually install it to get the EULA. - Can a GPL'd Windows program validly ship it as part of the install, or must it be left as a why does it fail with Error 14001? FAQ on the project's homepage? Whatever, we don't need vc_redist.exe in Debian archive -- at least 300 mirrors will have some disk space trashed for no good reasons. I don't ask that wrt Debian, just in case someone is reading who has also packaged a GPL port of their code for MS Windows is reading. thanks, Hamish -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1327001239.37252.yahoomailclas...@web110015.mail.gq1.yahoo.com
RFS: WorldForge base packageset
Dear mentors, I am looking for a sponsor for my set of packages skstream, wfmath, atlas-cpp, varconf, libwfut, mercator, and eris.o All of these packages were recently orphaned and i wish to adopt them and maintain them under the Debian Games team. The entire packageset will benefit from being uploaded together. The packageset is the basis for additional game client and game server packages. All of these packages have as the upstream author the WorldForge project http:://www.worldforge.org/ and are licensed under the GPL2+. * Package name: skstream Version : 0.3.8-1 Section : libs It builds those binary packages: libskstream-0.3-6 - iostream-based C++ socket library libskstream-0.3-6-dbg - iostream-based C++ socket library - debugging symbols libskstream-0.3-dev - iostream-based C++ socket library - development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/skstream Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/s/skstream /skstream_0.3.8-1.dsc * Package name: wfmath Version : 0.3.11-1 Section : libs It builds those binary packages: libwfmath-0.3-5 - WorldForge math library libwfmath-0.3-5-dbg - WorldForge math library - debugging library libwfmath-0.3-dev - WorldForge math library - development files libwfmath-doc - WorldForge math library - API documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/wfmath Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/w/wfmath/wfmath_0.3.11-1.dsc * Package name: atlas-cpp Version : 0.6.2-1 Section : libs It builds those binary packages: libatlas-cpp-0.6-1 - World Forge wire protocol library - runtime libs libatlas-cpp-0.6-1-dbg - World Forge wire protocol library - debugging libs libatlas-cpp-0.6-dev - World Forge wire protocol library - developer files libatlas-cpp-doc - World Forge wire protocol library - documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/atlas-cpp Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/atlas-cpp/atlas-cpp_0.6.2-1.dsc * Package name: varconf Version : 0.6.7-1 Section : libs It builds those binary packages: libvarconf-1.0-7 - WorldForge configuration file handling library libvarconf-1.0-7-dbg - WorldForge configuration file handling library - - debugging librar libvarconf-dev - WorldForge configuration file handling library - development file To access further information about this package, please visit the following URL: http://mentors.debian.net/package/varconf Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/v/varconf/varconf_0.6.7-1.dsc * Package name: libwfut Version : 0.2.2-1 Section : libs It builds those binary packages: libwfut-0.2-1 - WorldForge Update Tool (libraries) libwfut-0.2-1-dbg - WorldForge Update Tool (debugging libs) libwfut-0.2-dev - WorldForge Update Tool (development files) python-libwfut-0.2 - WorldForge Update Tool (Python bindings) wfut - WorldForge Update Tool (executable) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/libwfut Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/libw/libwfut/libwfut_0.2.2-1.dsc * Package name: mercator Version : 0.3.0-1 Section : libs It builds those binary packages: libmercator-0.3-1 - WorldForge terrain library libmercator-0.3-1-dbg - WorldForge terrain library - debugging symbols libmercator-0.3-dev - WorldForge terrain library - development files To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mercator Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mercator/mercator_0.3.0-1.dsc * Package name: eris Version : 1.3.19-1 Section : libs It builds those binary packages: liberis-1.3-19 - WorldForge client entity library liberis-1.3-19-dbg - WorldForge client entity library - debugging library liberis-1.3-dev - WorldForge client entity library - development files liberis-doc - WorldForge client entity library - API documentation To access further information about this package, please visit the following URL: http://mentors.debian.net/package/eris Alternatively, one can download the package
Re: Packaging proprietary software
Well, you basically have three ways (that I know of): 1. checkinstall - In my opinion as an amateur packager, it is by far the easiest solution. Maybe others disagree, I'd suggest it for trivial binary packages. 2. a dirty way of doing it, creating your own package using the ar command (a .deb package is basically an .ar archive): http://en.wikipedia.org/wiki/Ar_%28Unix%29 freemind is a java application: * http://packages.qa.debian.org/f/freemind.html * http://ftp.debian.org/debian/pool/main/f/freemind/freemind_0.9.0+dfsg-1_all.deb You can find some other packages written in java by tracking down the java maintainers: http://qa.debian.org/developer.php?login=pkg-java-maintain...@lists.alioth.debian.org 3. read and find out how to create a package using debhelper and a debian source package. I'm not sure if *dh_make* (a command that helps you create a new debian source package from scratch) and debhelper commands will help you with java (I suppose they do :) ), but for a binary source code all you need is to point to the files using the debian/install file. I helped someone once to package binary package (it was a windows binary, it was easier for them to make it work through wine) and make it available to the ubuntu linux community: https://launchpad.net/~ts.sch.gr/+archive/ppa (Note that the program is GPL'ed in case someone is wondering, I forget where the actual source code is though, should be somewhere here: http://alkisg.mysch.gr/ ) dget -ux http://ppa.launchpad.net/ts.sch.gr/ppa/ubuntu/pool/main/g/glossa/glossa_0.9.4.0-2.dsc cd glossa-* ls debian/ As I mentioned previously, the trivial thing to do is to change the debian/changelog, the debian/control and debian/install to match your software and files accordingly. debuild -S -sa ls ../ and voila! You have a debian source package (.dsc, .diff.gz and .orig.tar.gz), which you can build with the help of *pbuilder* (or * pbuilder-dist* in ubuntu) Either way, you need to know the basic structure of either a debian source package or a debian binary package, the new maintainer guide will help you a lot with that: http://www.debian.org/doc/manuals/maint-guide/ I hope this answer is more acceptable. :)
Re: Packaging proprietary software
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.01.2012 20:49, Savvas Radevic wrote: 2. a dirty way of doing it, creating your own package using the ar command (a .deb package is basically an .ar archive): http://en.wikipedia.org/wiki/Ar_%28Unix%29 0.0 Please use dpkg-deb --build or dpkg -b if you really want to do such things. Needless to say, you better forget about this possibility in its entirely. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPGHcgAAoJEMcrUe6dgPNtNbAQAMc78Tum1lmkQfqJXEPy+ODF 5+KtKhcfRqXPQxUHJxX+7Y407BuObH9IQuXSJ+Oi5ojzC2fiSnFrCEAp4/OKbuCF BLgWOGtZRm2ePiCMUJriAiWLSMVX7DdQ2GuUm9WfozInP4XVGaWEy8BzPlfTOu+r l39B82S8R+QHTgIq8Df3TF3M2V1LkywOo0ZpLDSvSnX3BvjRDNNePuukUFFoh/hn TVLiFJ5KC62hGe/RdNAmXvTicLrSaPj531ueHl1eV3KkSeloo+jGqrYcRuGhS9Pg bEKu4w4gY8wv04jV+9SxOlL01ptMs5RSIJukB8J7MM3uXNd1nCmUyX0hsMlL9o3e XMd9wDPgyd8/ODTCiklErQ8bVbYESut6/xdAEpIBsqv8MiCA5S90NZJV05VaMWO6 +9hnNi6LVUFw5loJ95WoQ7Odtru0Q4rQAzIgZsPOEmp6ezLlSnRaAEJsCpvTtm3P bnd44pJMewZjTAxUno1J7ar/WSAulSODWdr2GILcbnPekaBtr/z8rUZ3fVRiJNlj Nv3QiHqZ/Yv+tpVEOlpXR/CsQ9JXb4alZxYSvTQ6UtOG3i+fFmWnNVDNxmY24lPl Y2j4wQmZygRn/k4375nCyvJNT0byFKoyR7e/CTGjWCmkz3nseIIjycsyawluTt4d 1jQMyDEtFTjvDZa+Sct9 =wK78 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f187720.5070...@toell.net
Re: Packaging proprietary software
Thanks for the pointer. I never tried the second way I mentioned, but I saw that it is possible (the tutorial is old though): https://synthesize.us/HOWTO_make_a_deb_archive_without_dpkg
RFS: pyhoca-cli
Dear mentors, I am looking for a sponsor for my package pyhoca-cli. * Package name: pyhoca-cli Version : 0.1.4.2-4 Upstream Author : Mike Gabriel, Dick Kniep * URL : http://wiki.x2go.org * License : GPLv3+ Section : python It builds those binary packages: pyhoca-cli - Command line X2Go client written in Python To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pyhoca-cli Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pyhoca-cli/pyhoca-cli_0.1.4.2-4.dsc I would be glad if someone uploaded this package for me. Kind regards, Mike Gabriel -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpxcdubEisX3.pgp Description: Digitale PGP-Unterschrift
RFS: pyhoca-gui
Dear mentors, I am looking for a sponsor for my package pyhoca-gui. * Package name: pyhoca-gui Version : 0.1.0.10-5 Upstream Author : Mike Gabriel mike.gabr...@das-netzwerkteam.de, Dick Kniep dick.kn...@lindix.nl * URL : http://wiki.x2go.org * License : GPLv3+ Section : python It builds those binary packages: pyhoca-gui - Graphical X2Go client written in (wx)Python To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pyhoca-gui Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pyhoca-gui/pyhoca-gui_0.1.0.10-5.dsc I would be glad if someone uploaded this package for me. Kind regards, Mike Gabriel -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp8xnCkPQO05.pgp Description: Digitale PGP-Unterschrift
RFS: python-x2go
Dear mentors, I am looking for a sponsor for my package python-x2go. * Package name: python-x2go Version : 0.1.1.8-4 Upstream Author : Mike Gabriel, Dick Kniep * URL : http://wiki.x2go.org * License : GPLv3+ Section : python It builds those binary packages: python-x2go - Python module providing X2Go client API To access further information about this package, please visit the following URL: http://mentors.debian.net/package/python-x2go Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/python-x2go/python-x2go_0.1.1.8-4.dsc I would be glad if someone uploaded this package for me. Kind regards, Mike Gabriel -- DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419 GnuPG Key ID 0xB588399B mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgpSdT6yPQ2Cz.pgp Description: Digitale PGP-Unterschrift
Re: Packaging proprietary software
Paul Tagliamonte paul...@ubuntu.com writes: On Thu, Jan 19, 2012 at 10:37 AM, Savvas Radevic vice...@gmail.com wrote: P.S. I believe that Debian supports and helps with packaging open source software, not closed source and proprietary software. And thus spake the wiki: debian-mentors is for the mentoring of new and prospective debian developers. Almost any question relating to Debian development is potentially on-topic for d-mentors. Debian is a free software operating system. Any non-free software is thereby not a contribution to Debian, no matter how useful it is to some users of Debian. So if you want to package non-free software, while we are unlikely to actively hamper you, you are likewise not going to get as much help from people who want to mentor contributors to Debian, which is a free-software operating system. -- \ Rommel: “Don't move, or I'll turn the key on this can of Spam!” | `\ —The Goon Show, _Rommel's Treasure_ | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87y5t32s7k@benfinney.id.au
RFR: eegdev
Dear mentors, I am looking for reviews for my package eegdev. * Package name: eegdev Version : 0.0-1 Upstream Author : Nicolas Bourdaud nicolas.bourd...@gmail.com * URL : http://cnbi.epfl.ch/software/eegdev.html * License : LGPL-3+ Section : libs It builds those binary packages: eegdev-plugins-free - Biosignal acquisition device library (free plugins) libeegdev-dev - Biosignal acquisition device library (Developement files) libeegdev0 - Biosignal acquisition device library libeegdev0-dbg - Biosignal acquisition device library (Debugging symbols) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/eegdev Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/e/eegdev/eegdev_0.0-1.dsc I would be glad if someone review this package. Kind regards, Nicolas Bourdaud signature.asc Description: OpenPGP digital signature
Re: RFS: python-x2go
(I don't intend to sponsor this package.) * Mike Gabriel mike.gabr...@das-netzwerkteam.de, 2012-01-19, 23:41: dget -x http://mentors.debian.net/debian/pool/main/p/python-x2go/python-x2go_0.1.1.8-4.dsc I'd remove the commented-out commands from debian/rules. I'd also remove also explicit install and binary-indep targets, since the wildcard % do exactly the same. You provide build-arch and build-indep targets, but they do something different than the build target. That's bad. (dpkg-buildpackage currently doesn't use build-* targets, but it might start doing so in the future.) You should not explicitly delete debian/*.log, debian/packagename, etc. dh_clean takes care of this. Deleting debian/patches in the clean target is certainly a bad idea! You define PYVERS variable in debian/rules, but you don't use it anywhere. Upstream provides a test suite, please run it at build time (preferably using all supported Python versions). Does this package support Python 2.5? debian/pyversions says it does, XS-Python-Version says it doesn't. Please use only one of them, BTW. XB-Python-Version is deprecated, please remove it. = 0.13.0-0~0 is a pretty weird version constraint. Maybe = 0.13.0 or even = 0.13 could be used instead? You should close the ITP in the changelog. I (and most other sponsor here) normally require one changelog entry per upload to the archive. Lintian emits some experimental and informative tags that you might want to fix: X: python-x2go: duplicate-files usr/share/doc/python-x2go/html/frames.html usr/share/doc/python-x2go/html/index.html X: python-x2go: duplicate-files usr/share/doc/python-x2go/html/toc-x2go.backends.control._stdout-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.info._stdout-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.terminal._stdout-module.html X: python-x2go: duplicate-files usr/share/doc/python-x2go/html/toc-x2go.backends.printing._gconf-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.profiles._gconf-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.settings._gconf-module.html X: python-x2go: duplicate-files usr/share/doc/python-x2go/html/toc-x2go.backends.printing._file-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.profiles._file-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.settings._file-module.html X: python-x2go: duplicate-files usr/share/doc/python-x2go/html/toc-x2go.backends.printing._winreg-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.profiles._winreg-module.html usr/share/doc/python-x2go/html/toc-x2go.backends.settings._winreg-module.html I: python-x2go: possible-documentation-but-no-doc-base-registration It looks like documentation takes much more space than the rest of the package (7.6M vs 780K unpacked). Since end users don't need the documentation, maybe it'd be worthwhile to split it into a separate package? I'd exclude x2go.tests module from the binary package. setup.py have install_requires = ['setuptools', ...], but the package doesn't depend on python-setuptools. So either setup.py or the Depends is wrong (probably the former). x2go/monkey_patch_paramiko.py has a different license than the rest of the code, but this is not documented in debian/copyright. The strange status of x2go/gevent_subprocess.py is probably worth documenting, too. $ pyflakes . | grep ': undefined name' ./x2go/mimebox.py:100: undefined name 'mimebox_actions' ./x2go/checkhosts.py:225: undefined name 'random' ./x2go/checkhosts.py:225: undefined name 'string' ./x2go/checkhosts.py:225: undefined name 'string' ./x2go/log.py:123: undefined name 'types' ./x2go/log.py:125: undefined name 'types' ./x2go/mimeboxactions.py:92: undefined name 'self' ./x2go/mimeboxactions.py:100: undefined name 'self' ./x2go/mimeboxactions.py:152: undefined name 'WindowsError' ./x2go/utils.py:63: undefined name 'stdout' ./x2go/client.py:997: undefined name 'X2goSessionExceptionRegistryException' ./x2go/printactions.py:98: undefined name 'self' ./x2go/printactions.py:106: undefined name 'self' ./x2go/printactions.py:191: undefined name 'WindowsError' ./x2go/backends/profiles/_gconf.py:51: undefined name 'X2goNotImplementedYetException' ./x2go/backends/profiles/_winreg.py:51: undefined name 'X2goNotImplementedYetException' ./x2go/backends/profiles/_httpsbroker.py:50: undefined name 'X2goNotImplementedYetException' ./x2go/backends/profiles/_file.py:83: undefined name 'check_profile_id_or_name' ./x2go/backends/settings/_gconf.py:64: undefined name 'X2goNotImplementedYetException' ./x2go/backends/settings/_winreg.py:64: undefined name 'X2goNotImplementedYetException' ./x2go/backends/control/_stdout.py:171: undefined name 'SSHException' ./x2go/backends/printing/_winreg.py:75: undefined name 'X2goNotImplementedYetException' ./x2go/backends/terminal/_stdout.py:325: undefined name 'X2goTerminalSessionException' ./x2go/backends/terminal/_stdout.py:942:
RFS: lebiniou (new upstream version 3.14)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear mentors, I am looking for a sponsor for my package lebiniou. Package name: lebiniou Version : 3.14-1 Upstream Author : Olivier Girondel oliv...@biniou.info URL : http://biniou.net/ License : GPL2+ Section : graphics It builds this binary package: lebiniou - displays images that evolve with sound To access further information about this package, please visit the following URL: http://mentors.debian.net/package/lebiniou Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/l/lebiniou/lebiniou_3.14-1.dsc I would be glad if someone uploaded this package for me. Kind regards, - -- Olivier Girondel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8YsTEACgkQpqVXaJzJYNJeNACdGZ56QqCv9YhSto4B9Cko3vzl Q/EAn3eWdRRC7Tb95SE8PMI54l3QWL5i =e6v7 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f18b13c.7090...@biniou.info
RFS: acsccid (New Upstream Release)
Dear mentors, I am looking for a sponsor for my package acsccid. acsccid 1.0.3 added more ACS CCID smart card readers support as well as legacy smart card readers such as ACR38 running proprietary protocol (non-CCID). It also improved card protocol parameters handling so that the optimal baud rate between reader and card is selected. * Package name: acsccid Version : 1.0.3-1 Upstream Author : Advanced Card Systems Ltd. * URL : http://acsccid.sourceforge.net/ * License : LGPL-2.1+ Section : libs Here is the change log: * New upstream release. * Removed debian/patches/pcsc-lite-1_7_3.patch. * Updated debian/copyright. * Updated debian/libacsccid1.udev from upstream. It builds those binary packages: libacsccid1 - PC/SC driver for ACS USB CCID smart card readers To access further information about this package, please visit the following URL: http://mentors.debian.net/package/acsccid Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/a/acsccid/acsccid_1.0.3-1.dsc I would be glad if someone uploaded this package for me. Kind regards, Godfrey Chung
GREAT news: My First Debian Package ! - vpcs
GREAT news: I'm ready to upload my first Debian package ! Link: (source + amd64 binary) http://forum.gns3.net/post14018.html = NAME vpcs - A light-weight network virtual pc simulator. DESCRIPTION The VPCS can simulate up to 9 PCs. You can ping/traceroute them, or ping/traceroute the other hosts/routers from the virtual PCs when you study the Cisco routers in the Dynamips. VPCS is not the traditional PC, it is just a program, and only few network commands can be used in it. But VPCS can give you a big hand when you study the Cisco devices in the Dynamips. VPCS can replace the routers or virtual machine boxes which are used as PCs in the Dynamips net‐ work. It can connect to VirtualBox or to GNS3 Network Simulator. = I have tested the final package on a Debian 6.0 AMD64 box. And it works ! It passes lintian with only few warnings; Suggestions welcome ! Where to upload it ? This package is very small, but it is needed for my GNS3 users and to get me involved with Debian. That's why it is important. I patched the makefile with quilt + made a man page. Erik: Could you sponsor me ? -- -Alexey Eromenko Technologov -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOJ6w=hghc-5x0amokzygnxbk9qncqdkzadvx7pp+v-3umz...@mail.gmail.com
Re: RFR: eegdev
Hi, On Fri, Jan 20, 2012 at 12:33:44AM +0100, Nicolas Bourdaud wrote: I am looking for reviews for my package eegdev. If nobody is quicker than me I will have a look at this package tonight. Cheers, Michael -- Michael Hanke http://mih.voxindeserto.de -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120120054102.GB9230@meiner
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Thu, Jan 19, 2012 at 1:27 PM, Lucas Nussbaum wrote: Hi, I'm generally not a big fan to overuse the BTS for stuff it wasn't really designed for. This tends to result in complex processes that are difficult to follow for newcomers. That statement actually describes the Debian project as a whole (not just bts-using services/teams). There are extensive processes in Debian for everything, and as such its not going to necessarily be easy for any newcomer. Then again, that may not be such a bad thing as it means that *qualified* newcomers have already demonstrated the fact that they can educate themselves. If that means answering similar questions somewhat regularly, so be it. A simple link to the developers reference often suffices. That's not so hard. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnsl35_ojnh7fn1a4ufb_jx2jcsk22zebsatw+tscx...@mail.gmail.com
Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests
On Thu, Jan 19, 2012 at 1:07 PM, Russ Allbery wrote: Jakub Wilk jw...@debian.org writes: * Gergely Nagy alger...@balabit.hu, 2012-01-19, 17:24: I might be mistaken, but the amount of NEW Why only NEW? Checking only NEW packages doesn't buy us more than, say, checking only package with with have r in their name. I know, this is what ftp-folks do. I call this securi^Wdistributability theater. For the main archive, the NEW check I think is best thought of as a spot check to ensure maintainers are doing their jobs. The real responsibility of not uploading non-redistributable material lies with the Debian project members with upload rights. ftpmaster is just checking for mistakes (at the point at which most mistakes are made). The difference for mentors is that the uploaders are not (yet) Debian project members and are not guaranteed to be trained in our licensing policies, and have not agreed to follow our rules. So, I think these concerns can be abated by thinking of mentors more of an alternative NEW queue for newcomers; rather than as an alternative package pool, which it's not (binary packages are not served, and files hosted are not widely distributed since most users wouldn't know what to do with a source package even if they got one). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNcnpW_kNuX=MD=4mo04tzdqcigk+tuym1_c2thdx8...@mail.gmail.com
Re: Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
On Thu, Jan 19, 2012 at 6:47 AM, Arno Töll wrote: DSA is the team which makes a DNS CNAME record, or provides a hosting facility. In my interpretation they are not making facts by that. Making mentors.debian.net a .org makes the project official part of Debian, just like any other core team, e.g. ftp-master, security team, release team and so on. That's not something which should be decided without consensus among Debian Developers and, perhaps, a DPL which delegates some people to a mentors task. Thus, I am sending this mail to -devel again. Maybe anyone wants to raise the voice on that matter. I don't think it is possible to gain a consensus of debian developers. There is of course the option of a GR, but those are a nightmare and have unintended consequences. DSA decides what services they host, so we only need to convince them that a mentors machine wouldn't be a burden. Anyway, I think if we can get people behind this, we would want to make it happen quickly, then the mentors.debian.org psuedo-package would be available, and we could straightforwardly implement the bug-based RFP process. That's the plan, but again: tracking sponsor requests as bugs, and integrate mentors.debian.net into Debian are unrelated problems. Any proposal can be implemented without touching the status-quo of the other. They are intimately related as we need a pseudo-package to even begin the bug-based workflow, and that needs to be a .org. So the official domain is required first. The term contributor conveys a much more welcoming message as it says this is the place where I can go to learn about start making contributions to debian, and this is where we can go to help people become contributors. That's the problem. A contributor can have many roles in Debian, it is overbooked just like terms such as DSA and maintainer (albeit zack suggested to come over the latter problem). Like I've said before, this is not about eliminating ambiguity. Every single word in every single language is ambiguous. It's simply unavoidable. It's about choosing the word with the right context for the goals of the service. This should be a place for contributors to come together to collaborate and make their work better before pestering a DD about it; with minimal experienced intervention (mentoring). This is to attempt to help solve the problem that practically no DDs want to be burdened with mentoring. Let's make this about contributors primarily helping themselves. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPdOiDpk71kPfmMOcTTCOQSW0CeRDqKy0x0t=7txdv...@mail.gmail.com
Re: RFS: lebiniou (new upstream version 3.14)
Hi, On 20/01/2012 01:11, Olivier Girondel wrote: Dear mentors, I am looking for a sponsor for my package lebiniou. Package name: lebiniou Version : 3.14-1 Upstream Author : Olivier Girondel oliv...@biniou.info URL : http://biniou.net/ License : GPL2+ Section : graphics I have not done a full review, but I think your debian/control file miss some Build-Depends like libpulse-dev or zlibg1-dev... Cheers, Nicolas signature.asc Description: OpenPGP digital signature
Re: Making mentors.debian.net a .org (was: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests)
I'm putting the l10n-english team in BCC as they *might* want to help us out here but I don't really want to start cross-posting. You'll figure out which list to proceed on, right? On Fri, Jan 20, 2012 at 01:07:02AM -0500, Michael Gilbert wrote: On Thu, Jan 19, 2012 at 6:47 AM, Arno Töll wrote: The term contributor conveys a much more welcoming message as it says this is the place where I can go to learn about start making contributions to debian, and this is where we can go to help people become contributors. That's the problem. A contributor can have many roles in Debian, it is overbooked just like terms such as DSA and maintainer (albeit zack suggested to come over the latter problem). Like I've said before, this is not about eliminating ambiguity. Every single word in every single language is ambiguous. It's simply unavoidable. It's about choosing the word with the right context for the goals of the service. That's the primary goal, yes, absolutely. Though the past shows clearly how un ambiguous terms served us with confusion, may they have been as appropriate as possible (see the DM != DM != DD != maintainer debacle). My point being, we should look for a perfectly describing term, and then make sure it's not used already in a different (or worse: a similar) context. This should be a place for contributors to come together to collaborate and make their work better before pestering a DD about it; with minimal experienced intervention (mentoring). Well, I'm not a native english speaker, though what you're describing doesn't sound like mentoring but rather training. To mentor, as I understand it, is an action someone skilled performs in order to teach or train another person. As you said, the service provided here is for those who still learn, who are being mentored, i.e. it's actually not for mentoring. Now, I'm not sure training is the right term, as it suggests (to me) the service is something like a playground, but I can be mistaken. A native speaker should probably say something here. Hauke -- .''`. Jan Hauke Rahm j...@debian.org www.jhr-online.de : :' : Debian Developer www.debian.org `. `'` Member of the Linux Foundationwww.linux.com `- Fellow of the Free Software Foundation Europe www.fsfe.org signature.asc Description: Digital signature
