Re: Bug#806572: RFS: multimail/0.50~20150922-1 [ITA]

[Robert James Clay]

Hi Tobias!

On Thursday, January 07, 2016 05:54:29 AM Tobias Frost wrote:
 
> On Tue, 05 Jan 2016 18:08:55 -0500 Robert James Clay 
> wrote:
> > On Tuesday, January 05, 2016 04:27:48 AM Tobias Frost wrote:
> > > - Is the patch forwarded to upstream?
> > 
> >The non vendor specific parts of it, you mean?  I plan to further
> > discuss other aspects of it with him, yes...  I have provided him
> > with the results of package builds but he hasn't commented...
> 
> The Makefile looks buggy to me, not vendor-specific: Hardcoded paths
> are bad. But ok, a patch will do it for now. However, please then set
> the patch headers appropiately, especially the Forwarded one with (if
> available) a link to more information. 

  I'll be discussing that with the author, but in the mean time will see about 
updating the patch headers more appropriately.



> > > - d/rules: Are the lines setting CPPFLAGS and friend really needed?
> > 
> >As I recall, those were needed to clean up the hardening related
> lintian errors.
> 
> With debhelper 9 and compat 9 this is no longer needed.

According to my notes, I was still seeing hardening related errors, after 
changing the debhelper version to 9.  I'll investigate that again.


> 
> You can cleanup your d/rules even more: This is enough:
> 
> #!/usr/bin/make -f
> 
> %:
> dh $@

   I'll be looking into how it might be reduced to that, although there is at 
least one thing I'd want to keep...


> 
> Why: 
> - the dh_installchangelogs --keep HISTORY is not needed, Debian users
> know that they have to look on changelog.gz

 And those already familiar with the application (but not necessarily Debian) 
would expect to see the HISTORY file, so I'd rather keep that.  (It only adds a 
sym link after all...)


> - dh_installdocs --link-doc=multimail just adds complexity, saving
> maybwe 10k.

   And not really needed any longer, when the dbgsym package is being used.   
I'll take care of that


> - dh_auto_install --destdir=debian/multimail destdir is automatically
> figured out by dh_auto_install. 

   I'll check into that as well, as I don't recall why I explicitly still had 
that set.


> 
> d/copyright:

   I'll investigate the issues you raised regarding the debian/copyright file 
and resolve as necessary.






RJ Clay
j...@rocasa.us

Bug#810529: RFS: moc/1:2.6.0~svn-r2788-1

[Elimar Riesebieter]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "moc" as my main sponsor and uploader
isn't available at the moment.

Package name: moc
Version : 1:2.6.0~svn-r2788-1
Upstream Author : mocma...@daper.net
URL : http://moc.daper.net/
License : GPL2+
Section : sound

It builds those binary packages:

moc - ncurses based console audio player
moc-ffmpeg-plugin - ncurses based console audio player - ffmpeg plugin

To access further information about this package, please visit the following 
URL:
http://mentors.debian.net/package/moc

Alternatively, one can download the package with dget using this command:
dget -x 
http://mentors.debian.net/debian/pool/main/m/moc/moc_2.6.0~svn-r2788-1.dsc

Changes since the last upload:

* Update to svn r2788 (closes: 803842)
  - Upstream applied a slightly modified patch from Andreas Cadhalpun to
prevent a FTBFS with FFmpeg 2.9. Thanks Andreas!
...

Thanks in advance
Elimar
-- 
 Never make anything simple and efficient when a way
  can be found to make it complex and wonderful ;-)

Re: Re: mentor wanted

[Gianfranco Costamagna]

Hi,



>I know...I looked over this mailing list and almost every message starts with 
>"Bug #".
>Going back to the Debian Developer's Reference, it says if someone wants a 
>mentor
>to help via email, they should ask here. I need advice, but on a broader array 
>of
>issues than just one bug.
>
>Examples of issues would be:
>
>- getting links on blends.debian.org
>
>- setting up pages on blends.debian.org/fluxbox/ (I think I need a symbolic 
>link from
>  https://blend-fluxbox.alioth.debian.org/ but I don't know how to access that)
>
>- setting up task pages (auto generated from control files)
>
>- how to package metafiles for a blend (I understand the basics)
>
>- how to package scripts that set up configs in /etc and set up /etc/skel and 
>copy that
>   to the users home dir
>
>So, really, it's a whole set of issues.


A whole set of issues, but mentors as said by Paul is regarding mostly 
packaging issues (and
pointing to the right direction when non-packaging issues are arisen).

So, please get in touch with blend list :)

cheers!

G.

Bug#809727: RFS: hwb/1:040412-7

[Jakub Wilk]

On Thursday, January 07, 2016 05:32:49 PM Mattia Rizzolo wrote:
To upload a non-free package, and get it built by the autobuilders you 
need 'XS-Autobuild: yes' and according to DevRef § 5.10.5 also to mail 
somebody (dunno for what).


So that the package can be (manually) whitelisted.

* Robert James Clay , 2016-01-09, 09:33:
Something to do with explaining if it "is legally allowed and 
technically possible to auto-build the package", although it's not 
clear to me if that email (and a presumed response to it) should happen 
before the package is uploaded.


The person doing whitelisting will probably want to look at the package, 
so I'd only send e-mail after the package has been uploaded and 
ACCEPTed.


--
Jakub Wilk

Bug#809727: RFS: hwb/1:040412-7

[Robert James Clay]

On Thursday, January 07, 2016 05:32:49 PM Mattia Rizzolo wrote:
> On Thu, Jan 07, 2016 at 03:45:17PM -0500, Robert James Clay wrote:
 
> To upload a non-free package, and get it built by the autobuilders you
> need 'XS-Autobuild: yes' and according to DevRef § 5.10.5 also to mail
> somebody (dunno for what).

  Something to do with explaining if it "is legally allowed and technically  
possible to auto-build the package", although it's not clear to me if that 
email (and a presumed response to it) should happen before the package is 
uploaded.  I'll look at setting this up for my next version of the package.


> https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#non-free-buildd

  Yes, that also is what I've been referencing...

> 
> well "default git url" is not really a thing.

   Well, for access using git there might be but I (finally) see that is not  
what you were referring to...  I'll see about getting that corrected also with 
my next upload of package.




RJ Clay

Re: O: wicd -- wired and wireless network manager

[toogley]

Hey,

- my github repo contains all branches the debian git repo has.

- when i build from the stable branch, files cointaining the name 
"squeeze" are created - so i guess, it's a squeeze build.
But https://packages.debian.org/search?keywords=wicd shows different 
versions of wicd also for debian wheezy and debian jessie.


==> When the most current version of the stable brench produces the 
squeeze build, where can i find the build for wheezy and jessie - or are 
those two really not existent?

And why is the "stable" branch not named "oldoldstable" or sth similar?

- What are the "master", the "debconf-defaults" and the "nmu" branch 
used for?


- 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=wicd;include=tags%3Apatch

says, for #759884 is a patch available - but where can i find that one?
just to be sure: am i correct that i can't just add the tr.po file 
directly to git?


- The former git commits are just containing a few files in the debian 
dir. but when i build the version by myself, i get a whole lot of 
changes: http://paste.debian.net/hidden/100ce554/
 ==> you surely had build the package when committing new patches or 
changes - but obviously you diddn't added them (at least not that bunch 
of files in the pastie).

Why? Or did i sth wrong?


@wookey: I'll use "gbp import-orig"; it seams to be a more seamless 
integration.


Thanks :)

On 01/07/2016 08:17 PM, Axel Beckert wrote:

Hi,

toogley wrote:

Additionally I've set up the github repo
https://github.com/toogley/pkg-wicd - but i didn't make any changes
yet.


You should also push at least the "upstream" and preferably also the
"pristine-tar" branch to your repo. At least these are the three
branches which the git-buildpackage toolchain (see below) uses a lot.


Question: Jessie has currently this package
https://packages.debian.org/jessie/git-remote-bzr which would allow
us (since upstream uses bazaar) to fetch new upstream changes more
easily. But i don't know if its appropriate for debian packaging,
since it's an additional dependency for the process of maintaining
itself.


There's no real widely adopted workflow for incorporating upstream git
(or other repos) into the packaging repositories.

On the other hand, there's a very established workflow for importing
upstream tar balls ("gbp import-orig" from the git-buildpackage
package). This is also the one which has been used for the wicd
repository you cloned.

So unless you want to track upstream VCS snapshots, "gbp import-orig"
should suffice for nearly all cases.

Regards, Axel

Bug#796030: RFS: tablesnap/0.7.2-1 [ITP] -- Backup utility for the Cassandra database

[Gianfranco Costamagna]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Jeremy
> I am looking for a sponsor for my package "tablesnap"
> 
the package has been removed from mentors, are you still interested?

cheers,

G.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCAAGBQJWkOCMAAoJEPNPCXROn13ZJt0QAKnMOk7Pak0QzjiXQ3op4Ekd
LYPjvHKhE1qcwEkojjTGXvoLT9OJ24k0Pf7iC9qq55u6v8ATj5e4C1CeIMWcuVup
CHonfulbml/0QH790ykc0iYnnWJWDKIQLcnI06EANzLjofNZqr5eWat5au+HGGJf
0AGneBg+woD/JWRdKjf9DUyw4gSnRODnIx9/iRSTQtp+J3Td5GOCoXIl/INnULuO
CQYj4xsQOcfxhYWElAJbZcZJgAyoRFEgnBNkBc1/3bal9bVsFGZ3YcT6qlpyjJrG
WJL/2jgn8CgGO8woOx/EuQXDvPOoznP6warW0sxu+S6ZuzRBnJnGZUVGFFFAprNx
ejkxBf9jStBGgncbCqSgOPCpogLNTnAq/hs2nRwunwYHIkGzmkABzW9hjhaf7QcL
hd9gh6W9KYji7TCbwRL82gYGyLIhn4KR47+pDWP8622VFtQu9FflDg+6tkprqF42
1Kk/xGkV7wI0s/rUlIzVXm3ss3jiPWmszpK2CuzRqDTCvAq9NrwT2zPY+K90Kej5
zdBL8qc7cZOZzZtfDdjIKdh0POZQJnmFUey4BwZ7xtBzwtKabcMxEB0PWCYeIb4q
E81ssd7KrGfSW9biXeEslPiX8gGEzxB5qx3RQ3S/URdh9+gIxc0d/Cp19y0Z2yt0
FZ4zHZ4p3yEMJjuTc+PV
=1J0X
-END PGP SIGNATURE-

Bug#810361: marked as done (RFS: mpfrc++/3.6.3+ds-1 [new version] -- multi-precision floating point number class for C++)

[Debian Bug Tracking System]

Your message dated Sat, 9 Jan 2016 14:38:05 +
with message-id <20160109143805.ga31...@chase.mapreri.org>
and subject line Re: Bug#810361: RFS: mpfrc++/3.6.3+ds-1 [new version] -- 
multi-precision floating point number class for C++
has caused the Debian Bug report #810361,
regarding RFS: mpfrc++/3.6.3+ds-1 [new version] -- multi-precision floating 
point number class for C++
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
810361: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810361
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal

Dear Mentors:

I am looking for a sponsor for the package mpfrc++ [1] that
I am maintaining on behalf of the Debian Science-Team.
This package is an update with some refreshments.

Thanks,
Jerome

[1] https://anonscm.debian.org/cgit/debian-science/packages/mpfrc++.git

-- System Information:
Debian Release: Jessie*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.7-ckt11-amd64-mbp62 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
--- End Message ---
--- Begin Message ---
On Fri, Jan 08, 2016 at 03:22:11PM +0100, Jerome Benoit wrote:
>   I am looking for a sponsor for the package mpfrc++ [1] that
>   I am maintaining on behalf of the Debian Science-Team.
>   This package is an update with some refreshments.
> 
> Thanks,
> Jerome
> 
> [1] https://anonscm.debian.org/cgit/debian-science/packages/mpfrc++.git


uploaded :)

just a thing (for the next upload): can you use https in Vcs-Browser?


Thanks for your contribution to Debian!
-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---

Re: Bug#801253: O: wicd -- wired and wireless network manager

[Axel Beckert]

Hi,

short note to all those people in the Cc: On the next iteration, I'll
drop all Cc except debian-mentors@lists.debian.org and the bug-report
itself. Feel free to object, to subscribe to the bug report or to
debian-mentors. :-)

toogley wrote:
> - my github repo contains all branches the debian git repo has.

Great, looks much better now.

> - when i build from the stable branch, files cointaining the name
> "squeeze" are created

Ah, you need to use the master branch.

The stable branch was probably named a little bit short-sighted and
should have been named "squeeze" instead. It contains updates to the
wicd package in squeeze, i.e. back then they were "stable updates"
which had backported fixes for severe bugs which were only found after
a Debian Stable release.

> ==> When the most current version of the stable brench produces the
> squeeze build, where can i find the build for wheezy and jessie - or
> are those two really not existent?

In the master branch. There are no wheezy or jessie branches because
there was no need for stable-updates during the Wheezy or Jessie
release cycle yet.

> And why is the "stable" branch not named "oldoldstable" or sth similar?

"stable" is a suite name which always points to the _current_ stable
release, i.e. moves on every time Debian does a stable release. That's
why I think it would have been better to name that branch "squeeze".
The code names for releases don't move on. But back then, "stable" and
"squeeze" were the same. Nowadays, they are no more.

> - What are the "master", the "debconf-defaults" and the "nmu" branch
> used for?

The master branch is where the main development pof the package
happens. (That name is the default branch name, git uses if you don't
explicitly request a different branch name.)

I don't know about the debconf-defaults branch, but looking at it, it
seems an ancient feature branch (from 2009) which has been merged back
in the master branch, i.e. all changes from there are already
included.

The nmu branch is from me, because NMUs (non-maintainer uploads)
usually reside for a week or so in the DELAYED upload queue to allow
the maintainer to object. Since I didn't want to push these changes
into the master branch while the uploaded packages waits in the
DELAYED queue, because the package could have been rejected, I needed
a different branch to push to until the package has been accepted.
That was the NMU branch. I merged it into master after the NMU had
been accepted.

You migt

> - 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=wicd;include=tags%3Apatch
> says, for #759884 is a patch available - but where can i find that one?

Indeed, there's just a file, not a patch. Still the tag "patch" is
valid since the data to apply is available.

> just to be sure: am i correct that i can't just add the tr.po file
> directly to git?

In this case yes. Because it goes under debian/po/tr.po and not to
po/tr.po.

The subject says "debconf template translation" which means it's a
translation for the questions debconf may ask upon installation or
upgrade of the package. It's not a translation of the software.

(If it would have been a translation update for the software itself,
it would be probably the easiest to forward it to upstream, so that
they include it in their next release -- at least if you have a
responsive upstream. Otherweise you might want to add it as a quilt
patch under debian/patches/.)

> - The former git commits are just containing a few files in the
> debian dir. but when i build the version by myself, i get a whole
> lot of changes: http://paste.debian.net/hidden/100ce554/

Yeah, those files are artifacts of the build process and are cleaned
up again afterwards if you invoke debian/rules' clean target, e.g.
with "make -f debian/rules clean" (or "debuild clean" or "debclean"
depending on your preference -- the latter two need "devscripts"
installed).

Especially the new debian// directories contain what has
been put into the accordinly named .deb files. They're put together in
these directories before being compressed into the .deb format.

The debian/*debhelper* are helper files from the dh*
commands from debian/rules. They're cleaned up again when
debian/rules' clean target calls the "dh_clean" command.

New files not under debian/ are built by wicd's build system and are
cleaned up again when wicd's build system's clean target is called by
debian/rules' clean target.

I hope this helps.

>  ==> you surely had build the package when committing new patches or
> changes - but obviously you diddn't added them (at least not that
> bunch of files in the pastie).
> Why?

I'm sorry, I don't understand that paragraph.

> Or did i sth wrong?

Except having looked at the wrong branch: No. :-)

P.S. to Toogley: I might do a short-term QA upload of 1.7.3 to Debian
Unstable with what is currently in the master branch if the TODO in
debian/changelog has solved itself via dependency fixes as Gianfranco
suggested in 

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

[Jose M Calhariz]

One more iteraction.

On 07/01/16 14:31, Mattia Rizzolo wrote:
> On Sun, Jan 03, 2016 at 08:23:34PM +, Jose M Calhariz wrote:
>> On 03/01/16 13:21, Mattia Rizzolo wrote:
>>> 43: override_dh_auto_install:
>>> 44: dh_auto_install
>>> 45: dh_install
>>>
>>> instead please override only dh_install, no need to override
>>> dh_auto_install.
>> Not certain I have done the right thing here.  But I tested and did not
>> change a thing.
> yeah, it doesn't change the outcome, but it's 1) one line less in
> d/rules and 2) more correct.
>
> multiarchifying a lib can be hard.  But I don't think this is going to
> be that hard.  If I were you I'd just try to use dh_auto_configure
> instead of plain ./configure call, and bump the debhelper compat.
> See https://wiki.debian.org/Multiarch/Implementation for some hints,
> note that that page has some outdated bits (but we all hate keeping docs
> up to date :( )
 Did I get it right?
>>> looks good to me.  though I see there are files like
>>> ./usr/lib/x86_64-linux-gnu/rep/rules.mk
>>> that might be used by other packages.
>>> but if that one is a makefile, why is it under /usr/lib ?
>>>
>>> I need to try a piuparts run, and see if everything is right.
>>> Since there are only two r-deps once this package is more ready I'll try
>>> to build them against this, to see if this multi-lib change affects
>>> them.
>> And I intended to adopt that two r-deps.  What should make it easier.
> Indeed, I'll probably double check this particular bit another day.
>
> Given that now librep16 is multiarch-able, you should add a
> 'Multi-Arch: same' field in d/control for it.

Done.

>>> * librep-dev.links => no, please.  linking /usr/share/doc/
>>>   directory ain't nice at all, why is that in first place?
 The file  librep-dev.links is gone, but the links are still present. I
 don't know why :-(
>>> those links are caused by the --link-doc option of dh_installdocs.
>>> well, I'm not a fan of --link-doc, I really see too little point in it,
>>> int this case you just save some kB, just gaining troubles.
>>> But give that the current state of librep is a mixed (every binary have
>>> linked docs to librep9, except rep-doc), I'll leave the choice to you.
>>> Your choises are:
>>> * remove --link-doc for rep-doc, then you can just go on
>>> * remove --link-doc altogether, then you need a bunch of .maintscript
>>>   files (see dh_installdeb(1) and dpkg-maintscript-helper(1)
>> I will do this.  But need time to reread the docs.  Moved to TODO file.
> I tried to do this, you can find attached a patch that seems to do this
> transition correctly.

Done.

>
>>>   + I see there already are preinst snippet to remove the directory.  my
>>> reaction to this is: wtf?  it does so quite unconditionally and -.-'
 I changed the maintscripts to something I think is more sane.
>>> I'm not sure what would be the idea behind librep16.preinst ? why do you
>>> remove the symlink of librep9 ?
>>> I haven't tried, but I think that directory goes away when deinstalling
>>> librep9?
> yes it does.  So, can you explain why you did that?

Removed the librep16.preinst

>
>
> Something more:
>
> * d/copyright:
>   + there are 3 spurious line on top, not adhering to DEP-5, also they
> are redundant.  Please move Mikolaj email address to the debian/*
> stanza and remove the lines

Done

>   
> + umh, is the Upstream-Name really 'sawfish'?  Isn't it 'rep'?

Done.

> * d/control:
>   + vcs-field-not-canonical — please fix it

Done

> * is there a way to fix debian-rules-ignores-make-clean-error ?
>
>


I found the problem, Done.





signature.asc
Description: OpenPGP digital signature

Bug#810529: RFS: moc/1:2.6.0~svn-r2788-1

[Elimar Riesebieter]

* Mattia Rizzolo  [2016-01-09 15:53 +]:

[...]
> ok, some stuff I'd like to see changeed/explained before uploading:
> 
> * debian/rules:
>   + dh_strip --no-ddebs => WHY ?!  so much work has been done to get
> automatically built debug packages, why you wouldn't want them?

I don't want to bother pool space with 0.5M per each arch. I am not
aware of an useful case where debugging symbols where needed running
moc the last ten years or so.

>   + DPKG_EXPORT_BUILDFLAGS and the include are not needed in dh compat 9

Removed.

>   + dh_shlibdeps -- --warnings=0 => is there a particular reason to use
> --warnings=0 ?  e.g. is it so uselessly noisy otherwise?

Indeed, it is uselessly noisy otherwise.

> * debian/changelog:
>   + can you move the closes: to the line that tells about the ftbfs with
> ffmpeg 2.9?  after all, that bug is about the ftbfs, not about
> having a newer upstream

Done.

> * debian/moc.menu:
>   + can you consider removing it?  after the last CTTE deliberation the
> menu system is considered deprecated.

Removed.

> * debian/copyright:
>   + we are in 2016 ;)

Of course yes :) Corrected.

> 
> furthermore, be aware that even if added that `DEB_BUILD_MAINT_OPTIONS =
> hardening=+all`, blhc still complains about 'LDFLAGS missing
> (-Wl,-z,now)' and 'CFLAGS missing (-fPIE)' (and even there is a 'LDFLAGS
> missing (-fPIE -pie -Wl,-z,now)'.  and indeed you have several
> hardening-no-fortify-functions (which you already have, anyway).

Well, running blhc without an option gives no output but with --all
option. Hmm, at this point my skills stuck. I even know that
lintian -iI --pedantic gives a warning and discussed that with
upstream but there was no effort, though.

Thanks for the review.
Elimar
-- 
 Numeric stability is probably not all that
  important when you're guessing;-)

Bug#810529: RFS: moc/1:2.6.0~svn-r2788-1

[Mattia Rizzolo]

On Sat, Jan 09, 2016 at 07:50:47PM +0100, Elimar Riesebieter wrote:
> * Mattia Rizzolo  [2016-01-09 15:53 +]:
> > * debian/rules:
> >   + dh_strip --no-ddebs => WHY ?!  so much work has been done to get
> > automatically built debug packages, why you wouldn't want them?
> 
> I don't want to bother pool space with 0.5M per each arch. I am not
> aware of an useful case where debugging symbols where needed running
> moc the last ten years or so.

that's really not a good reason to disable them.
ddebs are stored in a separed archive (which means a separated pool and
a separate Packages file), which is not mirrored at all (yet, but we
don't plan to add many, and for sure we're not pushing mirrors to host
them).  Also, they are not used by default by nothing, and for clients
to have them they need to add a line in /etc/apt/sources.list

See https://lists.debian.org/msgid-search/5675e791.6060...@thykier.net
and https://wiki.debian.org/AutomaticDebugPackages for more information
on ddebs.
-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

[Mattia Rizzolo]

On Sat, Jan 09, 2016 at 06:57:08PM +, Jose M Calhariz wrote:
> > I'm going to try rebuilding the rdeps in the later today or tomrrow, and
> > I'll report back the results.
> 
> Ok.

that clearly fails because the header moved from e.g. rep.h =>
rep/rep.h.
Well, guess thtat's expected, also the two rdeps come from the same
project so well, guess we're just going to upload this to experimental,
and prepare the 2 rdeps later (that you said you're going to adopt,
actually you own only 1 ITA, btw).

> I have trimed the changelog.  Is not yet very good, but I hope that is
> good enough.

that's quite up to you, except some bits.
the rewrite of d/copyright using copyright-format-1.0 should be
documented, the rest looks documented enough to me.

> And I will talk with upstream about this things.

cool.


ok, once you do this I'll upload, and we shall go one with one r-dep,
I'd say, wouldn't you? :)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#809784: marked as done (RFS: cligh/0.2-3 ITP)

[Debian Bug Tracking System]

Your message dated Sat, 9 Jan 2016 21:17:11 +
with message-id <20160109211711.gc8...@chase.mapreri.org>
and subject line Re: Bug#809784: RFS: cligh/0.2-3
has caused the Debian Bug report #809784,
regarding RFS: cligh/0.2-3 ITP
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
809784: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809784
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-request
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "cligh"

* Package name: cligh
  Version : 0.2-3
  Upstream Author : Christopher M. Brannon 
* Url : http://the-brannons.com/software/cligh.html
* Licenses: BSD-3-clause, GPL-3+
  Section : python

It builds those binary packages:

cligh -- Command-line interface to GitHub

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

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

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

http://mentors.debian.net/debian/pool/main/c/cligh/cligh_0.2-3.dsc

Alternatively, you can access package debian/ directory via git from URL:

git://github.com/kaction/deb-cligh

More information about cligh can be obtained from 
http://the-brannons.com/software/cligh.html

Changes since last upload:

  * Rename python-pygithub dependency. More info: #808467

Regards,
  Dmitry Bogatov
--- End Message ---
--- Begin Message ---
On Tue, Jan 05, 2016 at 12:34:40PM +, Mattia Rizzolo wrote:
> On Tue, Jan 05, 2016 at 01:33:44PM +0300, Dmitry Bogatov wrote:
> > * Mattia Rizzolo  [2016-01-04 21:17:24+]
> > > Bad me.
> > > 
> > > The package itself is not great (really), but I skipped an installation

gosh, I must have mistyped this.  I meant to say that the package *is*
great (now I'd becurious to see where the 'not' came out from...)

> > > check earlier that I instead performed only now right before
> > > uploading...

But now it builds and installs nicely, so I just uploaded it :)

Thanks for your contribution to Debian! :D

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature
--- End Message ---

Bug#810572: RFS: twinkle/1:1.9.0+dfsg-3 -- Voice over Internet Protocol (VoIP) SIP Phone

[Peter Colberg]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "twinkle":

git clone https://anonscm.debian.org/git/pkg-voip/twinkle.git
cd twinkle && pristine-tar checkout ../twinkle_1.9.0+dfsg.orig.tar.xz

For verification, these are the current branch heads:

git show-ref --heads
fac45afd05dc46e71967e1ae95cf8c23ba54c9cf refs/heads/master
f2434eb35d0af8c8210d116ad060a6e774fcecea refs/heads/pristine-tar
a07d98e27942d7650fcdb6a645c1220b32995ae4 refs/heads/upstream

It builds these binary packages:

  twinkle - Voice over Internet Protocol (VoIP) SIP Phone

More information about twinkle can be obtained from http://twinkle.dolezel.info.

Changes since the last upload:

twinkle (1:1.9.0+dfsg-3) unstable; urgency=medium

  * Explicitly disable ALSA support on non-Linux architectures.
  * Set Maintainer field to Debian VoIP Team.
  * Add myself to Uploaders field.
  * Update Vcs-Git and Vcs-Browser fields.
  * Fix conflicting definition of socklen_t on GNU Hurd.

 -- Peter Colberg   Wed, 06 Jan 2016 08:15:17 -0500

If you decide to sponsor twinkle, please perform a source-only upload
so that buildd logs are published for amd64, too.

Regards,
Peter


signature.asc
Description: PGP signature

Bug#810529: RFS: moc/1:2.6.0~svn-r2788-1

[Mattia Rizzolo]

control: owner -1 !
control: tag -1 moreinfo

On Sat, Jan 09, 2016 at 04:07:20PM +0100, Elimar Riesebieter wrote:
> I am looking for a sponsor for my package "moc" as my main sponsor and 
> uploader
> isn't available at the moment.

yeah, sure :)

> Alternatively, one can download the package with dget using this command:
> dget -x 
> http://mentors.debian.net/debian/pool/main/m/moc/moc_2.6.0~svn-r2788-1.dsc

ok, some stuff I'd like to see changeed/explained before uploading:

* debian/rules:
  + dh_strip --no-ddebs => WHY ?!  so much work has been done to get
automatically built debug packages, why you wouldn't want them?
  + DPKG_EXPORT_BUILDFLAGS and the include are not needed in dh compat 9
  + dh_shlibdeps -- --warnings=0 => is there a particular reason to use
--warnings=0 ?  e.g. is it so uselessly noisy otherwise?
* debian/changelog:
  + can you move the closes: to the line that tells about the ftbfs with
ffmpeg 2.9?  after all, that bug is about the ftbfs, not about
having a newer upstream
* debian/moc.menu:
  + can you consider removing it?  after the last CTTE deliberation the
menu system is considered deprecated.
* debian/copyright:
  + we are in 2016 ;)


furthermore, be aware that even if added that `DEB_BUILD_MAINT_OPTIONS =
hardening=+all`, blhc still complains about 'LDFLAGS missing
(-Wl,-z,now)' and 'CFLAGS missing (-fPIE)' (and even there is a 'LDFLAGS
missing (-fPIE -pie -Wl,-z,now)'.  and indeed you have several
hardening-no-fortify-functions (which you already have, anyway).

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  http://mapreri.org  : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

[Jose M Calhariz]

On 09/01/16 17:50, Mattia Rizzolo wrote:
> On Sat, Jan 09, 2016 at 05:06:16PM +, Jose M Calhariz wrote:
>> One more iteraction.
> oh, this is getting cooler and cooler :)
>
>> On 07/01/16 14:31, Mattia Rizzolo wrote:
>>> On Sun, Jan 03, 2016 at 08:23:34PM +, Jose M Calhariz wrote:
 On 03/01/16 13:21, Mattia Rizzolo wrote:
> looks good to me.  though I see there are files like
> ./usr/lib/x86_64-linux-gnu/rep/rules.mk
> that might be used by other packages.
> but if that one is a makefile, why is it under /usr/lib ?
>
> I need to try a piuparts run, and see if everything is right.
> Since there are only two r-deps once this package is more ready I'll try
> to build them against this, to see if this multi-lib change affects
> them.
 And I intended to adopt that two r-deps.  What should make it easier.
>>> Indeed, I'll probably double check this particular bit another day.
>>>
>>> Given that now librep16 is multiarch-able, you should add a
>>> 'Multi-Arch: same' field in d/control for it.
>> Done.
> I'm going to try rebuilding the rdeps in the later today or tomrrow, and
> I'll report back the results.

Ok.

>> I found the problem, Done.
> woo :D
>
> OK, if the r-deps check I'm going to do will succeed I think we're good
> to upload.  :)
>
> just two more points:
>
> I find d/chaneglog to be somewhat a lot verbose.  I think it's too much
> verbose and also contains nowadays outdated bits (e.g. "Replace sed by
> something more easy to read for variable version on debian/rules" is
> just useless, also considering that line now doesn't exist anymore at
> all!  that's just an example,  I can see more).  So if I were you I'd
> try to re-read the whole changelog and make it more easy and useful.

I have trimed the changelog.  Is not yet very good, but I hope that is
good enough.

And I will talk with upstream about this things.
> The following lines are from check-all-the-things.
> The first chunk shows there is a typo in debian/changelog, you might
> want to fix it.  Then I ask you to please forward all the rest
> (typos or such, and outdated GPL-2+ text) upstream.
>
> $ codespell --quiet-level=3
> ./Makedefs.in:105: dependancy  ==> dependency
> ./ChangeLog:723: usefull  ==> useful
> ./ChangeLog:870: usefull  ==> useful
> ./configure:4647: nto  ==> not  | disable due to \n
> ./configure:7545: nto  ==> not  | disable due to \n
> ./configure:7695: nto  ==> not  | disable due to \n
> ./configure:8963: nto  ==> not  | disable due to \n
> ./configure:9998: nto  ==> not  | disable due to \n
> ./config.sub:1403: nto  ==> not  | disable due to \n
> ./NEWS:108: occured  ==> occurred
> ./NEWS:376: usefull  ==> useful
> ./aclocal.m4:106: occurence  ==> occurrence
> ./debian/changelog:163: Miscelaneous  ==> Miscellaneous
> ./intl/localealias.c:93: loosing  ==> losing
> ./intl/dcgettext.c:174: loosing  ==> losing
> ./intl/dcgettext.c:246: defintion  ==> definition
> ./m4/libtool.m4:2727: nto  ==> not  | disable due to \n
> ./m4/libtool.m4:3317: nto  ==> not  | disable due to \n
> ./m4/libtool.m4:3961: nto  ==> not  | disable due to \n
> ./m4/libtool.m4:4117: nto  ==> not  | disable due to \n
> ./m4/libtool.m4:4283: nto  ==> not  | disable due to \n
> ./m4/libtool.m4:4434: nto  ==> not  | disable due to \n
> ./m4/libtool.m4:5382: nto  ==> not  | disable due to \n
> ./m4/libtool.m4:6581: nto  ==> not  | disable due to \n
> ./src/streams.c:618: upto  ==> up to
> ./src/unix_main.c:452: Dont  ==> Don't
> ./src/sdbm.c:81: seperate  ==> separate
> ./src/README.sdbm:294: puting  ==> putting
> ./man/repl.texi:3: enviroment  ==> environment
> ./man/repl.texi:6: enviroment  ==> environment
> ./man/lang.texi:790: upto  ==> up to
> ./man/lang.texi:1414: sence  ==> sense, since
> ./man/lang.texi:4828: contruction  ==> construction
> ./man/lang.texi:4964: refered  ==> referred
> ./man/lang.texi:5098: Ususally  ==> Usually
> ./man/lang.texi:7300: upto  ==> up to
> ./man/lang.texi:9367: seperated  ==> separated
> ./man/lang.texi:9368: seperated  ==> separated
> ./man/news.texi:83: positon  ==> position
> ./man/news.texi:109: occured  ==> occurred
> ./man/news.texi:379: usefull  ==> useful
> ./lisp/rep/vm/assembler.jl:27: inbetween  ==> between
>
>
> $ licensecheck --check=. --recursive --copyright . | grep -F 'with incorrect 
> FSF address'
> ./intl/loadmsgcat.c: GPL (v2 or later) (with incorrect FSF address)
> ./intl/l10nflist.c: GPL (v2 or later) (with incorrect FSF address)
> ./intl/explodename.c: GPL (v2 or later) (with incorrect FSF address)
> ./intl/textdomain.c: GPL (v2 or later) (with incorrect FSF address)
> ./intl/libgettext.h: GPL (v2 or later) (with incorrect FSF address)
> ./intl/localealias.c: GPL (v2 or later) (with incorrect FSF address)
> ./intl/gettext.h: GPL (v2 or later) (with incorrect FSF address)
> ./intl/gettextP.h: GPL (v2 or later) (with incorrect FSF address)
> ./intl/dgettext.c: GPL (v2 or later) (with incorrect FSF address)
> ./intl/cat-compat.c: GPL (v2 or 

Bug#810536: RFS: roxterm/3.3.2-1

[Tony Houghton]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the latest version of my package "roxterm"

 * Package name: roxterm
   Version : 3.3.2-1
   Upstream Author : Tony Houghton 
 * URL : http://roxterm.sourceforge.net
 * License : GPL2+
   Section : x11

It builds these binary packages:

 roxterm  - Multi-tabbed GTK+/VTE terminal emulator - binaries
 roxterm-data - Multi-tabbed GTK+/VTE terminal emulator - data files
 roxterm-dbg  - Debugging symbols for roxterm
 roxterm-gtk2 - Transitional package to upgrade roxterm-gtk2 to
roxterm
 roxterm-gtk2-dbg - Transitional package to upgrade roxterm-gtk2-dbg to
roxterm-dbg
 roxterm-gtk3 - Transitional package to upgrade roxterm-gtk3 to
roxterm
 roxterm-gtk3-dbg - Transitional package to upgrade roxterm-gtk3-dbg to
roxterm-dbg

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

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

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

dget -x
http://mentors.debian.net/debian/pool/main/r/roxterm/roxterm_3.3.2-1.dsc

More information about roxterm can be obtained from
http://roxterm.sourceforge.net

Changes since the last upload:

roxterm (3.3.2-1) unstable; urgency=medium

  * Removed debian/dirs to prevent creation of now empty 
/usr/share/pixmaps.

  * Build-Depends avoids buggy version of gettext (Closes: #809570).
  * debian/rules: Use --enable-nls instead of deprecated 
--enable-translations.

  * New upstream release:
+ Fixed ssh port number in config ui (upstream #120).
+ Fixed configure --disable-nls.
+ Update New Window/Tab With Profile submenus when profiles change
  (upstream #121).
+ Fade text and background colour labels along with buttons
  (Closes: #810016).
+ Documented shortcuts translation problem described by #809719.

 -- Tony Houghton   Sat, 09 Jan 2016 14:00:02 +

Bug #809570 is actually due to a gettext bug (which is now fixed), but I
decided to keep a separate ticket open for roxterm because I changed its
Build-Depends to avoid the buggy version of gettext.

Re: Bug#801253: O: wicd -- wired and wireless network manager

[toogley]

I don't mind - the rest of your email, i'll answer in the next  days.

again, thank you :)

On 01/09/2016 03:57 PM, Axel Beckert wrote:

P.S. to Toogley: I might do a short-term QA upload of 1.7.3 to Debian
Unstable with what is currently in the master branch if the TODO in
debian/changelog has solved itself via dependency fixes as Gianfranco
suggested in one of the previous mails. I hope you don't mind.

Re: Bug#809727: RFS: hwb/1:040412-7

[Robert James Clay]

On Saturday, January 09, 2016 09:44:59 AM Jakub Wilk wrote:
> The person doing whitelisting will probably want to look at the package, 
> so I'd only send e-mail after the package has been uploaded and 
> ACCEPTed.

   That makes sense;  thanks for the clarification!




RJ Clay

Bug#810543: RFS: python-bond/1.4-1 [ITP]

[Yuri D'Elia]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-bond"

* Package name: python-bond
  Version : 1.4-1
  Upstream Author : Yuri D'Elia 
* URL : http://www.thregr.org/~wavexx/software/python-bond/
* License : GPL-2+
  Section : python

It builds those binary packages:

python-bond - transparent remote/recursive evaluation between Python and other 
languages
python3-bond - transparent remote/recursive evaluation between Python and other 
languages

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

 http://mentors.debian.net/package/python-bond

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

 dget -x 
http://mentors.debian.net/debian/pool/main/p/python-bond/python-bond_1.4-1.dsc

Changes since the last upload:

 This is my first package and upload to python-modules.

Bug#810529: RFS: moc/1:2.6.0~svn-r2788-1

[Elimar Riesebieter]

* Mattia Rizzolo  [2016-01-09 15:53 +]:

[...]
> ok, some stuff I'd like to see changeed/explained before uploading:
> 
> * debian/rules:
>   + dh_strip --no-ddebs => WHY ?!  so much work has been done to get
> automatically built debug packages, why you wouldn't want them?

I don't want to bother pool space with 0.5M per each arch. I am not
aware of an useful case where debugging symbols where needed running
moc the last ten years or so.

>   + DPKG_EXPORT_BUILDFLAGS and the include are not needed in dh compat 9

Removed.

>   + dh_shlibdeps -- --warnings=0 => is there a particular reason to use
> --warnings=0 ?  e.g. is it so uselessly noisy otherwise?

Indeed, it is uselessly noisy otherwise.

> * debian/changelog:
>   + can you move the closes: to the line that tells about the ftbfs with
> ffmpeg 2.9?  after all, that bug is about the ftbfs, not about
> having a newer upstream

Done.

> * debian/moc.menu:
>   + can you consider removing it?  after the last CTTE deliberation the
> menu system is considered deprecated.

Removed.

> * debian/copyright:
>   + we are in 2016 ;)

Of course yes :) Corrected.

> 
> furthermore, be aware that even if added that `DEB_BUILD_MAINT_OPTIONS =
> hardening=+all`, blhc still complains about 'LDFLAGS missing
> (-Wl,-z,now)' and 'CFLAGS missing (-fPIE)' (and even there is a 'LDFLAGS
> missing (-fPIE -pie -Wl,-z,now)'.  and indeed you have several
> hardening-no-fortify-functions (which you already have, anyway).

Well, running blhc without an option gives no output but with --all
option. Hmm, at this point my skills stuck. I even know that
lintian -iI --pedantic gives a warning and discussed that with
upstream but there was no effort, though.

Thanks for the review.
Elimar
-- 
 Numeric stability is probably not all that
  important when you're guessing;-)

Bug#809451: sponsorship-requests: librep/0.92.5-1 [ITA]

[Mattia Rizzolo]

On Sat, Jan 09, 2016 at 05:06:16PM +, Jose M Calhariz wrote:
> One more iteraction.

oh, this is getting cooler and cooler :)

> On 07/01/16 14:31, Mattia Rizzolo wrote:
> > On Sun, Jan 03, 2016 at 08:23:34PM +, Jose M Calhariz wrote:
> >> On 03/01/16 13:21, Mattia Rizzolo wrote:
> >>> looks good to me.  though I see there are files like
> >>> ./usr/lib/x86_64-linux-gnu/rep/rules.mk
> >>> that might be used by other packages.
> >>> but if that one is a makefile, why is it under /usr/lib ?
> >>>
> >>> I need to try a piuparts run, and see if everything is right.
> >>> Since there are only two r-deps once this package is more ready I'll try
> >>> to build them against this, to see if this multi-lib change affects
> >>> them.
> >> And I intended to adopt that two r-deps.  What should make it easier.
> > Indeed, I'll probably double check this particular bit another day.
> >
> > Given that now librep16 is multiarch-able, you should add a
> > 'Multi-Arch: same' field in d/control for it.
> 
> Done.

I'm going to try rebuilding the rdeps in the later today or tomrrow, and
I'll report back the results.

> I found the problem, Done.

woo :D

OK, if the r-deps check I'm going to do will succeed I think we're good
to upload.  :)

just two more points:

I find d/chaneglog to be somewhat a lot verbose.  I think it's too much
verbose and also contains nowadays outdated bits (e.g. "Replace sed by
something more easy to read for variable version on debian/rules" is
just useless, also considering that line now doesn't exist anymore at
all!  that's just an example,  I can see more).  So if I were you I'd
try to re-read the whole changelog and make it more easy and useful.

The following lines are from check-all-the-things.
The first chunk shows there is a typo in debian/changelog, you might
want to fix it.  Then I ask you to please forward all the rest
(typos or such, and outdated GPL-2+ text) upstream.

$ codespell --quiet-level=3
./Makedefs.in:105: dependancy  ==> dependency
./ChangeLog:723: usefull  ==> useful
./ChangeLog:870: usefull  ==> useful
./configure:4647: nto  ==> not  | disable due to \n
./configure:7545: nto  ==> not  | disable due to \n
./configure:7695: nto  ==> not  | disable due to \n
./configure:8963: nto  ==> not  | disable due to \n
./configure:9998: nto  ==> not  | disable due to \n
./config.sub:1403: nto  ==> not  | disable due to \n
./NEWS:108: occured  ==> occurred
./NEWS:376: usefull  ==> useful
./aclocal.m4:106: occurence  ==> occurrence
./debian/changelog:163: Miscelaneous  ==> Miscellaneous
./intl/localealias.c:93: loosing  ==> losing
./intl/dcgettext.c:174: loosing  ==> losing
./intl/dcgettext.c:246: defintion  ==> definition
./m4/libtool.m4:2727: nto  ==> not  | disable due to \n
./m4/libtool.m4:3317: nto  ==> not  | disable due to \n
./m4/libtool.m4:3961: nto  ==> not  | disable due to \n
./m4/libtool.m4:4117: nto  ==> not  | disable due to \n
./m4/libtool.m4:4283: nto  ==> not  | disable due to \n
./m4/libtool.m4:4434: nto  ==> not  | disable due to \n
./m4/libtool.m4:5382: nto  ==> not  | disable due to \n
./m4/libtool.m4:6581: nto  ==> not  | disable due to \n
./src/streams.c:618: upto  ==> up to
./src/unix_main.c:452: Dont  ==> Don't
./src/sdbm.c:81: seperate  ==> separate
./src/README.sdbm:294: puting  ==> putting
./man/repl.texi:3: enviroment  ==> environment
./man/repl.texi:6: enviroment  ==> environment
./man/lang.texi:790: upto  ==> up to
./man/lang.texi:1414: sence  ==> sense, since
./man/lang.texi:4828: contruction  ==> construction
./man/lang.texi:4964: refered  ==> referred
./man/lang.texi:5098: Ususally  ==> Usually
./man/lang.texi:7300: upto  ==> up to
./man/lang.texi:9367: seperated  ==> separated
./man/lang.texi:9368: seperated  ==> separated
./man/news.texi:83: positon  ==> position
./man/news.texi:109: occured  ==> occurred
./man/news.texi:379: usefull  ==> useful
./lisp/rep/vm/assembler.jl:27: inbetween  ==> between


$ licensecheck --check=. --recursive --copyright . | grep -F 'with incorrect 
FSF address'
./intl/loadmsgcat.c: GPL (v2 or later) (with incorrect FSF address)
./intl/l10nflist.c: GPL (v2 or later) (with incorrect FSF address)
./intl/explodename.c: GPL (v2 or later) (with incorrect FSF address)
./intl/textdomain.c: GPL (v2 or later) (with incorrect FSF address)
./intl/libgettext.h: GPL (v2 or later) (with incorrect FSF address)
./intl/localealias.c: GPL (v2 or later) (with incorrect FSF address)
./intl/gettext.h: GPL (v2 or later) (with incorrect FSF address)
./intl/gettextP.h: GPL (v2 or later) (with incorrect FSF address)
./intl/dgettext.c: GPL (v2 or later) (with incorrect FSF address)
./intl/cat-compat.c: GPL (v2 or later) (with incorrect FSF address)
./intl/po2tbl.sed.in: GPL (v2 or later) (with incorrect FSF address) GENERATED 
FILE
./intl/xopen-msg.sed: GPL (v2 or later) (with incorrect FSF address)
./intl/loadinfo.h: GPL (v2 or later) (with incorrect FSF address)
./intl/linux-msg.sed: GPL (v2 or later) (with incorrect FSF address)

Re: Re: Re: mentor wanted

[Stephan Foley]

Hi Paul and thanks for the reply.

Paul Wise wrote:

All these are topics for the debian-blends list.


Well, I did post to debian-blends and they told me to RTFM,
which I thought was pretty funny.

But, going back to my original post, I am just following
the Debian Developers' Reference manual which states:

The mailing list  has
been set up for novice maintainers who seek help with
initial packaging and other developer-related issues.
Every new developer is invited to subscribe to that
list (see Section 4.1, “Mailing lists” for details).

Those who prefer one-on-one help (e.g., via private
email) should also post to that list and an
experienced developer will volunteer to help.

So, basically, I am looking for "an experienced developer"
who will "volunteer to help" "via private email" as I was
lead to expect would happen from the Debian documentation.

Re: Re: Re: mentor wanted

[Stephan Foley]

Hi Gianfranco,

Gianfranco Costamagna wrote:
> A whole set of issues, but mentors as said by Paul is regarding
> mostly packaging issues

Well, the whole idea behind blends is packaging. For example, to
have tasks posted to the website I need a control file in a Debian
folder. I need a rules file, I need metafiles, etc, etc.

I can understand you guys not wanting to get involved and that is
fine by me. I can always read the documentation. I was just going
by the manual which lead me to expect more general help in this
mailing list.

Re: Re: Re: mentor wanted

[Paul Wise]

On Sun, Jan 10, 2016 at 10:53 AM, Stephan Foley wrote:

> Well, I did post to debian-blends and they told me to RTFM,
> which I thought was pretty funny.

I guess you are referring to this mail where Andreas pointed you at
the documentation that answers some of your questions.

https://lists.debian.org/20160108232507.gb13...@an3as.eu

I don't see any jokes or humor in that mail.

> But, going back to my original post, I am just following
> the Debian Developers' Reference manual which states:
...
> Those who prefer one-on-one help (e.g., via private
> email) should also post to that list and an
> experienced developer will volunteer to help.
>
> So, basically, I am looking for "an experienced developer"
> who will "volunteer to help" "via private email" as I was
> lead to expect would happen from the Debian documentation.

Interesting, I didn't know that paragraph existed.

Pretty much all Debian mentoring is done in public not in private.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Re: Re: Re: mentor wanted

[Stephan Foley]

Thanks for the reply, Paul.

Paul Wise wrote:
> Pretty much all Debian mentoring is done in public not in private.

OK, this is cool with me. I will return with any packaging questions.

Thanks for your time,

Steve

Re: Re: Re: mentor wanted

[Wookey]

+++ Stephan Foley [2016-01-09 22:02 -0500]:
> Hi Gianfranco,
> 
> Gianfranco Costamagna wrote:
> > A whole set of issues, but mentors as said by Paul is regarding
> > mostly packaging issues
> 
> Well, the whole idea behind blends is packaging. For example, to
> have tasks posted to the website I need a control file in a Debian
> folder. I need a rules file, I need metafiles, etc, etc.
> 
> I can understand you guys not wanting to get involved and that is
> fine by me. I can always read the documentation. I was just going
> by the manual which lead me to expect more general help in this
> mailing list.

It's not so much a matter of not wanting to get involved - it's just
that few of us know anything about the details of blends. We know
about packaging. So we can't actually help much.

I am aware that blends are mostly implemented by way of special
packages but not what goes in them...

So do please ask here again if you have packaging problems, or you
don't get any help on the blends list, but honestly, asking there
(+self-help of course) is the best advice from what you've explained
so far.

And unless you _need_ to ask something in private for some reason,
it's much better to ask in public. That way the question is already
answered for the next person who comes along and searches. It's
doesn't matter if the questions feel dumb - we all had to start
somewhere. The instruction you found about mentoring 'via private
email' possibly meant to refer to the contact being by private mail,
not to the asking and answering of queries, although I agree it could
be read either way.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature