Re: PC file not exist on libiniparser-dev

[Jérémy Lal]

Le dim. 31 mars 2024 à 00:55, kwang son  a écrit :

> Hi,
>
> I'm a new user to Debian.
> I hope this is the right place to ask questions.
>
> libiniparser-dev does not have pc file.
> which is exist on upstream repo [1]
>
> I want to know
> 1. -dev not needs pc file?


Not mandatory.
*-dev usually distributes headers. Optionally .pc file.


> 2. why upstream has, but debian packaging not?
>

Maintainer of the package probably overlooked installing it - or had a
reason not to install it.

You can open a wishlist bug asking gently to install that pkgconfig pc
file, using
reportbug libiniparser-dev

In the meantime, use -liniparser and -I/usr/include/iniparser.h (or similar
with correct names).

Jérémy

Re: Question on why package was rebuilt

[Jérémy Lal]

Le ven. 16 févr. 2024 à 04:03, Mathias Gibbens  a écrit :

> On Thu, 2024-02-15 at 16:20 -0800, Loren M. Lang wrote:
> > Hello,
> >
> > I recently had a package sponsors and entered into unstable called tiv.
> > It can be seen here:
> >
> > https://packages.debian.org/sid/tiv
> >
> > Everything went OK, but I see that the amd64 arch package appears to
> > have been re-built for some reason. It's version is showing up with a
> > +b1. I am curious if there is some long to indicate what the issue might
> > have been that led to a rebuild. Could there have been a compilation
> > issue or other things I should be concerned about or is it likely
> > something harmless? Is there a log for this case?
>
>   There's no cause for concern -- it's a normal part of a new package
> entering the archive.
>

Indeed...

  When a package is uploaded to NEW, you have to upload both the source
> and binary package(s) for review. After the package is accepted, the
> buildds auto-build for any other architectures that don't already have
> a binary package. Migration policy requires all packages to be built on
> official buildds from their source package[1]. Since the amd64 binary
> package already existed from the upload to NEW, it wouldn't be auto-
> built and would block migration of your package to testing.
>

This isn't what happened, I suppose, since we all debian maintainers need
to do source-only uploads after a package has been accepted through the NEW
process.
Unless I'm mistaken, that source-only upload cannot be replaced by a
binNMU, can it ?
What happened is more likely to be a standard rebuild against a new version
of a dependent library.

  The "+b1" indicates a binBMU was performed[2,3]. If you look at the
> buildd logs (https://buildd.debian.org/status/package.php?p=tiv),
> you'll see the relevant changelog entry for the amd64 package: "Rebuild
> on buildd".
>

A binNMU, but right.


>
> Mathias
>
> [1] --
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-and-binary-uploads
> [2] --
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#source-nmus-vs-binary-only-nmus-binnmus
> [3] --
> https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#recompilation-or-binary-only-nmu
>

nginx: how plugins should b-d nginx-dev to be auto-transitioned ?

[Jérémy Lal]

Hi,

Jan and I are trying to make libnginx-* plugins be rebuilt automatically by
transition tracker on each nginx upgrade.
Alas, I don't understand how to declare this - here, nginx-dev is an
arch:all package.
Will transition tracker pick it up if we have
libnginx-xxx B-D nginx-dev
nginx-dev D nginx-abi-
and
nginx provides nginx-abi-xxx ?

thanks for any cue,
Jérémy

Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration

[Jérémy Lal]

Le dim. 30 oct. 2022 à 22:42, Jérémy Lal  a écrit :

>
>
> Le jeu. 20 oct. 2022 à 13:28, Jérémy Lal  a écrit :
>
>>
>>
>> Le jeu. 20 oct. 2022 à 13:09, Alper Nebi Yasak 
>> a écrit :
>>
>>> Package: sponsorship-requests
>>> Severity: wishlist
>>> X-Debbugs-Cc: Jérémy Lal 
>>> X-Debbugs-Cc: Hans-Cristoph Steiner 
>>> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>>>
>>> Dear mentors,
>>>
>>> I am looking for a sponsor for my package "depthcharge-tools":
>>
>>
>> I'll be glad to review/upload it next week (my DD gnupg key is being
>> renewed).
>> If anyone can do it before, that'll be okay too.
>>
>>
> Everything seems to be fine with your package.
> It builds fine, is lintian-clean, copyright is ok, and best practices are
> observed.
>
> Since it's a python program, it would make more sense to team-maintain it
> in the python-team group.
> I cloned your repo to
> https://salsa.debian.org/python-team/packages/depthcharge-tools
>
> Now you need to request write access (developer role) to that repository.
> Please have a look at https://wiki.debian.org/Teams/PythonTeam/HowToJoin
>
> After that, debian/control should be modified to be:
> Maintainer: Alper Nebi Yasak 
>  , Debian Python Team 
> Vcs-Browser:
> https://salsa.debian.org/python-team/packages/depthcharge-tools
> Vcs-Git:
> https://salsa.debian.org/python-team/packages/depthcharge-tools.git
>

Also since python-team admins are busy, I've took the liberty to make the
changes,
slightly differently (see
https://salsa.debian.org/python-team/packages/depthcharge-tools),
and I uploaded your package to NEW.

Jérémy

>

Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration

[Jérémy Lal]

Le jeu. 20 oct. 2022 à 13:28, Jérémy Lal  a écrit :

>
>
> Le jeu. 20 oct. 2022 à 13:09, Alper Nebi Yasak 
> a écrit :
>
>> Package: sponsorship-requests
>> Severity: wishlist
>> X-Debbugs-Cc: Jérémy Lal 
>> X-Debbugs-Cc: Hans-Cristoph Steiner 
>> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>>
>> Dear mentors,
>>
>> I am looking for a sponsor for my package "depthcharge-tools":
>
>
> I'll be glad to review/upload it next week (my DD gnupg key is being
> renewed).
> If anyone can do it before, that'll be okay too.
>
>
Everything seems to be fine with your package.
It builds fine, is lintian-clean, copyright is ok, and best practices are
observed.

Since it's a python program, it would make more sense to team-maintain it
in the python-team group.
I cloned your repo to
https://salsa.debian.org/python-team/packages/depthcharge-tools

Now you need to request write access (developer role) to that repository.
Please have a look at https://wiki.debian.org/Teams/PythonTeam/HowToJoin

After that, debian/control should be modified to be:
Maintainer: Alper Nebi Yasak 
 , Debian Python Team 
Vcs-Browser: https://salsa.debian.org/python-team/packages/depthcharge-tools
Vcs-Git: https://salsa.debian.org/python-team/packages/depthcharge-tools.git

Cheers,
Jérémy

Bug#1022117: RFS: depthcharge-tools/0.6.0-1 [ITP] -- Tools for ChromeOS firmware/bootloader integration

[Jérémy Lal]

Le jeu. 20 oct. 2022 à 13:09, Alper Nebi Yasak  a
écrit :

> Package: sponsorship-requests
> Severity: wishlist
> X-Debbugs-Cc: Jérémy Lal 
> X-Debbugs-Cc: Hans-Cristoph Steiner 
> X-Debbugs-Cc: debian-pyt...@lists.debian.org
>
> Dear mentors,
>
> I am looking for a sponsor for my package "depthcharge-tools":


I'll be glad to review/upload it next week (my DD gnupg key is being
renewed).
If anyone can do it before, that'll be okay too.

Jérémy

Bug#1018255: RFS: polymc/1.4.1+ds-1 [ITP] -- FOSS Minecraft launcher supporting multiple instances and accounts

[Jérémy Lal]

Le mar. 18 oct. 2022 à 21:57, Ben Westover  a écrit :

> Hello,
>
> On Tue, 18 Oct 2022 11:03:09 +0200 Tobias Frost  wrote:
> > There is currently some drama envoling with upstream, possibly this
> RFS/ITP should be put on hold
> > until it is resolved (or maybe switched to one the forks that are
> currently materializing [fork])
> >
> > It seems that Lenny McLennigton, the main person behind upstream went
> rouge in a way that is difficult
> > to be aligned with Debian values (and CoC), as shown by their response
> on [twitter].
>

Where in Debian is it stated that an open source project has to have a Code
of Conduct to be part of Debian ?
I don't understand why the drama happening between upstream
project maintainers should concern Debian directly.

Jérémy

Re: Re: Re: Self dependent package, build profiles

[Jérémy Lal]

Hello,

not sure hundred per cent but nodejs package has that kind of issue and
uses build-profiles to work around it.


Le ven. 16 sept. 2022 à 22:45, Fab Stz  a écrit :

> > And does it always need the same version? (so every upload must be dome
> > twice)?
>
> It should indeed be the same version. There is an additional option we can
> set
> at config time to make it work without but then there are warnings saying
> that
> there is no guarantee it will work, and it is not supported by upstream.
>
>
>
>

Re: Preventing a broken release arch from blocking testing migration

[Jérémy Lal]

Le ven. 17 juin 2022 à 14:31, Daniel Gröber  a écrit :

> Hi Mentors,
>
> my package yosys has a test failure on mips64el that I can't figure out and
> consequently got removed from testing. I'm wondering how to deal with this?
>
> From reading the policy it seems I can use the Architecture field to list
> all arches except mips64el. Is that the right thing to do here?
>
> I also wonder if there is a way to specify "everything except mips64el"
> instead of listing all arches explicitly?
>

https://wiki.debian.org/ftpmaster_Removals#Removals_from_testing.2C_stable_and_oldstable

Jérémy

Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime

[Jérémy Lal]

(please don't top-post)
(cc-ing to relevant bugs and teams)


Le sam. 10 avr. 2021 à 22:26, Sergey Abroskin  a écrit :

> On Sat, Apr 10, 2021, 23:18 Jérémy Lal  wrote:
>
>>
>>
>> Le sam. 10 avr. 2021 à 21:42, Geert Stappers  a
>> écrit :
>>
>>> On Sat, Apr 10, 2021 at 09:17:12PM +0300, Sergey Abroskin wrote:
>>> > Dear mentors,
>>> >
>>> > I am looking for a sponsor for my package "deno":
>>> >
>>> >  * Package name: deno
>>> >Version : 1.8.3-1
>>> >Upstream Author : The Deno Authors
>>> >  * URL : https://deno.land
>>> >
>>> >
>>> >   https://mentors.debian.net/package/deno/
>>> >
>>> >   dget -x
>>> https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc
>>> >
>>> >* Initial release (Closes: 961337)
>>> >
>>>
>>> 
>>> stappers@paddy:/usr/src/debian/deno
>>> $ grep ^name Cargo.lock  | head
>>> name = "Inflector"
>>> name = "adler"
>>> name = "ahash"
>>> name = "ahash"
>>> name = "aho-corasick"
>>> name = "alloc-no-stdlib"
>>> name = "alloc-stdlib"
>>> name = "ansi_term"
>>> name = "anyhow"
>>> name = "anymap"
>>> stappers@paddy:/usr/src/debian/deno
>>> $ grep --after=1 ^Build-Depends debian/control
>>> Build-Depends: debhelper (>= 11), rustc, cargo
>>> Standards-Version: 4.1.3
>>> stappers@paddy:/usr/src/debian/deno
>>> $
>>> 
>>>
>>> What cargo needs doesn't match the Build-Depends.
>>> If uploaded, it would fail to build due missing build dependencies.
>>>
>>>
>>> Yes, consider packaging deno for Debian (and it's derivatives)
>>>
>>>> a very interresting challenge.
>>>
>> > Deno has ~400 dependencies. What should I do?

For all that concerns building:
https://wiki.debian.org/Teams/RustPackaging

For all that concerns userland:
https://wiki.debian.org/Javascript
In particular this is very interesting to read (because it explains what
could be bundled or not):
https://wiki.debian.org/Javascript/GroupSourcesTutorial

Debian toolchains have been upgraded (mainly by DD yadd) to cope with
bundled dependencies,
A.K.A. components. Uscan now supports this.

In my experience a huge project like Deno is going to drag sub-projects,
make them live,
and also make mistakes and depend on abandonware.
This isn't going to be a piece of cake. The more Deno and its deps are
stable, the more it's going to be easy to package.

Jérémy

Bug#986737: RFS: deno/1.8.3-1 [ITP] -- A secure JavaScript and TypeScript runtime

[Jérémy Lal]

Le sam. 10 avr. 2021 à 21:42, Geert Stappers  a écrit :

> On Sat, Apr 10, 2021 at 09:17:12PM +0300, Sergey Abroskin wrote:
> > Dear mentors,
> >
> > I am looking for a sponsor for my package "deno":
> >
> >  * Package name: deno
> >Version : 1.8.3-1
> >Upstream Author : The Deno Authors
> >  * URL : https://deno.land
> >
> >
> >   https://mentors.debian.net/package/deno/
> >
> >   dget -x
> https://mentors.debian.net/debian/pool/main/d/deno/deno_1.8.3-1.dsc
> >
> >* Initial release (Closes: 961337)
> >
>
> 
> stappers@paddy:/usr/src/debian/deno
> $ grep ^name Cargo.lock  | head
> name = "Inflector"
> name = "adler"
> name = "ahash"
> name = "ahash"
> name = "aho-corasick"
> name = "alloc-no-stdlib"
> name = "alloc-stdlib"
> name = "ansi_term"
> name = "anyhow"
> name = "anymap"
> stappers@paddy:/usr/src/debian/deno
> $ grep --after=1 ^Build-Depends debian/control
> Build-Depends: debhelper (>= 11), rustc, cargo
> Standards-Version: 4.1.3
> stappers@paddy:/usr/src/debian/deno
> $
> 
>
> What cargo needs doesn't match the Build-Depends.
> If uploaded, it would fail to build due missing build dependencies.
>
>
> Yes, consider packaging deno for Debian (and it's derivatives)
> a very interresting challenge.
>

Hi !

Deno is Javascript/Typescript !
Please cc and involve pkg-javascript team.

Issues are 3-fold:
- packaging cargo (rust's package manager) dependencies
- how Deno userland modules (written in typescript/javascript) are going to
be distributed
  (probably in a way comparable to how node or javascript modules are
distributed)
- https://github.com/denoland/rusty_v8
  how to make Node and Deno share the same v8. (This is where i might be
able to help).

Jérémy

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Jérémy Lal]

Le dim. 14 févr. 2021 à 17:33, Leopold Palomo-Avellaneda 
a écrit :

> Hi Mechtilde,
>
>
> El 14/2/21 a les 14:41, Mechtilde Stehmann ha escrit:
> > Hello Leopold,
> > hello all,
> >
> > does it also build at buildd after a source only upload.
>
> ok
>
> > At the official build machines it is n't allowed to install a package
> > which isn't called in debian/control beside the essential build packages.
>
> yes, you are right.
>
> > You have to call *all needed* packages for building in debian/control.
> > Otherwise it can't be build at the official build machines.
>
> Yes, it's true. But, this is not the case. It call all the dependencies
> to build the package. But it fails *before* you call pbuilder in a clean
> env.
>
> > This should be ensured by pbuilder. You have to be able to build in a
> > clean pbuilder chroot.
>
> I have a pbuilder installation to build packages. I'm using pbuilder,
> and I built a lot of backports to myself. The server where I run
> pbuilder is a Debian stable with several packages installed, nothing
> important. Without sphinx-common, when I try to build paperwork, from
> salsa I got:
>
> $ pdebuild
> W: /root/.pbuilderrc does not exist
> dpkg-checkbuilddeps: error: Unmet build dependencies: python3-sphinx
> python3-sphinxcontrib.plantuml sphinx-doc
> W: Unmet build-dependency in source
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: info: applying
> 0001-Search-for-data-files-in-system-folders.patch
> dpkg-source: info: applying
> 0002-Show-all-page-at-once-until-python3-getkey-gets-pack.patch
> dpkg-source: info: applying
> 0003-Disable-potentially-dangerous-plugins.patch
> dh clean --with python3,sphinxdoc --buildsystem=pybuild
> dh: error: unable to load addon sphinxdoc: Can't locate
> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to install
> the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains:
> /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.28.1
> /usr/local/share/perl/5.28.1 /usr/lib/x86_64-linux-gnu/perl5/5.28
> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.28
> /usr/share/perl/5.28 /usr/local/lib/site_perl
> /usr/lib/x86_64-linux-gnu/perl-base) at (eval 15) line 1.
> BEGIN failed--compilation aborted at (eval 15) line 1.
>
> make: *** [debian/rules:38: clean] Error 25
>
> Before, pbuilder is call. However, if I install sphinx-common and run
> again pbuilder paperwork is built.
>
> Another thing is if you really need to call:
>
>  dh $@ --with python3,sphinxdoc --buildsystem=pybuild
>
> with sphinxdoc.
>
> In any case, salsa C-I is passed and doesn't fail, and AFAIK they use a
> similar env as build machines. Please, DD, push this package. It would
> be a pity that we don't have this version in Bullseye.
>
> Best regards,
>
> Leopold
>
>
> > Kind regards
> >
> > Mechtilde
> >
> > Am 14.02.21 um 14:15 schrieb Leopold Palomo-Avellaneda:
> >> Mechtilde,
> >>
> >>
> >> El 14/2/21 a les 14:04, Mechtilde Stehmann ha escrit:
> >>
> >> [...]
> >>
> >>> dh clean --with python3,sphinxdoc --buildsystem=pybuild
> >>> dh: error: unable to load addon sphinxdoc: Can't locate
> >>> Debian/Debhelper/Sequence/sphinxdoc.pm in @INC (you may need to
> install
> >>> the Debian::Debhelper::Sequence::sphinxdoc module) (@INC contains:
> >>> /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.32.1
> >>> /usr/local/share/perl/5.32.1 /usr/lib/x86_64-linux-gnu/perl5/5.32
> >>> /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl-base
> >>> /usr/lib/x86_64-linux-gnu/perl/5.32 /usr/share/perl/5.32
> >>> /usr/local/lib/site_perl) at (eval 14) line 1.
> >>> BEGIN failed--compilation aborted at (eval 14) line 1.
> >>
> >> [...]
> >>
> >>
> >> IMHO the problem that you have here is that you have not installed in
> >> the box where you run pbuilder or gbp the package sphinx-common.
> >>
> >> That package contains the file
> >> sphinx-common: /usr/share/perl5/Debian/Debhelper/Sequence/sphinxdoc.pm
> >>
> >> that needs Debhelper to prepare the package to be built.
> >>
> >> I have backported paperwork without any problem.
> >>
> >> Best regards,
> >>
> >> Leopold
>

Hello,

i'll go ahead. However there is a high chance it won't migrate to testing,
due to soft freeze policy as Thomas pointed out. Let's see.

Jérémy

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Jérémy Lal]

Le dim. 14 févr. 2021 à 14:45, Mechtilde Stehmann  a
écrit :

> Hello Leopold,
> hello all,
>
> does it also build at buildd after a source only upload.
>
> At the official build machines it is n't allowed to install a package
> which isn't called in debian/control beside the essential build packages.
>
> You have to call *all needed* packages for building in debian/control.
> Otherwise it can't be build at the official build machines.
>
> This should be ensured by pbuilder. You have to be able to build in a
> clean pbuilder chroot.
>

Hi,

indeed, and we all agree on that.
I'm using sbuild in a clean sid chroot, and i don't see the problem with
sphinx at all.
Could the problem be somewhere else ?

Jérémy

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Jérémy Lal]

Le sam. 13 févr. 2021 à 11:28, Thomas Perret  a
écrit :

> Hi Jérémy,
>
> >
> > However, i don't quite understand the usefulness of these packages:
> > - openpaperwork-core
> > - openpaperwork-core-doc
> > - openpaperwork-gtk
> > - openpaperwork-gtk-doc
> >
> > I've installed openpaperwork-gtk and it seems it doesn't depend on
> > paperwork-gtk,
> > but maybe i'm missing some documentation, and the long package
> description
> > of
> > openpaperwork-gtk
> > doesn't help either.
>
> In fact, paperwork-gtk depends on openpaperwork-gtk.
>
> I agree that openpaperwork-* packages descriptions are not really helpful

Bug#978440: RFS: paperwork/2.0.2-1 -- Personal document manager

[Jérémy Lal]

Hi Thomas,

i've successfully built paperwork 2.0.2 in a clean sid chroot,
using gbp buildpackage (and sbuild).
The package is lintian clean.

However, i don't quite understand the usefulness of these packages:
- openpaperwork-core
- openpaperwork-core-doc
- openpaperwork-gtk
- openpaperwork-gtk-doc

I've installed openpaperwork-gtk and it seems it doesn't depend on
paperwork-gtk,
but maybe i'm missing some documentation, and the long package description
of
openpaperwork-gtk
doesn't help either.

Manually i had to do
dpkg -i paperwork-gtk_2.0.2-1_all.deb paperwork-backend_2.0.2-1_all.deb
 openpaperwork-core_2.0.2-1_all.deb
to get it, and that somehow looks wrong.

On the other hand, once installed, it seems to be working all right. I'll
try to do actual scanning with it later.

Jérémy

PS:

i really think it would be a bonus to Bullseye to have paperwork 2.
Maybe debian-release will allow it if we ensure the debian packaging is all
right very quickly.

anyone up to packaging AWX ?

[Jérémy Lal]

I've set up some basic, non-dfsg debian packages here:
https://salsa.debian.org/kapouer/awx/

It still needs a lot of work to deal with the dependencies:
in this instance the python and nodejs dependencies are downloaded during
build.

However the resulting package is very nice to use.

Jérémy

Re: new maintainer for package 'urlscan'

[Jérémy Lal]

Le lun. 8 avr. 2019 à 15:22, Boruch Baum  a écrit :

> Package 'urlscan'[1] in debian is ten point releases and over three
> years behind the developer's latest release[2], the listed debian
> maintainer hasn't responded to my e-mails, and the developer doesn't
> seem sure if the debian maintainer is still active[3]. The package is
> not on the current orphaned list[4]. All that being the case, I thought
> to offer to become the maintainer, thus this email to ask what the
> specific process would be in this case, and who would be available to
> mentor me. I probably have some history with debian that might be on
> record from years ago; I vaguely recall either e-signing or certifying a
> few documents, but in practice my past attempts to contribute to debian
> have been via bug reports and suggestions.
>

You ought to check
https://tracker.debian.org/pkg/urlscan

and propose to the last DD who signed the upload to sponsor your upload.

Jérémy


>
>
> [1] https://github.com/firecat53/urlscan
> [2] https://github.com/firecat53/urlscan/releases
> [3] https://github.com/firecat53/urlscan/issues/86#issuecomment-479557966
> [4] https://www.debian.org/devel/wnpp/orphaned
>
> --
> hkp://keys.gnupg.net
> CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0
>
>

Re: Taking over a package from an active DD

[Jérémy Lal]

2018-01-11 15:06 GMT+01:00 Mattia Rizzolo :

> On Thu, Jan 11, 2018 at 09:26:23PM +0800, gustavo panizzo wrote:
> > I sent 2 emails to the DD asking its plans for the package
> > and offering to take over the maintenance. To date I have no answer.
> >
> > What can I do?
>
> Sadly, we have no good ways to deal with those cases.  Your options are:
> 1 keep mailing hoping something will happen
> 2 keep NMUing like crazy hoping the maintainer won't mind and won't
>   overwrite your changes
> 3 do a "co-hijack", i.e. add yourself in Uploaders, and hope the
>   maintainer won't mind
> 4 completely hijack the package and hope the original maintainer won't
>   mind
> 5 get the Technical Committee on board and have them hijack the package
>   from the current maintainer and give it to you
>
> Also sadly, the only options that are "written down" and widely accepted
> are 1 and 5, where 1 most likely will lead to nothing and 5 will make
> everybody angry.  2 will be totally awkward and annoying in the long
> run, and 4 most likely will upset the current maintainer.  IMHO the best
> shot is to do a number of NMUs in several months, and then try option 3
> (possibly followed by 4 a couple of years later or so).
>

6 If the package has Vcs-* field, debcheckout, make another debian branch,
push your work and notify maintainer:
- he can rebase your branch on master
- you can do it if he's okay, and then you can upload the changes
Because the problem with NMU is that most of the time it's the original
maintainer who will have to merge the NMU back into the Vcs, and it's
unfair.

Jérémy

Re: Maintaining C++ library symbols control file with unstable mangled symbols

[Jérémy Lal]

2016-12-02 18:08 GMT+01:00 Ghislain Vaillant :
> On 02/12/16 16:36, lumin wrote:
>>
>> Hi mentors,
>>
>> I need advise on the way maintaining symbols control file when
>> the mangled C++ symbols are unstable.
>>
>> I'm maintaining a package named "Caffe". I migrated the same
>> source from experimental to unstable, and it FTBFS'ed as you
>> see at [0], due to the mangled C++ symbols change. Actually
>> this package FTBFS'ed many times in the history due to
>> symbols change. (I have no e.g. ppc64el machine, hence
>> unable to test before upload)
>
>
> Stopping you right there. Maintaining C++ symbols is notoriously painful,
> and I was advised back in my early packaging days to just avoid it.
>
> Perhaps things have changed since, and other people might disagree.

dh-acc and abi-compliance-checker might help you maintain your own
soname. Nothing guaranteed, though.

Jérémy

Bug#804252: [Pkg-javascript-devel] Bug#804252: RFS: node-readable-stream/2.0.3-1 [ITP]

[Jérémy Lal]

2015-11-06 16:27 GMT+01:00 Ross Gammon :

> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "node-readable-stream"
>
> * Package name: node-readable-stream
>   Version : 2.0.3-1
>   Upstream Author : Streams WG Team 
> * URL : https://github.com/nodejs/readable-stream#readme
> * License : Expat
>   Section : web
>
> It builds this binary package:
>
> node-readable-stream - Streams3, a user-land copy of the stream library
> from
> iojs v2.x
>
> To access further information about this package, please visit the
> following
> URL:
>
> http://mentors.debian.net/package/node-readable-stream
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x
> http://mentors.debian.net/debian/pool/main/n/node-readable-stream/node-
> readable-stream_2.0.3-1.dsc
>
> Debian packaging can be found here:
> http://anonscm.debian.org/cgit/pkg-javascript/node-readable-stream.git
>
> Changes since the last upload:
>
>   * Initial release (Closes: #796355)
>
>
> Regards,
> Ross Gammon
>


You don't need this, we have nodejs 4 in debian now, and
require('readable-stream') can be patched
away easily.

However, i'm all in favor of declaring that nodejs package Provides
node-readable-stream,
and place the shim in /usr/lib/nodejs, because i'm bored too.

nodejs could provide
/usr/lib/nodejs/readable-stream/index.js
```
exports.Readable = require('stream').Readable;
```

Jérémy

Bug#804252: [Pkg-javascript-devel] Bug#804252: RFS: node-readable-stream/2.0.3-1 [ITP]

[Jérémy Lal]

2015-11-06 16:45 GMT+01:00 Gianfranco Costamagna <
costamagnagianfra...@yahoo.it>:

> Control: tags -1 moreinfo
> Control: owner -1 !
>
> Hi
>
>
> >nodejs could provide
> >/usr/lib/nodejs/readable-stream/index.js
> >```
> >exports.Readable = require('stream').Readable;
> >```
>
>
> yes I thought the same, specially after I read
> README.Debian file
>
> "
> The watch file has been temporarily held at v2.0.3 of readable-stream.
> This is equivalent to the version of stream from the current LTS version
> of nodejs (4.1.2).
> The next version of readable-stream (2.0.4) is built from nodejs v5.0.0.
> "
>
> I guess some wait for node 5 to reach testing is better than upload this
> one and remove in a few months
> (unless I'm missing nomething)
>

That won't happen for a while.
Nodejs LTS is branch 4.2
Nodejs 5 will stay (and be updated, of course) in experimental until next
LTS is out.

Jérémy

Re: Big data is needed for unit test

[Jérémy Lal]

Le lundi 01 décembre 2014 à 17:28 +0100, Johannes Schauer a écrit :
 Hi,
 
 Quoting Paul Wise (2014-12-01 17:03:39)
   Should I simply remove this test, or can I include the data file in the
   package ?
  
  Can you include more details about this data file?
  
  What data format is the file in?
 
 depending on the answer to this question it might be very simple to compress
 the file to 5-10% of its original size (usually possible for XML based
 formats).

if that's the case then you have nothing special to do, since the
package tarball is compressed... so you just have to check the actual
size of the compressed upstream tarball.

Jérémy.



-- 
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/1417451738.11471.10.ca...@melix.org

Re: More help for ams statements needed (Was: [Help] Need help for architecture specific code)

[Jérémy Lal]

Le vendredi 05 septembre 2014 à 13:35 +0200, Andreas Tille a écrit :
 Hi,
 
 On Mon, Aug 04, 2014 at 12:58:42PM +0100, Wookey wrote:
  +++ Andreas Tille [2014-08-04 09:48 +0200]:

   ebwt.h:1909: Error: invalid instruction suffix for `popcnt'
   make[2]: *** [bowtie-build] Error 1
 
  The relevant line in the code is:
 
   $ grep -w -n  asm e*
   ebwt.h:1909:asm (popcntq %[x],%[count]\n: [count] =r 
 (count): [x] r (x));

A quick search shows this instruction is supported by -msse4.2 switch,
which is probably not enabled on debian i386 arch.

Another quick search show how to switch to popcnt (without q):

   ({ __cpu_mask r; \
- asm (popcntq %1, %0 : =r (r) : 0 (l));\
+ asm (popcnt %1, %0 : =r (r) : 0 (l));\
  r; })

Jérémy.




-- 
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/1409919323.27515.5.ca...@melix.org

Bug#759311: RFS: node-base64-url/1.0.0-1 [ITP]

[Jérémy Lal]

This package is questionnable because it contains too little code...
https://github.com/joaquimserafim/base64-url/blob/master/index.js

There is an ongoing discussion on pkg-javascript ML about bundling
packages:

http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/2014-August/008488.html

Jérémy.


-- 
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/1409043995.14474.15.ca...@melix.org

Re: Gatejs needs a mentor

[Jérémy Lal]

Le mardi 15 juillet 2014 à 09:04 +0400, Michael Vergoz a écrit :
 Hi
 
 I'm working on gatejs which is a reverse  forward proxy made using 
 javascript (nodejs).
 It is under the GPLv3
 We would like to port it for Debian. Is there someone to help me to do 
 that ?
 https://github.com/binarysec/gate
 https://github.com/binarysec/gateGhost
 
 Thanks in advance
 Michael
 
 -- 
 Michael Vergoz
 BinarySEC

You might want to visit pkg-javascript team
https://wiki.debian.org/Javascript

Jérémy.



-- 
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/1405426996.20229.1.camel@imac.chaumes

Re: What do you do when your sid development system stops working?

[Jérémy Lal]

Le dimanche 11 mai 2014 à 21:33 -0500, Paul Elliott a écrit :
 I like to do my packaging under sid, because
 that is where the packages will first have to run, so
 I can test them there.
 
 But what do you do when your sid system stop work
 after doing an apt-get dist-upgrade? X11 stopped working
 no screens found.
 
 Of course I filed a bug.
 
 But is there some kind of work around that will let you
 keep working somehow?

It happened to me this sunday (got caught by the llvm-3.4 upgrade).
I carefully downgrade each package recently updated, as logged
in /var/log/apt/history.log.
If i cannot find the old version of a package, i use lynx to download
directly the deb file out of snapshot.debian.org.
It usually restores the system in a working state.
Also, etckeeper might help if you're often fiddling with /etc.

Jérémy.



-- 
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/1399888609.26743.4.camel@imac.chaumes

Re: What do you do when your sid development system stops working?

[Jérémy Lal]

Le lundi 12 mai 2014 à 08:13 -0500, Paul Elliott a écrit :
 On Mon, May 12, 2014 at 11:56:49AM +0200, Jérémy Lal wrote:
  Le dimanche 11 mai 2014 à 21:33 -0500, Paul Elliott a écrit :
  
  It happened to me this sunday (got caught by the llvm-3.4 upgrade).
  I carefully downgrade each package recently updated, as logged
  in /var/log/apt/history.log.
  If i cannot find the old version of a package, i use lynx to download
  directly the deb file out of snapshot.debian.org.
  It usually restores the system in a working state.
  Also, etckeeper might help if you're often fiddling with /etc.
  
  Jérémy.
 
 Below is the long list of debs that were installed.
 do any strike people as suspicious? i.e. the one to check first?
 Thank You.


This is the culprit:

libllvm3.4:i386 (3.4-2, 3.4.1-1)

you just have to downgrade it.

Jérémy



-- 
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/1399900819.7162.0.camel@imac.chaumes

Re: What do you do when your sid development system stops working?

[Jérémy Lal]

Le lundi 12 mai 2014 à 09:26 -0400, The Wanderer a écrit :
 On 05/12/2014 09:20 AM, Jérémy Lal wrote:
 
  Le lundi 12 mai 2014 à 08:13 -0500, Paul Elliott a écrit :
 
  Below is the long list of debs that were installed. do any strike
  people as suspicious? i.e. the one to check first? Thank You.
  
  This is the culprit:
  
  libllvm3.4:i386 (3.4-2, 3.4.1-1)
  
  you just have to downgrade it.
 
 There has to be more to the situation than that, though - because I have
 libllvm 3.4.2 installed (both amd64 and i386), and just yesterday not
 only successfully booted but replaced a hard drive in the RAID array on
 which several of my LVM partitions are based.
 
 Do you know under what circumstances libllvm 3.4-2 is known to be a
 problem?

Yes,
https://bugs.debian.org/747701

and a fix has been uploaded already by Sylvestre.

Jérémy.



-- 
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/1399901596.7162.1.camel@imac.chaumes

Re: git packaging workflow notes, diagram

[Jérémy Lal]

On 04/04/2013 09:55, Daniel Pocock wrote:
 
 Hi all,
 
 I've had a few discussions with people about the git workflow for packaging.
 
 I've now made a diagram about this that may be useful for people, it is
 relevant to autotools projects in particular:
 
 http://danielpocock.com/autotools-project-distribution-and-packaging-on-debian
 
 Please let me know if anything could be clarified further

Conondrum can be solved, as explained today by Russ Allbery :

http://www.eyrie.org/~eagle/journal/2013-04/001.html


--
Jérémy


-- 
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/515d34a4.4070...@melix.org

Bug#700771: RFS: seafile-client/1.4.5-1 [ITP] -- online file storage and collaboration tool - client

[Jérémy Lal]

On 17/02/2013 11:43, Shuai Lin wrote:
 Package: sponsorship-requests
 Severity: wishlist
 
 Dear mentors,
 
   I am looking for a sponsor for my package seafile-client


Hello, sponsors,

i've helped Shuai Lin review his package. He has done
a great job at fixing the problems i pointed out.
I'm willing to sponsor him - but i am only DM, so i'll
continue reviewing his package until another DD step in.



Hi Shuai,

could you have a look at lintian pedantic/experimental warnings ?
You can quickly see them at your package page on mentors.d.n,
or reproduce using
lintian --pedantic -E seafile-client_1.4.5-1_amd64.changes
Mind that they could be false positives, in which case you
can ignore them. (Or better, report a bug to lintian package,
having made sure it hasn't already been reported before).

Regards

Jérémy.






signature.asc
Description: OpenPGP digital signature

Bug#694164: RFS: redmine/1.4.4+dfsg1-2 [NMU] [RC]

[Jérémy Lal]

On 24/11/2012 18:57, Michael Gilbert wrote:
 On Sat, Nov 24, 2012 at 8:17 AM, Dominik George n...@naturalnet.de wrote:
 I am looking for a sponsor for my package redmine
 
 Hi, thanks for working on these issues.  I'd like to see a few things
 corrected in the changelog, but otherwise it looks good.
 
   * NMU to fix RC bugs.
 
 There is specific language usually used in the nmu line.  You can
 automatically generate that with dch -n.  Technically you can word
 that however you want, but consistency is useful.
 
   * debian/control: add dependency on rubygems or recent enough ruby
 (Closes: #693994).
 
 Please give credit to the person originally proposing the patch for this 
 issue.
 
   * debian/postinst: replace exit status -1 with 2 for shell compatibility
 (Closes: #687449).
 
 Please mention which shells have this problem: i.e. dash does but bash 
 doesn't.


Thank you all for this work - Dominik, would you work directly on
the git repository of the redmine package ? That would allow much
easier maintenance.
I can find some time to upload the fixes this week.

Jérémy.


--
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/50b114c1.8020...@melix.org

Re: Changing SONAME in library version

[Jérémy Lal]

On 07/05/2012 15:41, Olе Streicher wrote:
 Dear mentors,
 
 I am the maintainer of the package cpl. Upstream just released a new
 version 6.0 and changed the SONAME for the built libraries from 12 to
 20. So, the source now builds a package libcplcore20 instead of
 libcplcore12. There are a few dependencies of other packages from
 libcplcore12, which I all maintain myself (esorex and python-cpl).
 
 The problem is now that I get migration excuses like
 
 out of date on i386: [...], libcplcore12, [...] (from 5.3.1-1)
 
 which I don't know how to handle. What is the usual way to get rid of
 these? 

Hi,
i am in the same situation, and am learning this :
http://wiki.debian.org/binNMU

Regards,
Jérémy.


-- 
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/4fa7d3be.5070...@melix.org

Re: Dependencies for FastCGI

[Jérémy Lal]

On 17/04/2012 05:43, Stefan Ott wrote:
 Hey mentors
 
 I have a question concerning one of my packages (fookebox). It
 currently depends on libapache2-mod-wsgi | httpd-wsgi since it's a
 web application that is typically called through WSGI. As requested in
 #667838, I now added the configuration files required to get it to run
 through FastCGI with python-flup. However, I am not entirely sure how
 to change my dependencies to indicate that this is a possibility.
 
 As I see it, one option would be to say that the package depends on
 either (libapache2-mod-wsgi | httpd-wsgi) or (libapache2-mod-fastcgi
 and python-flup). Yet a) I couldn't figure out the syntax to specify
 such a dependency and b) it would ignore the possibility of running
 FastCGI through anything other than libapache2-mod-fastcgi (there
 doesn't seem to be a virtual httpd-fastcgi package). Thus I figured
 the best way to do this is to change the current dependency into a
 recommendation (which would allow experienced admins to ignore it
 while still resulting in a working installation for people who don't
 care) and add libapache2-mod-fastcgi and python-flup as suggestions to
 indicate that they are supported and tested mechanisms. Or I could
 just leave that out and add a note about this possibility to
 README.Debian.
 
 So, before I start messing around, I was hoping that somebody might
 have some input on this. Any thoughts / suggestions?

There an (ongoing ?) discussion at :
http://bugs.debian.org/627213

Jérémy.


-- 
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/4f8d0741.7000...@melix.org

what happens if DM annual ping is late ? removed from keyring ?

[Jérémy Lal]

Hi,
i reported my DM annual ping at the anniversary date,
and now i can't upload :

Reject Reasons:
kapo...@melix.org is not in Maintainer or Uploaders of source package redmine

is this expected until the bug report has been processed,
or am i missing something ? I feel a bit worried about that :)

Jérémy.


-- 
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/4de3eb0b.6090...@melix.org

binutils gold

[Jérémy Lal]

Hi,
is it all right to upload a package built with gold linker ?

Regards,
Jérémy.


-- 
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/4da576e7.7040...@edagames.com

Re: upstream source with debian directory

[Jérémy Lal]

On 25/02/2011 10:44, Harald Jenny wrote:
 Hi Paul
 
 On Wed, Feb 23, 2011 at 07:48:13AM +0800, Paul Wise wrote:
 If you weren't using git I would say use dpkg-source v3 which removes
 any upstream debian/ dir during the unpack process.
 
 Well using v3 format does indeed solve the problem for the user which is not a
 bad thing either :-).
 

 With git I'm not sure but I'd be inclined to just resolve conflicts,
 continue the merge and maybe send upstream some patches.
 
 I have also access to the upstream git tree so (after discussion with the main
 maintainers) I may merge the changes myself.
 
 Now that
 upstream is also using git you can probably just switch from
 git-import-orig to git pull and pristine-tar.
 
 You don't have some Howto lying around making going into the detail in here?

If the content of the debian dir is not usable and a pain to merge,
as that sometimes can be the case, there is also the possibility to filter
it out with some debian/gbp.conf :

[DEFAULT]
pristine-tar = True

[git-import-orig]
filter = debian/*
filter = lib/*
filter-pristine-tar = True

Then git-import-orig won't import the upstream content in the debian dir :
no merge, no conflicts.

Jérémy.


-- 
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/4d678edb.3080...@melix.org

RFS: abi-compliance-checker (updated package)

[Jérémy Lal]

Dear mentors,

I am looking for a sponsor for the new version 1.21.9-0.1
of package abi-compliance-checker.

Ryan Niebur is the maintainer, and this mail exchange shows he's all
right with 1) the move to collab-maint and 2) an NMU.
The only change not agreed nor really necessary is the move to 3.0 quilt
format, but since there are no debian/patches, it shouldn't bother anyone.

It builds these binary packages:
abi-compliance-checker - tool to compare ABI compatibility of shared C/C++ 
library version

The package appears to be lintian clean.

The upload would fix these bugs: 568650, 568654, 592975, 598798

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/a/abi-compliance-checker
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/a/abi-compliance-checker/abi-compliance-checker_1.21.9-0.1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Jérémy Lal


-- 
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/4d65405a.3010...@melix.org

RFS: eot-utils

[Jérémy Lal]

Dear mentors,

I am looking for a sponsor for my package eot-utils.

* Package name: eot-utils
  Version : 1.0-1
  Upstream Author : Bert Bos b...@w3.org
* URL : http://www.w3.org/Tools/eot-utils/
* License : W3C® SOFTWARE NOTICE AND LICENSE
  Section : web

It builds these binary packages:
eot-utils  - Tools to convert from OTF or TTF to EOT font format

The package appears to be lintian clean.

The upload would fix these bugs: 589470

My motivation for maintaining this package is:
Allow usage of downloadable fonts in web pages;
all A-grade browsers have (all least basic) support
of CSS Fonts Module level 3. MSIE browsers need a special
font format (Embedded OpentType) to display the font.
This package allows to convert a font from TTF format to EOT format,
hence allowing cross-browser use of downloadable fonts.
Please note the license is advertised to be GPL-compatible.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/e/eot-utils
- Source repository: deb-src http://mentors.debian.net/debian unstable main
- dget 
http://mentors.debian.net/debian/pool/main/e/eot-utils/eot-utils_1.0-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Jérémy Lal



signature.asc
Description: OpenPGP digital signature

Re: How to upload packages with skipped uploads

[Jérémy Lal]

On 17/07/2010 16:28, Osamu Aoki wrote:
 Hi,
 
 I just uploaded xpdf and then realized I was not closing bug for the
 changelog entries from un-uploaaed versions.
 
 I just closed them manually but what did I miss to be like this.
 
 Is there some trick to indicate previos upload was not the previous
 version in pbuilder or debuild?
 
 I know it is some simple thing but it is rare unless we upload for
 sponsoring.  Help appreciated.
 
 Osamu
 
 

see dpkg-genchanges -v
then use debuild -v...


-- 
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/4c41c313.9050...@edagames.com

Re: mentors error?

[Jérémy Lal]

On 11/05/2010 14:13, Praveen A wrote:
 2010/5/11 Praveen A prav...@gmail.com:
 I got a similar message yesterday.
 
 Correction: Similar experience - Upload completed successfully, but
 not reflected on the site.
 -Praveen

Same problem here.
Some more symptoms :
- i uploaded on 7th, may, package was available minutes later;
  however, i received the confirmation email some days after.
- today the package is not available after more than 1 hour, still waiting.
- latest package shown is from yesterday

Jérémy.


-- 
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/4be9a488.7020...@edagames.com

Re: web frontend location

[Jérémy Lal]

On 28/04/2010 22:55, glaskoncILLa wrote:
 Hi,
 
 I'm preparing to apply as new Debian maintainer and I'm working on
 packaging of GestioIP application, http://www.gestioip.net/ , developed
 by Marc Uebel.
 Basicaly thats a IP address management application with web interface,
 based on perl cgi's sitting on mysql database.
 
 From what I've read till now in beginers manuals and find out
 investigating other similar packages, perl cgi's should be placed in
 /usr/share/gestioip directory.
 Thats kind of problem because application is originaly coded for taking
 place in /var/www/gestioip directory and changing that means either
 changing a lot of original code either some dirty quick fixes and we
 would like avoid that, if possible of course..
 
 So the question is; is it possible to put perl cgi's in
 /var/www/gestioip and stay compliant with Debian packaging rules?
 Thank you in advance.

That software looks configurable. Try it.

Also reading some policies might help :
http://www.debian.org/doc/packaging-manuals/perl-policy/
http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-web-appl
http://webapps-common.alioth.debian.org/draft/html/

Regards,
Jérémy.


-- 
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/4bd8a642.2090...@edagames.com

Re: RFS: lal

[Jérémy Lal]

i already said this,
but i'm not confortable at the idea of being packaged :)

Jérémy Lal


-- 
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/4ba7991e.6060...@edagames.com

what it's like to be old debian maintainer

[Jérémy Lal]

i'm wondering what happens when you spent hours and
years dealing with debian... is it something you don't regreat ?
I'm in the learning curve and it's still very interesting,
so it's natural for me to ask what more experienced people
feel about that.

Kind regards,
Jérémy.


-- 
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/4ba8219d.9080...@edagames.com

openssl and MIT license ?

[Jérémy Lal]

Hi,
i'm the maintainer of nodejs (MIT license), and upstream author announced
he is willing to switch to openssl.
I know there are issues with the GPL license and the openSSL license, so
i wonder if :
- the openSSL license is compatible with the MIT license ? Knowing that
  the code linking to openSSL will be MIT licensed. Some other portions
  of nodejs are GPL.
- the debian packaging work itself is GPL-2, i guess there's nothing wrong
  with that ?

Thanks for any tips,
Jérémy Lal



-- 
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/4ba4b75c.4030...@edagames.com

what between ITP and RFS ?

[Jérémy Lal]

Imagine this common use case :
- create an ITP
- then make the package available for sponsors (say, on mentors),
- then send an RFS
- later (sometimes a lot later, or even never), the package is uploaded

Is there already a standard way of showing in the ITP
that an RFS has been sent ?
I ask because it's very easy to find the ITP, but it's not
to know the current status of the ITP, until it's been resolved.

I would naively add a small note to it, but it does not seem to be
the right way.

Regards,
Jérémy.


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

RFS : node.js

[Jérémy Lal]

Dear mentors,

I am looking for a sponsor for my package node.js.

* Package name: node.js
  Version : 0.1.24-1
  Upstream Author : Ryan Dahl r...@tinyclouds.org
* URL : http://nodejs.org
* License : MIT, GPL-2
  Section : web

It builds these binary packages:
node.js- Event-based I/O for V8 javascript
node.js-dev - Development files for node.js

The package appears to be lintian clean.

The upload would fix these bugs: 553514

My motivation for maintaining this package is: as a web developer,
I'm currently working on using node.js as a comet server. Node.js is
a great piece of software and already a lot of other projects are
building on it. The current goal is to build a clean and simple web
framework, turning the fact that it uses javascript server-side as an
advantage. Upstream is active, and open to patchs and comments.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/n/node.js
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/n/node.js/node.js_0.1.24-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Jérémy Lal


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

watch file troubles again :)

[Jérémy Lal]

This time the web page contains this :
a href=/path/to/mypackage.zip class=myclassmypackage.zip/a - v1.01

I'm stuck with uscan getting what's inside an href.
Is there a way to get the version number, which is outside the href ?

Jérémy Lal


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

multiple database support with dbconfig-common : metapackages ?

[Jérémy Lal]

Hi,
i'm working on redmine package, which supports three db types :
sqlite, mysql, pgsql
and is using dbconfig-common to setup the db.

Instead of depending on :
sqlite3 | postgresql-client | mysql-client,
libdbd-sqlite3-ruby | libdbd-pg-ruby | libdbd-mysql-ruby
as bugzilla, drupal, and others do, which i think is
confusing the user; is it desirable to do as roundcube package, i.e.
providing three metapackages ? Each package providing the correct
dependencies for each db type.

Then it would give :
redmine depends on redmine-mysql | redmine-pgsql | redmine-sqlite

On second thought, one would like to have these metapackages :
for a php app:
- dbconfig-php-mysql | dbconfig-php-pgsql | dbconfig-php-sqlite
for a ruby app:
- dbconfig-ruby-mysql | dbconfig-ruby-pgsql | dbconfig-ruby-sqlite
and so on for other languages.
For example, dbconfig-ruby-pg would have these dependencies :
libdbd-pg-ruby, postgresql-client
Still, managing all the possibilities might create too much metapackages,
so it's probably better to stay with the first approach.

Thanks for any input on this.

Jérémy Lal


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

Re: multiple database support with dbconfig-common : metapackages ?

[Jérémy Lal]

On 28/09/2009 23:05, Boyd Stephen Smith Jr. wrote:

On Monday 28 September 2009 15:09:15 Jérémy Lal wrote:

Instead of depending on :
sqlite3 | postgresql-client | mysql-client,
libdbd-sqlite3-ruby | libdbd-pg-ruby | libdbd-mysql-ruby
as bugzilla, drupal, and others do, which i think is
confusing the user; is it desirable to do as roundcube package, i.e.
providing three metapackages ? Each package providing the correct
dependencies for each db type.

Then it would give :
redmine depends on redmine-mysql | redmine-pgsql | redmine-sqlite


IANADD, TINASOODP.

As a user, I think you are on the right track here.  The first set of
dependencies would be satisfied by sqlite3 and libdbd-pg-ruby, which might
leave redmine installed but completely non-functional.  AFAIK, there's no way
to express (pkg1  pkg2) | (pkg3  pkg4) without the intervening meta-
packages.

The only other way i found to not end up with a non-functional package was
to put the three libdbd packages as dependencies, which is not very good
either.
 

However, I am a bit surprised that you need to depend on both libdbd-pg-ruby
and postgresql-client.  Shouldn't libpq5 (desciprion: PostgrSQL client
libraries), brought in as a dependency of libdbd-pg-ruby be enough of a
client?  postgresql-client is only the front-end binaries.

I wasn't clear. The package uses dbconfig-common to create database, and 
dbconfig
uses one of those db client packages (sqlite3 | postgresql-client | 
mysql-client)
at config time. The runtime only uses libdbd-(pg|mysql|sqlite3)-ruby.

Regards,
Jérémy.





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

Re: RFS: ttf2eot

[Jérémy Lal]

On 16/09/2009 09:18, Paul Wise wrote:

On Wed, 2009-09-16 at 09:04 +0200, Jérémy Lal wrote:


The @font-face rule ? I don't. I know chrome needs --enable-remote-fonts,
because by default it's disabled. Surely IE has some option to disable it, too.
Maybe you don't like the idea, but websites are going this way...


Correct, I hate the idea.

PS: why didn't you reply to the list?


oops :)


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

RFS: ttf2eot

[Jérémy Lal]

Dear mentors,

I am looking for a sponsor for my package ttf2eot.

This single binary is really helpful for web designers who
need cross-browser support for @font-face CSS rule.
Currently this rule is supported on latest versions of webkit,
firefox, opera, which support ttf font format; and IE, which
supports eot font format.

* Package name: ttf2eot
  Version : 0.0.2-1
  Upstream Author : Tavis Ormandy tav...@sdf.lonestar.org
* URL : http://code.google.com/p/ttf2eot/
* License : GPL-2
  Section : text

It builds these binary packages:
ttf2eot- A TrueType to Embedded OpenType (EOT) Font converter

The package appears to be lintian clean.

The upload would fix these bugs: 534625

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/t/ttf2eot
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/t/ttf2eot/ttf2eot_0.0.2-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Jérémy Lal


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

what to do when upstream package is shipped with MB of dependencies ?

[Jérémy Lal]

I'm in a situation where upstream tarball is not very nice;
e.g. it's shipped with 3MB of dependencies, most of which
are already packaged.
I suppose a patch has no meaning here, since it consists in
removing the dependencies from the tarball. Another patch consists
in correcting the makefile to use already installed libraries instead
of rebuilding them. That one could be meaningfull.
Is doing a get-orig-source taking care of cleaning up upstream
a good solution ?

Regards,
Jérémy Lal



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

Re: Test of a package on a specific architecture

[Jérémy Lal]

On 12/09/2009 13:57, Pietro Battiston wrote:

Il giorno sab, 12/09/2009 alle 13.33 +0200, Laurent Guignard ha scritto:

On Sat, 12 Sep 2009 09:35:39 +0200, Pietro Battiston wrote:

Il giorno ven, 11/09/2009 alle 21.31 +0200, Jérémy Lal ha scritto:

VirtualBox supports 64 bits guests on 32 bits hosts,
provided you have a cpu that supports virtualization.



Are there any 32 bit cpus around which support virtualization?!

Pietro


Virtualbox is running fine on my laptop which is a Pentium M (32 bits
according intel documentation)...




Sure, but you can't run 64 bit systems, which is what Jérémy was
referring to.


VirtualBox says : your processor must support VT-X or AMD-V.
egrep '(vmx|svm)' /proc/cpuinfo






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

Re: Test of a package on a specific architecture

[Jérémy Lal]

VirtualBox supports 64 bits guests on 32 bits hosts,
provided you have a cpu that supports virtualization.


On 11/09/2009 21:17, Laurent Guignard wrote:

Hi mentors,

On my package, dhcp-probe, i have a problem on 64 bits architectures (amd64
for the bug report).
I built a patch with help of Ilkka Virta and i have not any 64 bits host to
test the patch.
How to test a package 64 bits on a 32 bits host ?
If it is impossible, where can i test my package before submit it for upload ?
Is there any machine where i can logon freely and test my package (i am not
Debian Developer nor Debian Maintainer) ?

Thanks in advance.

Best regards.




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

Re: RFS: dojo

[Jérémy Lal]

cool,
here are a few notes :
- add to debian/control#libjs-dojo-core description : This package contains the 
core Dojo project.
- is the dojo/build.txt file needed by dojo ? if not, don't install it
- add a README.Debian to dojox (although i don't know if you can define 
different readme for the different packages), explaining how to use the files 
in examples/ ?

Then subscribe to pkg-javascript-devel [0] and ask them to review your package.
Tell them i helped you a little, so they can blame me if i was wrong :)

Regards,
Jérémy Lal.

PS: i just subscribed to the list myself, i'm cooking a libjs package too

[0]
http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/

On 04/09/2009 18:15, Jason Morawski wrote:

Updated package has been uploaded to mentors.

This new package builds the different frameworks as separate binary
packages and moves the extraneous dojox files
to /usr/share/doc/libjs-dojo-dojox/examples/ maintaining the directory
structure.

On Wed, 2009-09-02 at 23:50 +0200, Jérémy Lal wrote:

Sorry to bother, but :


find . -name *.php

./dojox/analytics/logger/dojoxAnalytics.php
./dojox/analytics/logger/JSON.php
./dojox/form/resources/RecieveFile.php
./dojox/form/resources/cLOG.php
./dojox/form/resources/UploadFile.php
./dojox/resources/explore.php
./dojox/grid/compat/tests/support/data.php
./dojox/grid/compat/tests/support/json.php

find . -name *.sh

./dojox/storage/buildFlashStorage.sh

find . -name *.fla

./dojox/storage/storage_dialog.fla

find . -name *.as

./dojox/flash/ExpressInstall.as
./dojox/flash/DojoExternalInterface.as
./dojox/storage/Storage.as

Those files should not be placed in /usr/share/javascript !!!
I just went to http://www.dojotoolkit.org/
(i'm a jquery fan:) and discovered that in fact,
dojo, dijit, dojox represent three separate frameworks, with different needs,
so there should be three packages from one source :
libjs-dojo-core
libjs-dojo-dijit
libjs-dojo-dojox

however i can't really think of a way to package the last one, since
php, as, fla, sh files are mixed between static html, css, js files in that 
package.
But that should not stop you from packaging the first two.

Maybe i'm totally wrong, somebody, please tell me.

Regards,
Jérémy.





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

Re: RFS: dojo

[Jérémy Lal]

Hi,
please name your package
libjs-dojo

Regards,
Jérémy Lal.

On 02/09/2009 16:33, Jason Morawski wrote:

Dear mentors,

I am looking for a sponsor for my package dojo.

* Package name: dojo
   Version : 1.3.2-1
   Upstream Author : Alex Russella...@dojotoolkit.org
* URL : http://dojotoolkit.org
* License : BSD
   Section : web

It builds these binary packages:
jslib-dojo - Modular JavaScript toolkit

The package appears to be lintian clean.

The upload would fix these bugs: 515637

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/d/dojo
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/d/dojo/dojo_1.3.2-1.dsc

I would be glad if someone uploaded this package for me.

Please CC me when following up on this RFS.

Kind regards
  Jason Morawski




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

Re: RFS: dojo

[Jérémy Lal]

You just mixed up jslib and libjs.
There are no package name starting with jslib.
They all start with libjs :
http://packages.debian.org/search?keywords=libjs

On 02/09/2009 17:37, Jason Morawski wrote:

The source package is named dojo and the binary package produced is
named jslib-dojo. This follows the naming scheme used by the other
jslib packages. However, if the naming policy has changed regarding
these types of packages, I will be more than happy to oblige.

Please let me know, thank you.

On Wed, 2009-09-02 at 16:49 +0200, Jérémy Lal wrote:

Hi,
please name your package
libjs-dojo

Regards,
Jérémy Lal.

On 02/09/2009 16:33, Jason Morawski wrote:

Dear mentors,

I am looking for a sponsor for my package dojo.

* Package name: dojo
Version : 1.3.2-1
Upstream Author : Alex Russella...@dojotoolkit.org
* URL : http://dojotoolkit.org
* License : BSD
Section : web

It builds these binary packages:
jslib-dojo - Modular JavaScript toolkit

The package appears to be lintian clean.

The upload would fix these bugs: 515637

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/d/dojo
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/d/dojo/dojo_1.3.2-1.dsc

I would be glad if someone uploaded this package for me.

Please CC me when following up on this RFS.

Kind regards
   Jason Morawski







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

Re: RFS: dojo

[Jérémy Lal]

On 02/09/2009 17:46, Jason Morawski wrote:

You are totally correct, I can't believe I overlooked that. Also, with
regards to the chmod line in rules, I mainly added that to remove the
lintian warning that was produced. Should I instead supply a lintian
override?


the trouble is the place of the file, not making it executable :
/usr/share/javascript is supposed to contain static files,
not shell scripts.
so
/usr/share/javascript/dojo/dojox/storage/buildFlashStorage.sh
is in a bad place.

Depending on how it's used and by who, it could be placed in :
/usr/bin/  (with .sh removed and a man page added)
/usr/lib/libjs-dojo/
/usr/share/libjs-dojo/

and properly documented in the README.Debian, so one can know where it's been 
put.


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

Re: RFS: dojo

[Jérémy Lal]

Also please note that
/usr/share/javascript
will be accessible on the web server, e.g.
http://localhost/javascript

so in your debian/rules :
chmod +x 
debian/jslib-dojo/usr/share/javascript/dojo/dojox/storage/buildFlashStorage.sh
might be a bad place and idea.

Regards.
Jérémy.



On 02/09/2009 16:33, Jason Morawski wrote:

Dear mentors,

I am looking for a sponsor for my package dojo.

* Package name: dojo
   Version : 1.3.2-1
   Upstream Author : Alex Russella...@dojotoolkit.org
* URL : http://dojotoolkit.org
* License : BSD
   Section : web

It builds these binary packages:
jslib-dojo - Modular JavaScript toolkit

The package appears to be lintian clean.

The upload would fix these bugs: 515637

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/d/dojo
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/d/dojo/dojo_1.3.2-1.dsc

I would be glad if someone uploaded this package for me.

Please CC me when following up on this RFS.

Kind regards
  Jason Morawski




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

Re: RFS: dojo

[Jérémy Lal]

Here's some lintian warnings you can take care easily :
W: dojo source: out-of-date-standards-version 3.8.0 (current is 3.8.3)
no comment

W: dojo source: patch-system-but-no-source-readme
Means you need to add a debian/README.source explaining why you needed a patch.

Also i understand that mtasc is needed, why not add it to debian/control, as a
suggestion (my bet) or recommendation, you decide.

Cheers,
Jérémy.

On 02/09/2009 22:04, Jason Morawski wrote:

Updated package has been uploaded to mentors.

On Wed, 2009-09-02 at 18:03 +0200, Jérémy Lal wrote:

On 02/09/2009 17:46, Jason Morawski wrote:

You are totally correct, I can't believe I overlooked that. Also, with
regards to the chmod line in rules, I mainly added that to remove the
lintian warning that was produced. Should I instead supply a lintian
override?


the trouble is the place of the file, not making it executable :
/usr/share/javascript is supposed to contain static files,
not shell scripts.
so
/usr/share/javascript/dojo/dojox/storage/buildFlashStorage.sh
is in a bad place.

Depending on how it's used and by who, it could be placed in :
/usr/bin/  (with .sh removed and a man page added)
/usr/lib/libjs-dojo/
/usr/share/libjs-dojo/

and properly documented in the README.Debian, so one can know where it's been 
put.




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

Re: RFS: dojo

[Jérémy Lal]

Sorry to bother, but :


find . -name *.php

./dojox/analytics/logger/dojoxAnalytics.php
./dojox/analytics/logger/JSON.php
./dojox/form/resources/RecieveFile.php
./dojox/form/resources/cLOG.php
./dojox/form/resources/UploadFile.php
./dojox/resources/explore.php
./dojox/grid/compat/tests/support/data.php
./dojox/grid/compat/tests/support/json.php

find . -name *.sh

./dojox/storage/buildFlashStorage.sh

find . -name *.fla

./dojox/storage/storage_dialog.fla

find . -name *.as

./dojox/flash/ExpressInstall.as
./dojox/flash/DojoExternalInterface.as
./dojox/storage/Storage.as

Those files should not be placed in /usr/share/javascript !!!
I just went to http://www.dojotoolkit.org/
(i'm a jquery fan:) and discovered that in fact,
dojo, dijit, dojox represent three separate frameworks, with different needs,
so there should be three packages from one source :
libjs-dojo-core
libjs-dojo-dijit
libjs-dojo-dojox

however i can't really think of a way to package the last one, since
php, as, fla, sh files are mixed between static html, css, js files in that 
package.
But that should not stop you from packaging the first two.

Maybe i'm totally wrong, somebody, please tell me.

Regards,
Jérémy.


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

package sponsored and uploaded, then how to update it ?

[Jérémy Lal]

Hi,
i wish to update the package spawn-fcgi to correct a bug.
but i can't upload it to debian mentors : it's been removed
from my package list (probably because it's now in the debian
archive) and mentors refuses packages not starting with -1 version.

my question is : where to dupload it so that my mentor can check and
upload himself that update ?

i asked him, and while waiting i thought it could be worth asking here...

Regards,

Jérémy Lal


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

Re: First steps

[Jérémy Lal]

On 27/05/2009 10:13, Federico Gimenez Nieto wrote:

Pretty much anywhere is a good starting point, as long as (a) it's free,
and (b) the source doesn't require a lot patching to work or manipulation
to install. I haven't looked at openx myself, but as long as it doesn't
require you to manually install random files, etc. it's probably fine.
With that being said, the new-maint guide does recommend shying away from
daemons and packages with multiple binaries for a first package. As a web
advertising system, openx might fit into that category, meaning you might
want to start with something simpler. Then again, challenges are fun.



I would try to learn from other web applications already packaged, could
you please point me a good example? (openx relies on a web server with a
php interpreter and mysql/postgresql as databse server)

Also, are there any best-practices document for packaging web applications?

Thanks a lot,
Federico




I'm also interested in precisions about packaging web apps.
You should read [1], though it's a bit outdated.
Also look apt-get source some already packaged webapps is very
useful to learn ! Just look at the packages that depends on dbconfig-common.

the dbconfig-common package is useful for configuring mysql/pgsql/sqlite
databases using debconf.
The wwwconfig-common package could also be useful... though it
doesn't support other web servers than apache. In my opinion, wwwconfig-common
should offer possibility to configure any web server, (lighttpd, ngnx, 
cherokee...)
based on common use cases. The current state is either :
- depend on apache only
- cook some debconf stuff yourself to enable adequate config of some web servers
- depend on httpd and provide good documentation of what's left to configure 
manually.

[1]
http://webapps-common.alioth.debian.org/draft/html/

Jérémy Lal



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

Re: RFS: sphinxsearch

[Jérémy Lal]

On 13/05/2009 13:40, Tom Simnett wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jérémy Lal wrote:

On 12/05/2009 19:56, Tom Simnett wrote:


Ben Finney wrote:

Jérémy Lalje...@edagames.com   writes:
These command names are rather too generic. Perhaps they should be
prefixed with ‘sphinx-’?

These all look like installing the package with the wrong options to
‘configure’, but that's a guess.

Either write something useful in the README.Debian, or remove it if
it's
not needed for the package.

Perhaps Lintian was never run on this package before uploading it?

This has now been re-uploaded. The manpages don't exist, and as
there is
no ITP bug, it can't close it, so those warnings remain. Apart from
that
it appears to me to be clean.

Hi!
I'm not a mentor or DD, but you can:
1. Write man pages yourself - pick template from
/usr/share/debhelper/dh_make/debian/manpage.1.ex
2. Open an ITP bug for sphinxsearch yourself - just file a bug (using
reportbug tool) against wnpp package.

My 2 cents :)


I now have an ITP bug resolved and manpages. This package is now lintian
clean according to lintian :)

i just had a quick look at it (as a novice), as i'm willing to use it :
- usr/sbin is listed in debian/dirs but not really used ?
- watch file is missing
- /usr/share/doc/sphinxsearch should contain the doc provided by sphinx
source tarball, such doc should be properly registered using doc-base
and docs file.
- provide a README in the /usr/share/doc/sphinxsearch so that once the
package is installed, one knows what's left to do to get it working


Thanks for your suggestions Jérémy. I've added the docs from the source
package, and added a README.Debian file in with some additional
instructions.

As regards the watch file, this is correct. Currently the download site
gives a 403 Forbidden on the downloads directory:
www.sphinxsearch.com/downloads and I've reported this as a bug to
upstream. When this is made available, I'll add the watch file, but for
now this is useless.

Well, you should try
http://www.sphinxsearch.com/downloads.html
:)
exemple of line in the watch file (although maybe the regexp part is wrong) :

# Compulsory line, this is a version 3 file
version=3
http://www.sphinxsearch.com/downloads.html 
http://www.sphinxsearch.com/downloads/sphinx-([\d\.]*).tar.gz

Jérémy.


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

Re: RFS: sphinxsearch

[Jérémy Lal]

On 12/05/2009 19:56, Tom Simnett wrote:


Ben Finney wrote:

Jérémy Lalje...@edagames.com  writes:
These command names are rather too generic. Perhaps they should be
prefixed with ‘sphinx-’?

These all look like installing the package with the wrong options to
‘configure’, but that's a guess.

Either write something useful in the README.Debian, or remove it if it's
not needed for the package.

Perhaps Lintian was never run on this package before uploading it?

This has now been re-uploaded. The manpages don't exist, and as there is
no ITP bug, it can't close it, so those warnings remain. Apart from that
it appears to me to be clean.

Hi!
I'm not a mentor or DD, but you can:
1. Write man pages yourself - pick template from
/usr/share/debhelper/dh_make/debian/manpage.1.ex
2. Open an ITP bug for sphinxsearch yourself - just file a bug (using
reportbug tool) against wnpp package.

My 2 cents :)


I now have an ITP bug resolved and manpages. This package is now lintian
clean according to lintian :)

i just had a quick look at it (as a novice), as i'm willing to use it :
- usr/sbin is listed in debian/dirs but not really used ?
- watch file is missing
- /usr/share/doc/sphinxsearch should contain the doc provided by sphinx source 
tarball, such doc should be properly registered using doc-base and docs file.
- provide a README in the /usr/share/doc/sphinxsearch so that once the package 
is installed, one knows what's left to do to get it working

Regards,
Jérémy Lal.


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

Re: RFS: sphinxsearch

[Jérémy Lal]

the package is not lintian clean :

dpkg-deb : construction du paquet « sphinxsearch » dans « 
../sphinxsearch_0.9.8.1-1_i386.deb ».
 dpkg-genchanges  ../sphinxsearch_0.9.8.1-1_i386.changes
dpkg-genchanges: inclusion du code source original dans l'envoi (« upload »)
dpkg-buildpackage: envoi complet (inclusion du code source d'origine)
Now running lintian...
W: sphinxsearch source: out-of-date-standards-version 3.8.0 (current is 3.8.1)
W: sphinxsearch: binary-without-manpage usr/bin/indexer
W: sphinxsearch: binary-without-manpage usr/bin/search
W: sphinxsearch: binary-without-manpage usr/bin/searchd
W: sphinxsearch: binary-without-manpage usr/bin/spelldump
E: sphinxsearch: FSSTND-dir-in-usr usr/etc/
W: sphinxsearch: file-in-unusual-dir usr/etc/example.sql
W: sphinxsearch: file-in-unusual-dir usr/etc/sphinx-min.conf.dist
W: sphinxsearch: file-in-unusual-dir usr/etc/sphinx.conf.dist
W: sphinxsearch: non-standard-dir-in-usr usr/var/
W: sphinxsearch: readme-debian-contains-debmake-template
W: sphinxsearch: copyright-lists-upstream-authors-with-dh_make-boilerplate
W: sphinxsearch: copyright-contains-dh_make-todo-boilerplate
W: sphinxsearch: new-package-should-close-itp-bug
Finished running lintian.

Regards,
Jérémy Lal.



On 11/05/2009 17:16, Tom Simnett wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear mentors,

I am looking for a sponsor for my package sphinxsearch.

* Package name: sphinxsearch
   Version : 0.9.8.1-1
   Upstream Author : Andrew Aksyonoff
* URL : http://www.sphinxsearch.com/
* License : GPL v2
   Section : web

It builds these binary packages:
sphinxsearch - free open-source SQL full-text search engine

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- - URL: http://mentors.debian.net/debian/pool/main/s/sphinxsearch
- - Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- - dget
http://mentors.debian.net/debian/pool/main/s/sphinxsearch/sphinxsearch_0.9.8.1-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
  Tom Simnett
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkoIQUYACgkQcqOpPRWIaddJoQCaAx5sRs0VjimhXaz9c/wf1NTq
fmUAnRsDLnd0DI7avMTmuqXkSTHdNY3y
=KtG6
-END PGP SIGNATURE-






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

Skipping check of source package

[Jérémy Lal]

hi,
i just uploaded an update to the redmine package,
and i see that :

Lintian report: N: Skipping check of source package redmine

is displayed in my mentor console.
did i do something wrong ?

Regards,
Jérémy Lal



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

RFS: spawn-fcgi

[Jérémy Lal]

Dear mentors,

I am looking for a sponsor for my package spawn-fcgi.

* Package name: spawn-fcgi
  Version : 1.6.2-2
  Upstream Author : jan kneschke j...@kneschke.de,stefan bühler 
light...@stbuehler.de
* URL : http://redmine.lighttpd.net/projects/spawn-fcgi
* License : incremental
  Section : web

It builds these binary packages:
spawn-fcgi - A fastcgi process spawner

The package appears to be lintian clean.

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/s/spawn-fcgi
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/s/spawn-fcgi/spawn-fcgi_1.6.2-2.dsc

I would be glad if someone uploaded this package for me.

Please note the package uses update-alternatives, so after install one should 
use
 update-alternatives --config spawn-fcgi
to make use of this standalone version, instead of the lighttpd|cherokee one.

Kind regards
 Jérémy Lal


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

why do some libs have pc file, and some don't ?

[Jérémy Lal]

for example, libsoup-dev has /usr/lib/pkgconfig/libsoup-2.4.pc
while liburiparser-dev don't.
how come ?


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

override a package dependency (without rebuilding package)

[Jérémy Lal]

Hi,
is there a way to change a package dependency without rebuilding it ?
For example, gimp2.6 depends on libwebkit-1.0.1, and i want latest 
libwebkit-1.0.2
installed. I don't really care to break that dependency since gimp will work
without libwebkit (although some stuff will be broken, but i don't mind).
Of course i force installed libwebkit-1.0.2, still i don't want aptitude to 
complain
about gimp being broken. And i don't feel like fixing and rebuilding gimp, nor
i want to remove it !

Any way ?

Jérémy Lal.


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

Re: RFS: redmine

[Jérémy Lal]

well, I guess you can try just leaving them all in vendor/plugins/ and
seeing what people say...:)
has anybody replied to your request to join DRE yet?


nope.
but who does on monday :)


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

Re: RFS: redmine

[Jérémy Lal]

They aren't redmine plugins, but rails plugins that redmine requires.
okay, I'll work on those next week and next weekend.

Thanks,
Ryan


Ok, i get it.
indeed there are plugins in vendor/plugins,
but i fear that you can't really put them apart from redmine :
i asked JP Lang (upstream developer) about that, and he answers
most if not all plugins that are in the redmine svn have been
modified and redmine heavily depends on them.

To clear things up, i think we should separate plugins in two sets :
- redmine only plugins : those are not on rubyforge, seems to have
been made by redmine developers.
- packageable plugins : available on rubyforge, there's a good chance some
other rails apps would depend on them.

Anyway, i'm not a rails developer and don't really know how plugins
are used : is it common practice to fork them ?
May be some important plugins are worth a package, maybe some small
ones should be packaged with the app using them, as in the redmine's case.

Regards,

Jérémy Lal





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

Re: RFS: redmine

[Jérémy Lal]

Indeed, i'm going to upload 0.9.0-2 with quite a lot of corrections based on 
your remarks
and those of Jean-Philippe Garcia Ballester.
Regards,
Jérémy Lal


On 11/03/2009 16:25, Ryan Niebur wrote:

also, shouldn't Richard be mentioned as a copyright holder for the
debian packaging? It looks like you based your package off of his..





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

Re: RFS: redmine

[Jérémy Lal]

On 12/03/2009 05:39, Ryan Niebur wrote:

[dropped CC to mentors]

Hello again,

Sorry for the rushed email this morning, I was just leaving but wanted
to give you my input. :)

On Wed, Mar 11, 2009 at 04:12:54PM +0100, Jérémy Lal wrote:

On 11/03/2009 15:54, Ryan Niebur wrote:

Hi Jérémy,

Rather than installing vendor/plugins, all of the plugins should be
packaged. Gunnar Wolf did will_paginate, you can look at that for an
example.

ok, i'm going to have a look



also, if you don't want to package all of them yourself, feel free to ask me to 
do it.
I'd defidently be willing to. :)

for that matter, if you need any help with anything wrt packaging redmine, just 
ask.
I can't sponsor as I am not yet a DD, tho I can help with packaging.
I would also want to comaintain, if you want a comaintainer.

Indeed, i'll be glad.
Especially about the plugins, about which i have really no clue since i never 
used a redmine plugin.


Thanks for restarting the packaging effort on this!
--Ryan

PS: does your package automatically migrate on postinst?

yes

does it allow
multiple side by side redmine installs?

no

Does it use debconf to ask for
the database.yml stuff?

yes

Still haven't looked at it closely, it's been
a long day (err, week). :P


Jérémy Lal



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

RFS: redmine

[Jérémy Lal]

Dear mentors,

I am looking for a sponsor for my package redmine.

* Package name: redmine
  Version : 0.9.0-1
  Upstream Author : Jean-Philippe Lang jp_l...@nospam@yahoo.fr
* URL : http://www.redmine.org
* License : GPL-2
  Section : web

It builds these binary packages:
redmine- flexible project management web application

The package appears to be lintian clean.

The upload would fix these bugs: 478741

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/r/redmine
- Source repository: deb-src http://mentors.debian.net/debian unstable main 
contrib non-free
- dget http://mentors.debian.net/debian/pool/main/r/redmine/redmine_0.9.0-1.dsc

I would be glad if someone uploaded this package for me.

Kind regards
 Jérémy Lal


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

Re: RFS: redmine

[Jérémy Lal]

On 11/03/2009 15:54, Ryan Niebur wrote:

Hi Jérémy,

Rather than installing vendor/plugins, all of the plugins should be
packaged. Gunnar Wolf did will_paginate, you can look at that for an
example.

ok, i'm going to have a look



Also in debian/copyright, what does License: none mean?  Does that
mean that it can't be distributed? It needs a license..

There's also the following lintian output, some of which is ignorable:
I: redmine source: no-complete-debconf-translation
P: redmine source: debian-control-has-unusual-field-spacing line 7
I: redmine source: quilt-patch-missing-description 
00_load_default_data_env.patch
I: redmine source: quilt-patch-missing-description 
01_load_default_data_rescue_already_loaded.patch
I: redmine source: quilt-patch-missing-description 02_production_env.patch
P: redmine: copyright-refers-to-symlink-license usr/share/common-licenses/GPL
P: redmine: no-upstream-changelog
I: redmine: unused-override package-contains-empty-directory 
usr/share/redmine/vendor/plugins/gloc-1.1.0/lang/
I: redmine: unused-override script-not-executable 
./usr/share/redmine/extra/svn/reposman.rb
I: redmine: unused-override script-not-executable 
./usr/share/redmine/extra/svn/svnserve.wrapper

and you are missing a README.source.

i'll correct that



also have you seen[1] and the other responses to Richard's package?

You also might consider joining the Debian Ruby Extras team and seeing
if they can sponsor it for you. They were working with Richard on his
package.

i did not see that message.
i'll consider it indeed.
i contacted Richard who told me he would not have probably enough time to work 
more on the redmine package for
now, so i started upon his work and made sure it was working out of the box.


Thanks,
Ryan

1: 
http://209.85.173.132/search?q=cache:0HVrJjJmA2QJ:www.mail-archive.com/pkg-ruby-extras-maintainers%40lists.alioth.debian.org/msg00324.htmlhl=enct=clnkcd=6gl=us





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