Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it

[Ben Finney]

Howdy all,

Lintian recommends (via tag ‘debian-rules-missing-recommended-target’):

=
N:   Note that the following form is recommended however:
N:   
N: build: build-arch build-indep
N: build-arch: build-stamp
N: build-indep: build-stamp
N: build-stamp:
N:   build here
=

I am building arch-independent and arch-dependent packages from a rules
file. The actions don't need anything other than “dh $@”. (I don't want
to use the “%:” style, since I prefer the ‘.PHONY’ target to be
explicit).

But where should “dh $@” be put? The above information from Lintian
recommends that all the build actions should be in ‘build-stamp’, but
‘dh’ doesn't know about that target and barfs.

-- 
 \ “Facts are stubborn things; and whatever may be our wishes, our |
  `\   inclinations, or the dictates of our passion, they cannot alter |
_o__)the state of facts and evidence.” —John Adams, 1770-12-04 |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k4b5qzz9@benfinney.id.au

Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it

[Kilian Krause]

Hi Ben,

On Tue, 2011-07-26 at 17:10 +1000, Ben Finney wrote:
> Howdy all,
> 
> Lintian recommends (via tag ‘debian-rules-missing-recommended-target’):
> 
> =
> N:   Note that the following form is recommended however:
> N:   
> N: build: build-arch build-indep
> N: build-arch: build-stamp
> N: build-indep: build-stamp
> N: build-stamp:
> N:   build here
> =
> 
> I am building arch-independent and arch-dependent packages from a rules
> file. The actions don't need anything other than “dh $@”. (I don't want
> to use the “%:” style, since I prefer the ‘.PHONY’ target to be
> explicit).
> 
> But where should “dh $@” be put? The above information from Lintian
> recommends that all the build actions should be in ‘build-stamp’, but
> ‘dh’ doesn't know about that target and barfs.

If you're sure that you want to use dh but .PHONY then just put into
your rules something like:

build-indep:
dh $@
build-arch:
dh $@
build: build-arch build-indep

No need for a stamp as dh is already producing stamps internally.

At second thought I'm not too sure what would happen if you'd put %: dh
$@ and also .PHONY into debian/rules. Considering the internal stamps of
dh that might also be an option. 

Just out of curiosity: what are you stuffing into your .PHONY target
that you need to manually control?

-- 
Best regards,
Kilian


signature.asc
Description: This is a digitally signed message part

Re: different version numbers?

[Filippo Rusconi]

Greetings,

On Mon, Jul 25, 2011 at 10:13:56PM -0500, Paul Elliott wrote:

> What is the relationship, if any, between the version number of the source 
> pachage and the version number of a library, which has to do with SONAME.
> 
> What do these have to do with PACKAGE_VERSION in autotools?
> 
> My up stream, has version number associated with his source tarballs,
> that have nothing to do with debian or Linux, because he does not develop
> with Linux in mind. All though he does build a Linux static library.

As library packaging is generally regarded as a difficult task, a very
good guide at

http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

is a recommended reading. That guide contains also very clear
background information on the various version numbering systems
possibly involved.

Best regards,

Filippo

-- 
Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu
Researcher at CNRS and Debian Developer 
Author of ``massXpert'' at http://www.massxpert.org


signature.asc
Description: Digital signature

RFS: mosquitto (new upstream version)

[Roger Light]

Dear mentors,

I am looking for a sponsor for my package "mosquitto". This is an
updated package for a new upstream version. The new version includes
an additional exported symbol in the two libraries. I believe I've
updated the .symbols files correctly, but would appreciate it being
checked.

The package is lintian clean.

Thanks,

Roger

* Package name: mosquitto
 Version : 0.12-1
 Upstream Author : Roger Light 
* URL : http://mosquitto.org/
* License : BSD
 Section : net

It builds these binary packages:
libmosquitto0 - MQTT version 3.1 client library
libmosquitto0-dev - MQTT version 3.1 client library, development files
libmosquittopp0 - MQTT version 3.1 client C++ library
libmosquittopp0-dev - MQTT version 3.1 client C++ library, development files
mosquitto - MQTT version 3.1 compatible message broker
mosquitto-clients - Mosquitto command line clients
python-mosquitto - MQTT version 3.1 client library, python bindings

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/m/mosquitto
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget 
http://mentors.debian.net/debian/pool/main/m/mosquitto/mosquitto_0.12-1.dsc


-- 
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/cah7zdyd3ycfdvs_mipmtc+badyfpquy3t9muy3psyaxca+y...@mail.gmail.com

RE : different version numbers?

[PICCA Frédéric-Emmanuel]

> As library packaging is generally regarded as a difficult task, a very
> good guide at

> http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html

> is a recommended reading. That guide contains also very clear
> background information on the various version numbering systems
> possibly involved.

Yes it is a good introduction, but I could not find an answer to that question:

libX + libX-dev

or

libX + lib-dev


It is not clear to me what is the best practice.

See you

Frederic

--
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/a2a20ec3b8560d408356cac2fc148e5320a4e...@sun-dag1.synchrotron-soleil.fr

Re: RFS: mosquitto (new upstream version)

[Kilian Krause]

Hi Roger,

On Tue, 2011-07-26 at 09:20 +0100, Roger Light wrote:
> I am looking for a sponsor for my package "mosquitto". This is an
> updated package for a new upstream version. The new version includes
> an additional exported symbol in the two libraries. I believe I've
> updated the .symbols files correctly, but would appreciate it being
> checked.
> 
> The package is lintian clean.
> - dget 
> http://mentors.debian.net/debian/pool/main/m/mosquitto/mosquitto_0.12-1.dsc

Thanks for your work.

Your package still has rev 135 of DEP-5 in debian/copyright. That may be
worth updating with the next upload.

The files in debian/ are reported as in the future. You may want to
check your system clock. ;-)

Regarding the symbols: As I see it you're having C++ symbols in
libmosquittopp0. I think it'd make sense to use the c++ feature. See the
list archive of this list for a number of hints and references/best
practice etc.. Other than that no problems I would see there.

Your patches don't have a DEP-3 header making it impossible to tell
whether they have been pushed upstream. I guess upstream would be
interested in at least some of them.

You have debian/pyversions which you might also want to document in
debian/control as XS-Python-Version.

The binaries python-mosquitto, libmosquitto0-dev, libmosquittopp0-dev,
python-mosquitto do not have any arch dependent code AFAICT yet they are
marked as arch=any. Do you see any problem making them arch=all?

 
Anyway, built, signed, uploaded.

Cheers.

-- 
Best regards,
Kilian


signature.asc
Description: This is a digitally signed message part

Re: RE : different version numbers?

[Filippo Rusconi]

Greetings,

On Tue, Jul 26, 2011 at 08:26:19AM +, PICCA Frédéric-Emmanuel wrote:
> > As library packaging is generally regarded as a difficult task, a very
> > good guide at
> 
> > http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html
> 
> > is a recommended reading. That guide contains also very clear
> > background information on the various version numbering systems
> > possibly involved.
> 
> Yes it is a good introduction, but I could not find an answer to
> that question:
> 
> libX + libX-dev
> 
> or
> 
> libX + lib-dev
> 
> 
> It is not clear to me what is the best practice.

It is my understanding that both are possible, depending on what the
packager wishes to actually package. The most general case is that the
packager only wants to package the developement files for the last
version of the library. In that case, lib-dev is fine, because each
time that package gets installed it "overwrites" the files shipped
with the previous version.

It might happen, however, that the packager wishes to support the
developement of various versions of the library. Because two same
files can not belong to two different simultaneousy installable
packages (that would be a conflict), then it is required that the
developement files for lib1 be packaged in lib1-dev and the
development files for lib2 be packaged in lib2-dev.

Hope this helps (and is actually a correct understanding of the -dev
package naming/numbering process),

Kind regards,
Filippo

-- 
Filippo Rusconi, PhD - public crypto key C78F687C @ pgp.mit.edu
Researcher at CNRS and Debian Developer 
Author of ``massXpert'' at http://www.massxpert.org


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110726092317.GB2834@biophypfr

Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it

[Jakub Wilk]

* Kilian Krause , 2011-07-26, 09:18:
I'm not too sure what would happen if you'd put %: dh $@ and also 
.PHONY into debian/rules. Considering the internal stamps of dh that 
might also be an option.


% is supposed to be used for file targets only (though it's common to 
abuse it for other purposed these days). It won't work with .PHONY.


--
Jakub Wilk


signature.asc
Description: Digital signature

Re: RFS: mosquitto (new upstream version)

[Jakub Wilk]

* Kilian Krause , 2011-07-26, 11:33:
You have debian/pyversions which you might also want to document in 
debian/control as XS-Python-Version.


No. Use either debian/pyversions or XS-Python-Version, not both.

(Just to be clear: XS-Python-Version is not only for documentation 
purposes, it's actually used by some packaging helpers.)


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110726101000.ga7...@jwilk.net

What is needed to upload a package as DM?

[Satoru KURASHIKI]

hi,

I'm trying to upload a package to incoming queue as DM, but it fails.

> Reject Reasons:
> lur...@gmail.com is not in Maintainer or Uploaders of source package yaskkserv

I'm sure that what tutorial says
(http://wiki.debian.org/DebianMaintainer/Tutorial):

1) DMUA: yes
2) my key is in debian-maintainer keyring
3) the old package has my UID in maintainer filed

Please teach me what's needed for uploading.

--
$ apt-get source yaskkserv
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'yaskkserv' packaging is maintained in the 'Git' version
control system at:
git://git.debian.org/users/lurdan-guest/yaskkserv.git
Need to get 85.1 kB of source archives.
Get:1 http://ftp.jp.debian.org/debian/ sid/main yaskkserv 0.4.0-5 (dsc) [1251 B]
Get:2 http://ftp.jp.debian.org/debian/ sid/main yaskkserv 0.4.0-5
(tar) [73.0 kB]
Get:3 http://ftp.jp.debian.org/debian/ sid/main yaskkserv 0.4.0-5
(diff) [10.9 kB]
Fetched 85.1 kB in 0s (474 kB/s)
dpkg-source: info: extracting yaskkserv in yaskkserv-0.4.0
dpkg-source: info: unpacking yaskkserv_0.4.0.orig.tar.gz
dpkg-source: info: unpacking yaskkserv_0.4.0-5.debian.tar.gz

$ egrep '(Allowed|KURA)' yaskkserv_0.4.0-5.dsc
Maintainer: KURASHIKI Satoru 
Dm-Upload-Allowed: yes

$ gpg --list-keys 40A2F113
pub   4096R/40A2F113 2009-09-10
uid  KURASHIKI Satoru 
uid  KURASHIKI Satoru 
sub   4096R/D7B08969 2009-09-10

$ gpg --keyring /usr/share/keyrings/debian-maintainers.gpg
--no-default-keyring --list-keys 40A2F113
pub   4096R/40A2F113 2009-09-10
uid  KURASHIKI Satoru 
uid  KURASHIKI Satoru 
sub   4096R/D7B08969 2009-09-10

$ gpg --verify yaskkserv_0.4.0-6.dsc
gpg: Signature made Tue Jul 26 08:46:30 2011 JST using RSA key ID 40A2F113
gpg: Good signature from "KURASHIKI Satoru "
gpg: aka "KURASHIKI Satoru "
--

regards,
-- 
KURASHIKI Satoru


-- 
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/CAM0xXk-MrnA5bhUFvhCbKnZ=rgp+kqkpfujq48js++n5tey...@mail.gmail.com

Re: What is needed to upload a package as DM?

[Ryan Kavanagh]

Hi,

Hi, On Tue, Jul 26, 2011 at 08:30:03PM +0900, Satoru KURASHIKI wrote:
> I'm trying to upload a package to incoming queue as DM, but it fails.
> 
> > Reject Reasons: lur...@gmail.com is not in Maintainer or Uploaders
> > of source package yaskkserv

Have you tried replying to the email and asking ftp-masters what went
wrong? I had a similar issue last week and they told me that the issue
was caused by a space before the comma in the Uploaders field of a
previous upload. They should be able to help you out.

Kind regards,
Ryan


signature.asc
Description: Digital signature

RFS: hashalot

[Adam Borowski]

Hi!

I'd like to ask for a sponsor for an update to hashalot (a tool needed by
cryptsetup, obsolete nowadays but some folks still use it).

There's just one minor documentation fix, but I also nuked the whole
debian/rules replacing it with oh-so-long dh two liner.  The copyright is in
DEP-5 format as well.

dget http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc

Readable list of changes:
git://gitorious.org/hashalot/hashalot.git
https://gitorious.org/hashalot/hashalot/commits/master

-- 
1KB // Yo momma uses IPv4!


-- 
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/20110726113254.ga2...@angband.pl

Re: What is needed to upload a package as DM?

[David Kalnischkies]

On Tue, Jul 26, 2011 at 13:30, Satoru KURASHIKI  wrote:
> $ egrep '(Allowed|KURA)' yaskkserv_0.4.0-5.dsc
> Maintainer: KURASHIKI Satoru 
> Dm-Upload-Allowed: yes

Aren't fields in "Deb 822" format case-sensitive?
(They are at least if it comes to Packages files and co.)


Best regards

David Kalnischkies


-- 
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/CAAZ6_fCPTEAgH4_ygL4=c+JaY-1DcYipe=mylg7kizqmm2w...@mail.gmail.com

Re: RFS: eviacam

[Cesar Mauri]

Hi,


As promised, here is my review.


Thanks Paul for your thorough review! I (hopefully) managed to fix all 
the issues you pointed out. I uploaded an updated version to the mentors 
site which also appears to be lintian clean.


I hope that all these improvement will help to find an sponsor for eviacam.

More details are provided below.


I am looking for a sponsor for my package "eviacam".

* Package name: eviacam
   Version : 1.5.2
   Upstream Author : Cesar Mauri
* URL : http://viacam.org
* License : GPL


Version 3 or higher according to your copyright file.


Right.


   Section : x11

It builds these binary packages:
eviacam- A cross platform webcam based mouse emulator


For Debian it is not relevant that this software is cross platform. Also
the synopsis should not start with "A". I would suggest:
eviacom - webcam based mouse emulator


Updated debian/control


I was able to fix most Lintian errors and warnings, but I feel that to
fix the remaining warnings I would need some help.

W: eviacam source: non-native-package-with-native-version


This should be solved by adding a DEBIAN version to the version number
in your changelog. I.e. 1.5.2-1.


Done.


W: eviacam source: empty-debian-diff


This is because your upstream package already includes the debian
directory and there are no changes to be put in the diff and you are
using source 1.0 (implicit). If you want to continue also distributing
the debian directory in the upstream release I strongly suggest using
source version 3.0 (quilt) to avoid problems with NMU's. See also
dpkg-source(1).


OK. Switched to source version 3.0.


Further, my comments on your debian/* files:
changelog
- As mentioned above, include the Debian version in the first line
- Close your ITP bug in the first entry like so:
 * Initial release (closes: #634840 )
- Please update the time stamp to something more appropriate


Done.


changelog.in
- Not sure if this will be useful in the future. You will most likely
   be editing the changelog manually (with the help of dch)


changelog.in removed and left changelog alone.


compat
- I believe ideas about which version should be used for new packages
   varies from sponsor to sponsor, but 7 or 8 is most common nowadays. Of
   course this influences your build dependencies.


Set to 7


control
- Your standards version is very old. The current version is 3.9.2.
   Check what you need to change, and update accordingly.


Updated standards version to 3.9.1


- Any reason for not having priority "optional"?


None. Set priority from extra to optional.


- Consider putting your Debian packaging in a VCS and add the
   appropriate tags


Can you provide additional details about this?


- I don't think it is appropriate to mention the website in the
   description. The "Homepage" field is made for this purpose.


Fixed.


- As mentioned above, improve the short description


Done.


- I am no native speaker but I believe "a software" is rather strange.
   If you want to improve the description you could ask on
   debian-l10n-engl...@lists.debian.org


Changed "software" by "program"


- I don't have understanding of wx2, but do your recommends work, i.e.
   does the package find the right version, depending on the development
   package used in the build-depends?


Removed old dependency to wx2.6 which also generated the compilation 
error you point below.



copyright
- Not mandatory, but quite some sponsors want it: consider to change
   your copyright file to the DEP5 format [1].
- Please link to the versioned GPL in common-licenses.
- You did not include the copyright information of all the files. The
   copyright file MUST list all the copyright holders and all licenses
   of ALL files in your project.


Done


dirs
- I don't think you need this with this content.


Done. File removed.


docs
- NEWS is empty, don't install it.


Old (manually maintained in upstream) ChangeLog file renamed as NEWS 
file and added automatic ChangeLog generation from git



- Why install README.ca and not README.es?


Fixed. Now installs both.


rules
- I find the clean target a little strange, why copy the config.sub and
   config.guess there?


Removed.


- Clean up commented lines


Done.


- Not sure, but I think quite some options in your ./configure line are
   added by the builder automatically.


Not sure also.


Further comments:

Please include a watch file.


Included.


Your package is newer than the latest upstream release. As you are
upstream yourself, why didn't you create this new release yet?


Just in case the debianization triggers some changes in upstream.


The package FTBFS (fails to build from sourse) with the following error:
configure: error: Couldn't find linux/videodev.h nor libv4l1-videodev.h
Adding libv4l-dev to the build-depends helps to start building the
package. It would help to build your own packages in a clean environment
to check against such problems (and buil

Re: RFS: hashalot

[Jakub Wilk]

* Adam Borowski , 2011-07-26, 13:32:
I'd like to ask for a sponsor for an update to hashalot (a tool needed 
by cryptsetup, obsolete nowadays but some folks still use it).


There's just one minor documentation fix, but I also nuked the whole
debian/rules replacing it with oh-so-long dh two liner.


Did you verify that your new d/rules does everything that the old one 
did?



http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc


Rather than "debhelper (>= 8.0.0)" I'd simply use "debhelper (>= 8)". 
That way the build-dependency will be satisfied by debhelper 
8.0.0~bpo50+2, which is currently in backports/lenny.


You bumped debian/compat, bumped standards version, added Homepage field 
- none of these things are documented in the changelog.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110726123051.ga8...@jwilk.net

[done] RFS: libbs2b

[Eugene V. Lyubimkin]

Hi Andrew,

On 2011-07-25 13:48, Andrew Gainer wrote:
> Alright, thanks for the clarification. I've bumped each package to
> *-2, added changelog entries, and uploaded again.

I just uploaded it to the Debian's NEW queue. Thank you for the
contribution to Debian.

One minor detail (for the next upload) I didn't notice before: there is
no substitution variable '{misc:Pre-Depends}', so you can remove that
Pre-Depends line of libbs2b0 altogether.

You can send requests regarding bs2b packages directly to me for next
uploads.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


-- 
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/20110726123540.GA28201@r500-debian

Re: RFS: hashalot

[Adam Borowski]

On Tue, Jul 26, 2011 at 02:30:51PM +0200, Jakub Wilk wrote:
> * Adam Borowski , 2011-07-26, 13:32:
> >I'd like to ask for a sponsor for an update to hashalot (a tool
> >needed by cryptsetup, obsolete nowadays but some folks still use
> >it).
> >
> >There's just one minor documentation fix, but I also nuked the whole
> >debian/rules replacing it with oh-so-long dh two liner.
> 
> Did you verify that your new d/rules does everything that the old
> one did?

Yes, actually it does a bit more: the old one failed to install the upstream
changelog.

I just checked that it cross-builds correctly too, dh is smart enough to
disable the testsuite on cross builds like the old d/rules did.
 
> >http://mentors.debian.net/debian/pool/main/h/hashalot/hashalot_0.3-6.dsc
> 
> Rather than "debhelper (>= 8.0.0)" I'd simply use "debhelper (>=
> 8)". That way the build-dependency will be satisfied by debhelper
> 8.0.0~bpo50+2, which is currently in backports/lenny.

Good point, did it and re-uploaded to mentors (same URL).

> You bumped debian/compat, bumped standards version, added Homepage
> field - none of these things are documented in the changelog.

I do believe that such entries are spam that is counterproductive and hides
real changes:
* debian/compat is implied by migrating to dh
* updating standards is something every single sane sourceful upload does
  (lintian screaming at people helps here)
* Homepage is just moving around stuff that used to be in debian/copyright

Thus, I'd prefer to avoid useless entries.  Of course, if giving up on this
cosmetic issue would let me mooch an upload from you, I'll concede.

Meow!
-- 
1KB // Yo momma uses IPv4!


-- 
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/20110726132414.ga4...@angband.pl

Re: jampal_02.01.05-1_amd64.changes REJECTED

[Peter Bennett]

Hi Torsten

The looks/*.jar files are not distributed in the package. They are
present in the source because I do
distribute them with the Windows version of jampal.
Jampal runs fine without them, and some of them are available as
separate packages in Debian, so the
user can install them if he wants to.
What do I need to do about this? Do I need a repackaged source?

Peter

On 7/26/2011 9:30 AM, Torsten Werner wrote:
> Hi,
>
> there is no source code for the binaries looks/*.jar.
>
> Torsten
>
>
>
> ===
>
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
>
>


-- 
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/4e2ed018.9090...@comcast.net

Re: jampal_02.01.05-1_amd64.changes REJECTED

[Torsten Werner]

Hi Peter,

Am 26.07.2011 16:32, schrieb Peter Bennett:
> The looks/*.jar files are not distributed in the package. They are
> present in the source because I do
> distribute them with the Windows version of jampal.
> Jampal runs fine without them, and some of them are available as
> separate packages in Debian, so the
> user can install them if he wants to.
> What do I need to do about this? Do I need a repackaged source?

yes, that would be an option.

Torsten


-- 
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/4e2edfa6.30...@debian.org

Re: RFS: hashalot

[Jakub Wilk]

* Adam Borowski , 2011-07-26, 15:24:
I'd like to ask for a sponsor for an update to hashalot (a tool 
needed by cryptsetup, obsolete nowadays but some folks still use it).


There's just one minor documentation fix, but I also nuked the whole 
debian/rules replacing it with oh-so-long dh two liner.


Did you verify that your new d/rules does everything that the old one 
did?


Yes, actually it does a bit more: the old one failed to install the 
upstream changelog.


FWIW, that's because of bumping debheleper compat to 7.

I just checked that it cross-builds correctly too, dh is smart enough 
to disable the testsuite on cross builds like the old d/rules did.


What raised my suspicion was that that the old d/rules had:

| ifneq "$(wildcard /usr/share/misc/config.sub)" ""
| cp -f /usr/share/misc/config.sub config.sub
| endif
| ifneq "$(wildcard /usr/share/misc/config.guess)" ""
| cp -f /usr/share/misc/config.guess config.guess
| endif

dh certainly doesn't do anything like that. Granted, this code was 
silly[0] and, in this particular case, completely unnecessary[1], but 
I'd prefer to learn about such changes from the changelog.



You bumped debian/compat, bumped standards version, added Homepage
field - none of these things are documented in the changelog.
I do believe that such entries are spam that is counterproductive and 
hides real changes:

* debian/compat is implied by migrating to dh


Er, no. These are orthogonal things.

* updating standards is something every single sane sourceful upload 
does (lintian screaming at people helps here)


Did upgrading to the latest version require any changes in packaging? 
(I normally don't ask this question, as the answer is in the 
changelog...)


* Homepage is just moving around stuff that used to be in 
debian/copyright


This is actual improvement to your binary package; now I can type 
"dhomepage hashalot" and the upstream homepage (or rather "homepage") 
pops up.



Thus, I'd prefer to avoid useless entries.


I do insist that my sponsorees document all these little things, for 
various reasons:


1) It makes life easier for me, because I don't have to judge if 
something is "important enough" or not to document. It's also easier for 
sponsorees, since they don't have to guess if I will be happy with 
omitting a thing from d/changelog or not.


2) I try to teach my sponsorees to read debdiffs before requesting 
sponsoring and I consider complete changelog a proof that the maintainer 
actually did it. (My success in that area is limited so far; I often 
find gaps, not so minor as in this particular case... but I'm not giving 
up. :P)


3) I hate when changelog diverges from reality, which IME happens way to 
often. For example, the last item in your changelog mentions S-V is 
"Policy version 3.7.2 (no changes needed)", which has nothing to do with 
what actually is in d/control.


4) There are other reasons, but I don't have time to write them out. :P


A few more things:

hashalot.c has inconsistent indentation: sometimes tabs and sometimes 
spaces are used. At least one such inconsistency was introduced by 
debian diff. (Of course, it's nothing important, just saying...)


Quoting DEP-5: "if [remaining lines of the License field are] left blank 
here, the file must include a stand-alone License paragraph matching 
each license short name listed on the first line (see the Standalone 
License Paragraph section)." All but one of your files paragraph violate 
this requirement.


I wonder about the license of sha512.* files. The comment inside them 
says "Redistribution of this file is permitted under the GNU Public 
License." Could you clarify with the copyright holder if he in fact 
meant GNU *General* Public License?



[0] One should either update config.{sub,guess} unconditionally or not 
all.


[1] The configure script doesn't use config.{sub,guess} at all, and 
neither they are shipped in the upstream tarball.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110726162823.ga4...@jwilk.net

Re: jampal_02.01.05-1_amd64.changes REJECTED

[Kilian Krause]

Hi Peter,

On Tue, Jul 26, 2011 at 05:39:18PM +0200, Torsten Werner wrote:
> Am 26.07.2011 16:32, schrieb Peter Bennett:
> > The looks/*.jar files are not distributed in the package. They are
> > present in the source because I do
> > distribute them with the Windows version of jampal.
> > Jampal runs fine without them, and some of them are available as
> > separate packages in Debian, so the
> > user can install them if he wants to.
> > What do I need to do about this? Do I need a repackaged source?
> 
> yes, that would be an option.

I guess that would be one preferred method. Or as you're upstream yourself
you can as well leave the compiled *.jar out of any release tarball and
compile them as part of the windows build process. Alternatively you can
ship them in the *.zip for Windows and leave them excluded in the *.tar.gz
for Linux.

Which one you prefer is up to you. 

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: hashalot

[Kilian Krause]

Jakub,

On Tue, Jul 26, 2011 at 06:28:23PM +0200, Jakub Wilk wrote:
> * Adam Borowski , 2011-07-26, 15:24:
> >>>I'd like to ask for a sponsor for an update to hashalot (a
> >>>tool needed by cryptsetup, obsolete nowadays but some folks
> >>>still use it).
> >>>
> >>>There's just one minor documentation fix, but I also nuked the
> >>>whole debian/rules replacing it with oh-so-long dh two liner.
> >>
> >>Did you verify that your new d/rules does everything that the
> >>old one did?
> >
> >Yes, actually it does a bit more: the old one failed to install
> >the upstream changelog.
> 
> FWIW, that's because of bumping debheleper compat to 7.
> 
> >I just checked that it cross-builds correctly too, dh is smart
> >enough to disable the testsuite on cross builds like the old
> >d/rules did.
> 
> What raised my suspicion was that that the old d/rules had:
> 
> | ifneq "$(wildcard /usr/share/misc/config.sub)" ""
> | cp -f /usr/share/misc/config.sub config.sub
> | endif
> | ifneq "$(wildcard /usr/share/misc/config.guess)" ""
> | cp -f /usr/share/misc/config.guess config.guess
> | endif
> 
> dh certainly doesn't do anything like that. Granted, this code was
> silly[0] and, in this particular case, completely unnecessary[1],
> but I'd prefer to learn about such changes from the changelog.

On the contrary! dh can very well do such things! But it's required to pass
--with autotools_dev as argument (see man dh for more detail).

Regarding the rest I'm perfectly with you that all intended changes are to
be documented in debian/changelog even if they're abbreviated in a form like
"bump all of debian/compat and Build-Depends and debian/copyright to latest
standards" or something like this. But it needs to be clear that any change
a DD can find in the debdiff is valid and intentionally put there.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: eviacam

[Kilian Krause]

Hi César,

On Tue, Jul 26, 2011 at 02:30:24PM +0200, Cesar Mauri wrote:
[...]
> >control
> >- Your standards version is very old. The current version is 3.9.2.
> >   Check what you need to change, and update accordingly.
> 
> Updated standards version to 3.9.1

Without futher review of the actual package: Why not to 3.9.2?


[...]
> >- Consider putting your Debian packaging in a VCS and add the
> >   appropriate tags
> 
> Can you provide additional details about this?

The VCS (version control system) for the Debian packaging would be the Svn,
Git, Bzr or Hg URI pointing to where you track your Debian changes. Commonly
alioth.debian.org is a good starting point if you've nowhere else that's
already publically offering your VCS tree.

[...]
> >rules
> >- I find the clean target a little strange, why copy the config.sub and
> >   config.guess there?
> 
> Removed.

I hope you changed that to autotools-dev use. Usually it's a sensible
default to use autotools-dev (e.g. dh --with autotools_dev) if your package
does use autotools.

[...]
> >- Not sure, but I think quite some options in your ./configure line are
> >   added by the builder automatically.
> 
> Not sure also.

See /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm for exact
details.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: jampal_02.01.05-1_amd64.changes REJECTED

[Peter Bennett]

Thanks Kilian

I will create a repackaged source with a new version number 02.01.05-2,
with the "looks" directory excluded.
I will add a get-orig-source target that creates the repackaged source,
and try to conform with Debian developers Reference (6.7.8.2 Repackaged
upstream source).
At this time I will not change the upstream source.

Peter


On 7/26/2011 12:29 PM, Kilian Krause wrote:
> Hi Peter,
>
> On Tue, Jul 26, 2011 at 05:39:18PM +0200, Torsten Werner wrote:
>> Am 26.07.2011 16:32, schrieb Peter Bennett:
>>> The looks/*.jar files are not distributed in the package. They are
>>> present in the source because I do
>>> distribute them with the Windows version of jampal.
>>> Jampal runs fine without them, and some of them are available as
>>> separate packages in Debian, so the
>>> user can install them if he wants to.
>>> What do I need to do about this? Do I need a repackaged source?
>> yes, that would be an option.
> I guess that would be one preferred method. Or as you're upstream yourself
> you can as well leave the compiled *.jar out of any release tarball and
> compile them as part of the windows build process. Alternatively you can
> ship them in the *.zip for Windows and leave them excluded in the *.tar.gz
> for Linux.
>
> Which one you prefer is up to you. 
>


-- 
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/4e2efa78.7000...@comcast.net

Re: jampal_02.01.05-1_amd64.changes REJECTED

[Kilian Krause]

Hi Peter,

On Tue, Jul 26, 2011 at 01:33:44PM -0400, Peter Bennett wrote:
> Thanks Kilian
> 
> I will create a repackaged source with a new version number 02.01.05-2,
> with the "looks" directory excluded.
> I will add a get-orig-source target that creates the repackaged source,
> and try to conform with Debian developers Reference (6.7.8.2 Repackaged
> upstream source).
> At this time I will not change the upstream source.

please use 02.01.05~dfsg-1 in that case. Meaning your repackaged tarball
should have an upstream version of 02.01.05~dfsg. If you feel extra caution
for new repackaging mimic should already be added use 02.01.05~dfsg1-1.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Please try expo.debian.net -- a replacement for mentors.debian.net

[Asheesh Laroia]

Hi all people on debian-mentors,

Debexpo is a replacement for http://mentors.debian.net/. I hereby request 
testers! It is of "beta" quality -- I think it works fully and has enough 
features to replace mentors.debian.net.


It has the following improvements over http://mentors.debian.net/ :

* Maintainable code base
* More color on the front page
* Publicly-shown lintian results

I have been spending the past couple of days at Debconf fixing up the code 
and the deployment. I'm hereby asking for testing and feedback:


* Please try uploading a package and tell me if it works
  (especially tell me if it fails!).

* Please tell me if there are features we need before it can replace
  mentors.debian.net.

Frankly, I think it's ready as-is! Go to http://expo.debian.net/ to try 
it.


My goal with this debexpo work is to get the app and the deployment into a 
usable, documented state so it can replace mentors.debian.net. Then I will 
shift into the background and do only patch review and documentation 
writing.


Anyone interested in working on Debexpo, a Python + Pyons web app, should 
grab the source code. Some fixes require changing only the templates, and 
I promise to review your patches quickly (within four days, tops).


Bug tracker: 
https://alioth.debian.org/tracker/index.php?group_id=100127&atid=413115


(You can get the latest deployed source from git://expo.debian.net/live . 
I will push that to Alioth once I sort out some confusion with my SSH 
key.)


-- Asheesh.

P.S. There is no known way to change the "Needs a sponsor" field. Just 
delete the package if you don't need a sponsor, for now.


P.P.S. Any bugs that can be fixed by just editing the templates, I hope to 
see people submitting patches for!



--
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/alpine.deb.2.00.1107261224050.6...@rose.makesad.us

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Kilian Krause]

Hi Asheesh,

On Tue, Jul 26, 2011 at 01:55:00PM -0400, Asheesh Laroia wrote:
> Debexpo is a replacement for http://mentors.debian.net/. I hereby
> request testers! It is of "beta" quality -- I think it works fully
> and has enough features to replace mentors.debian.net.

that's great news!

I think you saw already at http://expo.debian.net/package/trafficserver:
sh: uscan: command not found

Looks like there's a path missing for your uscan test.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 26.07.2011 20:17, Kilian Krause wrote:
> I think you saw already at http://expo.debian.net/package/trafficserver:
> sh: uscan: command not found
> 
> Looks like there's a path missing for your uscan test.

This was fixed already, as far as I can tell. I think Asheesh just
forgot to mention this (or I could just re-upload the package). By the
way: Those packages are /not/ seeking sponsors, they are proof of concepts.

- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOLwaYAAoJEMcrUe6dgPNt8CQP/3MRCGM6iG5isxnDS/QgKY//
B0G3CqxgAwdkI6ogr9MNxUhCYURPPL8cIlIFMeUfPGqd/UjqH2bjM4pQuZH5BdN5
5vI1kz/Jf66Cblns9fj0pm2qS49dbFS6XIQyLuvDcza07SvDNPORGMsUcfHC2FB7
x+a8Gj0iKTI9fpqmdxlZL5GxtVXhITmZI0S1s/XXy1sfkZz4676w1yweboKIhqDA
a4e/N+8b9SXTQ4ICqGZWg++JjrriUX8lUqxVlfAR3jXnlRBNNcZVhoFZ541SNbfD
qwypD7DKvT1Fo8REh4WAn44nG74xtG0tfBzLorOPoJD+Ui6m64elBr8NlN0UeXNa
FAPyZSUMNsPt5jCyqseGHGHvR1aG5pOS/lFOyBx442nFG0TY/29+iSopxxPoLNCm
m7kmVPqgp9D37ktQ/7RhEoLtK+EKDzjyspebLiPADC85XD7Pdcw9IjxJh2iA0V6p
mwes9NmTyA5dCcquCoDLP9UVt6Qgt9oqPVX5uLR0lI1eL5Y20k/DO0F6kHYGvnIF
kfslgwmQAgkpGdEctwgnX3vhTC/ftSHE4p2dgum/+KkVQD1btckvDcyL+AIuOdFR
8aduPiGZbw7eAaH/fqA8ID7a8ab03tUVZ8L19IMIyAEV/TnoSq5vpsZGVbQvoHBR
OmPWGcWPOAaE45Wk6TOO
=yn+G
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e2f0699.3010...@toell.net

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Julien Valroff]

Hi Asheesh,

Le mardi 26 juil. 2011 à 19:55:00 (+0200 CEST), Asheesh Laroia a écrit :
> Hi all people on debian-mentors,
> 
> Debexpo is a replacement for http://mentors.debian.net/. I hereby
> request testers! It is of "beta" quality -- I think it works fully
> and has enough features to replace mentors.debian.net.

Thanks for working on this.

Looks very promising!

On the package details page, it would be great if URL's could be clickable
(Homepage, VCS-Browser). Also Lintian tags could be linked to their
description on lintian.d.o

I also think it is not necessary to show missing optional fields (eg.
various VCS-* fields).

It may also help to know whether the package is already in Debian (with
a link to packages.d.o in order to know more about the history of the
uploads) or if it is a new package.

As from the maintainer "personal package archive" page, I understand that
binary packages will be made publicly available? The page states 'deb ...'
entries in sources.list. If so, I think it is a bad idea. Only source
packages should be available to avoid people use this as a standard
repository (I remember it used to be the case for mentors.d.n).

Keep up the good work.

Cheers,
Julien

-- 
  .''`.   Julien Valroff ~  ~ 
 : :'  :  Debian Developer & Free software contributor
 `. `'`   http://www.kirya.net/
   `- 4096R/ E1D8 5796 8214 4687 E416  948C 859F EF67 258E 26B1


-- 
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/20110726183736.gg7...@kirya.net

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Julien,

On 26.07.2011 20:37, Julien Valroff wrote:
> On the package details page, it would be great if URL's could be clickable
> (Homepage, VCS-Browser). Also Lintian tags could be linked to their
> description on lintian.d.o

This issue is already tracked in the Alioth bug tracker. I agree, it
would be beneficial to have Lintian tags being referencing to
lintian.d.o, but this may be blocked by #631763.


- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOLwpGAAoJEMcrUe6dgPNtnooP/1B8v6XMIBuknvJdJdNv6xTd
idGQOd2KeTAqxJL34ZrwuLhysKrFdrMEoQv3XuA939MdokdlkAd7YnLgEfFJ9HjE
WRh8WQIwY0P+DDzk4/dHe2do3gOTerHTR6NU2/iI0JdlZmBRnPJ5mrLDFK1ZnXh1
ayV29QR1UCYXtNwY8qwRWb7tseIIPcjMMzZGzum2Gc16Pqds91BjaltRSW8dqUFr
7zh+Ln0yVNp+zAD6PXykAjXU/bnWVJ8ELw3dan6Wz33i8QsKWvKsREh1kgVQ/zbC
HdTacnv6PL4ZMPgRu9u/PGBNDF9cC5rB96pfR59U9Y7vUhg9uMppFjolxjYPcPsu
lfHKFwjLcJyRtT+uDDbF5Ks5uRdFnn4LgKbOow6tPSu/Se6ZywsHt11+cRKyUkMS
HcF7xSFMRneWy4mZyJtGtk/TaP6VUWxdYXWT18zsUmXrowSU1aL3YIGTbfEPztrj
FPdjN3JOB1jFR7lFxwMMF3i1EdhoA7PSgR8hWbH25SXlb7Mrn/97PGGnsLxgoIlC
oLopRwAN+YDl5YKc/0lqHwilyrNTRp1k14peWFIo71wxwsFc7rjBm0Ty4zr3gQ0Z
xCnZuNJwCpvOOohEgZfLi30eBj12Sg4r0PpxI51vq64zbicclCBUsqFSBYL7pfXl
v1HvoPy4wo7ElYVCy5Gk
=Epr3
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e2f0a47.4030...@toell.net

Re: RFS: espctag

[Jérôme SONRIER]

Le lundi 25 juillet 2011, Kilian Krause a écrit :
> having already signed off the according lib, I've also built, signed
> and uploaded this package. ;-)

Hi,

Thank you.


-- 
Jérôme SONRIER


signature.asc
Description: This is a digitally signed message part.

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Kilian Krause]

Hi,

On Tue, Jul 26, 2011 at 08:37:36PM +0200, Julien Valroff wrote:
> It may also help to know whether the package is already in Debian (with
> a link to packages.d.o in order to know more about the history of the
> uploads) or if it is a new package.

packages.qa.d.o please. 

And while we're writing the wishlist, please also inclulde:
* output from lintian -IX --pedantic
* changelog entry with colorized RC-bugs that are fixed
* whether or not the orig.tar.gz is original
* if there is a previous version in debian, debdiff to the source

basically more similar to http://ftp-master.debian.org/new.html

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Asheesh Laroia]

On Tue, 26 Jul 2011, Julien Valroff wrote:


Hi Asheesh,

Le mardi 26 juil. 2011 à 19:55:00 (+0200 CEST), Asheesh Laroia a écrit :

Hi all people on debian-mentors,

Debexpo is a replacement for http://mentors.debian.net/. I hereby
request testers! It is of "beta" quality -- I think it works fully
and has enough features to replace mentors.debian.net.


Thanks for working on this.

Looks very promising!


(-:

I am grateful to all the people who put energy into this: Signum 
(Christopher Haas) and Jonny Lamb, first, who started the project. Andrey 
(wRAR), who helped bring the project back to life about nine months ago. 
Christine Spang, for providing the hosting. Arno Toell and Karl Goetz, for 
urging me on in #debexpo, filing bugs, and giving feedback. Jan Dittberner 
and Ondrej Certik and Paul Wise and Serafeim Zanikolas, for the code they 
committed and pushed to git. Signum again, for his patience with me over 
the past year.


It's a lot of names, and it's been a lot of work for all those people!

My role here, as I will try to repeat and make clear, is to provide our 
community with something that we can use, and that we can improve. My role 
will not be to build any more features, but instead focus entirely on 
making sure that community maintenance is possible.


I will be quite happy to deploy patches written by others. The policy for 
SSH access to the deployment is that anyone who successfully gets a patch 
merged may have SSH access to the deployment.


To encourage that to happen faster, I'm going to reply to many of these 
requests with the information it would take to write a fix. I won't 
myself. If the community wants it fixed, someone other than me is going to 
have to fix it. I'll try to rank things in difficulty 0 (stringfix) to 5 
(a full day's work).


Some of the more difficult or sysadmin-esque issues I might handle myself, 
but in general the above is what I'll do.


On the package details page, it would be great if URL's could be 
clickable (Homepage, VCS-Browser).


Difficulty: 1

To fix this, you'll probably want to add a 'linkify' string processor to 
the template system.


Steps to fix:

Step 0: Do a 'git clone' of debexpo and set up a dev environment

Step 1: Add an htmlify function to the app

You can copy-paste this one, so long as you cite it, and rtain the Apache 
License.


https://github.com/facebook/tornado/blob/master/tornado/escape.py

Step 2: Change the templates to use that htmlify function

You can be inspired by 
http://188.40.52.54/cgit/anzu/commit/demos/chat?h=performance&id=f732f98063f8a0bf9f7e331876964bedbbdc8462


Step 3: Make sure it works

In the near future I will get the expo-dev.debian.net site working, but 
until then, test locally.


Step 4: Submit a patch

'git format-patch origin/master' will generate some files. Email them to 
the debexpo list (debexpo-devel at lists.alioth.org)



Also Lintian tags could be linked to their description on lintian.d.o


Difficulty: 0.5 (super easy; requires writing code)

Step 0: Do a git clone

Step 1: Edit debexpo/plugins/lintian.py

The call to:

self.failed(outcome, output, severity)

(currently line 70) is what passes the information to be logged into the 
database, where the package page will pull it out. 'output' is the line of 
text from lintian.


Change it so that outcome is an HTML string that contains the link.


I also think it is not necessary to show missing optional fields (eg.
various VCS-* fields).


Difficulty: 0 (super easy)

Step 0: Get a git clone

Step 1: Edit debexpo/plugins/controlfields.py

This line:

self.info('%s-is-not-present' % item.lower(), None)

Just remove it.

Step 2. Submit a patch to the mailing list


It may also help to know whether the package is already in Debian (with
a link to packages.d.o in order to know more about the history of the
uploads) or if it is a new package.


That would be great!

Difficulty: 1.5 (requires writing a plugin, and understanding how plugins 
are written -- but they are quite easy)


Step 0: Get a git clone

Step 1: Read a sample plugin

Take a look at debexpo/plugins/ubuntuversion.py

That's a good, simple quality-assurance plugin.

Step 2: Write a new plugin to check if the package is in Debian

You'd probably want to do a urllib.urlopen() on some URL -- 
packages.debian.org/sid/ + packagename, maybe -- and check its value. If 
the package is in Debian, generate a string that contains a link to the 
package page.


You pass that down the chain by just calling self.info() (if you descend 
from BasePlugin, as you should).


Step 3: (Preferable but not necessary) Write a test

It would be great if you submit a test case for this. If you're not sure 
how to do that, I would explain how.


Step 4: Submit a patch

As from the maintainer "personal package archive" page, I understand 
that binary packages will be made publicly available? The page states 
'deb ...' entries in sources.list. If so, I think it is a bad idea. Only 
source packages should 

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Asheesh Laroia]

On Tue, 26 Jul 2011, Kilian Krause wrote:


Hi,

On Tue, Jul 26, 2011 at 08:37:36PM +0200, Julien Valroff wrote:

It may also help to know whether the package is already in Debian (with
a link to packages.d.o in order to know more about the history of the
uploads) or if it is a new package.


packages.qa.d.o please.

And while we're writing the wishlist, please also inclulde:


Same story from before. I'm going to write up how these can be fixed!


* output from lintian -IX --pedantic


Difficulty: 0 (super easy)

(step 0: get the latest code from git)

Step 1: edit debexpo/plugins/lintian.py

Right now, we call lintian like this:

output = commands.getoutput('lintian %s' % self.changes_file)

You can adjust the command however you see fit.

Step 2: Submit a patch


* changelog entry with colorized RC-bugs that are fixed


Difficulty: 1

(step 0: get the latest code from git)

Step 1: read how we do I/O to the bug tracker now

Read debexpo/plugins/closedbugs.py

Step 2: Adjust that plugin, or write a new one, to generate the new 
report you want


Step 3: Make sure it shows up properly w/r/t HTML escaping

Step 4: Submit a patch


* whether or not the orig.tar.gz is original


How do we detect this programmatically?


* if there is a previous version in debian, debdiff to the source

basically more similar to http://ftp-master.debian.org/new.html


That would be a really good thing! I would suggest tying that to a new 
URL. If there is a previous version in Debian, the package page on 
expo.debian.net can link to the expo.debian.net/$package/$version/debdiff 
URL.


Difficulty: 2 (a non-trivial bit of code, but no major architecture 
changes)


Step 0: Get the code

Step 1: Read the lintian plugin to have a sense of how a non-trivial 
plugin works


That's in debexpo/plugins/lintian.py

Step 2: Read the code that makes the package page display

That would be:

* debexpo/config/routing.py
* debexpo/controllers/package.py
* debexpo/model/packages.py
* debexpo/templates/package/index.mako

Step 3: Create a new URL that displays nothing

Do that by creating a new method in debexpo/controllers/package.py and 
tying it to a route in routing.py.


Make sure your browser successfully loads it.

Step 4: Create a new plugin that will store these debdiffs

You'll need to make a new model, also.

Step 5: Make the plugin actually run debdiff, which will include 
downloading the package from Debian


Step 6: Make the plugin store those results in the database

Step 7: Make the package info page link to the debdiff URL if 
there is any debdiff content


Step 8: Make the debdiff URL actually show the debdiff contents

Step 9: Submit a patch

-- Asheesh.


--
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/alpine.deb.2.00.1107261538490.9...@rose.makesad.us

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Niels Thykier]

On 2011-07-26 22:01, Asheesh Laroia wrote:
> On Tue, 26 Jul 2011, Kilian Krause wrote:
> 
>> [...]
>> * output from lintian -IX --pedantic
> 
> Difficulty: 0 (super easy)
> 
> (step 0: get the latest code from git)
> 
> Step 1: edit debexpo/plugins/lintian.py
> 
> Right now, we call lintian like this:
> 
> output = commands.getoutput('lintian %s' % self.changes_file)
> 
> You can adjust the command however you see fit.
> 
> Step 2: Submit a patch
> 
>> [...]


Hi

To anyone interested in this, it might be a good idea to set up a
lintianrc file and use it (e.g. via --cfg) to keep the options separated
from the code.

~Niels


-- 
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/4e2f1e8f.3000...@thykier.net

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Kilian Krause]

Hi Asheesh,

On Tue, Jul 26, 2011 at 04:01:26PM -0400, Asheesh Laroia wrote:
> On Tue, 26 Jul 2011, Kilian Krause wrote:
[...]
> >* whether or not the orig.tar.gz is original
> 
> How do we detect this programmatically?

Thanks for taking the time to even explain that detailled how to get the
code working in the new way we're all proposing! That's an awesome help for
any of us having the free time to actually code something together and lend
this new project a helping hand!

As for the above, I'll happily throw in the technical background I had in
mind:

- detect whether debian/watch is there and useful
- if so and if the version is not mangled (like ~dfsg etc.), run uscan
  --force-download in a patched version that does not involve uupdate or
  svn-update (i.e. does call any programs that an "attacker" might want to
  turn against us)
- diff that against the orig.tar.* uploaded
- if different, put up a warning, unpack both and list the diff -urN if any

I'm not entirely sure if we want to run get-orig-source targets to rebuild
~dfsg tarballs and compare them. Or rather how we could sandbox that process
to make sure we're on the safe side but still don't allow any attacker to
abuse the system.

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Kilian,

On 26.07.2011 22:25, Kilian Krause wrote:
> I'm not entirely sure if we want to run get-orig-source targets to rebuild
> ~dfsg tarballs and compare them. 

I don't think, you really want to consider to run /anything/ which has
been supplied by a completely untrusted sponsoree. Being it a full or
partial or just a get-orig-source target run. This is an immediate risk
for the infrastructure, being it well protected or not for little benefit.


(just my 2c)
- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOLyTpAAoJEMcrUe6dgPNtB40P/jKI4+ml59JN8jZ6Ps+3pDic
pgU8lVMjb1QMeRsCc4RjM14+khYmjgja31HpNP/s3GeDnHdjDZha29oPAmTuGLkt
9CC05g9dELKS/eRiY7JHOeEG6o/Y9csnQR96bhaAzcHiSmYqF1NMj4Gl4pPN5RT6
WTOTLog1E6S5kcdfAvtCo7RWU1OWdOV6u8yI+fEFpsEFnc4bx3lIkbJXXI3vJVjH
uhWDIP1zDBUmw6Wn8LAWpa9wQPbonx2lX/ByzaccnraCk/fF36hDotoDnhqDM6iG
k7d5jo06xU/1HidtZ1BJIFMYCKP8DJT/sdExXjA+AqzC+g04fArQXMftRVRofRkb
ffAlTy+kP/PMv4SnWwRtnqdUpoBoU5VGKSWJsiz8MjUdU8OQ4x0prK+pF0BCvShe
ZtklUo4JAs3WYOwuTtb/VCDtcHPzZr9RzgV9FHin0Pz7zW4bD51ewgRWLN/rWYip
Pbt3BQKp1ZxtrvfA+FabocKyvvC55vjhuG/XY07hCSUg0KEIppg9lMq3PXBkDPy9
y4laBriwO/SyfBl/nLRhSVs8May3bNfu1nQa7XlFFar326O95Gdh6S7jWfBSnDqD
RqfhnhEPSHJsrI1dasS4Ay1BvrmNklGCG98K9Vy1vfyBzOejG/8BeE+TPrqv1xWB
1aRy1WEJhg/jhmjlOaI+
=Ou/Z
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e2f24ea.20...@toell.net

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Jakub Wilk]

* Kilian Krause , 2011-07-26, 22:25:

- detect whether debian/watch is there and useful
- if so and if the version is not mangled (like ~dfsg etc.), run uscan 
--force-download in a patched version that does not involve uupdate or 
svn-update (i.e. does call any programs that an "attacker" might want 
to turn against us)


It's a shame that uscan is insecure-by-design. I use my wrapper script 
to add a bit sanity to it: 
https://bitbucket.org/jwilk/debian-misc/src/tip/upscan


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110726204044.ga9...@jwilk.net

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Kilian Krause]

Hi Arno,

On Tue, Jul 26, 2011 at 10:34:50PM +0200, Arno Töll wrote:
> On 26.07.2011 22:25, Kilian Krause wrote:
> > I'm not entirely sure if we want to run get-orig-source targets to rebuild
> > ~dfsg tarballs and compare them. 
> 
> I don't think, you really want to consider to run /anything/ which has
> been supplied by a completely untrusted sponsoree. Being it a full or
> partial or just a get-orig-source target run. This is an immediate risk
> for the infrastructure, being it well protected or not for little benefit.

that was pretty much my point. I've currently no idea on how to secure the
setup enough so that we can safely sandbox the get-orig-source call
sufficiently to be terminated unconditionally after a timeout from the
outside and unable to speak to anything except some remote (web) servers and
a local disk cachedir where we'd pull a file from once completed. I bet
however it'd make an interesting SELinux challenge to put such thing
together. ;-)

That's nothing urgent and nothing that we should put efforts into now(TM).

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Kilian Krause]

Hi Jakub,

On Tue, Jul 26, 2011 at 10:40:44PM +0200, Jakub Wilk wrote:
> * Kilian Krause , 2011-07-26, 22:25:
> >- detect whether debian/watch is there and useful
> >- if so and if the version is not mangled (like ~dfsg etc.), run
> >uscan --force-download in a patched version that does not involve
> >uupdate or svn-update (i.e. does call any programs that an
> >"attacker" might want to turn against us)
> 
> It's a shame that uscan is insecure-by-design. I use my wrapper
> script to add a bit sanity to it:
> https://bitbucket.org/jwilk/debian-misc/src/tip/upscan

that one isn't packaged by chance and scheduled to also be able to do
multiple orig.tar.* as per dpkg-source v3? ;-)

Would make it a perfect drop in replacement for my review process. *g*

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Asheesh Laroia]

On Tue, 26 Jul 2011, Kilian Krause wrote:


Hi Asheesh,

On Tue, Jul 26, 2011 at 04:01:26PM -0400, Asheesh Laroia wrote:

On Tue, 26 Jul 2011, Kilian Krause wrote:

[...]

* whether or not the orig.tar.gz is original


How do we detect this programmatically?


Thanks for taking the time to even explain that detailled how to get the
code working in the new way we're all proposing! That's an awesome help for
any of us having the free time to actually code something together and lend
this new project a helping hand!

As for the above, I'll happily throw in the technical background I had in
mind:

- detect whether debian/watch is there and useful
- if so and if the version is not mangled (like ~dfsg etc.), run uscan
 --force-download in a patched version that does not involve uupdate or
 svn-update (i.e. does call any programs that an "attacker" might want to
 turn against us)
- diff that against the orig.tar.* uploaded
- if different, put up a warning, unpack both and list the diff -urN if any


Out loud, I just found myself saying: "Who so cool!"

That would be pretty awesome. I would completely love to see that.

I'm not entirely sure if we want to run get-orig-source targets to 
rebuild ~dfsg tarballs and compare them. Or rather how we could sandbox 
that process to make sure we're on the safe side but still don't allow 
any attacker to abuse the system.


To do get-orig-source would be pretty amazingly great. You're right that 
safety would a challenge when running code from within the debian/rules 
file.


It would be pretty superb to lock that process into a chroot. I would 
suggest using something like sbox 
 to do it.


-- Asheesh.


--
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/alpine.deb.2.00.1107261652250.9...@rose.makesad.us

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Kilian Krause]

Hi Asheesh,

On Tue, Jul 26, 2011 at 05:00:45PM -0400, Asheesh Laroia wrote:
> On Tue, 26 Jul 2011, Kilian Krause wrote:
[...]
> >- detect whether debian/watch is there and useful
> >- if so and if the version is not mangled (like ~dfsg etc.), run uscan
> > --force-download in a patched version that does not involve uupdate or
> > svn-update (i.e. does call any programs that an "attacker" might want to
> > turn against us)
> >- diff that against the orig.tar.* uploaded
> >- if different, put up a warning, unpack both and list the diff -urN if any
> 
> Out loud, I just found myself saying: "Who so cool!"
> 
> That would be pretty awesome. I would completely love to see that.

:-)


> >I'm not entirely sure if we want to run get-orig-source targets to
> >rebuild ~dfsg tarballs and compare them. Or rather how we could
> >sandbox that process to make sure we're on the safe side but still
> >don't allow any attacker to abuse the system.
> 
> To do get-orig-source would be pretty amazingly great. You're right
> that safety would a challenge when running code from within the
> debian/rules file.
> 
> It would be pretty superb to lock that process into a chroot. I
> would suggest using something like sbox
>  to do it.

just for the record: neither chroot nor sbox will be sufficient to protect a
production system. Maybe LXC will be, maybe SELinux, maybe XEN. That's the
least protection I'd settle for. Maybe even a combination of those (if we
put up an official description we'll be pretty open to being hacked due to
the foreseeable results of our architecture). Thus neither document too
publically how we do it nor what the exact internal versions are.

This being said, of course bringing more complexity will also make the
construct more fragile and more error-prone (read: more unsafe). That's why
I said it'd be a challenge to put this up in a manageable and yet secure
way. 

Most probably an interpreter with a whitelisting of commands will come in
most handy in the end.  ;-)

-- 
Best regards,
Kilian


signature.asc
Description: Digital signature

Re: RFS: cl-launch, cl-asdf (updated packages)

[Faré]

Dear mentors,

I am looking for a sponsor for
the new version 2:2.017-1 of my package "cl-asdf".

It builds theis binary package:
cl-asdf    - Another System Definition Facility

The package appears to be lintian clean.

The package cl-asdf can also be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/c/cl-asdf
- Source repository: deb-src http://mentors.debian.net/debian unstable
main contrib non-free
- dget http://mentors.debian.net/debian/pool/main/c/cl-asdf/cl-asdf_2.017-1.dsc

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

Kind regards,

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
If once you have paid him the Dane-geld / You never get rid of the Dane.
— Rudyard Kipling


--
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/can7nbxdhqsjbckdurjhuvffy+5rn_cshin9y1arwnpszzsd...@mail.gmail.com

Re: jampal_02.01.05-1_amd64.changes REJECTED

[Peter Bennett]

Kilian
I will have to use +dfsg1 instead of ~dfsg1, because ~ sorts before the
base version and now uscan thinks there is a newer version available
(unless I have failed to understand something here - which is quite likely)

jampal: Newer version (02.01.05) available on remote site:
  http://qa.debian.org/watch/sf.php/jampal/jampal-source-02.01.05.tar.gz
  (local version is 02.01.05~dfsg1)
jampal: Successfully downloaded updated package
jampal-source-02.01.05.tar.gz
and symlinked jampal_02.01.05.orig.tar.gz to it


On 7/26/2011 2:00 PM, Kilian Krause wrote:
> Hi Peter,
>
> On Tue, Jul 26, 2011 at 01:33:44PM -0400, Peter Bennett wrote:
>> Thanks Kilian
>>
>> I will create a repackaged source with a new version number 02.01.05-2,
>> with the "looks" directory excluded.
>> I will add a get-orig-source target that creates the repackaged source,
>> and try to conform with Debian developers Reference (6.7.8.2 Repackaged
>> upstream source).
>> At this time I will not change the upstream source.
> please use 02.01.05~dfsg-1 in that case. Meaning your repackaged tarball
> should have an upstream version of 02.01.05~dfsg. If you feel extra caution
> for new repackaging mimic should already be added use 02.01.05~dfsg1-1.
>


-- 
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/4e2f3401.8000...@comcast.net

Re: RFS: eviacam

[Cesar Mauri]

Hi,

Thanks Kilian for your feedback which helped me to improve the package. 
I've updated and uploaded it again to the mentors site. The package 
appears to be lintian clean.



[...]

Updated standards version to 3.9.1


Without futher review of the actual package: Why not to 3.9.2?


I had chosen that version to make lintian (stable version) happy.

OK. Changed to 3.9.2 (and updated lintian on my box to the latest version).


[...]

- Consider putting your Debian packaging in a VCS and add the
   appropriate tags


Can you provide additional details about this?


The VCS (version control system) for the Debian packaging would be the Svn,
Git, Bzr or Hg URI pointing to where you track your Debian changes. Commonly
alioth.debian.org is a good starting point if you've nowhere else that's
already publically offering your VCS tree.


I already use git on sf.net for upstream. May be the best approach is to 
adopt the scheme described here [1]. Isn't it?


[1] http://documentation.debian-projects.org/other/debian-packaging-git/


[...]

rules
- I find the clean target a little strange, why copy the config.sub and
   config.guess there?


Removed.


I hope you changed that to autotools-dev use. Usually it's a sensible
default to use autotools-dev (e.g. dh --with autotools_dev) if your package
does use autotools.


Finally I've decided to adopt the newer debian/rules format (shorter) 
and I've added the "--with autotools_dev" option.



[...]

- Not sure, but I think quite some options in your ./configure line are
   added by the builder automatically.


Not sure also.


See /usr/share/perl5/Debian/Debhelper/Buildsystem/autoconf.pm for exact
details.


Not a problem any more with the new debian/rules format.

Best regards,

César Mauri


--
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/4e2f3ca8.5080...@crea-si.com

Re: Debhelper doesn't know the ‘build-stamp’ target, but Lintian recommends it

[Ben Finney]

Kilian Krause  writes:

> Hi Ben,
>
> On Tue, 2011-07-26 at 17:10 +1000, Ben Finney wrote:
> > Lintian recommends (via tag ‘debian-rules-missing-recommended-target’):
> > 
> > =
> > N:   Note that the following form is recommended however:
> > N:   
> > N: build: build-arch build-indep
> > N: build-arch: build-stamp
> > N: build-indep: build-stamp
> > N: build-stamp:
> > N:   build here
> > =
>
> If you're sure that you want to use dh but .PHONY then just put into
> your rules something like:
>
> build-indep:
>   dh $@
> build-arch:
>   dh $@
> build: build-arch build-indep
>
> No need for a stamp as dh is already producing stamps internally.

This doesn't match Lintian's recommendation. Nor does the common ‘%:’
style rule.

Should Lintian's recommendation be changed?

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\Brain, but why would anyone want to see Snow White and the |
_o__)   Seven Samurai?” —_Pinky and The Brain_ |
Ben Finney


pgp2LamnFJtDj.pgp
Description: PGP signature

Re: Looking for mentor to package dolibarr erp/crm - ITP 634783

[Laurent Destailleur (eldy)]

I made all changed suggested by all answers i recevied after my first 
mentor request

to upload Dolibarr ERP & CRM :

Package provided is now a source package built with dpkg-source :
DSC:http://www.dolibarr.org/files/debian/dolibarr_3.1.0-1.1.dsc
Source tgz: http://www.dolibarr.org/files/debian/dolibarr_3.1.0-1.1.tar.gz
I still provide binary built with dpkg if needed (but should not):
Binary: 
http://www.dolibarr.org/files/debian/dolibarr_3.1.0-dev_all.deb


I removed most Lintian warnings. There is still 3 kinds of warnings:
* W: embedded-javascript-libraryThis can't be avoid because package 
use embedded library that are different version than one provided by 
debian default packages and are modified specially for Dolibarr software.
* W: embedded-php-library This can't be avoid because 
package use embedded PHP library that are different version of one 
provided by debian default packages and are modified specially for 
Dolibarr software.
* W: extra-license-file  This can't be avoid without 
removing licence files of js and php embedded library (see 2 previous 
points). Licence of embedded libraries are reported also into the 
copyright file.


I tried to provide a complete copyright file, fix packages dependencies, 
removed not necessary embedded libraries (those remainings can't be 
removed and we can't use another version than the one embedded).



I am waiting next feedbacks with this second try to guide me if 
something must be changed/fixed again.




Le 21/07/2011 01:53, Arno Töll a écrit :

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Laurent,

On 20.07.2011 23:05, Laurent Destailleur (eldy) wrote:

The package can be found on URL:
http://www.dolibarr.org/files/dolibarr-3.1.0-dev.deb

and


Because Dolibarr is a PHP application, binary package is also source
package (no compiled binaries inside).

I'm afraid, but this is not true. For sponsoring, a source package is
required, not a binary (.deb) package, being architecture independent or
not. So please, re-upload your source package if you want to have it
reviewed.

However, before you do, please fix problems with it.


Lintian tests report no errors.

Please run
lintian --pedantic -E -I dolibarr-3.1.0-dev.deb
(or even better on your *.changes file)

and come back if you reduced Lintian warnings to something in a more
sane magnitude.

Moreover please read again the maintainer guide and the policy. You are
massively abusing most^W^Wsome standards, including but not limited to
package relationships, embedded code copies, purpose of maintainer
scripts, source code distributions and a massively too shallow copyright
file.

- -- 
with kind regards,

Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOJ2pgAAoJEMcrUe6dgPNtWSIQALARqTr3dY4yBKiqcXVHw3+s
/CplriZKJVifQ5PjJNROLcr6G6tgLZTTvA4SPvQ5fWZVPXd47J3wm1XqUndrj+Ia
4Cm32TCpJvh+UY4ukBdtNRBb9whLVkNwp0KChBprINYoatB4e7jNYq8rdNejfoxX
RMy9gBrWaSTchQ+2sNrOWm/POpnPo+4dFCc7sTeUnYZaJTCZyFYm8YoTT2tTlscD
pyoigp5Ihxg6iY8gfyHR5yJw1Hp3NKmLlSlRdK5vkYU483CA4ZU7sA0epzkDQvix
KcaV/aGm1xmZfKR5OyR+Jhb8vSx3hs+mGlbpDyQxWDX7Cr8JBUs0krKmgAXmAzRy
ODSffhbQPLoJ1F5nd88C+9bhnFvWCPS7diEqA+zl+Wexz2iHoVxQQ42QTNDw4f4M
RYREkK7r1uSt3P3MAq9UnFQwQJm43opp53O4z7SwzUT4bpic0L8ycaXI+/qzAbLE
HTtqQK5XqSZHGAvpLBMh7PM6psFc46BtCduWAbOt41Y1/4TeHNKpykFov60nUDq6
HlgoE+IH8hGTGsJkmyoUOdxCA4VBheYy0FT44c21WU1IZ4PS+9wF2BdWIb3WZ7YG
SCGFUdxe3/p8D8x43BaAGRHn2TXR94F1xno8SEcpj3MZDGMbQPbK/o0DEM76rG5q
xPudhs47Q4wutKz8Q8M1
=h3gv
-END PGP SIGNATURE-





--
Eldy (Laurent Destailleur).
---
EMail: e...@destailleur.fr
Web: http://www.destailleur.fr

Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: cont...@destailleur.fr
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: cont...@destailleur.fr
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net


--
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/4e2f4598.1060...@destailleur.fr

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Ben Finney]

Asheesh Laroia  writes:

> Debexpo is a replacement for http://mentors.debian.net/. I hereby
> request testers! It is of "beta" quality -- I think it works fully and
> has enough features to replace mentors.debian.net.

Like many people, I have far too many online credentials already.
Signing up to a new service with new site-specific credentials is a
barrier to entry.

What hope is there for this new service to make use of existing
credentials from mentors.debian.net?

-- 
 \   “Working out the social politics of who you can trust and why |
  `\  is, quite literally, what a very large part of our brain has |
_o__)   evolved to do.” —Douglas Adams |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/8762mor6af@benfinney.id.au

Re: jampal_02.01.05-1_amd64.changes REJECTED

[Peter Bennett]

I have repackaged the source, built, signed, uploaded

Version is now 02.01.05+dfsg1-1

The package can be found on mentors.debian.net:
- URL: http://mentors.debian.net/debian/pool/main/j/jampal
- dget
http://mentors.debian.net/debian/pool/main/j/jampal/jampal_02.01.05+dfsg1-1.dsc

If all is OK please upload it.

Thanks
Peter

On 7/26/2011 2:00 PM, Kilian Krause wrote:
> Hi Peter,
>
> On Tue, Jul 26, 2011 at 01:33:44PM -0400, Peter Bennett wrote:
>> Thanks Kilian
>>
>> I will create a repackaged source with a new version number 02.01.05-2,
>> with the "looks" directory excluded.
>> I will add a get-orig-source target that creates the repackaged source,
>> and try to conform with Debian developers Reference (6.7.8.2 Repackaged
>> upstream source).
>> At this time I will not change the upstream source.
> please use 02.01.05~dfsg-1 in that case. Meaning your repackaged tarball
> should have an upstream version of 02.01.05~dfsg. If you feel extra caution
> for new repackaging mimic should already be added use 02.01.05~dfsg1-1.
>


-- 
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/4e2f4abc@comcast.net

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Asheesh Laroia]

On Wed, 27 Jul 2011, Ben Finney wrote:


Asheesh Laroia  writes:


Debexpo is a replacement for http://mentors.debian.net/. I hereby
request testers! It is of "beta" quality -- I think it works fully and
has enough features to replace mentors.debian.net.


Like many people, I have far too many online credentials already. 
Signing up to a new service with new site-specific credentials is a 
barrier to entry.


What hope is there for this new service to make use of existing 
credentials from mentors.debian.net?


There are a few major options:

1) Import the mentors.debian.net authentication data

2) Integrate OpenID logins, so you can use existing credentials (e.g. 
Google Account, your own personal OpenID,


3) Just use a silly password like 'password'

4) See if DSA will create a central authentication web thing, which they 
are considering (called Shibboleth)


5) Login by asking you to GPG-sign a random message generated by the 
backend


I'm open to other ideas.

One difficulty for this is that I don't plan to write much new code for 
debexpo -- just enough to get it to the point where it can replace 
mentors.debian.net. But if we come to a community decision about how we 
want login to work, and specify it well, I think we can find the energy to 
build it.


-- Asheesh.


--
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/alpine.deb.2.00.1107261916420.9...@rose.makesad.us

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Asheesh Laroia]

On Tue, 26 Jul 2011, Asheesh Laroia wrote:


* Please tell me if there are features we need before it can replace
 mentors.debian.net.


Arno found one showstopper bug, and I just fixed it.

If there are any others, let me know. Otherwise, about 24 hours from now, 
I plan to ask signum if we can turn mentors.debian.net off, and make it a 
debexpo instance.


That will mean losing the existing uploaded packages. But I think that's 
not such a huge loss.


(If Signum is around, and we can work out a way to do it, I will try to 
copy the accounts over.)


-- Asheesh.


--
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/alpine.deb.2.00.1107262007010.18...@rose.makesad.us

Re: Looking for mentor to package dolibarr erp/crm - ITP 634783

[Arno Töll]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Laurent,

thanks for your interest in putting packages to Debian. We all
appreciate your efforts, but ...

> Package provided is now a source package built with dpkg-source :
> DSC:http://www.dolibarr.org/files/debian/dolibarr_3.1.0-1.1.dsc
> Source tgz: http://www.dolibarr.org/files/debian/dolibarr_3.1.0-1.1.tar.gz
> I still provide binary built with dpkg if needed (but should not):
> Binary:
> http://www.dolibarr.org/files/debian/dolibarr_3.1.0-dev_all.deb

sorry, your package does not look too good.

First, you clearly did not use the source package you uploaded to build
your binary. I am not entirely sure what you did, but the binary package
has nothing to do with the source package you linked. Your binary
contains debconf scripts and, well, it works, your source package does not.

Your source package fails to build from source. This is due to a severe
syntax error in your debian/rules file. It must contain tabs, not
spaces. However, even if you fix this, your package won't work because
you don't make use of any debhelper file (e.g. an install file) and you
neither do provide a Makefile in your upstream source, debhelper could use.

Moreover your dependencies in your control file look insane. Just one
random note for it: You clearly don't want to recommend "firefox". You
should have noted, there is no Firefox in Debian anymore, since more
than 5 years, and even if it were, there is no point to recommend it.
Same for your debian/changelog file.

Finally your upstream source shows a clear misunderstanding of what we
would accept to be packaged to a Debian package. I guess it might work
for your internal corporate use (or wherever you use your stuff), but
I'm afraid, we can't accept such a package for Debian. You abuse the
file hierarchy standard (you install configuration to /usr), you install
a lot of files you shouldn't install (especially not to a document root,
e.g. /usr/share/dolibarr/htdocs/install) and you are embedding libraries
(e.g. /usr/share/dolibarr/htdocs/includes/artichow/), documentation
(/usr/share/dolibarr/htdocs/install/mssql/README), language files and
who knows what else.

Please rethink, if your package is really ready to be publicized. You
show a fundamental misunderstanding how Debian packages work, and the
quality requirements the packages should meet. Please read the new
maintainer's guide [1], the Debian policy [2] and the Debian developer
reference [3].

Don't hesitate to ask this mailing list again, once your package is in a
better shape or if you don't understand something the documents I
referenced require from you (e.g. you have technical questions).

[1] http://www.debian.org/doc/manuals/maint-guide/
[2] http://www.debian.org/doc/debian-policy/
[3] http://www.debian.org/doc/manuals/developers-reference/index.html


- -- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJOL1kAAAoJEMcrUe6dgPNtZ7QP/2Sdtzqawt1ufxW36B7O76Ng
fpUMFdJpy8EWm709KeLLrWYtQjd9mqj2rP0D5bF9gp6Zp6ha5zS3ZwYxhuIQrdo7
H0270xCOWfQFtQzSFN+hjsL121FSYmLz4Rd83MUz2xq+Ve8S81HE+KSLhpKdiyY5
Fxu0kit68cryW8NHMx+EfgBdaCZv98RWqubKkAChUfjP8UIXZPKclrVx+P3flsFo
cp98TKEfMR24ho6L9NUcYH1ig3cAAjGzixdimCo4/wBs/mbe03h3pAWfOVdiKTj/
MSSa9u8Hd2yLbefBt32V12k0pmpf/YBKR1sZnnayLKLpclzgmGnKrtOtKCGwd+R+
RJQ0Nf9pqDyXJ3Rg+YtL4phmQzSx8xwZDXY8+Vv2wXvD2bQ/v+NmIkWQgNqnqPhk
hPgLet2I/4syvk4gk1ZVlpjvl6F1Enqlfv2JTJ4XDKPM6lcRpA6D9DcLFGxkYRcQ
cPwql6qLlHMz1uPzdAA+jKO9hEARPjAnL9q9yKgOutjK6+oH3HlV9jTo9Gv4LRnD
jz/f6XWwL6+Vfst/wyPs1LfHuHI96d6eCn6InLkpT2vK3pmTrH1F7TlUhu9njhmQ
beboKhTOyYntffMP6XwzlQ19Stg73aeUQqUzMbTc0eZwZyam4FbwQo/rOzFRC+Ck
xpwqCNzcEmMtI6OIEhtZ
=RDzq
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e2f5901.4070...@toell.net

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Ben Finney]

Asheesh Laroia  writes:

> 2) Integrate OpenID logins, so you can use existing credentials (e.g.
> Google Account, your own personal OpenID,

This would be the option I'd most like to see, for the reason you give:
it allows a huge number of existing identities, including identities
managed by the person and not a corporation, to be re-used if the
visitor chooses to.

> One difficulty for this is that I don't plan to write much new code
> for debexpo -- just enough to get it to the point where it can replace
> mentors.debian.net. But if we come to a community decision about how
> we want login to work, and specify it well, I think we can find the
> energy to build it.

+1 to having DebExpo be an OpenID Relying Party for registration and
login.

http://wiki.openid.net/w/page/12995223/Relying-Party-Best-Practices>

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\ Brain, but three round meals a day wouldn't be as hard to |
_o__) swallow.” —_Pinky and The Brain_ |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uxcr1tu@benfinney.id.au

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Ben Finney]

Asheesh Laroia  writes:

> Otherwise, about 24 hours from now, I plan to ask signum if we can
> turn mentors.debian.net off, and make it a debexpo instance.

Gak! I didn't realise the proposal was for existing mentors.debian.net
service to be replaced immediately. In that case, please ensure existing
credentials continue to work for login to the new service.

> (If Signum is around, and we can work out a way to do it, I will try to
> copy the accounts over.)

Thank you in advance.

-- 
 \   “Everything you read in newspapers is absolutely true, except |
  `\for that rare story of which you happen to have first-hand |
_o__) knowledge.” —Erwin Knoll |
Ben Finney


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wrf4pn60@benfinney.id.au

Re: Please try expo.debian.net -- a replacement for mentors.debian.net

[Julian Mehnle]

Asheesh Laroia wrote:

> If there are any others, let me know. Otherwise, about 24 hours from
> now, I plan to ask signum if we can turn mentors.debian.net off, and
> make it a debexpo instance.
>
> That will mean losing the existing uploaded packages. But I think
> that's not such a huge loss.

Don't do that.  Such actions tend to piss off a significant portion of the 
users.  Someone may *just* have spent half a day figuring m.d.n out, 
creating an account, and uploading their packages.  Not saying m.d.n 
shouldn't go away, but don't treat people's work as if it was worthless 
("not such a huge loss", meaning "not worth my time to migrate the 
data").

Just some advice based on experience.

-Julian


signature.asc
Description: This is a digitally signed message part.