Bug#657783: RFS: haildb 2.3.2-1.1 [NMU] [RC] -- Library implementing InnoDB-like database

[Tobias Frost]

Am Samstag, den 28.01.2012, 20:12 +0100 schrieb Jakub Wilk:
> * Tobias Frost , 2012-01-28, 19:52:
> >  * Update standards version to 3.9.2, no changes required
> 
> No, no, no. We don't do such things in NMUs.
> 
> -- 
> Jakub Wilk

Fine with me, reverted & uploaded.


> 
> 




--
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/1327795039.29460.6.ca...@ithilien.loewenhoehle.ip

Bug#659498: RFS: solarpowerlog -- photovoltaic data logging

[Tobias Frost]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am (still) looking for a sponsor for my package "solarpowerlog".

As now the boost transition has been completed, it is time to reissue my 
request.
See for http://lists.debian.org/debian-mentors/2012/01/msg00012.html for my 
last request.

Changes since my last request:
- removed whitespaces from debian/*
- cleanup debian/changelog
- new upstream version to be fit for libconfig-1.4.8
- hardeing flags enabled.
- went for short-form debhelper
- compat set to 9

dget -x 
http://mentors.debian.net/debian/pool/main/s/solarpowerlog/solarpowerlog_0.22.dsc

 * Package name: solarpowerlog
   Version : 0.22
   Upstream Author : Tobias Frost 
 * URL : http://sourceforge.net/projects/solarpowerlog/
 * License : GPL, LGPL
   Section : utils

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

Kind regards,

Tobias Frost



-- 
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/20120211161556.29413.97668.report...@mordor.loewenhoehle.ip

Bug#659518: RFS: tokyocabinet/1.4.37-7 [QA] -- Tokyo Cabinet Database Libraries

[Tobias Frost]

Package: sponsorship-requests
Severity: normal

Dear mentors,

Please sponsor this QA-Upload. (I do not want to adopt this package)

Please note that I do not have access to collab-maint, so I cannot commit the 
changes to the VCS,
so I ask the sponsor to do push the changes when doing the upload.

 * Package name: tokyocabinet
   Version : 1.4.37-7
 * URL : http://fallabs.com/tokyocabinet/
 * License : BSD
   Section : libs

It builds those binary packages:

libtokyocabinet-dbg - Tokyo Cabinet Database Libraries [debug]
 libtokyocabinet-dev - Tokyo Cabinet Database Libraries [development]
 libtokyocabinet8 - Tokyo Cabinet Database Libraries [runtime]
 tokyocabinet-bin - Tokyo Cabinet Database Utilities
 tokyocabinet-doc - Tokyo Cabinet Database Documentation

To access further information about this package, please visit the following 
URL:

  http://mentors.debian.net/package/tokyocabinet

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/main/t/tokyocabinet/tokyocabinet_1.4.37-7.dsc

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

Kind regards,

Tobias Frost

Changes:
* setting Maintainer to QA-Team (orphaned in #650830)
* fixing these bugs:
  #659510 [tokyocabinet] tokyocabinet: FTBFS on hurd, do to missing msync 
syscall
  #638625 [tokyocabinet] tokyocabinet: FTBFS on s390x with testsuite errors
  #596502 [libtokyocabinet-dbg] libtokyocabinet-dbg: mistake in package 
description
* fixes two lintian warnings


tokyocabinet (1.4.37-7) unstable; urgency=low

  * QA upload
  * Orphaned for more than 14 days: Setting maintainer to QA.
  * Disable pthread support on s390x (Closes: #638625)
  * Do not use msync-syscall on hurd (Closes: #659510)
  * update -dbg Package description (Closes: #596502)
  * Fixes lintian warning "manpage-section-mismatch"
  * Fixes lintian warning "debug-package-should-be-priority-extra"
on libtokyocabinet-dbg

 -- Tobias Frost   Sat, 11 Feb 2012 19:22:42 +0100


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.1.4 (SMP w/3 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
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/20120211185956.11065.82211.report...@mordor.loewenhoehle.ip

Bug#659498: RFS: solarpowerlog -- photovoltaic data logging

[Tobias Frost]

Am Donnerstag, den 16.02.2012, 15:33 +0100 schrieb Benoît Knecht:
> And it doesn't build for me in a clean chroot, I get the following error
> (full build log attached):

Hallo Benoît,

well, that's strange... My packages are always pdebuild-checked and I
built it successfully on amd64, i386 and armel. (I'm using pdebuilder,
not cowbuilder)

I also re-checked again on amd64, even created a new pbuilder
enviroment, but unfortunatly I cannot reproduce this faiure. 

Analyzing your buildlog, there's something strange with ccache:

 ccache: FATAL: Failed to create /var/cache/pbuilder/ccache/7/d:
Permission denied

Could that be an hint?

coldtobi




--
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/1329427101.7428.15.ca...@ithilien.loewenhoehle.ip

Bug#659498: RFS: solarpowerlog -- photovoltaic data logging

[Tobias Frost]

Am Freitag, den 17.02.2012, 12:48 +0100 schrieb Benoît Knecht:

Sorry for the late reply, spare time was quite spare the last days...

> Hi Tobias,
> 
> As promised, here's my review of your package:
> 
>   - In debian/solarpowerlog.default, you define /etc/solarpowerlog as
> the default RUNDIR; what files is your program expecting to find
> there, HTML templates? If so, installing some default templates in
> /usr/share/solarpowerlog and pointing your program to that directory
> seems like a better option.

The templates were in an earlier release at /etc/solarpowerlog, but I
moved them to /usr/share/docs/solarpowerlog/examples after I got
received some critism about the usage of the similie timeline widgets,
which are (if they are) only very hard to package. 
So I won't install any default templates except as the said examples,
but I will remove the reference to the rundir and hint in the installed
example configuration file to use absolute paths.  

> You also note there that start-stop-daemon is taking care of running
> solarpowerlog in the background, but according to
> start-stop-daemon(8), "this is a last resort, and is only meant for
> programs that either make no sense forking on their own, or where
> it's not feasible to add the code for them to do this themselves";
> since your program can put itself in the background, you should
> rather use that possibility. This way, it will also make sense
> checking the exit status of start-stop-daemon in do_start in the
> init script, because if you use its '-b' option, it can't determine
> if the process failed to execute.

Yes, the daemon support of solarpowerlog is a mixture of barely tested,
incomplete, limited, you name it.. At least up to version 0.22, as I
worked on this with the last commit to my development branch. In other
words, 0.23, which I plan to release soon, will get rid of the hacks you
mentined above.  

> And it'd be best to wrap lines at 80 columns.
> 
>   - Running uscan tells me:
> 
>   Processing watchfile line for package solarpowerlog...
>   Newest version on remote site is 0.21a, local version is 0.22
>   solarpowerlog: remote site does not even have current version

I had an typo ("_" instead of "-") when I uploaded the latest tarball to
sf.net. Should work now. 

>   - I think your short description should read "photovoltaic data
> logger", as in "solarpowerlog is a ..."
> 
> And in the long description, you wrote "photo-voltaic"; I think you
> should stick to the former spelling.
> 
> The second paragraph of the long description is missing punctuation.

Fixed in my debian branch.

>   - In the solarpowerlog(1) man page, the SEE ALSO section appears to be
> a subsection of OPTIONS.
> 
> Please consider removing the AUTHOR section (see man-pages(7) for an
> explanation why).
> 
> In DESCRIPTION, I would start with "solarpowerlog tracks and
> logs..."; it's not just its purpose, it's what it actually does,
> right? Same for the second sentence.
> 
> In OPTIONS, you start with "These programs"; why the plural?

The easy things are already fixed, the complete rewording will take some
time ;-) 
Especially as I added several command line options (thanks to the
improved daemon support) I will have to rework those manpage. Its a
pitty that I like coding more than wording, but it is defintly on the
list. 

> Cheers,
> 
> -- 
> Benoît Knecht
> 
> 
> 

Many thanks for the feedback,

Bye,
coldtobi



--
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/1330383271.13931.29.ca...@ithilien.loewenhoehle.ip

Bug#661975: RFS: gearman-interface [NMU] -- fixes 2 RC bugs

[Tobias Frost]

Hallo Sanrdo,
thanks for your response. I'll add the patches to the BTS.

Note: Clynt (the current maintainer) asked me in a response to one the
BTS entries fixes (#6318020) to include his changes from his VCS as
well:

Am Freitag, den 02.03.2012, 23:55 -0800 schrieb Clint Byrum:
> Thanks, I have not been able to spend much time on gearman-interface
> lately. Thanks for the heads up. Note that the Vcs-Bzr in the package
> is more or less correct, and you may want to consider tacking my
pending
> changes on top of this as one of them is an RC bug fix. 

I think this would be best for the quality of package, but isn't
strictly NMU anymore (could also include other changes -- did not check
yet). 
Would this OK be with you?

coldtobi

Am Samstag, den 03.03.2012, 17:14 +0100 schrieb Sandro Tosi:
> Hello,
> 
> On Sat, Mar 3, 2012 at 06:45, coldtobi  wrote:
> > gearman-interface (0.13.2-2.1) unstable; urgency=low
> >
> >  * Non-maintainer upload.
> >  * Fix "FTBFS: SWIG version >= 1.3.31 is required. You have 2.0.4."
> >applying patch from ubuntu (Closes: #631820)
> >  * Apply fix for newer libgearman-dev (changes includes)
> >  * Fix "python-gearman.libgearman and python-gearman: error when trying
> >to install together" Cherry-picking relevant sections of the attached
> >patch in the bugrport (Closes: #620469)
> >
> >  -- Tobias Frost   Sat, 03 Mar 2012 01:03:30 +0100
> 
> I'd be happy to sponsor it but:
> 
> - remove all unneeded changes to debian/control (probably generated by
> the unhelpful sort-and-something tool)
> - you need to post the debdiff on the relevant bugs on BTS.
> 
> If you can send another package, i'll give it definetely a look (don't
> bump debian revision!).
> 
> Regards,
> -- 
> Sandro Tosi (aka morph, morpheus, matrixhasu)
> My website: http://matrixhasu.altervista.org/
> Me at Debian: http://wiki.debian.org/SandroTosi
> 
> 
> 




--
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/1330849484.13703.6.ca...@ithilien.loewenhoehle.ip

Bug#661975: RFS: gearman-interface [NMU] -- fixes 2 RC bugs

[Tobias Frost]

Hallo Sandro,

uploaded to d-m. 
* undid wrap-and-sort
* Patches are attached to the relevant BTS entries.
* Filed the 3rd RC bug (FTBFS reg. libgearman)
* no other changes made to the package.

Tobias

Am Sonntag, den 04.03.2012, 11:05 +0100 schrieb Sandro Tosi:
> On Sun, Mar 4, 2012 at 09:24, Tobias Frost  wrote:
> > Hallo Sanrdo,
> > thanks for your response. I'll add the patches to the BTS.
> >
> > Note: Clynt (the current maintainer) asked me in a response to one the
> > BTS entries fixes (#6318020) to include his changes from his VCS as
> > well:
> >
> > Am Freitag, den 02.03.2012, 23:55 -0800 schrieb Clint Byrum:
> >> Thanks, I have not been able to spend much time on gearman-interface
> >> lately. Thanks for the heads up. Note that the Vcs-Bzr in the package
> >> is more or less correct, and you may want to consider tacking my
> > pending
> >> changes on top of this as one of them is an RC bug fix.
> 
> Vcs-Bzr is not correctly set:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596794
> 
> > I think this would be best for the quality of package, but isn't
> > strictly NMU anymore (could also include other changes -- did not check
> > yet).
> > Would this OK be with you?
> 
> No, it 's not ok: you're preparing a NMU, so it has to be the smallest
> possible diff to fix the RC bugs. so what you need to do is provide
> for an updated package on mentors with the requested changes and to
> send the debdiff to the involved bug reports (that's a NMU rule);
> after that, all the additional work is more then welcome but unrelated
> to the NMU and not required (i.e. I won't uploaded with spurious
> changes, like those I mentioned before).

That's why I asked. 

> Please let me know when an updated package is available.
> 
> Regards,




--
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/1330864728.13703.16.ca...@ithilien.loewenhoehle.ip

Bug#659498: Uploaded solarpowerlog-0.23-1 to d/m

[Tobias Frost]

Dear mentors,  

Please see my updated version 0.23-1, I just uploaded to d-m (and sf.net
-- note it will take some time until the watch file will work)

Of course as I try with every package I maintain -- it is lintian clean
and tested to be built using pbuilder. (manually as well on my buildbot
setup -- covering armel and i386 archs) 

The dsc file is located at:
http://mentors.debian.net/debian/pool/main/s/solarpowerlog/solarpowerlog_0.23-1.dsc

I handled this as an upstream release, as the benefits of the new
functionalities are not (only) for the packaging, but my other users as
well.

A quite improved daemon support is now available in 0.23 -- including a
rewrite of the init startup file. 

* start-stop-daemon -b no longer necessary, the needed infrastructure
has been implemented in solarpowerlog.

* also handles pid files of its own (init-file uses
/var/run/solarpowerlog/solarpowerlog.pid -- the subdirectory is due to
that solarpowerlog is supposed not to be run as a non-priviledged user,
but it would not have rights make the pid file directly in /var/run.

* handles log files (stderr, stdout --> files) including support for
reopening those files on a signal (to be nice to logrotate). The init
file uses /var/log/solarpowerlog/solarpowerlog.* for the same reasons as
the subdir for the pid file

* To be complete, a logrotate config-file is available. 

If you read that much, it seems that I caught your attention, so if you
a DD please consider sponsoring ;-) Otherwise, any feedback/ review is
of course highly appreciated.

Best regards,
Tobias Frost (coldtobi)


Am Freitag, den 17.02.2012, 12:48 +0100 schrieb Benoît Knecht:
>
> Sorry for the late reply, spare time was quite spare the last days...
>
>> Hi Tobias,
>> 
>> As promised, here's my review of your package:
>> 
>> You also note there that start-stop-daemon is taking care of running
>> solarpowerlog in the background, but according to
>> start-stop-daemon(8), "this is a last resort, and is only meant for
>> programs that either make no sense forking on their own, or where
>> it's not feasible to add the code for them to do this themselves";
>> since your program can put itself in the background, you should
>> rather use that possibility. This way, it will also make sense
>> checking the exit status of start-stop-daemon in do_start in the
>> init script, because if you use its '-b' option, it can't determine
>> if the process failed to execute.
>
> Yes, the daemon support of solarpowerlog is a mixture of barely tested,
> incomplete, limited, you name it.. At least up to version 0.22, as I
> worked on this with the last commit to my development branch. In other
> words, 0.23, which I plan to release soon, will get rid of the hacks you
> mentined above.  


coldtobi



--
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/1331663317.31494.36.ca...@mordor.loewenhoehle.ip

Re: NMU and delayed

[Tobias Frost]

Hallo Michael,

You do not need to wait for the NMU.
If you upload a newer version before the DELAY expires, the NMU is
automatically cancelled.

Am Freitag, den 13.04.2012, 01:39 +0400 schrieb Michael Tokarev:
> On 13.04.2012 01:08, Tomasz Muras wrote:
> > Hello,
> > 
> > A Debian developer has uploaded a NMU (moodle 1.9.9.dfsg2-5.1) to 
> > DELAYED/7-DAY [1]. I have incorporated his changes, and added a new release 
> > (moodle 1.9.9.dfsg2-6) - the changelog now looks like [2].
> > Is there any reason I should wait for that NMU to get processed in DELAYED 
> > queue? Or can I go ahead and upload a newer package with his and my changes?
> 
> You can actually ask the developer who uploaded that NMU.
> And I guess he gave you some information about this, too.
> 
> But, without actually looking at the provided links, I can
> say that usually an NMU which is uploaded into DELAYED queue
> especially gives the actual maintainer some time to catch up.
> Ie, if you can incorporate the changes and upload new version
> faster, just go ahead and do it.  Provided the DELAYED queue
> wasn't choosen due to some other reason, -- in which case
> the developer who uploaded it there will know better for sure,
> again...
> 
> Thanks,
> 
> /mjt
> 
> 


--
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/1334296814.6694.1.ca...@ithilien.loewenhoehle.ip

Re: Changing SONAME in library version

[Tobias Frost]

Am Montag, den 07.05.2012, 15:53 +0200 schrieb 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.

For soname changes you probably wanted to set up a transition.
http://wiki.debian.org/OngoingTransitions
(Usually that should be done before the upload to unstable) The
transistion page helps a lot to keep track of the transistion, so you
should ask the release team to set one up for you.

The release team will then also schedule the binNMUs for you.

For small transisions (only a few packages), it could make more sense to
manually request binNMUs as in desrcibed in the link from Jérémy. The
challenge could be to find out which packages are still using the old
version (especially on foreign architectures), but here your sponsor can
help you (using dak,
http://wiki.debian.org/ftpmaster_Removals#Reverse_Dependencies)



--
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/1336453800.23020.10.ca...@ithilien.loewenhoehle.ip

Re: Bug#669585: RFS: bibtexconv/0.8.14-1 -- Looking for a Debian sponsor

[Tobias Frost]

Am Freitag, den 20.04.2012, 09:19 +0200 schrieb Mathieu Malaterre:
> Thomas,
> 
>   Couple of quick comments:
> 
> *  d/copyright does not contains copyrights for debian/* files. 

(Disclaimer:I did not check the package in question)
I think this is no longer required from policy 3.9.3 on but correct me
if I got the sentence at 
http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt
wrong.

coldtobi


--
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/1338736145.3613.2.camel@moria

Re: RFS: solarpowerlog

[Tobias Frost]

Hallo Artur,

thanks for your quick response. 

On Thu, 2011-12-22 at 13:17 +0100, Artur R. Czechowski wrote:
> Tobias,
> 
> On Thu, Dec 22, 2011 at 12:37:36PM +0100, Tobias Frost wrote:
> > The one warning -- empty-debian-diff -- is emitted as I also keep the debian
> > files in the git repository I use for development of solarpowerlog. 
> > Naturally
> > the diff is empty in this case. 
> 
> If you are also the upstream developer and you are planning to always keep
> Debian package with released version in sync, you can consider making the
> package as a native package.

Yes, this is how I'd like to manage it. I'm upstream and also debian is
my build-target of choice (I'm only using debian since 7..8 yrs).

>  Technically, you indicate it by not adding
> the -debianversion suffix into version number. In such case debian diff
> shall be empty.
> However, in this case, any change only in debian packaging would require
> to release new version of your software.

This is ok for me. 

> I have two small utilities for I am also an upstream developer and I prefer
> to keep the sources free of Debian packaging stuff.
> 

Well, I'd like to keep them together as I am using more than one
computer for development I love that a single git-pull will update
everything.

So if it is ok to go native I will change the repository to refect this
tonight.

Regards, 
coldtobi

> Regards
>   Artur


--
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/1324561407.13630.31.ca...@mordor.loewenhoehle.ip

Re: RFS: solarpowerlog

[Tobias Frost]

Am Donnerstag, den 22.12.2011, 15:41 +0100 schrieb Abou Al Montacir:

Mmm, understood. It probably makes sense to keep it non-native.

Can you give me some pointer how to do this best? Is it done in
debian/rules, but which make target is best for it .. looking at the
policy get-orig-source might be suitable?

Another idea I have is to use git for this task and keep the debian
directory in a dedicated branch. I think this could integrate well when
using git-buildpackage 

coldtobi

> On Thu, 2011-12-22 at 14:43 +0100, Tobias Frost wrote: 
> > Hallo Artur,
> > 
> > thanks for your quick response. 
> > 
> > On Thu, 2011-12-22 at 13:17 +0100, Artur R. Czechowski wrote:
> > > Tobias,
> > > 
> > > On Thu, Dec 22, 2011 at 12:37:36PM +0100, Tobias Frost wrote:
> > > > The one warning -- empty-debian-diff -- is emitted as I also keep the 
> > > > debian
> > > > files in the git repository I use for development of solarpowerlog. 
> > > > Naturally
> > > > the diff is empty in this case. 
> > > 
> > > If you are also the upstream developer and you are planning to always keep
> > > Debian package with released version in sync, you can consider making the
> > > package as a native package.
> > 
> > Yes, this is how I'd like to manage it. I'm upstream and also debian is
> > my build-target of choice (I'm only using debian since 7..8 yrs).
> > 
> > >  Technically, you indicate it by not adding
> > > the -debianversion suffix into version number. In such case debian diff
> > > shall be empty.
> > > However, in this case, any change only in debian packaging would require
> > > to release new version of your software.
> > 
> > This is ok for me. 
> > 
> > > I have two small utilities for I am also an upstream developer and I 
> > > prefer
> > > to keep the sources free of Debian packaging stuff.
> > > 
> > 
> > Well, I'd like to keep them together as I am using more than one
> > computer for development I love that a single git-pull will update
> > everything.
> > 
> > So if it is ok to go native I will change the repository to refect this
> > tonight.
> 
> Please note that you can also keep a regular package by adding a make
> file target that creates a source tar gz deleting/excluding debian
> directory. Then you have everything in the same git and you are not
> forced to increase the version number for packaging issues.
> 
> Please take into account that your project is general purpose open
> source and will/might be packaged by others.
> 
> Cheers,


--
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/1324587745.3632.6.camel@moria

Re: RFS: solarpowerlog

[Tobias Frost]

Hallo George,

dbixxx is currently not used and could be removed for the moment -- I
only have a feature branch that needs this library, but this feature is
quite low priority for the moment. (Probably best I remove it from trunk
for the time being...)

About ctemplate -- this is unfortunatly I library I really needed for a
key feature of solarpowerlog. (solarpowerlog statically links to it)
I fear that this library is not very often used in other projects, so I
cannot tell if it would be accepted by debian as an own package. Also
upstream of this library seems not to be active, last release was in
2009. So basically libctemplate could also be considered more as a kind
of a part of solarpowerlog than an own library. Of course I monitor
upstream for any changes.

Nethertheless, I was already thinking about packaging it (if it can be
accepted in debian), but I thought to postpone this for a moment until I
gained some experience in art of packaging. 

My question is, would it be ok -- in this circumstances -- to keep
ctemplate part of solarpowerlog for the time being?

Regards,
-- 
coldtobi

Am Donnerstag, den 22.12.2011, 15:06 +0200 schrieb George Danchev:
> On Thursday 22 December 2011 13:37:36 Tobias Frost wrote:
> > Dear mentors,
> > 
> > I am looking for a sponsor for my package "solarpowerlog".
> > 
> >  * Package name: solarpowerlog
> >Version     : 0.21-1
> >Upstream Author : Tobias Frost 
> >  * URL : http://sourceforge.net/projects/solarpowerlog/
> >  * License : GPL, LGPL
> >Section : utils
> 
> Hi,
> 
> Few more comments, actually this is my first impression looking at your 
> source 
> package.
> 
> Embedded (external) code copies is almost always a bad idea, security-wise, 
> and places burden on -security team, -release team, and what not, to identify 
> and update potentially erroneous code copy.
> 
> $ cat extlibs/README 
> ~~
> In this folder, external code is placed which is used by solarpowerlog but 
> which is not available through debian packages:
> 
> Please check the projects information for details about copyright, license and
> authors -- the packages are provided "as is".
> 
> Folder  License Origin
> ctemplate   GPL http://libctemplate.sourceforge.net
> Used for templating the HTML output
> Modifications: 
> Added C++ Wrapper to the header file.
> Emits smaller pages due filtering double-blanks 
> 
> Folder  License Origin
> dbixx   LGPL2.1 
> http://cppcms.svn.sourceforge.net/viewvc/cppcms/dbixx/trunk/
> CppCMS LibDBI C++ Wrapper -- C++ Web Development Framework
> Modifications:
> ~~
> 
> 
> Sure, there are quite a few embedded copies already [1], and it would be sad 
> to keep adding even more. IMO, packaging dbixx and ctemplate separately 
> should 
> be the way to go, so they could be easily identified in case of trouble, 
> fixed 
> just once, and potentially re-used as build-dependencies by other packages.
> 
> However, as far as I can see it, there is unfortunate upstream name clash. 
> The 
> source package name of 'ctemplate' has already been taken by another 
> unrelated 
> package, so maybe you can put 'html' in the source and binary package names 
> (perhaps 'chtmltemplate'?) if you decide to package and maintain this one: 
> http://libctemplate.sourceforge.net separately.
> 
> 
> [1] http://wiki.debian.org/EmbeddedCodeCopies
> 


--
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/1324590576.3632.34.camel@moria

Re: RFS: solarpowerlog

[Tobias Frost]

Am Donnerstag, den 22.12.2011, 19:59 -0200 schrieb Fernando Lemos:
> On Thu, Dec 22, 2011 at 10:17 AM, Artur R. Czechowski  wrote:
> > On Thu, Dec 22, 2011 at 12:37:36PM +0100, Tobias Frost wrote:
> >> The one warning -- empty-debian-diff -- is emitted as I also keep the 
> >> debian
> >> files in the git repository I use for development of solarpowerlog. 
> >> Naturally
> >> the diff is empty in this case.
> >
> > If you are also the upstream developer and you are planning to always keep
> > Debian package with released version in sync, you can consider making the
> > package as a native package.
> 
> Just to clarify, this piece of information is completely wrong.
> Quoting the mentors FAQ:
> 
> "You should only use a native Debian package when it is clear that the
> package would only ever be of use in Debian. Even if the software is
> currently only available in Debian, if someone could reasonably use
> the software on another distribution or on another operating system,
> then the package should be non-native. A few examples of normal
> packages are: libc6, apache, phpmyadmin. But lintian, dpkg and some
> other tools are purely developed for debian, and make no sense being
> released in another distribution."
> 
> It's not a matter of choice. If your package is not Debian-specific,
> it can't and won't be uploaded as a native package.

OK. 
I saw this explanation, and I saw the mail from Artur. so I thought
that it *seems* also to be ok. You are the experts in packaging, not me
and I had no reasons not to belive him.

> Now another big problem with your package is that it's using source
> package format 1.0. This is ancient, and for a new package entering
> the repositories, you should probably use format 3.0 (quilt). This
> would make your warning go away as well.

I commited to my repositories today 3.0 (native) after the mail from
Artur when figuring out how to switch to a native format. It read 1.0 as
I probably generated that file back in years ago I forgot to check this
file for updates.

I wonder why lintian did not tell me about this.

However, I already updated it to 3.0 (quilt) and will give it a try
tomorrow.  

> Don't try to take shortcuts because you're upstream. When you're
> packaging your software, think of it as if you weren't the upstream
> author. Debian doesn't care if you're the upstream author or not, and
> the tools will complain if you try to take shortcuts. It's crucial to
> keep this in mind.

> Also, although I didn't review your package, I noticed that Vcs-* is
> pointing to your development repositories. It should instead point to
> the repositories where the Debian packaging is hosted (usually in
> Alioth), if it's managed by a VCS at all. Again, development and
> packaging are separate roles.

http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-vcs
readed exactly as I need to enter the link to my VCS.
However, in my local copy this lines have already been removed.  

> One final piece of advice: please *read* the new maintainers' guide,
> the Debian policy and the mentors FAQ. This is all documented and very
> well explained. I don't mean to sound rude, but the fact that you're
> using format 1.0 and contemplating creating a native package for this
> is indicative that you might have missed simple stuff that's very well
> documented.

This is what I did now for some time. I think the documentation is not
that self-explanatory or otherwise I would have got it right the very
first time.  But I think that is why debian has mentors, and why this is
a very good idea.

Of course, I need also to rely on that the information given on this
mailing list is correct and not finding out one response later that I'm
getting blamed for being told wrong information. 

> Regards,
> 
> 


--
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/1324602917.8075.46.camel@localhost

Re: RFS: solarpowerlog

[Tobias Frost]

Am Freitag, den 23.12.2011, 01:20 +0200 schrieb George Danchev:
> On Thursday 22 December 2011 23:49:36 Tobias Frost wrote:
> > Hallo George,
> 
> Hoi,
> 
> (top posting is not preferred:)
> 
> > dbixxx is currently not used and could be removed for the moment -- I
> > only have a feature branch that needs this library, but this feature is
> > quite low priority for the moment. (Probably best I remove it from trunk
> > for the time being...)
> 
> Okay, let's forget dbixx for a while.
> 
> > About ctemplate -- this is unfortunatly I library I really needed for a
> > key feature of solarpowerlog. (solarpowerlog statically links to it)
> > I fear that this library is not very often used in other projects, so I
> > cannot tell if it would be accepted by debian as an own package. Also
> > upstream of this library seems not to be active, last release was in
> > 2009. So basically libctemplate could also be considered more as a kind
> > of a part of solarpowerlog than an own library. Of course I monitor
> > upstream for any changes.
> 
> Well, you can't have it both ways, either it has its own upstream (and so 
> packaged separately as source, and resp. binary packages) or you claim to 
> adopt it upstream jammed into your own project upstream. Even in that latter 
> case, you can still split separate shared library and -dev binary packages. 

No, not what I mean... My message should be more like "upstream
development seems to have ceased" and "I use the code not like a library
but more like as the code would be contained in my src directory". I
just keep it seperate ensure that everyone knows that this is code is
not programmed by myself.
To illustrate, I modified it to generate 25% smaller files (by
eliminating double whitespaces) but the upstream author did not want to
add this feature to his codebase. (so actually I use a fork of his
library).

I would love to keep that feature for solarpowerlog, but if it will be
packaged for "general" use I probably need to drop that feature as it
has a sligthly different behaviour in respect to the version at
sourceforge.

> Of 
> course, it would be better to be packaged as a separate source package, since 
> it is still a separate upstream project, and it doesn't even look tiny to be 
> merged into another, larger one.

Its tiny... It is only two files that makes the library. The remaining
files parts are examples. 

> > Nethertheless, I was already thinking about packaging it (if it can be
> > accepted in debian), but I thought to postpone this for a moment until I
> > gained some experience in art of packaging.
> 
> There is no rush, have your time.
> 
> > My question is, would it be ok -- in this circumstances -- to keep
> > ctemplate part of solarpowerlog for the time being?
> 
> Why going that route? It would be a compromise, which could be avoided. You 
> don't want your favorite distro to be full of packaged stuff, which embeds 
> copies and statically links to them :)

Well, I got and agree with your point in general.. Im just wondering, if
I actually still just *use* this library or I *specialized* it to suit
my program better...

(Opps, it almost 3 am I better go to bed now.)

coldtobi


--
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/1324605075.8075.75.camel@localhost

Re: RFS: solarpowerlog

[Tobias Frost]

Hallo,

I implemented your suggestions and re-uploaded the package. 

I also eliminated the "empty-debian-diff" linitian warning by now using a 
dedicated branch for the debian/ foler.

regards,
coldtobi


Am Donnerstag, den 22.12.2011, 12:37 +0100 schrieb Tobias Frost:
> Dear mentors,
> 
> I am looking for a sponsor for my package "solarpowerlog".
> 
>  * Package name: solarpowerlog
>Version     : 0.21-1
>Upstream Author : Tobias Frost 
>  * URL : http://sourceforge.net/projects/solarpowerlog/
>  * License : GPL, LGPL
>Section : utils
> 
> It builds those binary packages:
> 
> solarpowerlog - logging photovoltaic data
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/solarpowerlog
> 
> Alternatively, one can download the package with dget using this command:
> 
>   dget -x 
> http://mentors.debian.net/debian/pool/main/s/solarpowerlog/solarpowerlog_0.21-1.dsc
> 
> I would be glad if someone uploaded this package for me.
> 
> This is my very first request to sponsor a package, so it might be that I 
> missed something. Please point out if I missed something.  
> The package has been tested with pdebuilder dpkg-buildpackage, 
> git-buildpackage and has also been linitian checked (one warning -- described 
> below) 
> 
> The one warning -- empty-debian-diff -- is emitted as I also keep the debian 
> files in the git repository I use for development of solarpowerlog. Naturally 
> the 
> diff is empty in this case. 
> 
> Kind regards,
> 
> Tobias Frost
> 
> 
> 





--
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/1324676512.4875.1.camel@moria

Re: RFS: solarpowerlog (improved...)

[Tobias Frost]

A happy new year, dear mentors,

It seems that the boost thread library contains a bug making the version
supplied with this RFS broken (Debian BTS #653922). 

Upstream version 0.21a addresses this by requiring boost >= 1.48.

However, due to #653228 I cannot provide an updated debian package at
this time, as build-depends: libboost-dev (>= 1.48) won't pull in the
required version.

I update as soon as the boost transistion is done.

However, please go forward with the review of the package, and to ease
things I'd appreciate if a DD steps forward and indicated his/her will
to sponsor this package, to define clear goals and clear actions whats
needed to get this package into debian and avoiding wasting effort by
focused work.

BR
coldtobi

Am Dienstag, den 27.12.2011, 20:04 +0100 schrieb Tobias Frost:
> Dear mentors,
> 
> I am (still) looking for a sponsor for my package "solarpowerlog".
> However since my last request I had the opportunity to have some review on 
> the mentors mailing list
> as well on IRC (#debian-mentors) and got many hints and suggestions which 
> have been already implemented
> in the latest upload, as usual available through 
> http://mentors.debian.net/package/solarpowerlog
> or using
> dget -x 
> http://mentors.debian.net/debian/pool/main/s/solarpowerlog/solarpowerlog_0.21-1.dsc
> 
>  * Package name: solarpowerlog
>Version : 0.21-1
>Upstream Author : Tobias Frost 
>  * URL : http://sourceforge.net/projects/solarpowerlog/
>  * License : GPL, LGPL
>Section : utils
> 
> I would be glad if someone uploaded this package for me.
> 
> Kind regards,
> 
> Tobias Frost
> 
> 


--
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/1325445978.14293.18.camel@moria

Re: RFS: policyd-weight

[Tobias Frost]

Am Dienstag, den 03.01.2012, 04:10 +0800 schrieb Thomas Goirand:

> > OK, got it *but* what revision do i have to use?
> > http://anonscm.debian.org/viewvc/dep/web/deps/dep5.mdwn?revision=?
> > 
> > Thanks,
> > Werner
> 
> As per:
> http://anonscm.debian.org/viewvc/dep/web/deps/dep5/
> 
> the latest revision seem to be 240.
> 
> Thomas
> 

Mmmh, Wouldn't it be a great idea to mention this also in the
documention at http://dep.debian.net/deps/dep5/ ?
There it tells you to use 
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
(which gives you a 404...)

coldtobi


--
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/1325541631.4741.2.ca...@mordor.loewenhoehle.ip

Re: How to test the presence of packages ?

[Tobias Frost]

Am Dienstag, den 03.01.2012, 14:29 -0430 schrieb Luis Alejandro Martínez
Faneyth:
> If you need a simple script logic, you could use bash like this:
> 
> ==>8==>8==
> #!/bin/bash
> 
> PACKAGES="package1 package2 package3"
> 
> for PACKAGE in ${PACKAGES}; do
> 
> dpkg -l ${PACKAGE} > /dev/null 2>&1
> 
> if [ !$? ]; then
> aptitude install ${PACKAGE}
> fi
> done
> ==>8==>8==
> 
> Now, if you need this at package level, you should listen to Pietro's
> advices.
> 

.. of course you would never use such a snipped from a package install
script. The only way is to use dependencies.


--
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/1325619908.3249.4.camel@moria

Re: RFS: roxterm 2.4.2-1 (was 2.4.1-1)

[Tobias Frost]

Am Donnerstag, den 05.01.2012, 13:30 + schrieb Tony Houghton:

> The debian packaging and upstream are in one repository and I didn't
> want the contents of the release tarball to be inconsistent with what's
> in the package. I would also have to change the way I use git tags to
> generate a version number dynamically.

I do it that way: 
I use a dedicated git branch for the debian stuff, containing the
the debian stuff (and the source, but source is not edited in this
branch)
The developement (on the source) is done in a different branch and
whenever I want to make a debian package I just merge the latest source
into the "debian branch".  
This way your tricks with git-tags could still work. (Anyway, can you
elaborate on this, as I am curious about this idea)

> I think I'll separate the debian packaging from upstream soon, it does
> seem more practical overall. But I still don't really understand how
> automated tools can find the upstream source as well as the packaging
> from the Vcs control fields when they're in separate repositories.

I was told that the VCS cotnrol fields are not meant for "upstream" but
only to point to servers on the debian infrasturcture to contain the 
packaging stuff. 
(http://lists.debian.org/debian-mentors/2011/12/msg00407.html)





--
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/1325859161.3548.23.camel@moria

Re: Symbols and C++ inline constructor

[Tobias Frost]

Just a general remark just came into my mind about the symbols
dicssusion:

Is is really *safe* to use inline methods as API in libraries?

My belly states "no", because you might found yourselg to be unable to
fix bugs in library, if the software using the interface will use a
inline here and if there is a change the software needs to be
recompiled. 
(For example one needs a new variable in the to be
instanciated class, the inlined "code-copy" constructor will 
not know about that and will not initiate this one...)

coldtobi 





Am Samstag, den 07.01.2012, 19:46 +0100 schrieb Thomas Weber:
> On Fri, Jan 06, 2012 at 05:14:32PM -0800, Russ Allbery wrote:
> > Thomas Weber  writes:
> > > On Fri, Jan 06, 2012 at 12:14:11AM +, Roger Leigh wrote:
> > 
> > >> IIRC inline is only a hint--it's not guaranteed to
> > >> be inlined if the compiler thinks it's more efficient not to.  
> > 
> > > That is exactly my problem. A newer compiler version might change the
> > > decision of the former version due to better optimization; but then I
> > > see no way to guarantee stable symbols in the library.
> > 
> > If it's a private symbol not intended to be used by clients and that
> > wouldn't naturally be used by clients, you can mark it optional in the
> > symbols file (symbol tag optional), and then the symbols generation won't
> > care if it appears and disappears.
> 
> This doesn't answer my question, does it? I mean, your statement is true
> for whatever symbol that appears in the symbol file. My question is
> about inlined class methods specifically and the fact that the compiler
> might change its opinion about them with even minor version bumps.
> 
> > You have to do that for some things with C++, since there are places where
> > C++ just doesn't give you control over what symbols are exported.
> 
> One of the things that I find frustrating is the total lack of reliable
> and complete documentation about symbols; yet library maintainers are
> expected to keep the symbols file sane.
> 
> Example from dpkg-gensymbols (5):
> "For example, most of C++ template instantiations fall into this
> category" (it's talking about optional symbols here). 
> 
> So, which template instantiations are *not* safe to be tagged as
> optional? This is a different question, but I have quite some template
> instantiations in the symbol file as well. 
> 
>   Thomas
> 
> 


--
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/1326014802.6280.7.camel@moria

Bug#655184: FTBFS with Boost 1.48: dcpp/Atomic.h:60:45: error: 'boost::interprocess::detail' has not been declared

[Tobias Frost]

Package: eiskaltdcpp
Followup-For: Bug #655184

Dear Mentors,

please take a look at the package update from Boris Pek and maybe consider 
uploading the package.
It fixes a FTBFS due to the libboost transition. 

You can find the package here:

http://mentors.debian.net/package/eiskaltdcpp
http://mentors.debian.net/debian/pool/main/e/eiskaltdcpp/eiskaltdcpp_2.2.5-1.dsc


-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.1.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
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/20120109202732.5906.43436.reportbug@localhost.localdomain

RFS: dizzle (NMU, fixes 3 RC bugs)

[Tobias Frost]

Dear mentors,

I kindly ask you sponsoring a NMU on this package. It fixes 3 RC-bugs
(#647709, #647743, #653627) and was crafted on a minimal-invasiv-basis.

 * Package name: drizzle
   Version : 2011.03.13-1.1
   Upstream Author : Drizzle Developers team
 * URL : http://www.drizzle.org/
 * License : GPL
   Section : misc

It builds those binary packages:

 drizzle- Server binaries for Drizzle Database
 drizzle-client - Client binaries for Drizzle Database
 drizzle-dbg - Debugging symbols for Drizzle
 drizzle-dev - Development files for Drizzle development
 drizzle-doc - API Documentation for Drizzle internals
 drizzle-plugin-auth-file - File-based authentication for Drizzle
 drizzle-plugin-auth-http - HTTP authentication for Drizzle
 drizzle-plugin-auth-ldap - LDAP authentication for Drizzle
 drizzle-plugin-auth-pam - PAM authentication for Drizzle
 drizzle-plugin-dev - Development files for Drizzle plugin development
 drizzle-plugin-filtered-replicator - Filtered Replicator for Drizzle
 drizzle-plugin-gearman-udf - Gearman User Defined Functions for Drizzle
 drizzle-plugin-haildb - HailDB Storage Engine for Drizzle
 drizzle-plugin-logging-gearman - Gearman Logging for Drizzle
 drizzle-plugin-logging-query - Query Logging for Drizzle
 drizzle-plugin-mysql-protocol - MySQL Protocol for Drizzle
 drizzle-plugin-mysql-unix-socket-protocol - MySQL Unix Domain Socket
Protocol for Drizzle
 drizzle-plugin-pbms - PrimeBase Blob Streaming for Drizzle
 drizzle-plugin-performance-dictionary - Performance Dictionary for
Drizzle
 drizzle-plugin-rabbitmq - RabbitMQ Transaction Log for Drizzle
 drizzle-plugin-simple-user-policy - Simple User Policy for Drizzle
 drizzle-plugin-slave - Replication Slave Plugin for Drizzle
 libdrizzle-dbg - library for the Drizzle and MySQL protocols, debug
symbols
 libdrizzle-dev - library for the Drizzle and MySQL protocols,
development files
 libdrizzle1 - library for the Drizzle and MySQL protocols
 libdrizzledmessage-dev - Devel library containing serialized messages
used with Drizzle
 libdrizzledmessage0 - Library containing serialized messages used with
Drizzle

To access further information about this package, please visit the
following
URL:

  http://mentors.debian.net/package/drizzle

Alternatively, one can download the package with dget using this
command:
  dget -x
http://mentors.debian.net/debian/pool/main/d/drizzle/drizzle_2011.03.13-1.1.dsc

To be as minimal-invasive as possible, this NMU does only address the RC
bugs, and not other things (like there are e.g some whitespaces in
debian/control etc, ...) Therefore it is still not linitian-clean.

In #653627 I announced my intention to NMU and asked the maintainer to
object, also CC'ed him again with this RFS, so I would propose to upload
it to the delayed queue. 

For #647709, please review debian/control, if the rules to exlude the
build-dependency on libaio-dev for the ports kfreebsd-* in
debian/control looks sane to you. I used those the very first time and I
also do not have a kfreebsd installed, so I'd be happier if someone
could put an extra pair of eyes on it. However, I used pdebuilder to
ensure that drizzle also compiles without this build-dependency.

The NMU fixes this 3 RC bugs:
 #647709 [src:drizzle] drizzle: unbuildable on kfreebsd-amd64 (but
previously built there)

#647743  [src:drizzle] drizzle: FTBFS on several architectures
("Graphite loop optimizations can only be used if the libcloog-ppl0
package is
installed")

#653627  [src:drizzle] build failure with Boost 1.48: constructor
'boost::detail::shared_count::shared_count(P,
boost::detail::sp_inplace_tag)'

Best regards,
coldtobi


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

Re: Current and upcoming toolchain changes for jessie

[Tobias Frost]

Am Donnerstag, den 13.06.2013, 15:46 +0100 schrieb Steven Chamberlain:
> Hi,
> 
> On 13/06/13 13:51, Matthias Klose wrote:
> > GCC 4.8 is now the default on all x86 architectures, and on all ARM
> > architectures (the latter confirmed by the Debian ARM porters).  I did not 
> > get
> > any feedback from other port maintainers, so unless this does change and 
> > port
> > maintainers get involved with toolchain maintenance, the architectures 
> > staying
> > at 4.6 or 4.7 shouldn't be considered for a successful release 
> > (re-)qualification.
> 
> I trust these are the architectures that are okay so far:
> | gcc48_archs = amd64 armel armhf arm64 i386 x32 kfreebsd-amd64
> kfreebsd-i386 hurd-i386
> 
> So the following would be the architectures for which some response is
> requested urgently from port maintainers, to confirm they are ready for
> GCC 4.8 as default:
> 
> Release arches: ia64 mips mipsel powerpc s390 s390x sparc

Is there some kind of timeframe expected when switch can be expected?

I'm asking because I currently have some tool chain related build
failure on the above archs (except ia64) for drizzle [1] (Bug 708434) --

From here, it looks like that the gcc 4.6.3-14 used on this archs needs
a bin-nmu (?), as it is still expecting libcloog-ppl0, which is no
longer available. [2]

Matthias, could I be on the right path? What would be the right procedure
here? (CC'ing d-mentors for this question)

coldtobi

[1] https://buildd.debian.org/status/logs.php?pkg=drizzle&ver=1%
3A7.1.36-stable-4&suite=sid
[2] http://packages.qa.debian.org/c/cloog-ppl.html


--
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/1371151240.6107.0.ca...@mordor.loewenhoehle.ip

Re: ExpoSong package

[Tobias Frost]

Am Mittwoch, den 26.06.2013, 11:40 +0200 schrieb Samuel Mehrbrodt:
> Hi,
> Do I really need to have a manpage for my program?
> And what is a watch file?
> 

Yes, you need a manpage, see policy 12.1
(It will also create the lintian warning binary-without-manpage)

A watch file helps to detect if there is a new upstream version.
See uscan(1), http://wiki.debian.org/debian/watch/ and the policy 5.22

coldtobi


--
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/1372245892.18576.10.ca...@mordor.loewenhoehle.ip

Re: dependent packages blocked from testing

[Tobias Frost]

Ltt-controls has not been built on all archs (those out of date messages on the 
PTS). Seems that there are build deps not available.
(Take a look at the buildds status page)



Jon Bernard  schrieb:

>Hello,
>
>I'm facing a problem with two packages that are blocked from migrating
>into
>testing.  I'm having trouble seeing a clear path forward and I wonder
>if anyone
>could point me in a better direction.
>
>The specific packages are ltt-control[1] and ust[2].  If the source
>packages
>only built a single binary package, then apt's arbitrary selection of
>one to
>break the dependency chain would work, from what I understand.  But in
>this case
>each source package builds several binary packages and I do not see a
>clean way
>out of this (other than asking the release team to manually move them,
>but
>I would prefer to find a proper solution).  Is there any advise for
>this
>situation?  Specifically, how do I get out of this mess cleanly, and
>what could
>I have done differently to prevent this from ever happening?
>
>[1]: http://release.debian.org/migration/testing.pl?package=ltt-control
>[2]: http://release.debian.org/migration/testing.pl?package=ust
>
>Cheers,
>
>-- 
>Jon
>
>
>-- 
>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/20130718233730.GB19047@helmut.local

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: dependent packages blocked from testing

[Tobias Frost]

Am Freitag, den 19.07.2013, 13:02 +0600 schrieb Andrey Rahmatullin:
> On Fri, Jul 19, 2013 at 07:53:51AM +0200, Tobias Frost wrote:
> > Ltt-controls has not been built on all archs (those out of date messages on 
> > the PTS). Seems that there are build deps not available.
> > (Take a look at the buildds status page)
> It waits for ust to be built on ia64, mips, mipsel, s390, s390x and sparc.

Ok, lets analyze 
buildd's status page says:
"Dependency installability problem for ltt-control on hurd-i386,
kfreebsd-amd64 and kfreebsd-i386:

  ltt-control (= 2.1.1-2) build-depends on missing:
  - liburcu-dev (>= 0.7.4)

So on the above archs, it does not build due to problems with
liburcu-dev. But as this archs are never built before, so they are
not blocking the transistion. Of course, you could take a look at
liburcu if you can fix the FTBFs...


> Out of those, ia64 build just fails while mips, mipsel, s390x and sparc
> need systemtap-sdt-dev, which does not exist on those arches for at least
> quite some time. s390 has "No entry in s390 database" which I have no idea
> about.

Yes, for those archs you'll need fix ust, which has problems with
systemtap-sdt-dev.  
As Systemtap-sdt-dev is only available for i386 amd64 ia64 s390 powerpc
armel armhf, you 
1) (if possible) configure ust to not use systemtap-sdt on the other
archs  (I do this for example in drizzle, there drizzle's configure
automatically checks if it is available and does not utilize it if not
-- of course debian/control then needs arch-dependent
build-dependencies)
2) only build for those archs where system-tap is available. 
Note: You need to file an remove request for the old version on the
unsupported archs for ust, as they otherwise will block the transition. 

(If you go for 2), the rm requests are also needed for ltt-control)


coldtobi

> > Jon Bernard  schrieb:
> > 
> > >Hello,
> > >
> > >I'm facing a problem with two packages that are blocked from migrating
> > >into
> > >testing.  I'm having trouble seeing a clear path forward and I wonder
> > >if anyone
> > >could point me in a better direction.
> > >
> > >The specific packages are ltt-control[1] and ust[2].  If the source
> > >packages
> > >only built a single binary package, then apt's arbitrary selection of
> > >one to
> > >break the dependency chain would work, from what I understand.  But in
> > >this case
> > >each source package builds several binary packages and I do not see a
> > >clean way
> > >out of this (other than asking the release team to manually move them,
> > >but
> > >I would prefer to find a proper solution).  Is there any advise for
> > >this
> > >situation?  Specifically, how do I get out of this mess cleanly, and
> > >what could
> > >I have done differently to prevent this from ever happening?
> > >
> > >[1]: http://release.debian.org/migration/testing.pl?package=ltt-control
> > >[2]: http://release.debian.org/migration/testing.pl?package=ust
> > >
> > >Cheers,
> > >
> > 
> 
> -- 
> WBR, wRAR
> 
> 


--
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/1374273797.7060.25.ca...@ithilien.loewenhoehle.ip

Re: RFS: xchroot-v2.3

[Tobias Frost]

Hallo Elmar,

Not sure what your intention of this mail was, but I think its either
that you want to tell that xchroot might be worth for Debian or you
want to express your intention to package it yourself which brought you 
to the mentors mailling list.

Well, in the first case you should file a RFP bug against WNPP
(see http://www.debian.org/devel/wnpp/ ), in the second you should read
http://mentors.debian.net/intro-maintainers and package it yourself
(you need also to file a ITP bug against WNPP and when ready to submit
it to mentors file a RFS bug against sponsorship-requests. Read
http://mentors.debian.net/sponsor/rfs-howto for the procedure.)

coldtobi

Am Samstag, den 31.08.2013, 12:35 +0100 schrieb Elmar Stellnberger:
> name of the package: xchroot
> license: QPL-like; see for the program header or run the program with 
> --license
> short description: extended chroot with X11/Xorg forwarding and 
> aufs/unionfs support for read only roots
> long description:
>xchroot is a little convenience bash script that will allow you to 
> run X-based programs in your chroot environment.
> You may also chroot to a new environment without touching any of its 
> files either by using aufs and unionfs. You
> may backup your temporary changes on exit and kill of xchroot as 
> squashfs and incrementally restore them.
> 
> download URL:
>http://www.elstel.org/xchroot
>https://www.elstel.org/xchroot
> 
> why you should prefer packaging xchroot from elstel over xchroot from 
> mosquito:
> * the program is known to deliver good quality since years and is also 
> officially recommended by the openSUSE build service guide
> * the program is being actively developed; completely new features are 
> planned.
> * there is a good online documentation for the program which does also 
> leverage usage by casual users and users new to Linux
> * the incremental --save and --restore options not supported by mosquito 
> will make life of packagers easy and leverage usage from read-only root 
> file systems like roots on blue ray
> * unionfs as well as aufs support guarantee for a broad applicability; 
> f.i. when dual booting between a distribution that only supports unionfs
> * support also for casual users
> 
> why you should not package xchroot from mosquito:
> * no accomplished cleanup, kill -9 of processes, bugs and fallacies I do 
> not want to talk about.
> * writing a completely different program and then giving it the same 
> name as an already existent program will confuse innocent users (mine 
> has already been there for years and it has been published under the 
> name xchroot for a much longer time.)
> * the program has not been tested well under different conditions
> * no unionfs, no socat, no incremental restore, no good automounting 
> support.
> * no backward compatibility with Debian 6.0.x
> * the authors did not respond at all on my request to join the work on 
> elstel and to put xchroot under a better, generally accepted license
> 
> P.S.: I believe it would also be good choice to support this script 
> under the rescue console. When chrooting to a debian installation you 
> will otherwise have to mount a lot while mounting everything of use is 
> still too much for manual usage. This is a very common task for 
> maintenance activities; I even do that when running grub-install.
> 
> 
> 
> 
> 
> 
> 
> 


--
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/1377951816.1558.8.ca...@mordor.loewenhoehle.ip

Re: Maintainer of GNS3 and Dynamips

[Tobias Frost]

Hallo Daniel,

maybe you want also to file a wishlist bug "new upstream version"
available against the packages. You can also upload your package to
debian-mentors and give a link to the .dsc in the filed bugs and then
maybe wait some time for reaction.

There is a procedure in the developer manual which handles MIA, maybe
you want to proceed as suggested here: 
https://wiki.debian.org/qa.debian.org/MIATeam

Best regards,
coldtobi

Am Sonntag, den 15.09.2013, 12:01 +0100 schrieb Daniel Lintott:
> Hi Mentors,
> 
> Does anyone here know if Erik Wenzel (e...@debian.org) is still active
> in the debian community?
> 
> He's listed as the the maintainer for both gns3 and dynamips, both of
> which are severely outdated know. I sent Eric an email a fortnight
> ago, but have not heard anything back.
> 
> I have been creating some new packages for GNS3/Dynamips, particularly
> for Ubuntu users, which I'm distributing the a Launchpad PPA, with
> backing from the upstream authors.
> 
> Myself and the other guys at gns3.net would really like to see these
> packages updated, but appreciate that this needs to be done properly
> and through the right process.
> 
> Regards
> 
> Daniel Lintott
> 


--
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/1379250453.4974.26.ca...@mordor.loewenhoehle.ip

Bug#723584: RFS: dcl/0.1-1 ITP

[Tobias Frost]

Halo Fernando,

(i'm not a DD)

Some first look at the package soley at mentors:
- copyright (and d/copyright) file ist missing (make sure always to run lintian 
best with pedantic and experimental options)
-  please fix all lintian warnings. (I count 7
- you need to file an itp bug and close it in the changelog
- 




Fernando  schrieb:
>Package: sponsorship-requests
> Severity: normal 
>
> Dear mentors,
>
> I am looking for a sponsor for my package "dcl"
>
>* Package name: dcl
>  Version : 0.1-1
>  Upstream Author : Fernando Iazeolla 
>* URL : http://github.com/elboza/dcl
>* License : GPL
>  Section : utilities
>
> It builds those binary packages:
>
>   dcl   - D-cleaner (Disk && Directory Cleaner)
>
>To access further information about this package, please visit the
>following URL:
>
> http://mentors.debian.net/package/dcl
>
>
>Alternatively, one can download the package with dget using this
>command:
>
> dget -x http://mentors.debian.net/debian/pool/main/d/dcl/dcl_0.1-1.dsc
>
>More information about dcl can be obtained from
>http://github.com/elboza/dcl.
>
> Changes since the last upload:
>
>dcl (0.1-1) unstable; urgency=low
>
>* Initial release (Closes: #)  
>
>-- Fernando Iazeolla   Sun, 15 Sep 2013 23:21:52 +0200
>
>
>
> Regards,
>  Fernando Iazeolla
>
>--
>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/fb51f6ee-6299-45ed-900b-55c8bdd5e...@yahoo.it

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Bug#723583: RFS: avt/0.2-1 ITP

[Tobias Frost]

Same as with dcl : Please first fix all the lintian warnings.



Fernando  schrieb:
>Package: sponsorship-requests
>Severity: normal 
>
>Dear mentors,
>
>I am looking for a sponsor for my package "avt"
>
>* Package name: avt
> Version : 0.2-1
> Upstream Author : Fernando Iazeolla 
>* URL : http://github.com/elboza/avt
>* License : GPL
> Section : utilities
>
>It builds those binary packages:
>
>  avt   - Aviation Tools. metar and taf command line.
>
>To access further information about this package, please visit the
>following URL:
>
>http://mentors.debian.net/package/avt
>
>
>Alternatively, one can download the package with dget using this
>command:
>
> dget -x http://mentors.debian.net/debian/pool/main/a/avt/avt_0.2-1.dsc
>
>More information about avt can be obtained from
>http://github.com/elboza/avt.
>
>Changes since the last upload:
>
>avt (0.2-1) unstable; urgency=low
>
>* Initial release (Closes: #)  
>
>-- Fernando Iazeolla   Sun, 15 Sep 2013 22:58:17 +0200
>
>
>
>Regards,
> Fernando Iazeolla
>
>--
>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/f66d5818-8d6c-47f5-8331-924e7162c...@yahoo.it

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Bug#723582: RFS: metar/0.2-1 ITP

[Tobias Frost]

Same as with dcl : Please first fix all the lintian warnings.



Fernando  schrieb:
>Package: sponsorship-requests
>Severity: normal 
>
>Dear mentors,
>
>I am looking for a sponsor for my package "metar"
>
>* Package name: metar
> Version : 0.2-1
> Upstream Author : Fernando Iazeolla 
>* URL : http://githib.com/elboza/metar
>* License : GPL
> Section : utilities
>
>It builds those binary packages:
>
>  metar - a simple command line metar and taf.
>
>To access further information about this package, please visit the
>following URL:
>
>http://mentors.debian.net/package/metar
>
>
>Alternatively, one can download the package with dget using this
>command:
>
>dget -x
>http://mentors.debian.net/debian/pool/main/m/metar/metar_0.2-1.dsc
>
>More information about metar can be obtained from
>http://github.com/elboza/metar.
>
>Changes since the last upload:
>
>metar (0.2-1) unstable; urgency=low
>
>* Initial release (Closes: #)  
>
>-- Fernando Iazeolla   Mon, 09 Sep 2013 22:32:41 +0200
>
>
>
>Regards,
> Fernando Iazeolla
>
>--
>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/047d4b42-5dee-4eec-b177-25a0a3ae9...@yahoo.it

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Bug#723583: RFS: avt/0.2-1 ITP

[Tobias Frost]

Hallo Fernando,

Some additional notes:
(Disclaimer: I'm not a DD/DM; also I am quite new to reviewing...)

* avt seems to me not as a best-practice name: it is very short (and
might cause name collisions later), does not give a glue about the
package. How's about aviation-tools 

* As said already, please check your package with a recent version of
lintian. I won't repeat here what lintian tells. But it will be very
hard to find a sponsor with lintian problems present and good
explanations absent.

*d/compat: why not 9?

*d/control: your B-D on debhelper needs not version >8.0.0, >8 is
sufficient. (or >9, when you change d/compat)

* d/control: short description should be reworked, see policy §3.4, same
for the extended description:
"The description field needs to make sense to anyone, even people who
have no idea about any of the things the package deals with." (From the
policy)

*d/copyright is missing. Lintian told that already, but when you create
it, use the dep5 format.
(https://wiki.debian.org/Proposals/CopyrightFormat)

regards,
coldtobi


--
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/1379612472.30374.16.ca...@mordor.loewenhoehle.ip

Bug#723626:

[Tobias Frost]

Hallo Jon,

(Disclaimer: I'm not a DD/DM; also I'm quite new in reviewing, so I
might also overlook smth or be wrong)

Some notes while I looked at your package:
* d/patches/* please add dep3 headers. 
* Can you upgrade standards-version to 3.9.4?
* Please enable hardening (maybe along with setting d/compat to 9)
* Add yourself to debian/copyright. Maybe update it to dep5 format?
* orig source cannot be downloaded: I get a access denied error. Maybe
get in contact with upstream?
* d/rules I like debhelper short form better than the old one, might be
worth to upgrade as I find it easier to maintain.

Best regards,
coldtobi


--
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/1379616887.12899.11.ca...@mordor.loewenhoehle.ip

Bug#699723:

[Tobias Frost]

Hallo Dave,

(I am not a DD/DM; also I am new to reviewing, so I might missed smth or
I might be wrong)

Note: This refers to 0.6.15-3 on mentors

* d/changelog: usually you skip those versions NOT uploaded to Debian
and you document only changes made to the Debian packaging, not the
(upstream) changes of the source. 
* Therefore your version should be 0.6.15-1 and your d/changelog should
start with "New upstream release."
* There's some lintian infos like those:
I: podget: hyphen-used-as-minus-sign usr/share/man/man7/podget.7.gz:61
* You can remove d/rules.old
* Seems you maek your manpage manually with txt2man... I think it is
preferable to do that automatically buildtime


Best regards,
coldtobi


--
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/1379619129.12899.24.ca...@mordor.loewenhoehle.ip

Bug#721839: RFS: musl/0.9.13-2 [ITP]

[Tobias Frost]

Hi Kevin,

Am Freitag, den 20.09.2013, 21:52 +0200 schrieb Kevin Bortis:
> - Changelog should have just one note: "Initial packaging, Closes...".
> First debian/changelog entry closes ITP
> Last debian/changelog closes RFS
> OK like this?
No, RFS are not to be closed within the changelog. Your sponsor will
close it after uploading manually.

> 
> > The package was not yet uploaded into Debian.
> > - The package number should be 0.9.13-1
> Could I still keep the incrementation, because the earlier versions
> are already tagged & signed in the public git repository and also
> already uploaded to a Ubuntu PPA? (ppa:bortis/musl) So the first
> version for uploading would be 0.9.13-3 if you accept. Or we can wait
> for musl 0.9.14 wich, according to upstreams roadmap, will be released
> in the next two weeks to get a clean 0.9.14-1.

My feeling is that you'll need to keep the Ubuntu PPA and the Debian
package seperated and have them NOT in the same git branch. This will
save you trouble down the road as Debian != Ubuntu in many aspects and
you will face situations where you need only to upload Debian or
Ubuntu...

(usual disclaimer: I'm not an DD/DM; I might be wrong)

Best regards,
coldtobi


--
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/1379709880.692.7.ca...@mordor.loewenhoehle.ip

Bug#723626:

[Tobias Frost]

Am Donnerstag, den 19.09.2013, 16:08 -0400 schrieb Jon Daley:
> Yes, I saw the debian-lintian errors.  And I can take a look at those - I 
> wanted to see if I had the packaging procedure down correctly before 
> attacking those.  (and those issues have been around for years, so I 
> wasn't making anything worse by not touching them yet)

Well, a lintian-clean package attracts more sponsors :)
And as a maintainer you have not too much be afraid to make you package
worse but brave to improve it to the state of the art.

> 
> And I did see that the upstream link to the tar file was broken - his main 
> site still links to it, so I figure he must have just broken it.  If he 
> decides to stop publishing it - is there a process for that?  The code is 
> in the public domain.
> 

Mmmh, if upstream is gone this is a hint to think about if the
lifecylcle of the package comes also to a end. Popcon says around 500
installs, (with a big jump going up early this year); so IMHO the
package is still useful for quite many users.

> 
> On Thu, 19 Sep 2013, Tobias Frost wrote:
> 
> > Hallo Jon,
> >
> > (Disclaimer: I'm not a DD/DM; also I'm quite new in reviewing, so I
> > might also overlook smth or be wrong)
> >
> > Some notes while I looked at your package:
> > * d/patches/* please add dep3 headers.
> > * Can you upgrade standards-version to 3.9.4?
> > * Please enable hardening (maybe along with setting d/compat to 9)
> > * Add yourself to debian/copyright. Maybe update it to dep5 format?
> > * orig source cannot be downloaded: I get a access denied error. Maybe
> > get in contact with upstream?
> > * d/rules I like debhelper short form better than the old one, might be
> > worth to upgrade as I find it easier to maintain.
> >
> > Best regards,
> > coldtobi
> >
> > --
> > To unsubscribe, send mail to 723626-unsubscr...@bugs.debian.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/1379698997.12549.22.ca...@mordor.loewenhoehle.ip

Bug#717995: RFS: rawdog/2.18-1 [ITA]]

[Tobias Frost]

Hallo Adam,

thanks for your work :) I think the package would be fine for upload and
a great improvment over the current package in the archives. But I am
not a DD and I cannot judge  the code quality, as my knowledge on pyhton
is very limited. 

But maybe some DD on mentors sees this mail as inspiration to steps up
and upload it... As a user, I would appreciate it.

One very minor thong: It seems you have the packaging stuff in a git
repository (what I like very much), so you might want to add the
appropriate VCS-* fields into your debian/control. 

There was also some discussion in the thread about managing it via the
python-apps-team. In this case it would be advantageous to have the git
on some more public service, like alioth. (however, from my own
experience, it is hard to get an account there. So I definitely would
not see that as a blocking point).

Best regards,
coldtobi


Am Freitag, den 20.09.2013, 21:47 +0100 schrieb Adam Sampson:
> Dear mentors,
> 
> I'm (still) looking for a sponsor for my package "rawdog".
> 
>   Package name: rawdog
>   Version : 2.18-1
>   Upstream Author : Adam Sampson  (i.e. me)
>   URL : http://offog.org/code/rawdog/
>   License : GPL-2+
>   Section : web
> 
> It builds those binary packages:
> 
>   rawdog - RSS Aggregator Without Delusions Of Grandeur
> 
> To access further information about this package, please visit the
> following URL:
> 
>   http://mentors.debian.net/package/rawdog
> 
> Alternatively, one can download the package with dget using this
> command:
> 
>   dget -x 
> http://mentors.debian.net/debian/pool/main/r/rawdog/rawdog_2.18-1.dsc
> 
> I'd like to adopt the existing package, which is currently orphaned.
> (popcon reckons it has about 139 users, which means it's slightly more
> popular than udhcpc but slightly less popular than python3-markdown.)
> 
> This new version fixes all the outstanding bugs, is lintian-clean and
> has been considerably improved thanks to review on debian-mentors -- in
> particular, thanks very much to Etienne Millon and Jakub Wilk for all
> their helpful suggestions.
> 
> More information about rawdog can be obtained from:
> 
>   http://offog.org/code/rawdog/
> 
> Changes since the last upload:
> 
>   * New maintainer (Closes: #660507)
>   * New upstream release (Closes: #651080)
>   * Remove Debian patch that replaced feedfinder; this was merged
> upstream and extended in rawdog 2.15. (Closes: #650776, #657206)
>   * Depend on python-feedparser, which is no longer bundled with
> upstream rawdog. (Closes: #383422)
>   * Recommend python-tidylib.
>   * Provide a virtual python-rawdoglib package, for other packages that
> use rawdog's internal modules.
>   * Update the package to use debhelper 9, which simplifies the rules
> file.
>   * Update package description.
>   * Add a watch file.
>   * Put the copyright file into machine-readable form.
>   * Install the upstream changelog.
>   * Check that the package meets Debian policy version 3.9.4 (no further
> changes needed), and update Standards-Version.
> 
> To clone the Git repo for the debian/ directory:
> 
>   git clone http://offog.org/git/rawdog-debian.git
> 
> Thanks very much,
> 
> --
> Adam Sampson  
> 
> 


--
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/1379754845.2404.29.ca...@mordor.loewenhoehle.ip

Bug#717995: RFS: rawdog/2.18-1 [ITA]]

[Tobias Frost]

Am Samstag, den 21.09.2013, 11:27 +0100 schrieb Adam Sampson:
> On Sat, Sep 21, 2013 at 11:14:05AM +0200, Tobias Frost wrote:
> > [...] you might want to add the appropriate VCS-* fields into your
> > debian/control. 
> > There was also some discussion in the thread about managing it via the
> > python-apps-team.
> 
> Yup -- the reason I'd not done so is that the python-apps-team actually
> has a single repository for all the packages they manage, so if they're
> willing to take it I'd need to replay my changes against their repo
> anyway. If not, then I'll push my existing repo to a pkg-rawdog one on
> alioth.
> 
> Thanks,
> 

If not going to python-appd-team you probably want to consider pushing
it to collab-maint.
https://wiki.debian.org/Alioth/Git#Collab_Maint_project


--
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/1379766615.24484.5.ca...@mordor.loewenhoehle.ip

Bug#722432: RFS: totem-plugin-arte/3.2.0-1

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #722432

Adding block to 722609, as you say on mentors:
"The package FTBS currently (09/12) because of this unrelated bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722609";


-- 
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/20130921160024.25875.82191.report...@mordor.loewenhoehle.ip

Bug#722432: RFS: totem-plugin-arte/3.2.0-1

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #722432

Hallo Nicolas,

a very short review:

-> please tell what you needed to do to bump S-V. (state no changes if there
   were none necessary
-> you should add the remark "upload to unstable" when your previous upload
   was to experimental
-> I think for your hardening you need to depend on dpkg-dev >= 1.16.1~ not
   only on > 1.16.1 (see https://wiki.debian.org/Hardening)
   (or you switch to debhelper 9 )

coldtobi


-- 
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/20130921162040.26098.1569.report...@mordor.loewenhoehle.ip

Bug#723582: Bug#724324: RFS: metar/0.2-1 ITP

[Tobias Frost]

Hallo Fernando,

please do not open  new bug when you upload a new (not-uploaded) version
to mentors, just reply to your old bug. (I merged both bugs)
There, you should describe what you changed since the last update.

Ok, lets take a look.

--> Package name metar is already taken. You'll need a differnt one.
http://packages.qa.debian.org/m/metar.html

--> Check your linitian warnings before uploading.
Because you created a native package, which is not what you want.
See the linitan messges (W) native-package-with-dash-version and 
(I) missing-debian-source-format 

--> (W) binary-without-manpage /usr/bin/metar does not have a manpage.
--> please fix (I) mdescription-synopsis-might-not-be-phrased-properly

--> As you are upstream, please add upstream a changelog.

--> please add a dep5-style debian/copyright file. 

--> I'd suggest debian/compat 9 not 8 (and build-depend on debhelper >
9)

--> before uploading, you should update the timestamp in your changelog.
(dch -r)

--> There's a warning: package metar: unused substitution variable
${perl:Depends} --- You need to depend in your binary package on
${perl:Depends} not just on perl, I think

Best regards,
coldtobi

Am Montag, den 23.09.2013, 20:42 +0200 schrieb Fernando:
> Package: sponsorship-requests
> Severity: normal 
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "metar"
> 
> * Package name: metar
> Version : 0.2-1
> Upstream Author : Fernando Iazeolla 
> * URL : http://githib.com/elboza/metar
> * License : GPL
> Section : utils
> 
> It builds those binary packages:
> 
>  metar - a simple command line metar and taf.
> 
> To access further information about this package, please visit the following 
> URL:
> 
> http://mentors.debian.net/package/metar
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
>  dget -x http://mentors.debian.net/debian/pool/main/m/metar/metar_0.2-1.dsc
> 
> More information about metar can be obtained from 
> http://github.com/elboza/metar.
> 
> Changes since the last upload:
> 
> metar (0.2-1) unstable; urgency=low
> 
> * Initial release (Closes: #723827) 
> 
> -- Fernando Iazeolla   Mon, 09 Sep 2013 22:32:41 +0200
> 
> 
> 
> Regards,
> Fernando Iazeolla
> 


--
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/1379965383.12473.15.ca...@mordor.loewenhoehle.ip

Bug#723582: Bug#724324: RFS: metar/0.2-1 ITP

[Tobias Frost]

Hallo Fernando,

I saw on mentors that you've uploaded a new version and commented there:
> Do i need to throw a new RFS?
No, you just send a mail to 723...@bugs.debian.org

I already took a look this morning, here you go:

-> Do NOT override binary-without-manpage --> You need to write a manpage
-> Do NOT override description-synopsis-might-not-be-phrased-properly --> You 
need to fix your description in d/control 
-> You made a native package. That is wrong. What you need to do is in the 
description of native-package-with-dash-version (namely making 
debian/source/format to contain "3.0 (quilt)")
-> You need also to rename the source-package. 

I see some still some other problems with the package, like the source-package 
name cannot be metar. Also you do not need to make the directory structure 
under mcode ... Just put your two files in the root directory and let do 
debhelper do all the magic. E.g it will automatically detect the copyright file 
and will install it into the right directory. This is why the duplicate-files 
error shows up: You are not doing it correctly... 
So your "upstream tar" should have just this file tree:
metar-0.2/copyright
metar-0.2/metar

(ignoring that you cannot name your executeable meetar)
No usr/ in there. The debian *.install will be the place where to specify where
put the executeable, copyright will be automatically detected and installed 
correctly.

Eric noted also that metar in the archives does the same thing. 
Usually it should be avoided to have two packages doing the same thing unless 
there are other advantages to the users.
But maybe you can convince us that your version is superior?

Best regards,
coldtobi


--
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/1380126600.31430.15.ca...@mordor.loewenhoehle.ip

Bug#724539: RFS: psocksxx/0.0.1-1 [ITP]

[Tobias Frost]

Hallo Uditha,

(I'm not a DD/DM... Also quite new to reviewing)

Thanks for your work, however there is already a iostream based socket
library in Debian: libskstream. So maybe you can elaborate a little why
you think this library is a must in Debian :) (like reverse
dependencies...)

The package itself looks quite good, just a few remarks (I did not build
the package, just a paper-review)

d/control you libpsocksxx0 Provides: libpsocksxx. I think that is wrong,
as the so-name will be important when installing the library later. (But
I could be wrong here)

I think it is depreciated to install *.la files. 

You should enable multiarch-support

Maybe you'd like also to provide a -doc package with the generated
doxygen documentation. 

Please be aware: Buildd's do not have necessarily have networking, not
even lo is guaranteed. So you might want to disable (parts of) your
testsuite which relies on networking

Best regards,
coldtobi


Am Dienstag, den 24.09.2013, 23:01 +0100 schrieb Uditha Atukorala:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "psocksxx"
> 
> * Package name: psocksxx
> Version : 0.0.1-1
> Upstream Author : Uditha Atukorala
> * URL : https://github.com/uditha-atukorala/psocksxx
> * License : LGPLv3+
> Section : libs
> 
> It builds those binary packages:
> 
> libpsocksxx0 - C++ wrapper library for POSIX sockets
> libpsocksxx0-dev - C++ wrapper library for POSIX sockets (development)
> 
> To access further information about this package, please visit the
> following URL:
> http://mentors.debian.net/package/psocksxx
> 
> Alternatively, one can download the package with dget using this command:
> dget -x 
> http://mentors.debian.net/debian/pool/main/p/psocksxx/psocksxx_0.0.1-1.dsc
> 
> More information about psocksxx can be obtained from
> https://github.com/uditha-atukorala/psocksxx.
> 
> There are two lintian messages shown when run with "-I
> --show-overrides --pedantic";
> 1. no-upstream-changelog - this is due to upstream not having a
> changelog file for this version.
> 2. no-symbols-control-file - this is a little tricky to have because
> of c++ (STL) version differences and I can't see one .symbols file
> being valid for all the distributions.
> 
> Regards,
> Uditha Atukorala (Udi)
> 
> 


--
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/1380129777.31430.29.ca...@mordor.loewenhoehle.ip

Bug#723626:

[Tobias Frost]

Am Samstag, den 21.09.2013, 07:45 -0400 schrieb Jon Daley:
> >> Yes, I saw the debian-lintian errors.  And I can take a look at
> those - I
> >> wanted to see if I had the packaging procedure down correctly
> before
> >> attacking those.  (and those issues have been around for years, so
> I
> >> wasn't making anything worse by not touching them yet)
> >
> > Well, a lintian-clean package attracts more sponsors :)
> > And as a maintainer you have not too much be afraid to make you
> package
> > worse but brave to improve it to the state of the art.
> Yeah, I get it.  I guess I wanted to make sure there was going
> to 
> be a sponsor before I spent that time.  I've used this package for
> years 
> without a maintainer by just modifying the source. 

Hi Jon,

I should be more clear in my conclusion: As said, the package is in use
by many people, so it is in my opinion worth to be kept in Debian.

Regarding the packaging, it really depends what your goals are. If you
want to become the maintainer of the package (and you indicated that by
putting your name into the maintainer field) you will eventually find a
sponsor. It might take some time, though, and you need to show some
persistence. But you can invest this time to improve the package's
quality as much as possible (and this again will increase the changes of
being sponsored sooner). As already it is more likely to find a sponsor
if the package is in good shape and sponsors also likes to see that you
care.

coldtobi 


--
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/1380215345.307.19.ca...@mordor.loewenhoehle.ip

Bug#724807: RFS: yt/2013.09.28-1 [ITP]

[Tobias Frost]

Hallo Rich,

A short review: (I am not a DD/DM, so I cannot upload.)

I think "yt" as a package name is too short and well can cause
collisions down the road, please consider renaming it (and the
executeable) How about youtube-cli?

Your package has linitian warnings, please fix them.
You should also not put your .git directory in your tarball

d/README.source IMHO the workflow on the debian packaging repository
should be compaptible with git-buildpackage, then this file is 
not needed. 

I cannot find the upstream location of the tarball, but we'll
need one. There is also no get-orig-source target to regenerate 
the upstream tarball.

There is an extra License: MIT paragraph in d/copyright (line 13+14)

d/rules: your overrides seems not to be needed: You  execute in the
overriden target same dh_* command.

Ask upstream to provide a changelog.

The package does not build two times in a row:
dpkg-source: info: local changes detected, the modified files are:
 yt-2013.09.28/src/whitey.egg-info/PKG-INFO
 yt-2013.09.28/src/whitey.egg-info/SOURCES.txt
 yt-2013.09.28/src/whitey.egg-info/dependency_links.txt
 yt-2013.09.28/src/whitey.egg-info/entry_points.txt
 yt-2013.09.28/src/whitey.egg-info/not-zip-safe
 yt-2013.09.28/src/whitey.egg-info/top_level.txt

Best regards,
coldtobi



Linitian output (cleaned up a little)
P: yt source: source-contains-git-control-dir .git
P: yt source:
source-contains-prebuilt-windows-binary 
.git/objects/15/60a4fb268be93a02f03b3b0c1c2a6c9a4fcd81
 (many of those follows)
W: yt source: out-of-date-standards-version 3.9.3 (current is 3.9.4)
I: yt source: debian-watch-file-is-missing
P: yt: no-upstream-changelog
I: yt: spelling-error-in-manpage usr/share/man/man1/yt.1.gz prefered
preferred
I: yt: spelling-error-in-manpage usr/share/man/man1/yt.1.gz prefered
preferred
I: yt: hyphen-used-as-minus-sign usr/share/man/man1/yt.1.gz:30
I: yt: hyphen-used-as-minus-sign usr/share/man/man1/yt.1.gz:38
W: yt: binary-without-manpage usr/bin/pi-yt





Am Samstag, den 28.09.2013, 01:46 -0500 schrieb Javier P.L.:
> Package: sponsorship-requests
> Severity: normal whislist
> 
> I am looking for a sponsor for my package "yt"
> 
>  * Package name: yt
>Version : 2013.09.28-1
>Upstream Author : Rich Wareham 
>  * URL : https://github.com/rjw57/yt
>  * License : MIT
>Section : web
> 
>   It builds those binary packages:
> 
> yt- command-line YouTube client
> 
>   To access further information about this package, please visit the 
> following URL:
> 
>   http://mentors.debian.net/package/yt
> 
>   Alternatively, one can download the package with dget using this command:
> 
> dget -x 
> http://mentors.debian.net/debian/pool/main/y/yt/yt_2013.09.28-1.dsc
> 
>   Changes since the last upload:
> 
>   Initial release, closes: #724801.
> 
>   Regards,
>Javier Lopez
> 
> 


--
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/1380360591.14398.20.ca...@mordor.loewenhoehle.ip

Re: Wish to package astronomy software

[Tobias Frost]

Hallo Bamm,

On Sun, 2014-01-05 at 21:23 +0800, Bamm wrote:
> Hi Paul,
> 
> Thanks for replying to my inquiry.
> 
> > Please file an ITP (Intend to package) bug against the WNPP (pseudo)
> > package. You should use the reportbug command for that, as it gives you
> > the proper template to file out.
> 
> Thanks! Where do I report the ITP bug? Is there an online form, e.g., 
> bugzilla?

No, you gonna use the Debian BTS. A convenient tool is reportbug(1).
You might also want to read some of the docs at http://bugs.debian.org
to get familiar with the BTS, as you will need this skills for
maintaining a package.

> > Good, next thing is to provide us with the source.
> 
> I have created my source package. How do I provide it to you? Is it
> allowed to attach it into this message?

No, don't send it to this list. 

Please follow the instructions at
http://mentors.debian.net/intro-maintainers, especially the "Using
Mentors" section. 

> Regards,
> Bamm
> 
> 


--
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/1388943566.21832.8.ca...@mordor.loewenhoehle.ip

Re: Add debug files to existing packages or add -dbg packages?

[Tobias Frost]

You should male a dedicated dbg package. 

http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-dbg



Tony Houghton  schrieb:
>ROXTerm is going to need a new release soon and I'd like to include
>debugging symbols. It currently has binary packages roxterm-common
>(data
>files), roxterm-gtk3 (executables linked with GTK3 etc) and
>roxterm-gtk2
>(linked with GTK2 etc). Should debugging symbols always be put in
>separate -dbg packages or can they be added to existing packages? If
>there is a choice I'm leaning towards the latter.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.


-- 
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/16628aba-74ae-461e-b123-426cb5be9...@email.android.com

Bug#735953: RFS: shc/3.8.9-1 [ITP] -- Generic shell script compiler

[Tobias Frost]

Hi Tong,

You should always have an updated development system.
 It can also be a chroot, so it won't interfere with your daily needed 
installation. ( Indeed, a chroot for dev work has other advantages too; IMHO 
strongly suggested to use it always..)

-- 
coldtobi


Tong Sun  schrieb:
>Hi Eriberto,
>
>Thanks a lot for checking into my package.
>
>My sid is about 3~4 weeks old but somehow I don't have lintian
>problems of hyphen-used-as-minus-sign and
>hardening-no-fortify-functions. I've shot into the dark, so please
>verify for me. New build just uploaded:
>
>Uploading to mentors (via http to mentors.debian.net):
>  Uploading shc_3.8.9-1.dsc: done.
>  Uploading shc_3.8.9.orig.tar.gz: done.
>  Uploading shc_3.8.9-1.debian.tar.gz: done.
>  Uploading shc_3.8.9-1_source.changes: done.
>Successfully uploaded packages.
>
>PS. for hardening-no-fortify-functions, this is my fix:
>https://github.com/suntong001/shc-build/commit/c1daa032cddcb61e68d13b3b205f2c199ce28569
>
>If it doesn't work, please tell me how.
>
>Thanks
>
>On Sun, Jan 19, 2014 at 11:17 AM, Eriberto 
>wrote:
>> Hi Tong,
>>
>> How are you?
>>
>> Your package has several lintian messages and all are fixable.
>>
>> I: shc source: quilt-patch-missing-description
>01_remove-makefile.diff
>> I: shc source: quilt-patch-missing-description 02_add-Makefile.diff
>> I: shc source: quilt-patch-missing-description
>03_remove-pause-from-match.diff
>> I: shc source: debian-watch-file-is-missing
>> I: shc: hardening-no-fortify-functions usr/bin/shc
>> I: shc: spelling-error-in-manpage usr/share/man/man1/shc.1.gz
>> Unfortunatelly Unfortunately
>> I: shc: hyphen-used-as-minus-sign usr/share/man/man1/shc.1.gz:60
>> I: shc: spelling-error-in-manpage usr/share/man/man1/shc.1.gz comand
>command
>> I: shc: hyphen-used-as-minus-sign usr/share/man/man1/shc.1.gz:101
>>
>> I suggest to you fix the problems and re-upload your package, that is
>> very interesting and useful.
>>
>> Regards,
>>
>> Eriberto
>>
>>
>> 2014/1/18 Tong Sun :
>>>
>>> I am looking for a sponsor for my package "shc"
>>>

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.


-- 
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/f07fa03c-e18b-4074-8128-c858486c1...@email.android.com

Re: Checking build errors

[Tobias Frost]

Another possibility: Use qemu to simulate the target arch... Needs usually a 
good portion of patience, but helped me a couple times already.

Paul Wise  schrieb:
>On Thu, Jan 23, 2014 at 3:59 AM, L.C. Karssen wrote:
>
>> What I can't see is their exact error messages. This is because
>automake
>> by default runs tests in parallel and sends the output of the
>individual
>> tests to a file called test-suite.log. Is there a way to get access
>to
>> that file on the build machine?
>> Or is there another way to find out why the checks fail (short of
>> uploading a package where I run the tests serially and send output to
>> the screen)?
>
>You can choose one in decreasing order of preference:
>
>Ask your sponsor to login to the porterboxen, do a build and send you
>the results.
>
>https://db.debian.org/machines.cgi
>
>Get access to the porterboxen yourself, do a build and inspect the
>results.
>
>https://dsa.debian.org/doc/guest-account/
>
>Override dh_auto_test to output test-suite.log when it fails, reupload.
>
>> Please CC me in any replies as I'm not subscribed to this list.
>
>Done (I'm subscribed).

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.


-- 
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/41ec6306-0683-425c-a0fd-37327506f...@email.android.com

Re: Searching Sponsor - vimhelp-de #726545

[Tobias Frost]

Hallo Julian,

Great to see you steping in and lending Debian a hand.

First thing should be that you claim ownership of #726545 and change the bug
title from O: ... to ITA:  (You did the first one, but not the second one.
However, the ownership has been already reverted)

Then you should register at mentors.debian.net and upload your package, file a
RFS bug against sponsorship-requests (your personal page showing your packages
on mentors.d.n will provide you with a template to use for filing the RFS bug)
and wait for feedback and implement the suggestions.
Eventually you will then find a Debian Devloper sponsoring your upload...

Details of the sponsorhip process are described here:
http://mentors.debian.net/qa
https://wiki.debian.org/DebianMentorsFaq



Best regards,

-- 
coldtobi



> Hi,
>
> I'm new to Debian Developement and want to contribute to this great project.
> To start with packaging I searched an simple orphaned package. I think
> vimhelp-de is a good starting point.
>
> Now I'm searching a sponsor for helping me.
>
> A few informations about me: I'm from Germany and 23 years old. At the
> moment on education to software developer, but I'll finish it soon. Debian
> is my favorite os for years and now I want to help.
>
> And for every tip I'll be very thankfull!
>
> Yours sincerely
> Julian Goestl
>
>
>



-- 
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/e967fae032c6a7e7be09fbdc5f71d174.squir...@isengard.is-a-geek.net

Re: Need help signing and uploading

[Tobias Frost]

> There isn't a step-by-step manual for beginners.
> I think, it should be added too.
>
> Best Regards,
> Julian Goestl

Can you elaborate where you're stuck?
( eg using the checklist at http://mentors.debian.net/intro-maintainers ,  "4
Publish your Package")

Tobias

> Am 05.02.2014 20:33, schrieb Bart Martens:
>> On Wed, Feb 05, 2014 at 02:39:15PM +0100, Julian Göstl wrote:
>>> Hi,
>>>
>>> can anybody explain step-by-step how correctly sign and upload a
>>> package to mentors.debian.net?
>> Isn't this documented on mentors.debian.net ? If not, then it should be
>> added
>> there.
>>
>> Regards,
>>
>> Bart Martens
>
>



-- 
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/f25fd2b62fca6dcab5ce5a8b8da064b8.squir...@isengard.is-a-geek.net

Re: ngp/0.1-1.0 [NMU]

[Tobias Frost]

Hallo Jonathan,

(first the usual disclaimer: I'm not a DD so I cannot sponsor.)

I only briefly look into the packaage , so this is only a brief review
mostly from the data available from m.d.n... Sorry, also on a hurry ..


I see those problems which should work on:
-> you need to file an ITP Bug against wnpp and you cannot have a NMU
with an initial upload.
-> you have lintian warnings in your package, please fix them
-> your debian/control lacks the homepage field
-> d/copyright is incomplete, you should read
http://dep.debian.net/deps/dep5/ as this format is strongly recommended.
-> d/README.source is still a template. Edit or remove.
-> d/README.Debian is probably not needed, or are there Debian
specilities?
-> as you are using autoconf and friends, you should also use
dh_autoreconf in your rules.
-> There is no source for "search.png". Is this image indeed needed?
-> debian/patches is empty and should be removed
-> debian/ngp.1 should be included upstream (as you are upstream this is
easy)
-> you need to have a watch file (if you release) or an get-orig-source
target in debian/rules to regenerate the tarball.

A personal opinion: "ngp" is a little short for a package / binary name,
as this kind of pollutes the namespace (and there is a ngp2 in the
archives). Maybe consider a more self-explaining name?


Best regards,

-- 
coldtobi

Am Sunday, den 16.02.2014, 15:28 +0100 schrieb Jonathan Klee:
> Package: sponsorship-requests
> Severity: normal 
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ngp"
> 
>  * Package name: ngp
>Version : 0.1-1.0
>Upstream Author : Jonathan Klee
>  * URL : https://github.com/jonathanklee/ngp
>  * License : GPL
>Section : devel
> 
> It builds those binary packages:
> 
> ngp   - Ncurses code parsing tool
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/ngp
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x http://mentors.debian.net/debian/pool/main/n/ngp/ngp_0.1-1.0.dsc
> 
> More information about hello can be obtained from 
> https://github.com/jonathanklee/ngp
> 
>   Changes since the last upload:
> Initial release.
> 
> Best regards,
> Jonathan Klee


--
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/1392568055.16446.14.ca...@mordor.loewenhoehle.ip

Re: ngp/0.1-1.0 [NMU]

[Tobias Frost]

PS: 
It also does not build in an pdebuilder environment. 

checking for unistd.h... yes
checking libconfig.h usability... no
checking libconfig.h presence... no
checking for libconfig.h... no
configure: error: oops no libconfig.h ?
==> config.log <==
This file contains any messages produced by compilers while

(Seems to miss a B-D on libconfig.)

-- 
coldtobi

Am Sunday, den 16.02.2014, 15:28 +0100 schrieb Jonathan Klee:
> Package: sponsorship-requests
> Severity: normal 
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ngp"
> 
>  * Package name: ngp
>Version : 0.1-1.0
>Upstream Author : Jonathan Klee
>  * URL : https://github.com/jonathanklee/ngp
>  * License : GPL
>Section : devel
> 
> It builds those binary packages:
> 
> ngp   - Ncurses code parsing tool
> 
> To access further information about this package, please visit the following 
> URL:
> 
>   http://mentors.debian.net/package/ngp
> 
> 
> Alternatively, one can download the package with dget using this command:
> 
> dget -x http://mentors.debian.net/debian/pool/main/n/ngp/ngp_0.1-1.0.dsc
> 
> More information about hello can be obtained from 
> https://github.com/jonathanklee/ngp
> 
>   Changes since the last upload:
> Initial release.
> 
> Best regards,
> Jonathan Klee


--
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/1392568782.16446.16.ca...@mordor.loewenhoehle.ip

Re: Working with gbp and older releases

[Tobias Frost]

> Hi,
>
> I am trying to work on an orphaned package maradns. It uses quite a
> lot of patches managed with quilt. I created a repo on alioth [1] to
> manage different versions. I imported all the versions (debsnap and
> git-import-dscs). Now I am stuck with two problems:

Thanks for adopting and your contribution to Debian!

> 1. Should I keep the source unpatched in git or patched. If I keep it
> unpatched, after patching (dquilt push -a) gbp complains that I have
> uncommited changes. What should be done here?

The patches should not be applied.
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.PATCH
should give you hints.

> 2. I can see the newest maradns 2.X branch was installed only for
> experimental. The latest in unstable/testing was 1.4.12-5. It is now
> unusable, due to [2] and procpidfile change. I think the first release
> I would make is fixing this, so people can use it again (now it does
> not start). Is this git workflow correct ?

If you want to adopt you're free to do so. But you can also start with
the new upstream version if you think it is ready for primetime.


> I will checkout debian/1.4.15-5 tag, bump the changelog to 1.4.15-6,
> make changes in d/* and release with a new tag. Now, say I want to
> release the new 2.X version. I go back to master, add the changelog
> entry for 1.4.15-6 and work on the new release?

Did not get the details what you want to archieve...
Should 2.x go to experimental and (later) 1.4.15-6 to unstable?
If so, you should make an own branch for expermimental, and do the packageing
there.
See
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
for an proposal of the layout.

Otherwise please explain your intentions...


PS: You should change bug's title #739084 to ITA:  and set yourself as
owner of it

>
>
> [1] http://anonscm.debian.org/gitweb/?p=collab-maint/maradns.git
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=709826
>



-- 
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/4f763bca51f97780f73dd5d08dbffa03.squir...@isengard.is-a-geek.net

Re: Working with gbp and older releases

[Tobias Frost]

Hallo Darius,

Am Montag, den 17.02.2014, 20:52 +0100 schrieb Dariusz Dwornikowski:
> > > I am trying to work on an orphaned package maradns. It uses quite a
> > > lot of patches managed with quilt. I created a repo on alioth [1] to
> > > manage different versions. I imported all the versions (debsnap and
> > > git-import-dscs). Now I am stuck with two problems:
> > 
> > Thanks for adopting and your contribution to Debian!
> 
> Frankly I am still thinking about adopting. It is a great software, I
> use it quite often but while adopting I came to a few disturbing facts.
> 
> The first is the fact that upstream stated on [1] as follows:
> 
> "It would require some large company or government agency paying me a
> full-time living wage to add significant new features to MaraDNS.
> Since this is unlikely to happen, especially in today's economy, I am
> declaring MaraDNS finished: While I will still fix important security
> bugs in MaraDNS, and will probably still fix other critical bugs, I
> currently have no plans to add new features to MaraDNS."
> 
> Additionally, his mail signature gives makes me doubt that his
> commitment to his open source project is full, as in [2]. 
> 
> "Note: I do not answer MaraDNS (including Deadwood) support requests
> sent by private email without being compensated for my time. A MaraDNS
> support request is any and all discussion you may wish to have about
> MaraDNS in private email; if you want to email me to talk about
> MaraDNS then, yes, that is a support request. I will discuss rates if
> you want this kind of support. Thank you for your understanding."
> 
> Also I can see that the package has plenty of patches that could be
> forwarded to the upstream but for some reason were not forwarded or
> accepted. I will try to contact the former mainatainer and upstream to
> be 100% clear on that. 
> 
> I have little experience what should be done in such a case, maybe I
> have too high expectations on upstream. 

Well, IMHO it's legitimate for upstream to call a program "feature
complete" and mature. I think also it is not against the sprit of open
source to only add features if being paid, its basically a business
model decision one has to make (and not everyone does coding just as a
hobby). One still have all freedoms opens source gives you, also to fork
if desired.  

Of course, declaring a software "mature" marks a distinct point in the
life cycle of the software toward its end, and eventually it might be
wise at some point in the future to depreciate the package and call for
its removal. But at a popcorn of around 100, and with the statement that
upstream does at least care so much to handle security issues, I think
this is needs not to be now, especially if the package is actively
maintained (soon). and sd upstream just released a new version, their
statement to fix security updates seems not to be empty.

If the patches are not Debian-specific, I would not hesitate to forward
them to upstream and leave it up to upstream to include them or not,
even despite the statement. Some upstreams will be happy to include,
from others you won't even hear any feedback... But at least you should
try.  

> > 
> > > 1. Should I keep the source unpatched in git or patched. If I keep it
> > > unpatched, after patching (dquilt push -a) gbp complains that I have
> > > uncommited changes. What should be done here?
> > 
> > The patches should not be applied.
> > http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.PATCH
> > should give you hints.
> 
> Thank you. 
> > 
> > > 2. I can see the newest maradns 2.X branch was installed only for
> > > experimental. The latest in unstable/testing was 1.4.12-5. It is now
> > > unusable, due to [2] and procpidfile change. I think the first release
> > > I would make is fixing this, so people can use it again (now it does
> > > not start). Is this git workflow correct ?
> > 
> > If you want to adopt you're free to do so. But you can also start with
> > the new upstream version if you think it is ready for primetime.
> > 
> I think I will start. The former maintainer had builds of the new
> branch in experimental, I already prepared a package with the newest
> upstream version. 

ACK. (Reading the upstreams' homepage, you should definitly go for the
latest version. The latest upstream fixes a local DoS.
As a side, please add all CVE-# which closes the new version into the
changelog, please follow the procedure as in [1]))

You should also to file a bug against maradns to document that the
current version has secuirty problemss with the CVE's
http://maradns.samiam.org/security.html has the list.

> > 
> > > I will checkout debian/1.4.15-5 tag, bump the changelog to 1.4.15-6,
> > > make changes in d/* and release with a new tag. Now, say I want to
> > > release the new 2.X version. I go back to master, add the changelog
> > > entry for 1.4.15-6 and work on the new release?
> > 
> > Otherwise please explain your intention

Re: Working with gbp and older releases

[Tobias Frost]

Am Dienstag, den 18.02.2014, 21:12 +0100 schrieb Dariusz Dwornikowski:
> > > 
> > > ACK. (Reading the upstreams' homepage, you should definitly go for the
> > > latest version. The latest upstream fixes a local DoS.
> > > As a side, please add all CVE-# which closes the new version into the
> > > changelog, please follow the procedure as in [1]))
> > 
> > Thank you, I will do it. 
> 
> Ok the last time I responded I lied that I understood :). I just want
> to confirm, when I release I will close CVE bugs I found here [1] ?
> Correct ? But they do not have a corresponding bugs.d.o bug, so I just
> do: Closes CVE-foo-bar in a changelog, as written in your link ?

Never had a CVE myself, but I think this is the way to go:
technically you don't need a debian bug, you could just write (random
example here [1]) 

maradns (version-1) unstable; urgency=high

 * new upstream release
- fixes CVE--, CVE-- ...

but I would file one "cover" bugs smth like "Serveral security bugs" and
listing alls CVE's in the bug's text and just add a Closes: # to the new
upstream release line. For simplicity, I would just add all CVE's since
which are marked as fixed upstream since 1.4.12. (see below)
For the one without a CVE-Number, maybe just describe the problem and
say that there is no CVE Number.
For the CVE's already fixed by a older version than 1.4.12, it is
allowed to modify the old changelog entries, when the fix was actually
added. At least that's how I read 5.1 in the developer reference:
 
"When closing security bugs include CVE numbers as well as the Closes:
#n. This is useful for the security team to track vulnerabilities.
If an upload is made to fix the bug before the advisory ID is known, it
is encouraged to modify the historical changelog entry with the next
upload. Even in this case, please include all available pointers to
background information in the original changelog entry."

> > 
> > > 
> > > You should also to file a bug against maradns to document that the
> > > current version has secuirty problemss with the CVE's
> > > http://maradns.samiam.org/security.html has the list.
> > 
> > Ok. 

> I can see that they are documented there. Or I miss something. Number
> 19 is the CVE-None that is fixed in the most current version. Or again
> I did not understand. 

You should consider all since version 1.4.12: #15, #16, #18, #19

> 
> [1] https://security-tracker.debian.org/tracker/source-package/maradns
> 
> -- 
> Pozdrawiam,
> Dariusz Dwornikowski, Assistant
> Institute of Computing Science, Poznań University of Technology
> www.cs.put.poznan.pl/ddwornikowski/
> room 2.7.2 BTiCW | tel. +48 61 665 29 41
> 
> 
> 
> 
[1] https://svn.xiph.org/trunk/vorbis/debian/changelog


--
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/1392757279.19726.45.ca...@ithilien.loewenhoehle.ip

Re: Working with gbp and older releases

[Tobias Frost]

Am Mittwoch, den 19.02.2014, 20:00 +0100 schrieb Dariusz Dwornikowski
> I uploaded my version to mentors. Would you be so nice to review it ? 
> http://mentors.debian.net/package/maradns

Hi Dariusz,

Sure, I'll take a look.  (I'm not a DD, so I cannot sponsor.)  

A suggestion: You should the RFS Bug to get a broader audience, maybe
someone who can indeed sponsor.

Ok, lets jump into the package: (Note that I do not sort the items, I
just write as I see them; so no ordering, severity, ... implied. And
don't get shocked by the length of the remarks, thats normal for the
first shot.)

-> Please file a bug for your changelog entry "Several security bugs" to
document in the BTS that the current version in xxx has problems. 
(One bug is enough, just quote your 5-lines in the changelog as bug
report)

-> For the old changelogs, where you added for example

  [ Dariusz Dwornikowski ]
  * Security bugfix for CVE-2012-1570

This is somehow misleading as it implies that you actively did smth on
the pckageing, but leave it unclear "what has been done". I think you
should not add your name here and hadd the "CVE-" to the (existing)
changelog entry. In this special case I would just update the first line
to

maradns (2.0.06-1) experimental; urgency=low

  * New upstream release, fixes CVE-2012-1570

(And then document the change in d/changelog for the to-be-uploaded
version, for example
 
  * Updated old d/changelog entries: Added information when the CVEs   
where fixed: (adding Debian-Versions which where changed=  

If you bump the SV, you should not if there have been any changes
necessary and if not document that too.

Generally, d/changelog entries should reflect *what* have been changed
on not focus on the *why* something has changed. For example, you write
"We no longer modify the config (Closes: #710903)": 
I would write "updated d/postinst to no longer modifiy conffiles.
(Closes: #...)
(and in the patch for it, do not just comment out the lines, remove them
to be clear that this is not acciedentially commented out)

-> Regarding the usage of your repository. I would suggest to have "one
change - one commit" and also have the commit messages speak for the
changes (ideally, they are identical to the d/changelog entry); There
were at least some commit which changed more than the git log says.
(the commit for the conffile fix is a examples - it also changes
d/control but does not mention it)
(BTW, in this commit you change the dependency of duende to an *older*
version? As this looks weird, I *suppose* this is wrong... Maybe you
wanted to enforce the current version, then use ${binary:Version})

I see also that there are sometimes undocumented changes, please
document them. For example you updated the watchfile, add gpg signatures
but this is not documented in the d/changelog. But this is just an
example, there are more than this one. 

d/control:
Why is the Breaks / Replaces necessary for maradns-zoneserver and other
packages? Why does the docs breaks an older version of maradns?

In Debian there is a file DwRandPrime.h which seems somehow
autogenerated. What is its purpose?


((note, I had to stop the review here due to time constraints)


Best regards, 
Tobias


--
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/1393063332.2918.49.ca...@ithilien.loewenhoehle.ip

Re: Working with gbp and older releases

[Tobias Frost]

Am Samstag, den 22.02.2014, 12:21 +0100 schrieb Dariusz Dwornikowski:
>  
> > A suggestion: You should the RFS Bug to get a broader audience, maybe
> > someone who can indeed sponsor.
> 
> Yes, I thought it would be better to share first with you, since you
> seemed interesed. 

Ok, just keep in mind that as I cannot sponsor
(but it seems your DM advovate had sponsored you already in the past, so
probably no RFS needed.)
> > -> Please file a bug for your changelog entry "Several security bugs" to
> > document in the BTS that the current version in xxx has problems. 
> > (One bug is enough, just quote your 5-lines in the changelog as bug
> > report)
> 
> Did that, thank you.
+1 ( I just added the securitiy tag and raised its severity)

For the rest of this, I pulled the latest git version... So I might be
wrong if not everthing was pushed...

> > If you bump the SV, you should not if there have been any changes
> > necessary and if not document that too.

Probably you missed that one :) ... (btw, SV = Standard Versions) 

> > Generally, d/changelog entries should reflect *what* have been changed
> > on not focus on the *why* something has changed. For example, you write
> > "We no longer modify the config (Closes: #710903)": 
> > I would write "updated d/postinst to no longer modifiy conffiles.
> > (Closes: #...)
> > (and in the patch for it, do not just comment out the lines, remove them
> > to be clear that this is not acciedentially commented out)
> 
> Done. Thank you. 
You might want to do that also for some other entries, not only the
example I quoted ;-)


> > (BTW, in this commit you change the dependency of duende to an *older*
> > version? As this looks weird, I *suppose* this is wrong... Maybe you
> > wanted to enforce the current version, then use ${binary:Version})
> 
> Fixed that. Thank you. 

Did you push that change? 


> > 
> > I see also that there are sometimes undocumented changes, please
> > document them. For example you updated the watchfile, add gpg signatures
> > but this is not documented in the d/changelog. But this is just an
> > example, there are more than this one. 
> 
> I got rid of that because it did not work. 

OK, I understand that... it's uscan... However, please see the
attachment, this version works here :)

(but do a git rm debian/upstream-signing-key.asc as you have the key two
times in the repository) 

> > 
> > d/control:
> > Why is the Breaks / Replaces necessary for maradns-zoneserver and other
> > packages? Why does the docs breaks an older version of maradns?
> 
> This
> Breaks/Replaces was some technique of the old maintainer. I removed it
> and it works fine without it. I think it was because of him updating
> conffiles in d/postinst, which got the package to violate the policy. 

Mmm... Checking the git repository, it seems that this was due to the
fact that maradns was split into several packages after 1.4.06, so this
was needed for an smooth upgrade.
IMHO it is safe to remove those lines, because this is only an issue in
oldstable. 

> > 
> > In Debian there is a file DwRandPrime.h which seems somehow
> > autogenerated. What is its purpose?
> 
> This is a weirdo. While building maradns generated a random prime
> number and writes it to DwRandPrime.h, I keep the upstream original in
> the debian repository to avoid "upstream changed" problems. After
> every build the DwRandPrime.h would be changed and gbp and debuild
> would complain. This assures reproductible builds.  
> > 
> > 

You can also just delete the file in the clean target ... Removed files
should not be a problem for dpkg-source. 
(However, it does not build then, so there is a problem with the build
system; The patch deadwood_makefile.patch applied is broken in this
aspect: It runs the Prime-Generator only if the file it should generate
is actually already there; see an attached a new version of this patch
which just moves the "fi" a little to the left.)

( There is also a similar hack with  rng/rng-32bit-tables.h in d/rules;
but I did not analyze what to do to remove this hack...)
version=3
opts=pgpsigurlmangle=s/$/.asc/ http://maradns.samiam.org/download.html 
.*/maradns-(\d[\d\.]+)\.tar\.(?:gz|bz2)$
Author: Nicholas Bamber 
Subject: deadwood source code corrupted during build
 Also we don't like binaries with a capital in the name.
Forwarded: not-needed
Last-Update: 2014-02-25
--- a/deadwood-3.2.05/src/Makefile
+++ b/deadwood-3.2.05/src/Makefile
@@ -20,7 +20,7 @@
 	DwRecurse.o \
 	DwDict.o
 
-all:	Deadwood version.h
+all:	deadwood version.h
 
 # Since some systems may not have /dev/urandom (Windows, *cough* *cough*), we 
 # keep a randomly generated prime around 
@@ -30,12 +30,8 @@
 
 clean:
 	rm -f Test DwMain DwTcp *.exe *.o a.out RandomPrime writehash_test* \
-		Deadwood foo* dw_cache DwHash DwCompress *stackdump \
-		core ; \
-		./make.version.h ; if [ -e /dev/urandom ] ; \
-			then rm DwRandPrime.h  ; \
-			cc RandomPrime.c ; ./a.out > DwRandPrime.h ; rm a.out \
-		; fi 
+		deadwood foo

Bug#740120: RFS: gambc/4.7.2-1

[Tobias Frost]

Hi Jackson,

(Please note that I am not an DD)

Some remarks, not a complete review:
-> you should change the bug-title of 677709 to ITA and set yourself as owner

-> d/copyright:
I think you need also to include a shorttext on the Apache-2.0 license, not
only the link to /usr/share/common-licenses/

The manpage gsi.1 is "Released under the same license as Gambit-C.", not GPL-2+.

-> d/control
I'm not a native English speaker, but it is really "Scheme
interpreter|compiler" with a captial "S"?

-> d/watch
Maybe you want to contact upstream if they are willing to sign the code
tarballs? (not a blocking point, its nice-to-have on an subsequent upload ;-))

-> d/libgambc4.install
I think you can remove the shebang in this file.

(As said, only paper-review, did not try to build the package.)

thanks for your contribution!

-- 
Tobias

> Package: sponsorship-requests
> Severity: normal
>
> Dear mentors,
> Could someone please sponsor the package gambc? It is a scheme compiler
> that is currently 4 years out of date in debian. The mentors page is
> http://mentors.debian.net/package/gambc and the dsc at
> http://mentors.debian.net/debian/pool/main/g/gambc/gambc_4.7.2-1.dsc
>  Thank you
>


-- 
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/8e7e04c26175854e20982fa55747cd31.squir...@isengard.is-a-geek.net

Re: tophat: Help needed with boost

[Tobias Frost]

Am Dienstag, den 18.03.2014, 15:59 +0100 schrieb Jakub Wilk:
> * Christian Kastner , 2014-03-18, 15:31:
> >override_dh_auto_configure:
> > dh_auto_configure -- \
> > --with-boost-libdir=/usr/lib/$(DEB_HOST_MULTIARCH)
> 
> It doesn't smell good to me. Ideally the upstream build system should 
> figure out itself where's what. But then maybe fighting with the build 
> system is not worth the effort.

I had lately also some trouble with boost-thread: Namely the 1.54 thread
libary needs also to be linked against boost-atomic. Maybe it's this?
Maybe the used m4 macro misses that? (I had the problems on
solarpowerlog and drizzle.)

-- 
Tobias


--
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/1395166688.6283.5.ca...@ithilien.loewenhoehle.ip

Re: Real newbie ....

[Tobias Frost]

Hi Barry,


Am Sonntag, den 13.04.2014, 17:51 +0100 schrieb Barry Drake:
> Hi ...  Can I introduce myself.  I've been involved in 'The Sword 
> Project' for some years and am now going along the very steep learning 
> curve in order to update the packages which are some five years out of 
> date.  I'm running Ubuntu Trusty 14.04 beta and can build the packages 
> with no problem using pdebuild.  But - the build puts in a dependency on 
> libicu48 which is now removed from the Ubuntu repos and replaced with 
> libicu52 which is what the actual build from source is using.  The 
> control file produced is identical to that in the current out-of-date 
> package (1.6.2).  I am packaging version 1.7.3.

Can you please give a reference to your package? Maybe taking a look at
it gives some clues :) Best would be to upload it to mentors.debian.net

One possibility just came to my mind: Did you update your pbuilder
environment before building it? 

> I've worked out that dpkg is being used to get the dependencies (I 
> think) but I haven't a clue as to where it gets them from, or how I can 
> change this behaviour.  The builder puts them into the ${shlibs:Depends} 
> string, and I can't see any method of controlling what gets into that 
> string.  I've read and re-read the packaging startup manual and haven't 
> managed to find what to do.  The control file produced by the build has 
> the line:
> 
> Depends: libsword-common, libc6 (>= 2.4), libclucene-core1 (>= 2.3.3.4), 
> libcurl3-gnutls (>= 7.16.2), libgcc1 (>= 1:4.1.1), libicu48 (>= 4.8-1), 
> libstdc++6 (>= 4.6), zlib1g (>= 1:1.1.4)
> 
> and it needs to have libicu52 (>= 0) as the correct dependency.

Usually dpkg-shlibdeps is right in determining the dependencies.
Without source its hard to check the root-cause.
Maybe the Build-Dependencies are wrong, or you still have the old
library installed (and/or the old -dev package)? Are you building with
the unstable repositories (and your e.g chroot up-to-date)?

> I hope I've come to the right place to ask this kind of newbie 
> question.  I don't want to become a maintainer, jut to produce the build 
> source files and pass them on to one of the existing maintainers to sign 
> and submit.

Well, that's usually not that easy... Of course you can prepare the
upload, but still the maintainer has to do several extra checks before
he can sign it off and indeed upload it. A well-prepared patch certainly
is of great value, but the best would be to offer co-maintaince ... Or
if you "upstream" to help as the upstream contact. I my experience this
helps a lot, as in my experience "upstream" perceives the details of
packaging work different than the actually needs of Debian. (This is
usually well-meant, don't get me wrong, but there a just so many details
to consider. This is for example why upstream never should ship
a /debian directory in its source tarball ...)

> Kind regards,Barry Drake.
> 
> 


--
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/1397417469.3870.50.ca...@ithilien.loewenhoehle.ip

Re: Real newbie ....

[Tobias Frost]

Am Sonntag, den 13.04.2014, 21:49 +0100 schrieb Barry Drake:
> On 13/04/14 20:40, Wookey wrote:
> > So the simple fix is to update your pbuilder chroot, or build with 
> > sbuild instead (which probably involves running sbuild-createchroot to 
> > set up an unstable chroot for it to use (and running sbuild-update 
> > --keygen once to make some keys for apt to use). Each build gives you 
> > a nice log file showing exactly what was installed to satisfy the 
> > build deps, so you shoul dbe able to see which libicu version was 
> > installed. I've not checked anything, so it could be more subtle than 
> > this, but that's my first guess.
> 
> Thanks for such an amazingly quick reply guys.  I've re-initilised the 
> chroot environment, with no difference.  My source is at: 
> https://www.dropbox.com/sh/urhm7iekss5a6a4/I7FveejRSd
> and the packages it built are at: 
> https://www.dropbox.com/sh/s748z00c3zxiupp/-SdnD2xcHR
> 
> Regards,  Barry.

First remark (as you seem somehow associated with upstream): in the
orig.tarball there is a .svn directory.. A good upstream does not ship
them in their tarballs ;-)

BTW, the changelog misses "-1" (The Debian revision). This is weird as
my pbuilder refuses to build non-native packages with a native version,
but yours seems more forgiving in this case... You should check if
your're really on unstable :) (My pbuilder is at 0.215)

(My pbuilder builds also against libicu52; so it's not the source)

Best regards,
Tobi
> 
> 


--
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/1397426886.20086.9.ca...@ithilien.loewenhoehle.ip

Re: Real newbie ....

[Tobias Frost]

Am Montag, den 14.04.2014, 15:03 +0100 schrieb Barry Drake:
> On 13/04/14 23:08, Tobias Frost wrote:
> > BTW, the changelog misses "-1" (The Debian revision). This is weird as 
> > my pbuilder refuses to build non-native packages with a native 
> > version, but yours seems more forgiving in this case... You should 
> > check if your're really on unstable :) (My pbuilder is at 0.215) (My 
> > pbuilder builds also against libicu52; so it's not the source) Best 
> > regards, Tobi 
> 
> Thanks again for all your help.  I deleted the pbuilder directory from 
> /var/cache and re-created the environment.  I also used dpkg -l to see 
> what was installed.  libicu48 is not in my system, but was downloaded 
> and installed in the chroot environment during the build.  It is not in 
> the pbuilder base.tgz file.  I assume the dependency was plucked out of 
> a sword file, so I purged both of the out-of-date sword packages and 
> dpkg -l doesn't show any at all connected with sword.  My own 
> installation of the up-to-date sword was made using 'make install' as 
> part of the original build.  I've also used the dpkg --clear-avail and  
> --forget-old-unavail  commands to try and get rid of old history.
> 
> The version of pbuilder I have is pbuilder 0.215ubuntu7  The build is 
> marked unstable because I have built from sword svn trunk: release will 
> be in a few days at which point I can do a stable build.

Could it be that pbuilder on ubuntu behaves differently than in Debian?
Looking at [1] line 1155 it seems that "saucy" is the default target for
pbuilder update. And it's libicu48 in saucy [2]

[1] http://patches.ubuntu.com/p/pbuilder/pbuilder_0.215ubuntu7.patch
[2] http://packages.ubuntu.com/de/saucy/libicu48

> I always have a current version of Ubuntu as well as the testing version 
> so although I'm using 14.04, I have a dual boot 13.10 installation on a 
> separate drive.  I'm going to wipe this, and do a clean install of 
> Saucy.  Then I'll make a  fresh packaging environment there to get a 
> clean build.  I will put the source there and try as before.
> 
> That's unless anyone has any further suggestions.

Just debstrap yourself an Debian sid chroot for development :)
Will be also easier to get support here, as there are differences to
Ubuntu, and you spare yourself the dual-booting :)

> 
> Regards,Barry.
> 
> 


--
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/1397497735.16069.7.ca...@ithilien.loewenhoehle.ip

Re: Real newbie ....

[Tobias Frost]

Am Montag, den 14.04.2014, 22:00 +0100 schrieb Barry Drake:
> On 14/04/14 18:48, Tobias Frost wrote:
> > Just debstrap yourself an Debian sid chroot for development :) Will be 
> > also easier to get support here, as there are differences to Ubuntu, 
> > and you spare yourself the dual-booting :)
> 
> Haven't a clue as to how to do that.

Just install deboostrap and issue 
mkdir debian-sid
debootstrap sid ./debian-sid  http://http.debian.net/debian/

https://wiki.debian.org/Debootstrap -- BTW the first hit if you google
"Debian debootstrap"

>   So I thought 'when in Rome'. I 
> decided to pop a spare hard drive into the trayless caddy that I 
> normally use for backups.  I installed Debian on that drive, and sadly, 
> it doesn't work.  It asked me part-way through the install if I had a 
> some necessary proprietary drivers, but it didn't say which ones, so I 
> answered 'no'.
My last Wheezy install went through without any problems. But that've
been some time ago. If I rememember correctly, the firmware it asks for
is just for the  network. 

>   I assume it wanted X11 drivers as it failed to start the 
> graphics environment.  I got out of it by doing ++ to get 
> a terminal.   Shame really, but this is possibly why so many folk don't 
> use Debian.  If you can point me to solutions to this, I'll persevere.

However, your mileage varied, but this needs probably more information
from your side. What's your  hßardware, to start with? Which installer
did you use? the net installer? Which release?  Wheezy? 
(You should not use the unstable/sid installer as this ride might be
bumpy; Better ist to install the last stable and then upgrade to sid; Or
give the alpha for Jessie a try, 'cause that needs some testing anyway) 
What are the XOrg logs telling you? 

BTW, you can always ask on #debian for help if you stuck.. This would
probably also faster than the mentors list (for which this also
off-topic)

Tobi

> Regards,Barry.
> 
> 


--
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/1397543980.8813.11.ca...@ithilien.loewenhoehle.ip

Re: Another Newby question - was - Re: Real newbie ....

[Tobias Frost]

Am Donnerstag, den 17.04.2014, 15:20 +0100 schrieb Barry Drake:
> On 15/04/14 15:08, Barry Drake wrote:
> > Just to let you know it worked 'out of the box', and I now have 
> > packages that seem OK.  pbuilder is a very different animal under 
> > debian.  The behaviour in Ubuntu is totally different.  Thanks again 
> > for all your help and patience.
> 
> I have another problem.  I installed the newly built packages - 
> libsword9_1.7.3+dfsg-1_i386.deb  and libsword-dev_1.7.3+dfsg-1_i386.deb  
> from within my chroot debian packaging environment and successfully 
> built from source a program called 'BibleTime' which is dependant on the 
> above.
> 
> However, when trying to package BibleTime, dbuilder fails with the above 
> not satisfied.  I've not attached the entire log, but the error seems to 
> be in:
>   pbuilder-satisfydepends-dummy depends on libsword-dev (>= 1.7.0); however:
>Package libsword-dev is not installed.
>   pbuilder-satisfydepends-dummy depends on libsword9 (>= 1.7.0); however:
>Package libsword9 is not installed.
> 
> Is this because the packages are unstable, or is there some magic I have 
> to use to tell pbuilder where the locally held packages are?  I 
> installed them from the same directory that is above the bibletime 
> source, and that is where they are still.  I've re-read the Debian 
> packaging guide, and it looks to me as though all dependencies must be 
> met from the Debian package repo.  Is this the case, or is there a 
> workaround?

https://wiki.debian.org/PbuilderTricks#How_to_include_local_packages_in_the_build

> Kind regards,Barry Drake/
> 
> 
> 


--
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/1397808284.23957.44.ca...@ithilien.loewenhoehle.ip

Bug#745135: RFS: mariadb-10.0/10.0.10-1 [ITP] -- Latest version of worlds most popular non-Oracle database

[Tobias Frost]

Hallo Otto,

(disclaimer: I cannot sponsor it, I'm not a DD)


Am Freitag, den 18.04.2014, 13:20 +0300 schrieb Otto Kekäläinen:

>   More information about MariaDB packaging can be obtained by asking
> me by e-mail, I promise to reply quickly.
> 
> The packaging is very similar to that of mariadb-5.5, already in
> Debian, but that sponsor has so many packages and is not available for
> reviewing mariadb-10.0 in the forseeable future, thus I am now
> requesting for a new sponsor the help me with mariadb-10.0.
> 

I did only take a look a the mentors interface, especially at the
lintian section. It seems there are several things to be fixed:
W outdated-autotools-helper-file -- looks like that dh-autoreconf or
autotools-dev would like to be your friends. 
Please also the linitan errors, eg  dir-or-file-in-var-run or
missing-dependency-on-libc
(There are many other information errors that are easy to fix)

For the overriden linitian warnings: Most of those should be fixed
instead of overriden: binary-without-manpage
command-with-path-in-maintainer-script manpage-has-errors-from-man
If you cannot fix them now, don't override them.

Generally, if you override linitian, please do document *why* in the
overrides.

Stopping here, as it makes no sense to review the code if there are
still lintian *errors*


> As everything can be compared to existing and accepted mariadb-5.5,
> the task of sponsoring my 10.0 should be relatively trivial. In
> general the Debian MySQL team is low on manpower, so a new sponsor
> here is desperately needed.

BTW, to me it seems that mariadb-5.5 itself would have use of some
overhaul. There are e.g 4 errors and 8 warnings for it; at least one of
the errors would qualify RC (if linitian is right on this, of course;
but then they should be overriden)

(I'm currently in the NM process, I'll consider when done to join the
Debian MySQL team)

-- 
Tobi


> 
>   Regards,
>Otto Kekäläinen
> 
> 
> 
> -- 
> Check out our blog at http://seravo.fi/blog
> and follow @ottokekalainen
> 
> 



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

Bug#745135: RFS: mariadb-10.0/10.0.10-1 [ITP] -- Latest version of worlds most popular non-Oracle database

[Tobias Frost]

Am Samstag, den 19.04.2014, 10:24 +0300 schrieb Otto Kekäläinen:
> Hello Tobias,
> 
> Thanks for looking into this. My comments:
> 
> 
> 2014-04-18 15:12 GMT+03:00 Tobias Frost :
> > Hallo Otto,
> >
> > (disclaimer: I cannot sponsor it, I'm not a DD)
> 
> You still help me improve the quality of the package and mentor me
> mentally, so thanks anyway!

Well, I'm just always telling that to avoid disappointment later.
And different DD's have different expectations before they sponsor,
which in the end could even mean that you're doing something first and
undoing later. (But that's worst-case.)

> 
> > I did only take a look a the mentors interface, especially at the
> > lintian section. It seems there are several things to be fixed:
> 
> I fixed some of the issues and pushed to git, see changes at
> http://anonscm.debian.org/gitweb/?p=pkg-mysql/mariadb-10.0.git;a=log
> 
> Considering that MariaDB 5.5, MySQL 5.5 and MySQL 5.6 in Debian all
> have a long list of Lintian issues, I think it is a bit too demanding
> if all Lintian issues should be addressed, but of course it would be
> nice to have as many as possible fixed.

Well, goal of all packages should be that they should be as lintian
clean as possible. As you said, 5.5 is in the archives, I say 10.0 is
not; for many DDs lintian cleaness is a requirement for sponsoring.
(Also note that lintian evolves and therefor will report now issues that
where not detected at that time 5.5 was introduced)  

> > W outdated-autotools-helper-file -- looks like that dh-autoreconf or
> > autotools-dev would like to be your friends.
> 
> Autotools is not used. These files seems to be just upstream cruft
> left over, so I added a override with this comment.
> 
> > Please also the linitan errors, eg  dir-or-file-in-var-run or
> 
> I removed that dir. I haven't checked with upstream it it is OK, but
> obviously this one must be removed and later re-introduced as a mkdir
> line in the server startup script or similar.

Yes, as the policy says (the lintian error description has a link to the
section), you need to create it at boot-time, in the init.d script.

> > missing-dependency-on-libc
> 
> Fixed.
> 
> > (There are many other information errors that are easy to fix)
> 
> >From my point of view all the low hanging things are done. Any help
> with nailing the remaining issues is very appreciated.
> 
> > For the overriden linitian warnings: Most of those should be fixed
> > instead of overriden: binary-without-manpage
> > command-with-path-in-maintainer-script manpage-has-errors-from-man
> > If you cannot fix them now, don't override them.
> 
> Are you sure? To me all these non-actionable warnings generate a lot
> of noise and hides issues I could actually address. Although when I
> look at 
> http://lintian.debian.org/full/pkg-mysql-ma...@lists.alioth.debian.org.html#mysql-5.5_5.5.35+dfsg-2
> and 
> http://lintian.debian.org/full/pkg-mysql-ma...@lists.alioth.debian.org.html#mysql-5.6_5.6.16-1~exp1
> they seem to have all these spelling errors and manpage warnings etc
> not overridden. Maybe I should indeed remove those overrides...

Argueable, there is somehow personal taste involved. 
However, I think overrides are only acceptable if I cannot do something
against or if lintian is simply wrong. If the issue is valid, I do not
override but leave it open until I have a chance to fix it (it serves
also as a good reminder then.)
Also Spelling errors can be easily patched away.  

(BTW, I think there also some obsolete warnings overriden; you should
remove them... Best remove all overrides, build the package, and see
what you need to re-add.)

> > Generally, if you override linitian, please do document *why* in the
> > overrides.
> 
> I've now added some more comment lines into the lintian-overrides.
> Some of this packaging is inherited from years back, so as time passes
> I'll review the need for old patches and overrides and the like, but I
> do want to have some progress before I invest a lot more of my time
> into this package. Having a sponsor waiting and promising to upload if
> I work hard enough would be very encouraging..

Sure, I know that feeling. However, thats also chicken-egg-problem:
A good or perfect package is a also a advertisement for sponsors. 
(However from my experience, you'll find an sponsor eventually if you
show that you care and try to deliver the best you can) 

> Stopping here, as it makes no sense to review the code if there are
> > still lintian *errors*
> 
> I have now found a solution to all errors now and there are only three
> "harmless" warnings left.

BTW, when you iterate, can you always upload to mentors afterwards?
Th

Re: ITA for an abandoned package: evolver case

[Tobias Frost]

Am Mittwoch, den 08.06.2016, 11:59 +0100 schrieb Jerome BENOIT:
> Thanks for the reply.
> 
> On 08/06/16 10:40, Gianfranco Costamagna wrote:
> > Hi,
> > 
> > > May I fill an ITA or something to signify that someone to working
> > 
> > > the [surface] evolver package ?
> > 
> > A bug with patches should be enough, ITA means somebody orphaning
> > the package
> > and only the maintainer/MIA team can do it.
> > 
> > But a bug with patches and you proposing the maintainership is
> > something
> > that might be appreciated by the community
> 
> Right now the package rocks.
> But the upstream version is (very) old, and the Debian package
> material
> clearly needs some refreshment. Is a patch really appropriate here ?
> May I rather wait for  clear orphaning instead ?

You can still NMU it, even new upstream versions; but you'll need some
justification here, especially as the current version is mostly
bugfree, according to the BTS. (but #745500 might be a candidate for a
RC severity -- at least when reading the tex; didn'T check) 

So I'd first file bug saying "Please package new upstream Version
x.yy". You can offer to help there, provide a patches/repositories ...
If there is no response within some time (weeks), NMU it.

I'd also file a bug "Is this package still maintained?,
(along the spirit of the "should we RM xyz" bugs like (random, googled
one) 796118, not RM but O/ITA as target.) Give the maintainer a few
weeks to respond, if there is no response, reassign it with "O:" or
"ITA:"

--
tobi

> Jerome
> 
> > 
> > G.
> > 
> 

Bug#827700: RFS: cplay/1.50-1 [NMU]

[Tobias Frost]

Hi Gianfranco,

On Wed, Jun 22, 2016 at 06:54:38AM +, Gianfranco Costamagna wrote:
 
> well, the package hasn't been touched in over a decade, so I presume
> it might be fine to upload the fixes in deferred/15, even as NMU.
> I guess they had *all* the time to refactor the package, and update it.
> 
> I'm ccing them both, and a member of MIA team, even if I'm unsure about the
> MIA process for non DD people,
> 

MIA Team is also handling non-DD, so I'm on it already.

-- 
tobi (for the MIA Team)

Re: ITA for an abandoned package: evolver case

[Tobias Frost]

Am Donnerstag, den 30.06.2016, 11:17 +0100 schrieb Jerome BENOIT:
> 
> > 
> > in the meanwhile, according to quantz, the MIA process started some
> > time ago (on 2016-05-24),
> 
> 
> How can we get the current status of the process ? 
> 

This is not supposed to be posted to a public mailing lists, but as DD
you can logon to qa.debian.org and check there yourself* [1].

[1] https://wiki.debian.org/qa.debian.org/MIATeam

-- 
tobi

Bug#829012: RFS: udftools/1.2-0.1 [NMU] [RC]

[Tobias Frost]

Hi Pali,

The udftools package has (now) been orphaned by the MIA Team (#829016).
if you want you can just adopt it. 

-- 
tobi

Re: Bug#829605: RFS: aspell-sk/2.02-0-0.1 [RC, NMU]

[Tobias Frost]

Some time ago a dh extension has Bern made for aspell dictinaries which should 
help. Take a look at aspell-it. (Im currently on the road so I cannot check if 
this also applies to this package and it was Quote long ago Ehen I worked 
aspell-it)



Am 6. Juli 2016 01:21:32 GMT+02:00, schrieb Adam Borowski :
>On Tue, Jul 05, 2016 at 02:28:30PM +0200, Pali Rohár wrote:
>> On Tuesday 05 July 2016 01:17:39 Jakub Wilk wrote:
>> > Did you need to do any packaging changes to update S-V?
>> > I wouldn't recommend updating S-V in an NMU.
>> 
>> Well, Debian has in archives very old (maybe prehistoric) version of 
>> aspell-sk package. I reported this problem in bug 603719 in past
>*six* 
>> years ago and everybody in Debian ignored it, current maintainer too.
>> 
>> And now when I saw that aspell-sk package is going to be removed from
>
>> Debian, I updated compat level and thought that bringing new version 
>> should be done too...
>
>The package hasn't been updated since 2005, despite upstream being
>alive.
>I'd say it's hijack time (or, if you prefer a veneer of propriety,
>orphaning
>then adopting 20 minutes later).
>
>-- 
>An imaginary friend squared is a real enemy.

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

Re: Bug#829605: RFS: aspell-sk/2.02-0-0.1 [RC, NMU]

[Tobias Frost]

Am Mittwoch, den 06.07.2016, 09:33 +0200 schrieb Tobias Frost:
> Some time ago a dh extension has Bern made for aspell dictinaries
> which should help. Take a look at aspell-it. (Im currently on the
> road so I cannot check if this also applies to this package and it
> was Quote long ago Ehen I worked aspell-it)
> 

(Gosh, this was the result of Android autocorrection when directory is
not correctly set...) 

So, I looked at it again. Seems so that aspell-sk could (and then also
should) use of dh_aspell-simple(1).

As said, the refrence package made at that time was aspell-it, so
taking a look at it will for sure help. See also #737515 and http://lis
ts.alioth.debian.org/pipermail/dict-common-dev/2014-June/000789.html)

--
tobi


> 
> Am 6. Juli 2016 01:21:32 GMT+02:00, schrieb Adam Borowski  ngband.pl>:
> > On Tue, Jul 05, 2016 at 02:28:30PM +0200, Pali Rohár wrote:
> > > On Tuesday 05 July 2016 01:17:39 Jakub Wilk wrote:
> > > > Did you need to do any packaging changes to update S-V?
> > > > I wouldn't recommend updating S-V in an NMU.
> > > 
> > > Well, Debian has in archives very old (maybe prehistoric) version
> > > of 
> > > aspell-sk package. I reported this problem in bug 603719 in past
> > *six* 
> > > years ago and everybody in Debian ignored it, current maintainer
> > > too.
> > > 
> > > And now when I saw that aspell-sk package is going to be removed
> > > from
> > 
> > > Debian, I updated compat level and thought that bringing new
> > > version 
> > > should be done too...
> > 
> > The package hasn't been updated since 2005, despite upstream being
> > alive.
> > I'd say it's hijack time (or, if you prefer a veneer of propriety,
> > orphaning
> > then adopting 20 minutes later).
> > 
> > -- 
> > An imaginary friend squared is a real enemy.
> 

Re: libgdbm transition

[Tobias Frost]

Am Mittwoch, den 13.07.2016, 11:33 +0100 schrieb James Cowgill:

> You will have to file all the bugs manually, but I expect all the
> bugs will follow a similar template.

You'll find mass-bug(1) from devscripts helpful on the filing part.

> 
> James

-- 
tobi

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Tobias Frost]

Am Mittwoch, den 24.08.2016, 22:06 +0200 schrieb Elmar Stellnberger:
> 
> 
>    The license in use, C-FSL v1.0 will still need to be reviewed. A 
> predecessor license C-FSL v0.8 had already been discussed on 
> debian-legal some time ago. However v1.0 has been reworked basing
> on the input I had received from there and should now hopefully be 
> without issues. 

I think one recommendation has not been followed. If not, I *strongly*
recommend: 
PLEASE Do not run your own license. See https://people.debian.org/~bap/
dfsg-faq.html §5

I took me some time to locate this license (please put it somewhere and
link to it).
I located it then in the header of the xchroot script, and as I only
had 5 minutes to take a look, I come only to this sentence:

"If a specific version number is mentioned then usage rights include
this version as well as any newer version which will always be similar
in spirit to this license. The term Convertible Free Software license
may be abbreviated as C-FSL."

- This will fail the the tentacle of evil test. 
- What happens if there is no version number attached? Choose any?
Choose latest?

"3. It is your obligation that the changed version of your sources will
be available to the public for free within the time frame of a month at
least if there is no undue hindrance by the authors to make it
available. "

As distribution is not limited to the people using the stuff, this is
non-free. Fails Desert Island Test and Dissident Tests. 

(I have stopped here... Above is not a complete analysis of any
section, also not up to 3.I)


PLEASE do not run your own license. 

--
tobi

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Tobias Frost]

Am Donnerstag, den 25.08.2016, 20:56 +0200 schrieb Elmar Stellnberger:

(snip)
> 
>    Anyone else who could assert me that an additional GPL-3 clause
> would 
> do what I want: i.e. give an additional right to relicense to a
> group 
> called original authors only; let this be called GPL-3 + relicensing
> by 
> authors. The GPL-3 amendment would more or less be the same as #7 of 
> C-FSL and a statement to tag the GPL-3 abbreviation with the
> relicensing 
> by authors flag.
>    Is it really true that this can not be interpreted as restriction 
> just because any contributor would have to consent in giving the 
> original authors this additional right. It means that someone who
> does 
> not consent is not allowed to apply changes because then the whole 
> license would need to turn invalid.

Actually, I believe this is problematic in terms of DFSG
(For a more based answer, I suggest you to post this question to
debian-legal.) 

For it dependis on what you mean with "right to relicense". 

But maybe one step back.. As Author of your work you have always the
right to relicense, as in "from this release on, it is license xyz.".
Note the "from this release on" part, because retrospectivly you cannot
change the rules*. Then, it is easy as long as you are the sole author
for the complete work, if they are other people with copyright on the
work, they need to consent with it or their parts removed/replaced.
(You previously wrote smth along this, so this should be nothing new
for you)

(* as you know, this is tested by the "Tentacles of Evil")

But I guess this is not what you meant... I guess your're fearing that
someone patches the software, you'd like to the change, like to
incoropoate it, and then relicense the whole thing. As said, if you
reach out to the author doing so and get the consent, everyone's cool.

If your license term wants to avoid that you need that consent, I think
that is problematic and wer're in Tentacles' Land again: You could
effectivly take away the rights of that author, worst case even make
something out of it closed source without the author being able to
object. So IMHO at least the relicensing term must ensure that you
cannot revoke existing rights.

Usually, the FLOSS world solves this problem with copyright
assignments, not with the license. And copyright assignments might
deter contributors, so probably also a blanco-relicense statement.

As said, this is my feeling on the topic; please ask on debian-legal,
as a public mailing list you can for sure post your license and
questions. Not unikely that someone answer. 

(It is also possible that I did not get your intentions.)

> 
> Finally I would like to ask anyone who knows about another issue
> with 
> C-FSL to share it with me as the programs in question will likely be 
> available under C-FSL + GPL-3 + relicensing by authors for some
> ongoing 
> time.
> 
> up to now I have noted the following issues for C-FSL:
> * explicitly allow unchanged redistribution
> * version number to use as default: v1.1
> * mention online URL in the license
> 
> see: https://www.elstel.org/license/C-FSL-v1.0.txt

Again, please avoid making own licenses. This is a road doomed to
failure. 
The topic is so complicated that even law experts and law department
struggle to get it right: avoiding loopholes and really make it
watertight while preserving the spirit of FLOSS
  
> Regards,
> Elmar
> 

--
tobi

Disclaimer: IANAL.

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Tobias Frost]

Package: sponsorship-requests
Followup-For: Bug #835368
Control: tags -1 wontfix

As the license is non-free, tagging the RFS as wontfix: It cannot be uploaded
to main.
I did not check if if non-free would be possible as target. 

-- 
tobi


-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#830788: RFS: ifstat/1.1-9

[Tobias Frost]

Hi Goswin,

Am Montag, den 11.07.2016, 15:44 +0200 schrieb Goswin von Brederlow:

> Package: sponsorship-requests
> Severity: normal
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "ifstat"
> 
>  Package name: ifstat
>  Version : 1.1-9
>  Upstream Author : Gal Roualland 
>  URL : http://gael.roualland.free.fr/ifstat/
>  License : GPL
>  Section : net
> 
> It builds those binary packages:
> 
> ifstat- InterFace STATistics Monitoring
> libifstat-dev - Ifstat Development Files
> 
> To access further information about this package, please visit the
> following URL:
> 
> https://mentors.debian.net/package/ifstat
> 
> 
> Alternatively, one can download the package with dget using this
> command:
> 
>   dget -x https://mentors.debian.net/debian/pool/main/i/ifstat/ifstat
> _1.1-9.dsc
> 
> More information about hello can be obtained from https://www.example
> .com.
> 
> Changes since the last upload:
> 
> ifstat (1.1-9) unstable; urgency=low
> 
>   * Update to debhelper version 9 (Closes: #817499, #828348).
>   * Add multiarch support.
>   * Fix bandwidth spelling in manpage (Closes: #617336).
>   * Use dpkg-buildflags for hardening.
> 
>  -- Goswin von Brederlow   Mon, 11 Jul 2016
> 12:03:29 +0200
> 
> 
> The changes are purely packaging (except the spelling) related and a
> straight
> update from the old rules file to dh. It blocks some transitions so
> it's
> mildly important to get uploaded soon.
> 
> Regards,
>  Goswin von Brederlow
> 

any news on your package?

What I also noticed is that you have added a B-D on libssl-dev,
but I cannot find any reference that the source is actually using it.
Using Openssl on GPL'ed code without explicit license grant would be
bad... Can you expand?

(Note that I did a NMU on the current version in sid to fix only the
compat level 4 bug)

-- 
tobi

Bug#839725: uptimed: 0.4.0+git20150923.6b22106-1 [ITA]

[Tobias Frost]

Control: owner -1 !

I will take a look at part of gustavo's NM process.

--
tobi

Bug#840500: RFS: asciinema/1.3.0-2 [RC]

[Tobias Frost]

Control: owner -1 !
Thnks

Will take a look ASAP (either today evening or Friday)

--
tobi

> Package: sponsorship-requests
> Severity: important
>
>
> Hello
>
> I'm looking for an sponsor of my updated asciinema package
>
> If closes an RC bug, and various fixes/improvements
>
> Here is the last entry in the changelog
>
> asciinema (1.3.0-2) unstable; urgency=medium
>
>   * Correct the license from MIT to GPL-3+ (Closes: #840134).
>   * Relicense the debian directory to GPL-3+
>   * Use upstream manpage
>   * Run the test suite, as it does not get run by default
>   * Store the generated tarball using pristine-tar
>
>  -- gustavo panizzo   Tue, 11 Oct 2016 09:28:07 +0800
>
> git repo can be found at
> https://anonscm.debian.org/git/collab-maint/asciinema.git
>
> built package can be downloaded from
> https://mentors.debian.net/debian/pool/main/a/asciinema/asciinema_1.3.0-2.dsc
>
> attached the debdiff between 1.3.0-1 and 1.3.0-2
>
>
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (300, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>

Bug#839725: uptimed: 0.4.0+git20150923.6b22106-1 [ITA]

[Tobias Frost]

Hallo Gustavo,

thanks for adopting the package!

ok, let's start with the review.
(The review is part of the NM process, gustavo's NM archive gets a copy
via BCC) 

Am Dienstag, den 04.10.2016, 18:22 +0800 schrieb gustavo panizzo:
> Package: sponsorship-requests
> Severity: normal
> 
> Hello
> 
> I'm looking for an sponsor of my package uptimed,
> I want to adopt this package after it was orphaned by the previous
> maintainer #830765
> 
> uptimed is an old package (in debian since '99) it has many bugs
> open,
> I fixed some bugs but others I wasn't able to reproduce them,
> so my plan is to upload to experimental
> and contact the reporters to see if they/I can reproduce the bugs
> then fix
> them.
> 
> I want to upload to experimental to check if it builds reproducibly
> in all Debian architectures.
> Be aware that I'll request another upload latter for unstable.
> 
> debian/rules and packaging in general was polished, modernized, and
> uploaded
> to collab-maint
> 
> this is the changelog

let me nitpick on your changelog a bit ;-)

> uptimed (1:0.4.0+git20150923.6b22106-1) experimental; urgency=medium
> 
>   * New maintainer, thanks Thibaut Varene for your previous
> work (Closes: #830765)
>   * Packaging is now maintained in collab-maint using a git repo

>   * Packaging an snapshot from upstream
>   * Packaging using git tags instead of tarballs

Those are acutally one change, not two.

>   * Change dh compat to level 9. No changes were needed
>   * Build depend on debhelper 9 and dh-autoreconf

those two lines are a little contradicting, you need the B-D version
for compat 9; and why not go for compat 10, it makes dh-autoreconf
default, for instance.  

>   * Update Homepage field on debian/control (Closes: #806456)
>   * Handle missing /etc/uptimed.conf (Closes: #680419)
>   * Simplify uptimed init.d script, restart unconditionally on
> uptimed
> postinst
>   * Match the location of the $PIDFILE in the init script and the
> daemon
> configuration (Closes: #336922) (LP: #482629)
>   * Create /run/uptimed via a tmpfile on systemd systems
>   * Change the default interval to save the database from 300 to 3600
> seconds

why? (changelogs should answer those questions...)

>   * Bump Standards-Version to 3.9.8. No changes were needed
>   * Override 2 lintian warnings (unused-debconf-template)

Why is the override neccessary?

>   * Remove perl dependency on libuptimed0 and libuptimed-dev, perl-
> base is
> enough
>   * Change watch file to look at github
>   * Update uptimed's service file, to start after the time is in
> sync,
> it still may fail if systemd-timesyncd.service is not in use
> 

as said, those are nitpicks but a important reason to have changelogs
is to transport the information why something has changed and not only
what. This gives the users the opportunity to assess if a change
affects them. 

Another nitpick is: try to group related changes, it helps
understanding them.

To the package:
 * d/*.dirs shouldn't be neccessary anymore, 
 * *.la files should not be distributed anymore, did you check if it
   can vbe dropped? (https://wiki.debian.org/ReleaseGoals/LAFileRemoval
   )
 * d/control: the "Replaces: libuptimed" could be dropped (it is from a
   release long long ago; nitpick)
 * ist uptime.conf.5 regenerated at build time? its header says it
   should... 
 * there is an linitian _error_ init.d-script-needs-depends-on-lsb-
   base, but that should be easy to fix.
 * the spelling fix patch is not documented in the changelog
  * d/copyright is incomplete, I see at least one file with is not
covered: src/sd-daemon.c by L. Poettering

Please fix the lintian error, the d/copyright and then I'll upload.
The *.la can be fixed in a subsequent upload, but maybe you can include
it already in the revised packages.

-- 
tobi

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

Bug#839725: uptimed: 0.4.0+git20150923.6b22106-1 [ITA]

[Tobias Frost]

Hallo Gustavo,

 
> * there is an linitian _error_ init.d-script-needs-depends-on-lsb-
>   base, but that should be easy to fix.

Never mind this one, it will be removed from lintian.
(#838997)


--
tobi

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

Bug#839725: uptimed: 0.4.0+git20150923.6b22106-1 [ITA]

[Tobias Frost]

Hi Gustavo,

Am Mittwoch, den 19.10.2016, 14:15 +0800 schrieb gustavo panizzo:
> On Sun, Oct 16, 2016 at 10:35:42AM +0200, Tobias Frost wrote:
> > 
> > Please fix the lintian error, the d/copyright and then I'll upload.
> > The *.la can be fixed in a subsequent upload, but maybe you can
> > include
> > it already in the revised packages.
> 
> 
> I've pushed to alioth, please take a look
> 

Please recheck, I can't see the changes here.

tobi@edoras:~/workspace/deb/nm/gustavo/uptimed/uptimed$ git remote get-
url origin
git.debian.org:/git/collab-maint/uptimed.git
tobi@edoras:~/workspace/deb/nm/gustavo/uptimed/uptimed$ git log | head
-n 10
commit 1490651ea12e9db47e839c947da867971bab9b18
Author: Holger Wansing 
Date:   Tue Oct 18 22:41:44 2016 +0200

German translation: proofreading by Markus Hiereth, thanks!

commit 118d01074feb3dee9079950d6976634e391255b9
Author: Holger Wansing 
Date:   Sat Oct 15 15:36:50 2016 +0200



> (archive-gfa@nm.d.o is bcc'ed)
> 
> 
> 

Bug#841066: RFS: gnome-shell-extensions-pixelsaver/1.9-1, ITP: 829089 -- pixel saver extension for GNOME shell

[Tobias Frost]

Control: owner -1 !
Control: tag -1 moreinfo

Hi highvoltage,

Package is fine, however one thing needs fixing:
The themes have authorship attributed, but this is not reflected in 
the copyright file. Those themes also do not necessarily have the same
license as the extension itself (e.g Arc-dark says it is based on
https://github.com/horst3180/Arc-theme, which is GPL-3+; though I did
not check which files have been taken or if it was only for
inspiration)

Another nitpick: As the extension does not support all gnome-shell
versions, can you add a versioned depends on gnome-shell > = 3.16 ?

Thanks for packaging this extension!

--
tobi

Bug#841065: RFS: gnome-shell-extensions-dashtodock/55-1, ITP: 829185 -- dash-to-dock extension for GNOME shell

[Tobias Frost]

Control: owner -1 !
Control: tags -1 moreinfo

Hallo highvoltage,

Can you check if you think those comments are valid? 

- the patch for the installation directory should be upstreamed,
(I had something similar for one of my extensions, I solved it this
way:)
https://github.com/laserb/gnome-shell-extension-suspend-button/pull/19

- I guess the README should also not installed to /usr/share/gnome-
shell/extensions/dash-to.../ but /usr/share/doc/gnome-shell-extensions-
dashtodock (probably an extra "docs" in the filename of debian/gnome-
shell-extension-dashtodock-docs.docs)

- you're shipping in the debian.tar an autoreconf.(before|after)..
Probably stray files

- maybe also a versioned dependency on gnome-shell >=3.18 won't hurt
here as well to avoid issues when (partially) upgrading from jessie
 
- translators copyright should be also recorded in d/copyright.

Thanks!

--
tobi

Bug#841070: RFS: gnome-shell-extensions-remove-dropdown-arrows/7-1, ITP: 829071 -- removes drop down, arrows from panel on GNOME shell

[Tobias Frost]

Control: owner -1 !
Control: tags -1 moreinfo

Hi highvoltage,

Package does not build using pbuilder, I think a B-D on zip is missing

dh build
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
make -j1
make[1]: Entering directory '/build/gnome-shell-extension-remove-
dropdown-arrows-7'
zip -j remove-dropdown-arr...@mpdeimos.com.zip README.md LICENSE
extension.js metadata.json
make[1]: zip: Command not found
Makefile:13: recipe for target 'dist' failed
make[1]: *** [dist] Error 127
make[1]: Leaving directory '/build/gnome-shell-extension-remove-
dropdown-arrows-7'
dh_auto_build: make -j1 returned exit code 2
debian/rules:4: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


Two additonal nitpicks:
- Maybe a versioned dependency on gnome-shell?
- The patch for gnome-shell 3.22 is not needed, as with newer gnome-
shells the default has been changed, so that no longer needed.
Details: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837594#19

--
tobi

Bug#841065: RFS: gnome-shell-extensions-dashtodock/55-1, ITP: 829185 -- dash-to-dock extension for GNOME shell

[Tobias Frost]

Am Montag, den 24.10.2016, 11:31 +0200 schrieb Jonathan Carter
(highvoltage):
> On 22/10/2016 16:28, Tobias Frost wrote:
> > - translators copyright should be also recorded in d/copyright.
> 
> I added the translations with copyright assertions in d/copyright:
> 
> https://gitlab.com/highvoltage/gnome-shell-extension-dashtodock-packa
> ging/commit/e446de895987a1a271c9e3fe7232ed853fc772ea
> 
> It looks right to me but it seems like it parses differently than I
> understand:
> 
> I: gnome-shell-extension-dashtodock source:
> wildcard-matches-nothing-in-dep5-copyright po/BR.po (paragraph at
> line 31)
> N:
> N:The wildcard that was specified matches no file in the source
> tree. This
> N:either indicates that you should fix the wildcard so that it
> matches the
> N:intended file or that you can remove the wildcard. Notice that
> in
> N:contrast to shell globs, the "*" (star or asterisk) matches
> slashes and
> N:leading dots.
> N:
> N:Refer to
> N:https://www.debian.org/doc/packaging-manuals/copyright-format/1
> .0/ for
> N:details.
> N:
> N:Severity: minor, Certainty: possible
> N:
> N:Check: source-copyright, Type: source
> N:
> I: gnome-shell-extension-dashtodock source:
> unused-file-paragraph-in-dep5-copyright paragraph at line 31
> N:
> N:The Files paragraph in debian/copyright is superfluous as it is
> never
> N:used to match any files. You should be able to safely remove
> it.
> N:
> N:Refer to
> N:https://www.debian.org/doc/packaging-manuals/copyright-format/1
> .0/ for
> N:details.
> N:
> N:Severity: minor, Certainty: possible
> N:
> N:Check: source-copyright, Type: source
> 
> Could you perhaps give me a pointer theregnome-shell-extension-
> dashtodock?

There is no po/BR directory in the source. ;)


> thanks!
> -Jonathan

Bug#841917: RFS: gnome-shell-extensions-refresh-wifi/6-1, ITP: 841913 -- keep wifi access point list current in GNOME shell

[Tobias Frost]

Control: owner -1 !

Hi Jonathan,

Am Montag, den 24.10.2016, 14:49 +0200 schrieb Jonathan Carter
(highvoltage):
> 
> * Package name    : gnome-shell-extensions-refresh-wifi
>   Version : 6-1
>   Upstream Author : Gopi Sankar Karmegam
> * URL : https://github.com/kgshank/gse-refresh-wifi
> * License : GPL-3
>   Programming Lang: Javascript
>   Description : keep wifi access point list current in GNOME
> shell

can you add a gnome-shell dependency to the binary package?

Otherwise it is fine and I'll upload it then.

--
tobi

Bug#843636: RFS: gnome-shell-extension-disconnect-wifi/3.22.14, ITP: 843633 -- disconnect wifi extension for GNOME shell

[Tobias Frost]

control: owner -1 !

Hi Jonathan,

Can you rebuild locale/*.mo during build?
Otherwise it is fine!

--
tobi

Bug#844462: RFS: nitrogen/1.6.0-1 [QA]

[Tobias Frost]

Control: owner -1 !

Will take a look tonight.

Am Mittwoch, den 16.11.2016, 10:36 +0800 schrieb gustavo panizzo:
> Package: sponsorship-requests
> Severity: normal
> 
> Hello
> 
> I'm looking for an sponsor for my QA upload to tsocks
> 
> 
> it closes a bug and prevents a FTBFS (compat level 7),
> I've improved the general shape of the package and enables
> it to build on !linux
> 
> The changelog follows
> 
> nitrogen (1.6.0-1) unstable; urgency=medium
> 
>   * QA upload
>   * Set the maintainer to Debian QA Group
>   * New upstream release (Closes: #796980)
>   * Increase the compat level to 10
> - Build depend on dh > 10
> - Remove build dependency on autotools-dev, autoconf, autopoint,
>   and automake
>   * Remove build dependency on dpkg-deb (>= 1.16.1~)
>   * Bump standards version to 3.9.8, the following changes were
> needed
> - Remove obsolete menu file
>   * Enable hardened build
>   * Simplify debian/rules
>   * Drop old pathches
> - fix_FTBFS_binutils-gold.patch, no longer needed
> - add_desktop_file.patch, merged upstream
>   * Fix spelling on manpage
> - spelling-fixes.patch
>   * Enable build on !linux, thanks Christoph Egger
>  for the patch (Closes: #794901)
>   * Package upstream's git log as changelog, as the Changelog in the
> source
> is very outdated
>   * Add README.source
>   * Packaging is now maintained on a git repo under collab-maint
>   * Add Vcs fields to debian/control
>   * Add pristine-tar to the git repo
>   * Add gbp.conf
> 
> the git repo can be found at
> https://anonscm.debian.org/cgit/collab-maint/nitrogen.git
> 
> thanks
> 
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (300, 'unstable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 

Bug#843636: RFS: gnome-shell-extension-disconnect-wifi/3.22.14, ITP: 843633 -- disconnect wifi extension for GNOME shell

[Tobias Frost]

Am Freitag, den 11.11.2016, 20:18 +0100 schrieb Tobias Frost:
> control: owner -1 !
> 
> Hi Jonathan,
> 
> Can you rebuild locale/*.mo during build?
> Otherwise it is fine!
> 
> --
> tobi
> 

ping :)

--
tobi

Bug#846325: RFS: netperfmeter/1.6.1-1

[Tobias Frost]

Control: owner -1 !
Control: tags -1 +moreinfo


Hi Thomas,

required fixes for uploads:
- d/changelog:
The entries for not released Debian versions should be deleted
(preferred) or marked as UNRELEASED. You also can concentrate all
entries not part of a prior (Debian) release into the most recent
entry.
- d/copyright: The license short tag should be GPL-3+ not GPL-3 (note
the "+")
- d/control: Is colorgcc really needed as B-D? Here it builds
without...
- d/control: Standard-Version is not latest.
- d/compat: Please migrate to compat level 10 -- then also autoreconf
and stuff will be run automatically.
- d/control: your homepage is down.
- d/rules: the override for dh_installchangelogs is not needed. 

nitpicks, not required for upload
- As far as I can see debian/netperfmon.(install|manpages) is not
needed, picked up automatically.

For the check-all-the-thing I recommend to install this package and run
it yourself. I only quoted a bit of it.
Use e.g
check-all-the-things --checks-output-lines 256 


Check-All-The-Things: (nitpick section, but please implement as much as
you think makes sense)

- several versioned B-Ds are already fulfilled in oldstable, can be
dropped: 

Warning in 'control source Build-Depends:3' value 'dpkg-dev (>=
1.16.1~)': unnecessary versioned dependency: dpkg-dev (>= 1.16.1~).
Debian has oldstable -> 1.16.18; stable-kfreebsd -> 1.17.25; stable ->
1.17.27; testing -> 1.18.15;
Warning in 'control source Build-Depends:4' value 'libbz2-dev (>=
1.0)': unnecessary versioned dependency: libbz2-dev (>= 1.0). Debian
has oldstable -> 1.0.6-4; stable -> 1.0.6-7+b3; unstable -> 1.0.6-8;
unstable -> 1.0.6-8+b1;
Warning in 'control source Build-Depends:6' value 'libglib2.0-dev (>=
2.0.0)': unnecessary versioned dependency: libglib2.0-dev (>= 2.0.0).
Debian has oldstable -> 2.33.12+really2.32.4-5; stable-kfreebsd ->
2.42.1-1; stable -> 2.42.1-1+b1; jessie-backports -> 2.48.0-1~bpo8+1;
testing -> 2.50.2-2; experimental -> 2.51.0-2;
Warning in 'control source Build-Depends:7' value 'libsctp-dev (>=
1.0.5)': unnecessary versioned dependency: libsctp-dev (>= 1.0.5).
Debian has oldstable -> 1.0.11+dfsg-2; stable -> 1.0.16+dfsg-2;
unstable -> 1.0.17+dfsg-1;

Warning in 'control binary:netperfmeter Recommends:2' value 'subnetcalc
(>= 2.0.2)': unnecessary versioned dependency: subnetcalc (>= 2.0.2).
Debian has stable-kfreebsd -> 2.1.3-1; testing -> 2.1.3-1+b1;

-- your homepage is down:
E: debian/control: Homepage: http://www.iem.uni-due.de/~dreibh/netperfm
eter/: ERROR (Certainty:certain)
   Curl:28 HTTP:0 Timeout was reached Connection timed out after 60001
milliseconds

E: debian/copyright:4: URL: http://www.iem.uni-due.de/~dreibh/netperfme
ter/: ERROR (Certainty:possible)
   Curl:28 HTTP:0 Timeout was reached Connection timed out after 6
milliseconds

-- flawfinder (could be false positive)
$ flawfinder -Q -c .
Flawfinder version 1.31, (C) 2001-2014 David A. Wheeler.
Number of rules (primarily dangerous function names) in C/C++ ruleset:
169
./src/outputfile.cc:153:  [4] (format) printf:
  If format strings can be influenced by an attacker, they can be
exploited
  (CWE-134). Use a constant for the format specification.
bool OutputFile::printf(const char* str, ...)
./src/outputfile.cc:160:  [4] (format) vsnprintf:
  If format strings can be influenced by an attacker, they can be
exploited,
  and note that sprintf variations do not always \0-terminate (CWE-
134). Use
  a constant for the format specification.
(clipped, more hints exists)



include-what-you-use:


src/outputfile.h should remove these lines:
- #include   // lines 28-28

===
# As per RFC 6068, there should be no slashes after "mailto:";.
$ grep -rF mailto:/ .
./src/createsummary.1:mailto://dre...@iem.uni-due.de
./src/netperfmeter.1:mailto://dre...@iem.uni-due.de
./src/combinesummaries.1:mailto://dre...@iem.uni-due.de
./src/pdfmetadata.1:mailto://dre...@iem.uni-due.de
./src/plot-netperfmeter-results.1:mailto://dre...@iem.uni-due.de
./src/extractvectors.1:mailto://dre...@iem.uni-due.de
./src/runtimeestimator.1:mailto://dre...@iem.uni-due.de
./src/pdfembedfonts.1:mailto://dre...@iem.uni-due.de

===
Typos:
./ChangeLog:5727: priviledges  ==> privileges
./src/netperfmeter.cc:528: successfull  ==> successful


=
deheader

./src/flow.cc has more than one inclusion of 
deheader: ./src/tools.cc has more than one inclusion of 
deheader: in ./src/combinesummaries.cc, =\s*false portability requires
.
deheader: remove  from ./src/combinesummaries.cc
deheader: remove  from ./src/combinesummaries.cc
deheader: remove  from ./src/combinesummaries.cc
deheader: in ./src/control.cc, fopen() portability requires .
deheader: in ./src/control.cc, =\s*false portability requires
.
deheader: in ./src/control.cc, ntohs() portability requires
.
deheader: in ./src/control.cc, exit() portability requires .
deheader: remove  from ./src/control.cc
deheader: remove  from ./src/cont

Bug#847197: RFS: gnome-shell-extension-multi-monitors ITP: 847178 -- Better support for additional monitors in GNOME shell

[Tobias Frost]

Control: owner -1 !
Control: tags -1 moreinfo

Hi Jonathan,

Can you "recompile" the schema file in d/rules?
I used for one of my packages something along: 
glib-compile-schemas --strict --targetdir=schemas/ schemas

Otherwise the package is fine and I'll upload it ASAP :)

--
tobi

Bug#847175: RFS: gnome-shell-extension-system-monitor/31-1, ITP: 847080 -- Display system information in GNOME Shell status bar

[Tobias Frost]

Control: owner -1 !
Control: tags -1 moreinfo

Hi Jonathan,

as before: please recompile the gschema file.

One observation: There seems to be two set of locale directories in the
sources. Maybe something for upstream to sort out? (This is nothing
that blocks the upload)

--
tobi

Bug#847308: Bug#847076: ITP: gnome-shell-extension-shortcuts -- Creates a shortcuts help pop-up in GNOME Shell

[Tobias Frost]

Hi Kyle,

please also open a RFS bug for this..

packaging:
- there is a missing Dependency on gnome-shell

upstream:
- the version constraint metadata.json looks weird: 3.22.2...
  shouldn't it be only 3.22 or like? Not sure, please x-check. (this is
also something for the logout button extension)

-- 
tobi

Bug#847305: Bug#847050: ITP: gnome-shell-extension-log-out-button -- A GNOME Extension to add a log out button to the system activities menu

[Tobias Frost]

Hallo Kyle,

Please open up a RFS bug and also bounce this mail to the bug. 

Review:

- the packaging seems fine

upstream related:
- seems so that the gschema is not needed, is it?
- when disabling the extension (e.g via gnome-tweak-tool), the icon
stays in the menu. This is bug, I guess as e.g gnome-shell-extension-
suspendbutton does immediatly remove the button once disabled in g-t-t)
- when enabling the extension via gnome-tweak-tool, the icon goes to
the far right in my case, when reloading gnome-shell it is then placed
in the "middle"? Is this intentional?

--
tobi

Bug#847308: Bug#847076: ITP: gnome-shell-extension-shortcuts -- Creates a shortcuts help pop-up in GNOME Shell

[Tobias Frost]

Control: tags -1 moreinfo

Hi Kyle,

(sorry, I missed a bit the last review)

d/changelog:
- do not bump version until the first upload is done. 
  in other words, it should just read, no other entries

gnome-shell-extension-shortcuts (1.0.3-1) unstable; urgency=medium

  * Initial Upload (Closes: #847076)

 -- Kyle Robbertze   Wed, 07 Dec 2016 10:12:14
+0200

- there is an trailing space in d/control line 15

- d/dirs is not needed. 

- d/rules: (this is bikeshedding, you do not need to follow) I prefer
  to clean via (the file) d/clean not via an override in d/rules.

 - src/convenience.js is originally not copyrighted by you, but 
   by Giovanni Campagna  and also under
   BSD-3-clause. Please approbiatly attribute copyrights.
   (This is a show stopper)

- in the schema description is a typo: pannel.

--
tobi

 
On Wed, 7 Dec 2016 10:31:04 +0200 Kyle Robbertze 
wrote:
> 
> 
> On 06/12/2016 23:45, Tobias Frost wrote:
> > Hi Kyle,
> > 
> > please also open a RFS bug for this..
> Done
> > 
> > packaging:
> > - there is a missing Dependency on gnome-shell
> Added
> > 
> > upstream:
> > - the version constraint metadata.json looks weird: 3.22.2...
> >   shouldn't it be only 3.22 or like? Not sure, please x-check.
(this is
> > also something for the logout button extension)
> Should be just 3.22. Seems the gnome tool to create the extension
> skeleton added the exact version I am using.
> > 
> 
> Cheers
> Kyle
> 

Bug#847305: Bug#847050: ITP: gnome-shell-extension-log-out-button -- A GNOME Extension to add a log out button to the system activities menu

[Tobias Frost]

Control: tags -1 moreinfo

Most of #847308 also applies here.

--
tobi