Re: parallel building without make

2008-01-30 Thread Lucas Nussbaum 
On 29/01/08 at 17:23 -0300, Felipe Sateler wrote:
> Recently dpkg-buildpackage got the option to build in parallel via the -j
> option. This means that debian/rules is called with that option set, and sets
> parallel=n in DEB_BUILD_OPTIONS.
> The problem is that for build systems not using make (eg, scons), this option 
> is
> not inherited. Of course, one could parse DEB_BUILD_OPTIONS and find if
> parallel=n is set and then call the build system with the equivalent option.
> However this means that, although one specified n threads of execution, there
> can be more than n threads concurrently. Consider this case:
> 
> build: build-indep build-arch
> build-arch:
> scons -j$(NTHREADS) buildProgram
> build-indep:
> scons -j$(NTHREADS) buildDocumentation
> 
> Where NTHREADS is calculated from DEB_BUILD_OPTIONS. If I call 
> dpkg-buildpackage
> with -j2, I will get build-arch and build-indep running concurrently, which
> means I will actually get 4 scons threads running instead of the intended 2. 
> 
> What should I do? I see 3 options:
> 1- Don't use the -j flag in scons
> 2- Use the -j flag and potentially use more threads than specified
> 3- Use the -j flag with a lower number (eg, NTHREADS/2).
> 
> Any opinions?
 
Don't use dpkg-buildpackage -j. Only set DEB_BUILD_OPTIONS="parallel=n",
so build-arch and build-indep are not run in parallel, but you still get
several scons threads.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposal for collaborative maintenance of packages

2005-12-19 Thread Lucas Nussbaum 
On 18/12/05 at 17:19 +0100, Raphael Hertzog wrote:
> [ Sorry for the crosspost, but the subject is of interest to many people ]
> 
> Hello everybody,
> 
> following the last discussion at the Debian-QA meeting on Darmstadt, it
> appears that the proposal called "Collaborative maintenance" is of generic
> interest :
> - for Debian sponsors and Debian mentors
> - for QA which may use the infrastructure for orphaned packages
> - for Ubuntu's MOTU School
> 
> I tried to describe the big lines of the project in this wiki page:
> http://wiki.debian.org/CollaborativeMaintenance

Interesting.

Disclaimer: I'm neither a DD nor a MOTU. I'm part of the debian
pkg-ruby-extras team, which maintains some ruby-related packages
collaboratively. I'm also part of MOTURuby, a MOTU team that takes care
of all ruby-related packages in Ubuntu.

Your proposal mixes technical issues and human issues.

First, technical issues:

* Chances are very low that you will get Ubuntu people to use svn
instead of bzr. bzr is the "official" VCS in Ubuntu, it is written in
Python, the "official" language in Ubuntu. Making Ubuntu people use svn
is like asking a vi user to switch to emacs.

* Generating a dynamic web page means using a non-distributed
architecture. I started working on similar stuff, but with the
assumption that maintainers will run the scripts themselves (or with
cron). An output for ruby-related packages is available on
http://ox.blop.info/bazaar/rubyversionslist.html . The webpage about the
tools is https://wiki.ubuntu.com/MOTUTools . An easier approach could be
to provide the information in an easy way on all websites so some
scripts could fetch the pages, parse them, and generate the useful
reports.

Human issues:
* The main problem is how to define trust relationships between DDs,
MOTUs, would-be DD and MOTU-Hopefuls :
  * Do we want to define them globally, or on a per-team basis ?
  * What should they be ? Does Debian want to trust MOTU-hopefuls ? Does
  Ubuntu want to trust would-be DDs ?

I think that we shouldn't try to reach a too wide scope here. Chances
are high it will be too complex and will just fail. Why not start by
developping tools to help Debian & Ubuntu collaborate by exchanging
patches, bug reports and source packages, and wait for collaborative
maintenance ?

Of course, the problem space of REVU and {mentors,sponsors}.d.n is
similar, and common tools could be developed too instead of reinventing
the wheel.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Rebuilding the whole archive.

2007-05-14 Thread Lucas Nussbaum 
(I'm not subscribed to the list)

> On Mon May 14, 2007 at 09:15:23 +0900, Charles Plessy wrote:
> > Dear Mentors,
> > 
> > I would like to do a mass rebuild of at least a significant part of the
> > archive to investigate a potential problem on G5 running the powerpc
> > port.  I am currently trying to use
> > /usr/share/doc/pbuilder/examples/pbuildd/buildd.sh from the pbuilder
> > package, but I have a few problems with it.
> > 
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423483
> > 
> > I also wanted to try wanna-build, but the only archive I found
> > explicitely forbids the usage of the program:
> > (http://svn.cyberhqz.com/svn/wanna-build/debian/changelog)
> > Since this was added after the parution of Julien Danjou's buildd howto,
> > I am taking the message seriously and will not use wanna-build.
> > 
> > Even if I manage with buildd.sh, I would be interested to know about
> > alternatives. My main interest is to generate build logs, but I do not
> > need to keep the .debs. Are there better tools for this ?

If you just want to rebuild all packages once, you don't need
wanna-build. Just parse the Source files and get the list of (package,
version) you want to build. Then use pbuilder or sbuild to build them
all.

My preference goes to sbuild, because it's closer to what is really
running on the buildds (so you get less false positives). But pbuilder
should probably suit your needs as well.
 
Good luck,
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RFS: mailscanner (updated package)

2007-07-12 Thread Lucas Nussbaum 
On 12/07/07 at 19:26 +0200, Simon Walter wrote:
> 
> Dear mentors,
> 
> I am looking for a sponsor for the new version 4.61.7-1
> of my package "mailscanner".
> 
> It builds these binary packages:
> mailscanner - email virus scanner and spam tagger
> 
> The package appears to be lintian clean.
> 
> The upload would fix these bugs: 412883, 425861, 429954
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/m/mailscanner
> - Source repository: deb-src http://mentors.debian.net/debian unstable main 
> contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/m/mailscanner/mailscanner_4.61.7-1.dsc
> 
> I would be glad if someone uploaded this package for me.
 
Hi Simon,

diff -burN mailscanner-4.58.9/debian/changelog 
n/mailscanner-4.61.7/debian/changelog
--- mailscanner-4.58.9/debian/changelog 2007-07-12 20:28:35.0 +0200
+++ n/mailscanner-4.61.7/debian/changelog   2007-07-12 20:29:01.0 
+0200
@@ -1,4 +1,12 @@
-mailscanner (4.58.9-2) unstable; urgency=low
+mailscanner (4.61.7-1) unstable; urgency=low
+
+  * New upstream version (Closes: #425861, #429954)
+  * Add portuguese debconf translation. (Closes: #412883)
+  * Removed f-prot location patch, f-prot-installer package has been removed
+
+ -- Simon Walter <[EMAIL PROTECTED]>  Sat, 07 Jul 2007 13:24:36 +0200
+
+mailscanner (4.58.9-2) unstable; urgency=high
 
   * Exim.pm: Fix serious problem with patch for #346212, MailScanner couldn't 
read any address

please fix that: it *might* confuse the BTS's version-tracking. And you don't
want to confuse the BTS version-tracking. ;)

Other comments:
- please consider making clamav a Recommends, or (more likely) clamav-daemon.
- please consider including the ubuntu patch. It won't hurt, especially if 
/var/run is cleaned up. (/var/run is on /tmpfs in Ubuntu, so that's probably 
the reason for that patch)
- please consider fixing bug #432881 now that I filed it ;)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: RHS: libterm-ansicolor-ruby

2007-08-19 Thread Lucas Nussbaum 
On 15/08/07 at 00:12 +0530, Deepak Tripathi wrote:
> Dear mentors,
>
> I am looking for a sponsor for my package "libterm-ansicolor-ruby".

Hi,

Have you considered maintaining this package inside the pkg-ruby-extras
team? It would probably help a lot when looking for sponsors.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Package requiring a customised version of libc6

2007-08-23 Thread Lucas Nussbaum 
On 24/08/07 at 01:26 +0100, David Given wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Don Armstrong wrote:
> [...]
> > The people who have responded to you so far strongly suspect that it's
> > not worth the effort, but without knowing why the glibc we already
> > distribute can't be used, it's hard for us to give you a definitive
> > answer.
> 
> *nods*
> 
> As far as I can tell --- I've contacted upstream to confirm this --- what
> plasticfs wants to do is to override the underlying system calls

Then what about using ptrace and overriding syscalls in the way
usermodelinux used to do it?

You could point your upstream to this article:
Rapid File System Development Using ptrace
Richard P. Spillane, Charles P. Wright, Gopalan Sivathanu, and Erez
Zadok
Should still be available from
http://www.cs.huji.ac.il/~feit/exp/prog.html
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 0-day NMUs, DELAYED/n uploads

2007-10-16 Thread Lucas Nussbaum 
Hi,

If I understand things correctly, we are discussing the NMU of grig by
Cyril (#444509).

On 16/10/07 at 16:36 -0700, Richard Hecker wrote:
> Cyril Brulebois wrote:
>> The rules defined in [1] applied. And instead of pinging the maintainer,
>> waiting, and then uploading (to DELAYED/0), it looked like (after
>> talking with DDs during the BSP I mentioned) that DELAYED/n was a good
>> means of notifying the maintainer, through the nmudiff sent to the bug,
>> making the patch publicly visible, as well as the status of the bug
>> (patch & pending tags), and letting the maintainer the time to react.
>>
>>  1. http://lists.debian.org/debian-devel-announce/2007/09/msg0.html
>>
>>   
> While that link describes a temporary necessity, the regular
> NMU rules still apply.  I do not know which DDs you talked with,
> but submitting an NMU to a "DELAYED/n" queue IS NOT "a
> good means of notifying the maintainer."  You should always
> try to contact the maintainer first!

The maintainer was properly notified through the BTS:
- when the patch was provided
- when the package was uploaded to DELAYED/5.
This means several days before the upload reaches the archive. Had the
maintainer wanted to stop the process, he could have told Cyril (or his
sponsor), and the upload could have been removed from DELAYED/n.

> I am not suggesting that a maintainer that refuses to respond
> will hold up the NMU.  I want to explicitly note the disrepect
> that is shown when a maintainer first learns of the NMU from
> a DELAYED queue without prior notice.

Which disrespect? Cyril has been very helpful (despite not being a DD
yet), submitting patches and fixes to a lot of RC bugs. He is extremly
responsive. I'm not sure if the case of a maintainer refusing the NMU
before the 'n days' delay expired already happened, but I'm sure that
Cyril would have dealt with it correctly.

> If a person cannot communicate with some email, being a 'lone wolf'
> submitting NMUs will not benefit the project in the long term.  The
> NMU does not replace communication skills.

Mails were sent to the relevant bugs on the BTS (and thus to the
maintainer(s)). Do you need a personal email, because you filter out BTS
mails? Then we probably have another problem.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: 0-day NMUs, DELAYED/n uploads

2007-10-17 Thread Lucas Nussbaum 
Hi,

This thread started on [EMAIL PROTECTED] The process that should be followed for
0-day NMUs is being discussed. (reminder: it's allowed to do 0-day NMUs
for RC bugs and release goals, for bugs older than 7 days).

Please continue the discussion on -devel@, as it's of interest to
everybody.

On 17/10/07 at 07:51 -0700, Richard Hecker wrote:
>>> If a person cannot communicate with some email, being a 'lone wolf'
>>> submitting NMUs will not benefit the project in the long term.  The
>>> NMU does not replace communication skills.
>>> 
>>
>> Mails were sent to the relevant bugs on the BTS (and thus to the
>> maintainer(s)). Do you need a personal email, because you filter out BTS
>> mails? Then we probably have another problem.
>>   
> Yes, we do have a problem. From section 5.11.1 of our
> developers reference (http://www.debian.org/doc/developers-reference),
> the admonition is to "contact the developer first, and act later." It
> appears to me that people do not even understand what the usual
> rules are for NMUs.

When dealing with a bug, it is painful to do an action at one point (notifying
the maintainer), and to have to remember that another action needs to be
done later (do the upload). The DELAYED queue helps a lot with that by
making it possible to do both actions at the same time, but still leave
some time for the maintainer to react.

The following processes seem appropriate to me:
- for bugs older than 7 days:
  - send a mail to the BTS with the NMU diff
  - at the same time, upload directly to unstable, or to DELAYED/1, 2,
  or 3, depending on the package (is it a very popular package?), the
  maintainer (is he active?) and the patch (am I 100% it won't break, or
  only 99%?)

- for bugs newer than 7 days:
  - send a mail to the BTS with the NMU diff
  - at the same time, upload to DELAYED/(7-age), or to
DELAYED/(7-age+1,2,3), depending on the same conditions as above

But it seems that some maintainers disagree. Is there a consensus that
those processes are OK? If not, what could we do, without making it too
painful for the NMUer?
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mentors.debian.net reloading

2007-10-26 Thread Lucas Nussbaum 
On 26/10/07 at 11:42 +0200, Christoph Haas wrote:
> It does a lot of QA checks etc.

Could you please describe what's currently being done wrt QA checks?

> I have summarized a current list of ideas on my wiki [4].

Any reason why wiki.d.o is not used for this? It would make it much
easier for people to contribute.

Some comments:

Please seperate features list and implementation details: if you want
other people to contribute, you might have to be flexible with things
such as which framework/language you choose.

Regarding CPU-intensive QA tests (builds and piuparts runs): I think
that it's very important to do them on mentors. I don't think that
resources are a problem: nobody said that you _had_ to host mentors
yourself.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mentors.debian.net reloading

2007-10-26 Thread Lucas Nussbaum 
On 26/10/07 at 14:18 +0200, Christoph Haas wrote:
> > Please seperate features list and implementation details: if you want
> > other people to contribute, you might have to be flexible with things
> > such as which framework/language you choose.
> 
> Regarding frameworks: since I'm pretty active in the Pylons project and
> probably will have to do >50% of the work myself anyway (currently >99%)
> I chose the weapons. I hope others are more flexible and like my choice. :)
> 
> The list is deliberately kept a bit sketchy. When it comes to planning
> the actual application I intend to have a thorough documentation. Right
> now it's more like mental notes on how to do certain things. Just ignore
> them if they don't make sense. Nothing is fixed on the list. But I won't
> turn a coffee machine into an nuclear power plant so some parameters are
> fixed. And it will have to be Python because otherwise even the utility
> libraries would have to be rewritten. It's not like we'd have to start
> entirely from scratch.
> 
> > Regarding CPU-intensive QA tests (builds and piuparts runs): I think
> > that it's very important to do them on mentors.
> 
> Might be helping the sponsor to determine if the package builds. But I'm
> not sure if it's worth it. Just my personal opinion.

I'm more interested in piuparts tests than in builds, actually. The
point is that most DDs don't use piuparts because there's not many
benefits in spending time setting it up. Having a piuparts installation
working on mentors.d.n would allow everybody to easily test his
packages.

Regarding builds, it might not be necessary, but it's still good to
have. When packages are waiting for a long time, rebuilding them from
time to time could exclude some packages that are no longer candidates
for sponsorship (since they fail to build).

> > I don't think that resources are a problem: nobody said that you _had_
> > to host mentors yourself.
> 
> It is a rented virtual root server with enough power and 1 TB of free
> traffic that I pay for from my spare money. I think it would be able to
> do that if needed.
> 
> I might get you wrong but to me you sound more like "If you are
> incapable of running the service properly then let someone else step up"
> instead of "I think that test builds are important. If you agree but
> don't have the proper resources I can perhaps offer some computing
> power.". Sorry if my emotion chip got you wrong.

Your emotion chip went a bit wrong, but not totally ;) I have the
feeling that the lack of open-ness in mentors.d.n caused several people
to reinvent it (with sponsors.d.n and REVU). Of course, it's not the
only cause, but I have the feeling that mentors could be much better
than it currently is, but isn't, because of the fact that it was
developed "privately".

I hope that things will change, but everybody has to have an open mind
if we want this to happen.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: mentors.debian.net reloading

2007-10-26 Thread Lucas Nussbaum 
On 26/10/07 at 16:06 +0200, Christoph Haas wrote:
> On Fri, Oct 26, 2007 at 03:26:57PM +0200, Lucas Nussbaum wrote:
> > On 26/10/07 at 14:18 +0200, Christoph Haas wrote:
> > 
> > I'm more interested in piuparts tests than in builds, actually. The
> > point is that most DDs don't use piuparts because there's not many
> > benefits in spending time setting it up. Having a piuparts installation
> > working on mentors.d.n would allow everybody to easily test his
> > packages.
> 
> That would mean getting the package in Debian (with the dependencies),
> installing it, testing upgrading to the new deb etc., right? I just
> worry what happens if I try that with a package that pulls in 1 GB of
> dependencies. How would that work? (Disclaimer: I have just recently
> begun to actually use piuparts.)

It works fine, but takes some time. I ran piuparts several times over
the whole archive, without running into severe problems.

> > Regarding builds, it might not be necessary, but it's still good to
> > have. When packages are waiting for a long time, rebuilding them from
> > time to time could exclude some packages that are no longer candidates
> > for sponsorship (since they fail to build).
> 
> Right. But although I used to sponsor a lot of packages hardly any of
> them actually failed to build. Mostly because the maintainer forget a
> certain dependency. But it's certainly possible to run pbuilder on the
> package.

What Ondrej proposes is to turn mentors into a package archive, where
packages would be built automatically on several arches, and people
could download them. In that case, it's required to build package for
all archs available in the service (you can't ask the uploader to do
that hmiself).
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Automated testing of maintainer and init script interaction?

2007-11-03 Thread Lucas Nussbaum 
On 02/11/07 at 10:39 -0700, Zack Weinberg wrote:
> Has anyone written a utility for automatically testing the interaction
> between maintainer and init.d scripts?  To verify that, for instance,
> package purge works no matter what debconf variables are set, or
> whether or not the daemon is running.

I don't think so, but it could be a good idea to hack piuparts into
doing that.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: proposed new pseudo-package 'debian-mentors' for handling sponsoring requests

2012-01-19 Thread Lucas Nussbaum 
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] 

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: Package uploaded with UNRELEASED distribution.

2009-08-23 Thread Lucas Nussbaum 
On 20/08/09 at 22:45 +0900, Charles Plessy wrote:
> Le Thu, Aug 20, 2009 at 09:39:44PM +0800, Paul Wise a écrit :
> > The changes file says Distribution: unstable:
> > 
> > http://packages.qa.debian.org/v/velvet/news/20090819T133220Z.html
> 
> Very good point. So only the changelog is borken.
> 
> I built the package with its UNRELEASED changelog with sbuild, which puts the
> schroot's name in the Distribution field of the changes control file. The
> inconsistency with the changelog went unnoticed by our tools. Luckily, the
> package was really intended for upload. I will fix the changelog at the next
> upload, the error does not seem to be disruptive.

I had a package rejected out of NEW because of that (same case:
UNRELEASED in changelog, Distribution: unstable in .changes). Being
curious, I asked ftpmasters why it this was a problem (besides not being
very beautiful), but didn't get an answer.

I think that it's mostly harmless: I can't think of any important part
of Debian architecture parsing the changelog to extract that
information. It probably just doesn't look nice on
http://packages.debian.org/.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: RFS: ruby-fftw3

2009-09-15 Thread Lucas Nussbaum 
On 15/09/09 at 22:34 +0900, Youhei SASAKI wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "ruby-fftw3".
> 
> * Package name: ruby-fftw3
>   Version : 0.2-1
>   Upstream Author : Takeshi Horinouchi 
> * URL : http://ruby.gfd-dennou.org/products/ruby-fftw3/
> * License : GPL ver.2 or later
>   Section : ruby
> 
> It builds these binary packages:
> libfftw3-ruby1.8 - Ruby FFT library using FFTW Ver.3
> 
> The package appears to be lintian clean.
> 
> The upload would fix these bugs: 546748
> 
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/r/ruby-fftw3
> - Source repository: deb-src http://mentors.debian.net/debian unstable main 
> contrib non-free
> - dget 
> http://mentors.debian.net/debian/pool/main/r/ruby-fftw3/ruby-fftw3_0.2-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Hi,

Have you considered maintaining it inside the pkg-ruby-extras team?
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: New developer.

2009-11-25 Thread Lucas Nussbaum 
On 25/11/09 at 14:26 +0100, Alexander Reichle-Schmehl wrote:
> Hi!
> 
> * Nuno Paquete  [091125 14:18]:
> 
> > How can I get GnuPG key?
> 
> You create one yourself.
> 
> 
> > I don't know anybody in the team and 
> 
> You know, that you need someone to advocate you?
> 
> 
> > I've read that I need someone to give me one.
> 
> Where did you read this?
> 
> 
> > I'm thinking about doing this:
> > - Read all the necessary documentation (I need to read a lot yet)
> > - Get a GnuPG key
> 
> No, you create a key and get it signed by soomeone in the project.
> 
> 
> > - Submit myself as a maintainer of a project
> 
> Before you do that, you should already have contributed to the project.
> e.g. being part of a (packaging) team or getting packages uploaded for
> you by a sponsor.

Why the harsh answer? The guy probably just understood that he had to do
those steps before starting to contribute.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On intermediary deb-releases, their archiving.

2010-01-21 Thread Lucas Nussbaum 
On 22/01/10 at 00:51 +0100, Mats Erik Andersson wrote:
> Hello all,
> 
> in trying to disect an RC-bug I find myself wanting to
> compare, using debdiff, two immediate successor packages,
> like
> 
>  this_1.20-15.dsc   and   this_1.20-16.dsc.
> 
> However, for the particular package in question Lenny has
> 1.20-13.1 and both testing and unstable share 1.20-16.
> These are available from the standard mirrors.
> 
> Is there some location where one could, with some luck,
> encounter also the intermediary packages that have been
> superseeded with time? Or are such packaged quickly
> pushed into oblivion?

James Westby (Canonical) is working on a service that imports the full
history of Debian packages in bzr branches. That will be eventually used
to simply the process of merging new versions from Debian.

The branches for each package are available from
https://code.launchpad.net/debian, or
https://code.launchpad.net/~ubuntu-branches/debian/sid/libnokogiri-ruby/sid
(for a specific package).

It's still ungoing work, some revisions might be missing, and he also
plans to rebase the branches when snapshot.debian.org will be available.
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: On intermediary deb-releases, their archiving.

2010-01-21 Thread Lucas Nussbaum 
On 22/01/10 at 10:34 +0900, Charles Plessy wrote:
> Le Fri, Jan 22, 2010 at 12:20:50PM +1100, Ben Finney a écrit :
> > Mats Erik Andersson  writes:
> > 
> > > in trying to disect an RC-bug I find myself wanting to compare, using
> > > debdiff, two immediate successor packages, like
> > >
> > >  this_1.20-15.dsc   and   this_1.20-16.dsc.
> > >
> > > However, for the particular package in question Lenny has 1.20-13.1
> > > and both testing and unstable share 1.20-16. These are available from
> > > the standard mirrors.
> > 
> > Right. The donated archive space is sufficient for the packages that are
> > currently part of a Debian suite.
> 
> By the way, Ubuntu stores snapshots in Bzr branches, so if syncs were regular,
> one may find what he wants for Debian in Launchpad:
> 
> https://code.launchpad.net/ubuntu/+source/
   ^- debian

L.


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: +dfsg extension meaning and reference docs ?

2010-03-24 Thread Lucas Nussbaum 
On 24/03/10 at 19:40 +0100, Obey Arthur Liu wrote:
> Repack. These files cannot live on Debian archives (or ISOs). I'm not sure
> about what rules apply to Alioth or collab maint though.
> 
> Arthur
> 
> On Mar 24, 2010 6:45 PM, "Olivier Berger" 
> wrote:
> 
> Hi.
> 
> I cannot manage to find the reference docs that would explain the
> rationale and requirements on upstream sources to be repackaged in
> source packages with the +dfsg extension.
> 
> Any pointer to authoritative docs ?
> 
> Thanks in advance.
> 
> Best regards,
> 
> P.S.: my concern is with files that are non-free according to DFSG,
> present in upstream tarball, but that are not present in binary
> packages... what should be done ?

Arthur, could you please try to respect netiquette when sending mail on
Debian mailing lists?

L.


-- 
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/20100324211220.ga10...@xanadu.blop.info

Re: RFS: NMU goocanvas (updated package)

2010-05-08 Thread Lucas Nussbaum 
On 08/05/10 at 20:20 +0900, Charles Plessy wrote:
> Le Sat, May 08, 2010 at 01:01:00PM +0200, Jeffrey Ratcliffe a écrit :
> > On Sat, May 08, 2010 at 09:57:53AM +0800, Paul Wise wrote:
> > > You might want ping the maintainer directly and to report them as MIA
> > > if they do not respond:
> > 
> > He's been pinged on several occasions on #521722[1]. Ubuntu has
> > had new upstream version for nearly a year.
> > 
> > I'll ping him again directly and wait two weeks, but I assumed this is
> > what the 10-day delayed queue was for - to give the maintainer a last
> > chance to respond before the NMU is uploaded.
> 
> Dear Jeff,
> 
> If goocanvas is updated by NMU, who will be responsible for taking care for 
> any
> issue introduced by this upload: the maintainer? you? the NMU sponsor? It is 
> to
> avoid such solution where responsability is unclear that packages are not
> updated by NMU in Debian.

It is not unclear. If Jeff NMUes it, he is responsible (together with
his sponsor) for the damage he will have introduced.

> If the maintainer does not respond to the requests
> for updates, is is a hint that the package needs a new maintainer (in addition
> or replacement for the current one), or that the package should better be
> removed. Updating a package by NMU solves a problem in the short term, but
> increases the risk that nobody will be there for later problems.
> 
> Perhaps you can propose to the current maintainer to open his package to
> collaborative maintainance, by creating or joining a team, or simply accepting
> co-maintainers (you?) who commit themselves on a longer term than a single
> upload?

So you recommend to continue to try to contact the maintainer? When does
it stop?

It sounds perfectly fine to update the package with a NMU, with the due
notices to the maintainer (DELAYED/7 or more). Independantly, Jeff
should also make sure that the MIA team knows about that maintainer, so,
in the end, the MIA team will be able to orphan the package.


In general, I think that we are a bit too careful when dealing with
non-responding maintainers. The maintainer of this package has ignored
comments on that bug report for more than a year, despite making an
upload on another package recently
(http://packages.qa.debian.org/d/deja-dup/news/20100403T142238Z.html).
It is quite clear that he lost interest, but forgot to orphan the
package.

Also, the behaviour of not replying to to such requests is really very
harmful, and causes a huge loss of time to the project: replying with a
"sorry, I'm too busy, please take appropriate action to take over the
package" message takes less than 5 mins. Instead, we are discussing this
on -mentors@, have to get the MIA team involved, and delay updates. That
sucks.

  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/20100508114317.ga20...@xanadu.blop.info

Re: RFS: clustershell

2010-06-07 Thread Lucas Nussbaum 
(Please Cc me on replies, I don't follow -mentors@ very closely).

First question: why do we need yet another parallel command execution
tool? Why is it better than pdsh, dsh, dish, fabric, capistrano,
taktuk+kanif, etc? I'm not arguing that it is not better, but we have so
many of those that it would make sense to elaborate a bit.

On 06/06/10 at 23:37 +0200, Stéphan Gorget wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "clustershell".
> 
> * Package name: clustershell
>   Version : 1.2.83
>   Upstream Author : Stephane Thiell 
> * URL : https://sourceforge.net/projects/clustershell/
> * License : CeCILL-C
>   Programming Lang: Python
> 
> It builds these binary packages:
> clustershell - An event-based Python library to execute commands on
> distant cluster nodes
> 
> Description: An event-based Python library to execute commands on local
> or distant cluster nodes in parallel depending on the selected
> engine and worker mechanisms.
> .
> The library provides also advanced nodeset handling methods. Its goal
> is to improve the administration of cluster by providing a lightweight
> but scalable API for developers.
> .
> Example : clush -w node[001-256] hostname
> or clush -w node[001-256] apt-get update|clubak -c 

That's not how Description: works. first line is supposed to be a 1-line
summary. And I don't think that it's a place for providing documentation
(or examples).
-- 
| Lucas Nussbaum
| lu...@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F |


-- 
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/20100607090938.ga7...@xanadu.blop.info

Re: Bug#584769: RFS: clustershell

2010-06-07 Thread Lucas Nussbaum 
On 07/06/10 at 13:13 +0200, Stéphan Gorget wrote:
> On Mon, Jun 7, 2010 at 11:09 AM, Lucas Nussbaum 
> wrote:
> 
> > (Please Cc me on replies, I don't follow -mentors@ very closely).
> >
> > First question: why do we need yet another parallel command execution
> > tool? Why is it better than pdsh, dsh, dish, fabric, capistrano,
> > taktuk+kanif, etc? I'm not arguing that it is not better, but we have so
> > many of those that it would make sense to elaborate a bit.
> >
> > Clustershell is a tool like dsh or pdsh but it also provides a python API.
> It is used by lustre-shine[1]

So your plan is to also package lustre-shine? Have you gotten in touch
with the Lustre packaging team, then?

> and it can also be used to script actions on a cluster.
> 
> [1] lustre-shine (https://sourceforge.net/apps/trac/lustre-shine/) is a
> command
>  line tool designed to setup and manage the Lustre file system on a cluster.
> 
> > On 06/06/10 at 23:37 +0200, Stéphan Gorget wrote:
> > > Dear mentors,
> > >
> > > I am looking for a sponsor for my package "clustershell".
> > >
> > > * Package name: clustershell
> > >   Version : 1.2.83
> > >   Upstream Author : Stephane Thiell 
> > > * URL : https://sourceforge.net/projects/clustershell/
> > > * License : CeCILL-C
> > >   Programming Lang: Python
> > >
> > > It builds these binary packages:
> > > clustershell - An event-based Python library to execute commands on
> > > distant cluster nodes
> > >
> > > Description: An event-based Python library to execute commands on local
> > > or distant cluster nodes in parallel depending on the selected
> > > engine and worker mechanisms.
> > > .
> > > The library provides also advanced nodeset handling methods. Its goal
> > > is to improve the administration of cluster by providing a lightweight
> > > but scalable API for developers.
> > > .
> > > Example : clush -w node[001-256] hostname
> > > or clush -w node[001-256] apt-get update|clubak -c
> >
> > That's not how Description: works. first line is supposed to be a 1-line
> > summary. And I don't think that it's a place for providing documentation
> > (or examples).
> >
> 
> 
> A better description would maybe be :
> Description : Distributed shell that provides an efficient python interface
>  Event-based Python library to execute commands on local or distant
>  cluster nodes in parallel depending on the selected engine and
>  worker mechanisms.
>  .
>  The library provides also advanced nodeset handling methods. Its goal
>  is to improve the administration of cluster by providing a lightweight
>  but scalable API for developers.

This doesn't explain what makes the interface "efficient".

In any case, I would recommend getting in touch with either pkg-lustre
(http://pkg-lustre.alioth.debian.org/) or the PAPT team
(http://wiki.debian.org/Teams/PythonAppsPackagingTeam). I'm not
qualified myself to sponsor python stuff.

  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/20100607114253.ga10...@xanadu.blop.info

Re: Uploading during freeze time

2010-10-13 Thread Lucas Nussbaum 
On 11/10/10 at 09:14 -0700, PJ Weisberg wrote:
> 2010/10/11 Jordi Gutiérrez Hermoso :
> > Why do fixes to testing have to go through unstable, even during freeze 
> > time?
> 
> Because a lot more people use Unstable than use Testing

Citation needed.

- 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/20101013131151.ga12...@xanadu.blop.info

Re: Bug#585510: herculesstudio: changing back from ITP to RFP

2011-02-19 Thread Lucas Nussbaum 
On 20/02/11 at 01:55 +, Liang Guo wrote:
> Hi,
> 
> Add CC to p2 and debian-mentors
> 
> Actually all packaging work had already completed, I had sent RFS to
> debian-mentors too:
> 
> http://lists.debian.org/debian-s390/2010/07/msg7.html
> 
> But before herculesstudio can be used in Debian, hercules should be compiled
> with external gui support, I had reported a bug 585508 to ask the package 
> owner
> to enable external gui support, but I got no response.
> 
> I've pushed herculesstudio source to git repository:
> git://git.debian.org/git/collab-maint/herculesstudio.git
> 
> and hercules with some improvement to git repository:
> git://git.debian.org/git/collab-maint/hercules.git
> 
> If someone can sponsor this package or continue this work, I'll be very glade.

Hi,

The last activity of the hercules maintainer in Debian is from May 2010,
so I'm not sure if he is still active. What you could do is prepare an
hercules upload as a (friendly) NMU, and then seek a sponsor for it.

- 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/20110220071402.gh5...@xanadu.blop.info

Debian Packaging Tutorial

2011-05-05 Thread Lucas Nussbaum 
Hi,

I’ve been working on a Debian packaging tutorial. It is composed of
about 60 slides providing a throughout overview of Debian packaging.

It now reached the point where I consider it ready for use, and I am
looking forward to reviews and comments.
The document is split into 4 different PDFs:
* the tutorial itself:
  
http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=packaging-tutorial.pdf;hb=refs/heads/pdf
* a practical session about modifying the ‘grep’ package:
  
http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract1-grep.pdf;hb=refs/heads/pdf
* a practical session about packaging the ‘gnujump’ game from scratch:
  
http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract2-gnujump.pdf;hb=refs/heads/pdf
* a practical session about packaging a Java library:
  
http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract3-java.pdf;hb=refs/heads/pdf

And of course, it can be found on git.debian.org:
git clone git://git.debian.org/~lucas/packaging-tutorial.git

Comments very much welcomed!

- 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/20110505145738.ga22...@xanadu.blop.info

Re: Debian Packaging Tutorial

2011-05-06 Thread Lucas Nussbaum 
On 05/05/11 at 13:37 -0500, Matt Zagrabelny wrote:
> On Thu, May 5, 2011 at 9:57 AM, Lucas Nussbaum  
> wrote:
> > Hi,
> >
> > I’ve been working on a Debian packaging tutorial. It is composed of
> > about 60 slides providing a throughout overview of Debian packaging.
> >
> > It now reached the point where I consider it ready for use, and I am
> > looking forward to reviews and comments.
> > The document is split into 4 different PDFs:
> > * the tutorial itself:
> >  http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=packaging-tutorial.pdf;hb=refs/heads/pdf
> > * a practical session about modifying the ‘grep’ package:
> >  http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract1-grep.pdf;hb=refs/heads/pdf
> > * a practical session about packaging the ‘gnujump’ game from scratch:
> >  http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract2-gnujump.pdf;hb=refs/heads/pdf
> > * a practical session about packaging a Java library:
> >  http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract3-java.pdf;hb=refs/heads/pdf
> >
> > And of course, it can be found on git.debian.org:
> > git clone git://git.debian.org/~lucas/packaging-tutorial.git
> >
> > Comments very much welcomed!
> 
> Hey Lucas,
> 
> Thanks for providing this. I've noticed an inconsistency and have
> attached a patch.

Thanks! Applied.

L.


-- 
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/20110506065648.ga13...@xanadu.blop.info

Re: Debian Packaging Tutorial

2011-05-06 Thread Lucas Nussbaum 
On 05/05/11 at 17:54 +0200, Fabrizio Regalli wrote:
> Hi Lucas,
> 
> On Thu, 2011-05-05 at 16:57 +0200, Lucas Nussbaum wrote:
> > Hi,
> [...]
> >   
> > http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=packaging-tutorial.pdf;hb=refs/heads/pdf
> 
> It's an interesting and useful document.
> Just a little note: on page 37, when you talk about Vcs* perhaps it
> would be better add the link to the wiki pages[1],[2] so a user can be
> check it quickly and understand better what you're talking.
> However, it's a clear and comprehensive document.

Thanks, added.

> Thank you for your work: it's very appreciated especially for someone
> like me who are new in Debian packaging process.

You're welcomed :)

- 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/20110506070431.gb13...@xanadu.blop.info

Re: Debian Packaging Tutorial

2011-05-06 Thread Lucas Nussbaum 
On 06/05/11 at 19:15 +0800, Thomas Goirand wrote:
> On 05/05/2011 10:57 PM, Lucas Nussbaum wrote:
> > Hi,
> >
> > I’ve been working on a Debian packaging tutorial. It is composed of
> > about 60 slides providing a throughout overview of Debian packaging.
> >
> > It now reached the point where I consider it ready for use, and I am
> > looking forward to reviews and comments.
> > The document is split into 4 different PDFs:
> > * the tutorial itself:
> >   
> > http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=packaging-tutorial.pdf;hb=refs/heads/pdf
> > * a practical session about modifying the ‘grep’ package:
> >   
> > http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract1-grep.pdf;hb=refs/heads/pdf
> > * a practical session about packaging the ‘gnujump’ game from scratch:
> >   
> > http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract2-gnujump.pdf;hb=refs/heads/pdf
> > * a practical session about packaging a Java library:
> >   
> > http://git.debian.org/?p=users/lucas/packaging-tutorial.git;a=blob_plain;f=pract3-java.pdf;hb=refs/heads/pdf
> >
> > And of course, it can be found on git.debian.org:
> > git clone git://git.debian.org/~lucas/packaging-tutorial.git
> >
> > Comments very much welcomed!
> >
> > - Lucas
> >   
> This is very cool. I also wrote one, which I used for doing
> presentations that I did both in Shanghai, to the SHLUG,
> and in HoChiMin City for the MiniDebconf Vietnam last
> november. I think it would be cool to merge the 2 presentations,
> you and me might have things to share.
> 
> What's your source for making the PDF? I simply used
> OpenOffice...

Latex beamer. Is your presentation available somewhere?

L.


-- 
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/20110506122610.ga25...@xanadu.blop.info

Re: Debian Packaging Tutorial

2011-05-08 Thread Lucas Nussbaum 
On 07/05/11 at 08:33 +0800, Thomas Goirand wrote:
> On 05/06/2011 08:26 PM, Lucas Nussbaum wrote:
> > On 06/05/11 at 19:15 +0800, Thomas Goirand wrote:
> >> On 05/05/2011 10:57 PM, Lucas Nussbaum wrote:
> >>> And of course, it can be found on git.debian.org:
> >>> git clone git://git.debian.org/~lucas/packaging-tutorial.git
> >>>
> >>> Comments very much welcomed!
> >>>
> >>> - Lucas
> >>>   
> >> This is very cool. I also wrote one, which I used for doing
> >> presentations that I did both in Shanghai, to the SHLUG,
> >> and in HoChiMin City for the MiniDebconf Vietnam last
> >> november. I think it would be cool to merge the 2 presentations,
> >> you and me might have things to share.
> >>
> >> What's your source for making the PDF? I simply used
> >> OpenOffice...
> > 
> > Latex beamer. Is your presentation available somewhere?
> > 
> > L.
> 
> Here it is, attached.

Hi Thomas,

There is clearly some potential to converge between those two tutorials.
Are you interested in doing the work yourself?

- 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/20110508134642.ga24...@xanadu.blop.info

Re: Debian Packaging Tutorial

2011-05-08 Thread Lucas Nussbaum 
On 09/05/11 at 02:19 +0800, Thomas Goirand wrote:
> On 05/08/2011 09:46 PM, Lucas Nussbaum wrote:
> > On 07/05/11 at 08:33 +0800, Thomas Goirand wrote:
> >   
> >> On 05/06/2011 08:26 PM, Lucas Nussbaum wrote:
> >> 
> >>> On 06/05/11 at 19:15 +0800, Thomas Goirand wrote:
> >>>   
> >>>
> >>> Latex beamer. Is your presentation available somewhere?
> >>>
> >>> L.
> >>>   
> >> Here it is, attached.
> >> 
> > Hi Thomas,
> >
> > There is clearly some potential to converge between those two tutorials.
> > Are you interested in doing the work yourself?
> >
> > - Lucas
> >   
> I'm afraid I don't know Latex.

If you look at the source, you will see that it uses a subset of LaTeX
that is very simple.

- 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/20110508210223.ga6...@xanadu.blop.info

Re: RFS: pmatch

2011-07-03 Thread Lucas Nussbaum 
On 04/07/11 at 08:31 +0200, Kilian Krause wrote:
> Hi Tomasz,
> 
> On Sun, 2011-07-03 at 17:58 +0100, Tomasz Muras wrote:
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "pmatch".
> > 
> > * Package name: pmatch
> >   Version : 0.4.0-1
> >   Upstream Author : Tomasz Muras
> > * URL : http://pmatch.rubyforge.org/
> > * License : GPL v3
> >   Section : utils
> > 
> > It builds these binary packages:
> > pmatch - Duplicate finder and removal tool
> > 
> > The package appears to be lintian clean.
> > 
> > The upload would fix these bugs: 632450
> > 
> > I'm an upstream author of the package and DM - after review and few
> > uploads I plan to maintain the package myself. Packaging is fairly
> > simple - there is really only one ruby script that needs to be
> > packaged (plus accompanying files). My motivation for creating and
> > packaging this utility is lack of the functionality I required-  see
> > pmatch page and ITP bug for more details.
> > 
> > The package can be found on mentors.debian.net:
> > - URL: http://mentors.debian.net/debian/pool/main/p/pmatch
> > - Source repository: deb-src http://mentors.debian.net/debian unstable
> > main contrib non-free
> > - dget 
> > http://mentors.debian.net/debian/pool/main/p/pmatch/pmatch_0.4.0-1.dsc
> > 
> > I would be glad if someone uploaded this package for me.
> 
> 
> Thank you for your work. Reading the ITP with all the replies I'm
> somewhat hesitant to sponsor this without asking a possibly redundant
> question. Yet as of now I'm not convinced with your answer.
> 
> ATM I'm still not fully seeing your rationale why the superior
> functionality of pmatch cannot be added to some project (like fdupes
> which I've used in the past) for other reasons than it not being ruby.
> Have you tried to talk to them and they don't like patches or what's the
> backstory?

Also, there's already a pmatch project, that seems more popular:
http://www.phpinsider.com/php/code/pmatch/

Since you are the upstream, it might be worth considering changing the
name.

- 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/20110704065422.ga32...@xanadu.blop.info

Re: News about the mentors.debian.net transition to upgraded software

2011-08-14 Thread Lucas Nussbaum 
On 14/08/11 at 17:07 +0400, Stanislav Maslovski wrote:
> Well, then it is a shame that the system has not been given even a
> slight test since all these years...

On 14/08/11 at 17:18 +0400, Stanislav Maslovski wrote:
> You shold have asked for external testing and help *BEFORE* switching
> mentors.debian.net to the new system.

On 14/08/11 at 21:18 +0400, Stanislav Maslovski wrote:
> That "you" above supposed to mean "people who care about debexpo and
> take active part in its deployment."
> 
> [...]
> 
> Well, then it means that there was not enough publicity in this
> process. I hardly remember hearing anything about debexpo before I
> found yesterday that the system on mentors.debian.net was replaced by
> a new one.
> 
> Another reason why people cared so little about it was, probably,
> because the old system worked all right. At least, I do not recall
> having any problems with it myself.

Come on, Stanislav. Don't behave so badly. Such comments are very
demotivating for people who put their free time into debexpo. Of course
it's not perfect and still needs work, but:
1) debexpo was available (on expo.d.n) since the end of July, and
apparently you didn't care about testing it back then.
2) debexpo is a very promising piece of software, that could play a key
role in solving one of Debian's biggest problems.

Being able to report bugs (even annoying ones) while still being polite
and helpful is a very important skill in a free software community.
Apparently you don't have that ability yet. Now, let's hope that all
(potential or present) contributors did not run away after reading your
messages. Because *you* would be the one to be blamed, then.

L.


-- 
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/20110814201543.ga4...@xanadu.blop.info

Re: ITP: i-news (2nd request) -- GTK-based highly graphically-configurable RSS Ticker - Bug#638999

2011-08-25 Thread Lucas Nussbaum 
On 25/08/11 at 21:32 +0200, Emmanuel Thomas-Maurin wrote:
> Dear mentors,
> 
> Sorry if this is a silly question. I previously mentionned the name
> choice was not definitive but must I pick *first* a fully suitable one
> in order to get a chance of getting sponsorded?

Packages renames are possible but a bit painful, so yes, it's better to
make sure you won't change the name before getting sponsored.

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/20110825195827.ga16...@xanadu.blop.info

Re: ITP: i-news (2nd request) -- GTK-based highly graphically-configurable RSS Ticker - Bug#638999

2011-08-25 Thread Lucas Nussbaum 
On 26/08/11 at 00:05 +0200, Emmanuel Thomas-Maurin wrote:
> On 08/25/2011 09:58 PM, Lucas Nussbaum wrote:
> > On 25/08/11 at 21:32 +0200, Emmanuel Thomas-Maurin wrote:
> >> Dear mentors,
> >>
> >> Sorry if this is a silly question. I previously mentionned the name
> >> choice was not definitive but must I pick *first* a fully suitable one
> >> in order to get a chance of getting sponsorded?
> > 
> > Packages renames are possible but a bit painful, so yes, it's better to
> > make sure you won't change the name before getting sponsored.
> > 
> > Lucas
> 
> Thanks. As I have to decide now, please let me know if I must change the
> package name or not? Sorry, I know this is redundant but I need a final
> answer.

The package name should somehow match the upstream name.
The upstream name is your decision as the upstream developer. Debian
doesn't have anything to do with choosing upstream names, except when
it's a really bad choice when it's too generic or conflicts with the
name of another package.

L.


-- 
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/20110826045602.ga27...@xanadu.blop.info

Plans for rails & wheezy (Was: RFS: ruby-activemodel)

2011-08-27 Thread Lucas Nussbaum 
On 27/08/11 at 09:49 +0530, karim memon wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "ruby-activemodel".
> 
>  * Package name: ruby-activemodel
>Version : 3.0.10-1
>Upstream Author : David Heinemeier Hansson
>  * URL : http://rubygems.org/gems/activemodel
>  * License : MIT
>Section : ruby
> 
> It builds those binary packages:
> 
> ruby-activemodel - toolkit for building modeling frameworks (part of Rails).
> 
> To access further information about this package, please visit the following
> URL:
> 
>   http://mentors.debian.net/package/ruby-activemodel
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> http://mentors.debian.net/debian/pool/main/r/ruby-activemodel/ruby-activemodel_3.0.10-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Hi,

I haven't looked at the package, but I know that Ondřej Surý has been
doing some work on rails-related packages, so maybe he would like to
have a look (Added to Cc).

Also, I was wondering what should be our plans for Rails in wheezy (2.3
vs 3.0). What do people think? (I'm clueless about rails)

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/20110827073153.ga27...@xanadu.blop.info

Re: [DRE-maint] RFS: ruby-omniauth

2011-08-27 Thread Lucas Nussbaum 
On 27/08/11 at 03:08 +0530, Muneeb Shaikh wrote:
> Dear mentors,
> 
> I am looking for a sponsor for my package "ruby-omniauth".
> 
>  * Package name: ruby-omniauth
>Version : 0.2.6-1
>Upstream Author : Michael Bleigh ,
>  Erik Michaels-Ober 
> 
>  * URL : http://github.com/intridea/omniauth
>  * License : MIT
>Section : ruby
> 
> It builds those binary packages:
> 
> ruby-omniauth - Rack middleware for standardized multi-provider
> authentication
> 
> To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/ruby-omniauth
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x
> http://mentors.debian.net/debian/pool/main/r/ruby-omniauth/ruby-omniauth_0.2.6-1.dsc
> 
> I would be glad if someone uploaded this package for me.

Hi,

The gem has dependencies on oa-basic (= 0.2.6), oa-enterprise (=
0.2.6), oa-core (= 0.2.6), oa-more (= 0.2.6), oa-oauth (= 0.2.6),
oa-openid (= 0.2.6). Are you sure that the package can work standalone
like that?
If it's the case, please remove the commented line in debian/control

In debian/copyright, you need to state the license for Files:* and Files:
debian/*.

Why do you patch the gemspec for the description? if the description is
not suitable for the debian package, you should change it in
debian/control directly.

FIXME in ruby-omniauth.docs

Ah, now I see that the package builds several gems. I don't think that
it's a layout that we support at the moment, so it might require changes
in gem2deb itself. Antonio, what do you think?

- 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/20110827074310.gd27...@xanadu.blop.info

Re: Plans for rails & wheezy (Was: RFS: ruby-activemodel)

2011-08-28 Thread Lucas Nussbaum 
On 28/08/11 at 10:27 +0530, karim memon wrote:
> >
> > So please don't upload. Ruby is API mess even without multiple rails
> > versions.
> >
> > > Hi,
> > >
> > > I haven't looked at the package, but I know that Ondřej Surý has been
> > > doing some work on rails-related packages, so maybe he would like to
> > > have a look (Added to Cc).
> > >
> > > Also, I was wondering what should be our plans for Rails in wheezy (2.3
> > > vs 3.0). What do people think? (I'm clueless about rails)
> > >
> > > Lucas
> >
> 
> So do i need to stop working on this package? and what about the ITP, what
> should it be retitled to?

It only means that it's not that simple. Please talk to Ondrej to see
what needs to be done, and how you can help.

Actually, this goes for all dispora-related uploads. They really require
some coordination. Please try to give us a global view of what's
required to get it done.

And note that according to
http://lists.debian.org/debian-ruby/2011/07/msg00025.html, the priority
is still to get the transition done, i.e get all current packages
transitioned, not add new ones. This still applies for me:
 
  From now on, I will only sponsor new packages (not already in Debian)
  if the requester has done some of the "collective" tasks listed on
  that page. I don't think that it's a too hard policy: handling new
  upstream releases is generally quite easy, for example.

Also note that transitioning packages and doing other "collective
shores" is a great way to learn. You can find TODO lists on
http://pet.43-1.org/pkg-ruby-extras/pet.cgi
and http://pkg-ruby-extras.alioth.debian.org/wheezy/details.html

- 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/20110828141733.ga8...@xanadu.blop.info

Re: Tracking RFSs as bugs

2011-09-07 Thread Lucas Nussbaum 
On 05/09/11 at 15:12 -0400, Michael Gilbert wrote:
> Hi,
> 
> I've been thinking about how mentors works lately (after watching
> Asheesh's debconf11 talk).  It seems like the 4 day response effort
> worked somewhat well for a while, but kind of tailed off, and I've been
> pondering what could be done instead that would have some staying power.
> 
> I've noticed that the release team has a lot of success addressing their
> issues in a rather timely manner.  I think that this success comes from
> the fact that they treat all of the items they need to accomplish as
> bugs [0].  So, as requests get old, they notice that and do something
> about it (or they just close it out if the submitter isn't responsive). 
> 
> Anyway, I think mentors could greatly benefit from a similar work flow.
> So, I was wondering if there were any thoughts on setting up a
> mentors.debian.net pseudo-package [1]?  It seems like all of the
> existing ones are debian.org features, so I'm not sure if that would
> require mentors becoming an "official" .org service first or not?
> 
> Anyway, I think this could be a really significant improvement to the
> mentors culture.

The BTS provides a good way to track requests. But mentors.d.n does,
too. On the other hand, the BTS doesn't have a useful interface to
search, filter and sort RFSes based on various criterias, such as:
- is the package already in Debian? (sponsoring a second upload is
  easier)
- did I sponsor the previous upload?
- is the package related to Ruby (easy to determine by grepping
  build-depends and depends)
- ...

all of this can easily be implemented on mentors.debian.net, but cannot
be added to a BTS pseudo-package. So I don't see the point of using a
BTS pseudo-package instead of mentors.d.n. (I also don't see the point of
using mentors.d.n together with a BTS pseudo-package.)

Additionally, it's very important to note that not all packages should
eventually be uploaded, so the fact that some packages never get
sponsored is a feature. Debian doesn't want to contain every piece of
free software ever written, because some of them have better
alternatives already in Debian, for example. How would you deal with
that with a BTS pseudo-package? After some time, there will be a few
hundred RFSes that should never ever be uploaded to Debian, but are
still open. Who gets to decide that they can be closed?

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/20110907173901.ga23...@xanadu.blop.info

Re: RFS: logservice -- new upstream release

2011-12-19 Thread Lucas Nussbaum 
On 01/12/11 at 14:41 +0100, Haïkel Guémar wrote:
> Dear mentors,
> 
> I am looking for a sponsor for the following package:
> 
> name: logservice
> version: 2.8.0
> upstream: DIET developers
> upstream url: http://graal.ens-lyon.fr/DIET/logservice.html
> license: CeCILL-A (GPLv2 like)
> short description: Logging service for distributed applications
> section: science
> debian science git: 
> http://anonscm.debian.org/gitweb/?p=debian-science/packages/logservice.git
> 
> 
> packages built:
> * logcentral (logging daemon)
> * logcentral-tools (various command-line tools)
> * liblogservicecomponentbase2 (base library for loggers)
> * liblogservicetoolbase2 (base library for clients)
> * liblogforwarderutils2 (base library for both libraries listed above)
> 
> I would be glad if someone could review then upload this package.

Hi Haikel,

There seems to be something fucked up between the package currently in
the archive, versioned 2.7-1, and what's in git, where there's no such
version (it's versioned 2.7.0-1 in git).

So, I'm lost, and can't review. I don't know where the version in the
archive comes from.

Thanks
-- 
| Lucas Nussbaum  Assistant professor @ Univ. Nancy 2 |
| lucas.nussb...@loria.fr   LORIA / AlGorille |
| http://www.loria.fr/~lnussbau/+33 3 54 95 86 19 |


-- 
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/20111219142620.ga16...@xanadu.blop.info

Re: RFS: logservice -- new upstream release

2011-12-19 Thread Lucas Nussbaum 
On 19/12/11 at 16:02 +0100, Haïkel Guémar wrote:
> Le 19/12/2011 15:26, Lucas Nussbaum a écrit :
> >
> >Hi Haikel,
> >
> >There seems to be something fucked up between the package currently in
> >the archive, versioned 2.7-1, and what's in git, where there's no such
> >version (it's versioned 2.7.0-1 in git).
> >
> >So, I'm lost, and can't review. I don't know where the version in the
> >archive comes from.
> >
> >Thanks
> 
> Sorry,
> 
> looks like a naughty boy (that should me) forgot to push tags to alioth.

Hi,

I'm sorry, but I still don't get it.

The version tagged debian/2.7.0-1 in git doesn't match the version in
the archive (2.7-1), so there's obviously something very wrong.

L.


-- 
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/20111219193739.ga27...@xanadu.blop.info

Re: RFS: diet -- new upstream release

2012-01-11 Thread Lucas Nussbaum 
On 11/01/12 at 16:48 +0100, Sylvestre Ledru wrote:
> Le jeudi 01 décembre 2011 à 16:34 +0100, Haïkel Guémar a écrit :
> > Dear mentors,
> > 
> > I am looking for a sponsor for  the following package:
> I will sponsor it.

Hi,

This is also on my radar, but feel free to sponsor it. (I'm quite busy
currently)

However, there is a big problem with the git repo of this package (or at
least there was when I looked at it in december):
the version tagged debian/2.7.0-1 in git doesn't match the version in
Debian, that is versioned 2.7-1 (neither the version nor the content
match).

I think that the state of the git repo should be cleaned up before
someone makes an upload.

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/2012081806.ga8...@xanadu.blop.info

Bug#718610: RFS: ruby-sys-admin/1.6.0-1

2013-08-07 Thread Lucas Nussbaum 
On 02/08/13 at 23:23 -0400, Sam Kottler wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
>   Dear mentors,
> 
>   I am looking for a sponsor for my package "ruby-sys-admin"

Hi,

Have you tried getting in touch with the Ruby team, instead?
https://wiki.debian.org/Teams/Ruby ; debian-r...@lists.debian.org

Someone might be more able to review and sponsor your package there.

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/20130807191326.ga2...@xanadu.blop.info

Re: Upgrading the Debian Policy

2013-09-24 Thread Lucas Nussbaum 
On 24/09/13 at 16:15 +0200, Thibaut Paumard wrote:
> Le 24/09/2013 15:58, Paul Wise a écrit :
> > On Tue, Sep 24, 2013 at 2:48 PM, Dominik George wrote:
> > 
> >> Sorry to disapoint you, but you should read *all of* DPM before passing
> >> a package for upload to a sponsor or to mentors.
> > 
> > I don't think we have never expected that new maintainers read policy
> > before creating a package.
> 
> Hi,
> 
> I disagree with that: I expect prospective package maintainers to read
> and follow the "Debian New Maintainers' Guide", which states:
> 
>  "The following is the very important documentation which you should
> read along with this document:
> - debian-policy [...]
> - developers-reference - [...]"

On the other hand, developers-reference mainly documents procedures that
are only applicable to DD (or marginaly, to DM). I don't think that it's
such a useful read for prospective maintainers.

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/20130924162132.ga24...@xanadu.blop.info

Re: Bug#860690: crac: FTBFS on i386: build-dependency not installable: libjellyfish-2.0-dev

2017-04-19 Thread Lucas Nussbaum 
On 19/04/17 at 11:28 +0200, Andreas Tille wrote:
> Hi Lucas,
> 
> could you please be more verbose why this is a RC bug?  Crac was never
> Build on i386 (neither was it on any other arch than amd64) exactly
> because this not installable Build-Dependency.  As far as I know there
> is no point in restricting the Build-Architectures explicitly since once
> the Build-Dependency would become available on some architecture several
> package might needed edits (may be several times for different
> architectures).
> 
> Am I missing something?

No, and I probably agree; see
https://lists.debian.org/debian-release/2017/04/msg00751.html

Lucas

Re: Bug#860652: snap-aligner: FTBFS on i386: SNAPLib/SortedDataWriter.cpp:338:70: error: no matching function for call to 'max(long unsigned int, _int

2017-04-19 Thread Lucas Nussbaum 
Hi,

On 19/04/17 at 09:19 +, Gianfranco Costamagna wrote:
> Hello Lucas
> 
> 
> Can you please fix your script? :)
> rmadison -u debian snap-aligner
> snap-aligner | 1.0~beta.18+dfsg-1 | testing| source, amd64, arm64, 
> mips64el, ppc64el
> snap-aligner | 1.0~beta.18+dfsg-1 | unstable   | source, amd64, arm64, 
> mips64el, ppc64el
> snap-aligner | 1.0~beta.18+dfsg-1 | unstable-debug | source
> 
> 
> for sure a package that was never built on i386 should not be RC buggy for 
> that,
> unless I'm missing something obvious here!

I quite agree:
https://lists.debian.org/debian-release/2017/04/msg00751.html

Lucas

Re: Facilitating contributions by newcomers

2014-11-11 Thread Lucas Nussbaum 
On 09/11/14 at 20:20 +0100, Christian Kastner wrote:
> The WNPP list in itself is useful, but when looking at it again
> recently, I distinctly recalled how foreign most of the packages were to
> me when I first started contributing -- not a great motivator into
> getting involved with something. And I recognized a number of RFHs that
> have received numerous replies over the time, but couldn't be followed
> up upon with because RFHs are frequently the result of a lack of time in
> the first place (openldap anyone?).

Do you have how-can-i-help installed?
The WNPP list might not be the best approach to finding interesting
packages to adopt. But looking at the intersection with packages you
have installed locally (using how-can-i-help --old) makes it a lot more
interesting.

Lucas


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014192825.ga24...@xanadu.blop.info

Re: Facilitating contributions by newcomers

2014-11-11 Thread Lucas Nussbaum 
Hi Don,

On 09/11/14 at 13:44 -0800, Don Armstrong wrote:
> On Sun, 09 Nov 2014, Christian Kastner wrote:
> > With the recent gamification of just-about-everything, I was wondering
> > whether following such an achievement-oriented approach, with
> > opportunities for contribution formulated as a list of specific tasks,
> > instead of general avenues, would be helpful in overcoming this
> > initial difficulty. (This would be in addition to mentors.debian.net
> > and other established avenues for entry to Debian, not a replacement).
> 
> This is an avenue that I'm interested in exploring for the BTS as well,
> so if people have good ideas, or want to be involved with this, please
> contact me in #debbugs on irc.debian.org, or email
> ow...@bugs.debian.org.

Have you considered adding the 'gift' tag[0] to some BTS bugs?
how-can-i-help now uses this tag to list bugs affecting Debian
infrastructure in a separate category. Stefano Zacchiroli did that
for some debsources bugs, and this apparently had noticeable effects in
terms of contributions.

The current how-can-i-help output for this category is:
Bugs affecting Debian infrastructure (tagged 'gift'):
 - installation-reports - https://bugs.debian.org/764277 - Graphical DE task 
don't install any DE
 - qa.debian.org - https://bugs.debian.org/761119 - debsources: suite-based 
navigation
 - qa.debian.org - https://bugs.debian.org/761149 - debsources: allow redirects 
to package versions based on suite/codename
 - qa.debian.org - https://bugs.debian.org/761227 - debsources: add totals to 
all /stats tables
 - qa.debian.org - https://bugs.debian.org/761228 - debsources: make pie charts 
more readable
 - qa.debian.org - https://bugs.debian.org/761229 - debsources: make trend 
charts more readable
 - qa.debian.org - https://bugs.debian.org/761232 - debsources: release pages 
should mention release number and date
 - qa.debian.org - https://bugs.debian.org/762951 - debsources: 
increase/maximize test coverage
 - qa.debian.org - https://bugs.debian.org/763921 - debsources: detailed 
directory listing with file types and permissions
 - www.debian.org - https://bugs.debian.org/766923 - www.debian.org: Who's 
using Debian page - 2014 update

(yeah, there's a bug here -- hcih considers all pseudopackages as 'debian
infrastructure' which doesn't work for installation-reports)

[0] https://wiki.debian.org/qa.debian.org/GiftTag


Lucas


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014193234.gb24...@xanadu.blop.info

Re: Facilitating contributions by newcomers

2014-11-11 Thread Lucas Nussbaum 
On 11/11/14 at 14:13 -0800, Don Armstrong wrote:
> On Tue, 11 Nov 2014, Lucas Nussbaum wrote:
> > Have you considered adding the 'gift' tag[0] to some BTS bugs?
> 
> I probably should do that; I actually wasn't that familiar with the gift
> tag before this e-mail.
> 
> > how-can-i-help now uses this tag to list bugs affecting Debian
> > infrastructure in a separate category. Stefano Zacchiroli did that for
> > some debsources bugs, and this apparently had noticeable effects in
> > terms of contributions.
> 
> [...]
> 
> > [0] https://wiki.debian.org/qa.debian.org/GiftTag
> 
> Does anyone have any thoughts about elevating the gift tag to a
> fully-fledged BTS tag?

I am totally in favor of turning it into a real tag.

There has been discussions about renaming the tag (see thread starting
at https://lists.debian.org/debian-project/2013/09/msg00096.html ; my
personal preference is entry-point
(https://lists.debian.org/debian-project/2013/09/msg00108.html) for the
geeky factor). We should rename it at the same time.

Lucas


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2014222325.ga3...@xanadu.blop.info

Re: Bug#976906: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)

2020-12-11 Thread Lucas Nussbaum 
On 10/12/20 at 18:20 +0100, Andreas Tille wrote:
> Hi Mathieu,
> 
> On Thu, Dec 10, 2020 at 11:10:17AM +0100, Mathieu Malaterre wrote:
> > "make -j160"
> > 
> > that would be my guess :)
> 
> This sounds pretty likely, thought.  Thanks for the hint.

Hi,

I tried building with SMT off (so the machine only has 20 visible
cores), and the build succeeded. So yes, it's likely caused by
parallelism.

Lucas

Re: Bug#976906: Possible lex issue for ppc64el (Was: Bug#976906: libpll: FTBFS on ppc64el: lex_utree.l:22:10: fatal error: parse_utree.h: No such file or directory)

2020-12-11 Thread Lucas Nussbaum 
Here is a patch based on this :
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html

Tested on a power machine (where the build failed) and it seems to work.

F.
Description: Fix parallel build
This happened here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976906
Solution found here : 
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
Author: Frédéric Bonnard 
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -8,6 +8,8 @@
 AM_YFLAGS = -d -p `${SED} -n 's/.*_\(.*\)/pll_\1_/p' <<<"$*"`
 AM_LFLAGS = -P `${SED} -n 's/.*_\(.*\)/pll_\1_/p' <<<"$*"` -o lex.yy.c
 
+BUILT_SOURCES = parse_rtree.h parse_utree.h
+
 libpll_la_SOURCES=\
 fasta.c \
 gamma.c \

Bug#799268: RFS: ck/1.6.2 [ITP]

2015-09-17 Thread Lucas Nussbaum 
On 17/09/15 at 12:43 +0200, Grigori Fursin wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ck"
> 
> * Package name: ck
>   Version : 1.6.2
>   Upstream Author : Grigori Fursin 
> * URL : http://github.com/ctuning/ck
> * License : BSD-3-clause
>   Section : python

Hi,

Quick (and probably incomplete) review:

Must be fixed:
- Given that this software is not specific to Debian, and publishes
releases on its homepage, this should not be a native package. instead,
its version should be of the form 1.6.2-1, 1.6.2-2, so that the Debian
revision (the part after the '-') can be changed when packaging changes
are made, without making a new upstream release.

- I'm not familiar with python packaging, but when building this
package, I only get a python2 package (and no python3 package). There's
something wrong here. I wonder if it's related to the fact that the
version of python-stdeb that you seem to be using (according to the
headers in say debian/rules) is very old. Given that Debian packages are
uploaded targetting Debian 'unstable', it's better to do Debian
development in unstable or testing (possibly in a chroot).

Should probably be fixed:
- If I understand ck correctly, it's more an application than a library:
users are not really exposed to the fact that it's written in python,
and the python lib is not supposed to be used by third parties (it can
be used in ipython, but the target is not really to build a third party
application on top of it).
If that's correct, then it should not be packaged like a python library,
but more like an application (that happens to be written in python).
- there's another problem: namespace pollution in few-characters
commands. It's usually a bad practice to name something (that is not a
historical unix tool) with 1 or 2 letters only.

Could be fixed:
- The description is a bit too long by Debian standards.

Lucas

Bug#799268: RFS: ck/1.6.2 [ITP]

2015-09-18 Thread Lucas Nussbaum 
On 18/09/15 at 12:25 +0200, Grigori Fursin wrote:
> Hi Lucas,
> 
> Thank you very much for your time to check it - really appreciated!
> And sorry for some mix ups - it's my first time trying to package
> something for Debian ;) ...
> 
> >Must be fixed:
> -> Given that this software is not specific to Debian, and publishes
> >releases on its homepage, this should not be a native package. instead,
> >its version should be of the form 1.6.2-1, 1.6.2-2, so that the Debian
> >revision (the part after the '-') can be changed when packaging changes
> >are made, without making a new upstream release.
> 
> Oh, I see. I will check how to fix that ...
> 
> >- I'm not familiar with python packaging, but when building this
> >package, I only get a python2 package (and no python3 package). There's
> >something wrong here. I wonder if it's related to the fact that the
> >version of python-stdeb that you seem to be using (according to the
> >headers in say debian/rules) is very old. Given that Debian packages are
> >uploaded targetting Debian 'unstable', it's better to do Debian
> >development in unstable or testing (possibly in a chroot).
> 
> I created a separate package for python3-ck but it's true that it
> doesn't look like it was uploaded - need to check that ...
> 
> >Should probably be fixed:
> >- If I understand ck correctly, it's more an application than a library:
> >users are not really exposed to the fact that it's written in python,
> >and the python lib is not supposed to be used by third parties (it can
> >be used in ipython, but the target is not really to build a third party
> >application on top of it).
> >If that's correct, then it should not be packaged like a python library,
> >but more like an application (that happens to be written in python).
> 
> In fact, it is both. It can be used as a standalone python library or it can
> be used as an application (via ck batch script).

Then you might want to package the application separately, so that the
library packages are really libraries.

> >- there's another problem: namespace pollution in few-characters
> >commands. It's usually a bad practice to name something (that is not a
> >historical unix tool) with 1 or 2 letters only.
> 
> Oh, I didn't know that :( . Will it really be a problem (I didn't see any
> tool called ck yet)? The problem is that our users now share some artifacts
> in this format and they use this name (in scripts or internal calls),
> so changing this name now will be a nightmare :( ...

I'm not sure if there's an official policy about that. It's probably
worth trying to upload with a ck binary, and see if someone complains :)

Lucas

Bug#799268: RFS: ck/1.6.2 [ITP]

2015-11-10 Thread Lucas Nussbaum 
On 07/11/15 at 16:21 +0100, Grigori Fursin wrote:
> Hi Gianfranco,
> 
> After hacking various guides I managed to update python-ck
> based on what you mentioned:
> 
> >https://mentors.debian.net/package/python3-ck
> >this is a nack for me.
> >
> >You can build two binaries with the same source package, look e.g. to
> >https://sources.debian.net/src/python-esmre/0.3.1-3/
> 
> I have done that and deleted separate python3-ck package.
> 
> >this includes:
> >compat level --> 9
> >debhelper >= 9
> 
> Done.
> 
> >ITP bug?
> I changed it as ITP bug. It still complains and I guess
> this can only be fixed when I find a sponsor ...

you need both an ITP bug (because it's a new package) and an RFS bug
(because you are looking for a sponsor)
 
Lucas