Re: RFS: burp -- A cross platform network backup and restore program.

[Bartosz Feński]

W dniu 10.02.2012 19:47, Bas van den Dikkenberg pisze:

hi fEnIo,


I did complete rebuild of the packages and fixed all of the isues,

Can you please re evaluate the package and when it is oke sponsor it bye
uploading it for me?

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

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

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

   dget -x http://mentors.debian.net/debian/pool/main/b/burp/burp_1.3.0-1.dsc

With kind regards,

Bas van den Dikkenberg


Reviewed and uploaded. Thanks for fixing all problems!

regards
fEnIo


--
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/4f360d62.8000...@fenski.pl

Re: DEP-5 versioned URI / Lintian complains

[Charles Plessy]

Le Sat, Feb 11, 2012 at 05:42:29AM +, Samuel Bronson a écrit :
> Russ Allbery  debian.org> writes:
> 
> > Daniel Stender  danielstender.com> writes:
> > 
> > > For the very next of my commits,
> > 
> > > 1) what URI should I give to the very next commits, and should I just
> > > just disregard the Lintian complain
> > 
> > For right now, I would ignore the complaint and use an unversioned URL,
> > since so far as I can tell there is no versioned URL currently available
> > that takes you straight to the current text of the document.  However, I
> > may have missed something.
> 
> Actually, there is 
>  format.xml?revision=269&view=markup>. Not exactly the most readable, but it 
> does 
> work.

Hello Samuel,

I do not recommend to use this URL.  The current draft will not have normative
changes anymore, so you can use:

  http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

The DEP is in a final review stage.  Unless additional delays, I will probably
mark it accepted next week, and the above URL will become valid immediately
after the next Policy upload.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
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/20120211064552.gh19...@falafel.plessy.net

upstream changelog in LaTeX format

[Jerome BENOIT]

Hello List:

The upstream changelog of my package is in LaTeX format:
as the LaTeX is rough enough to be translated to HTML format by TtH,
I will put the HTML translation within the package.
Given that, what I am supposed to do with the LaTeX changelog source ?
May I put it within the package as well ? What about its PDF version ?

Thanks in advance,
Jerome


--
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/4f360d10.1030...@rezozer.net

Re: DEP-5 versioned URI / Lintian complains

[Samuel Bronson]

Russ Allbery  debian.org> writes:

> Daniel Stender  danielstender.com> writes:
> 
> > For the very next of my commits,
> 
> > 1) what URI should I give to the very next commits, and should I just
> > just disregard the Lintian complain
> 
> For right now, I would ignore the complaint and use an unversioned URL,
> since so far as I can tell there is no versioned URL currently available
> that takes you straight to the current text of the document.  However, I
> may have missed something.

Actually, there is 
. Not exactly the most readable, but it 
does 
work.

Unfortunately, Lintian doesn't know that yet, and won't accept it.

(I've probably messed up the To: and CC: fields due to sending through gmane; 
sorry for that, but I wasn't on the list yet when this was posted.)


-- 
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/loom.20120211t063616-...@post.gmane.org

Re: How to convince maintainer to use --as-needed?

[Paul Wise]

Someone referenced an earlier thread about --as-needed, I suggest you read that.

In addition, Gentoo has some documentation about it:

http://www.gentoo.org/proj/en/qa/asneeded.xml

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6ezgs-age5hx5wp7g9bfcj+3f2fbqi3vtjteqjfxhy...@mail.gmail.com

Re: How to convince maintainer to use --as-needed?

[Dmitry Smirnov]

On Sat, 11 Feb 2012 11:38:23 Paul Wise wrote:
> The --as-needed flag is a workaround for buggy upstream build systems,
> IMO it should not be used unless the relevant build systems will not
> be fixed any time soon.

Seems like a typical case with GNOME project stuff.

Do you know if there are something what might contribute to potential problems 
with --as-needed, like outdated toolchain?

So far we're reluctant to use --as-needed where it may be beneficial because 
in theory it might break something. However what's the practical likehood of 
that?

Do we know any particular example of --as-needed incompatibility to look into 
and analyse?

Regards,
Dmitry.


-- 
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/201202111257.38792.only...@member.fsf.org

Re: How to convince maintainer to use --as-needed?

[Dmitry Smirnov]

On Fri, 10 Feb 2012 23:15:22 Bernhard R. Link wrote:

> I personally strongly recommend against using --as-needed unless you
> understand very well what it does. It may change the runtime behaviour of a
> program without any signs at link time.

Surely it's a powerful thing which should be used with care.
Many packages has no or little benefit so using --as-needed would not be 
justified.

But sometimes an innocent call to library causing package to inherit the whole 
hierarchy of needless dependencies. 
And this affect not just obvious things like slower start-up and installation 
but also troubles with migration to testing and complications with library 
transitions. The latter sucks our precious manpower not just from package 
maintainer.

Package maintainers can surely track problems to --as-needed if that's the 
case and here we have hope because many packages using it already for years 
successfully.


> Unless you are entangled in libraries ignoring usual best practises and
> ignoring library borders in their headers (libglib, libboost), there
> might be better solutions than --as-needed.

I'd like to learn more about --as-needed alternatives. 
Could you suggest any resources/guidelines, please?

> 
> That is not to say there might not be cases where --as-needed is the
> best solution, but it is definitely not something one should apply
> blindly.
 
Indeed. 
But this seems to be more like risk management and less like informed 
technical decision. (I wonder what makes Ubuntu taking the risk applying --as-
needed to everything?)
Surely there must be software incompatible with --as-needed. But what are the 
chances to experience it? How to identify situation when --as-needed is likely 
to cause troubles?

Regards,
Dmitry.


-- 
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/201202111249.36777.only...@member.fsf.org

Re: How to convince maintainer to use --as-needed?

[Russ Allbery]

Paul Wise  writes:

> The --as-needed flag is a workaround for buggy upstream build systems,
> IMO it should not be used unless the relevant build systems will not be
> fixed any time soon.

Which in most cases they won't be.  Hell, I'm an upstream maintainer for
one case where *I'm* not going to fix it, because it's just too annoying
to try to get Libtool to not link a binary with the dependencies of its
shared library when they're both built from the same source tree.

On this one, I side with many upstreams: "fixing" this is more likely to
make the build system buggy on other operating systems and is not actually
a good idea unless all of the libraries the package uses support a
facility like pkgconfig (which is something that upstream is often not in
control of).

-- 
Russ Allbery (r...@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/87r4y2rvxw@windlord.stanford.edu

Re: How to convince maintainer to use --as-needed?

[Paul Wise]

The --as-needed flag is a workaround for buggy upstream build systems,
IMO it should not be used unless the relevant build systems will not
be fixed any time soon.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/caktje6ex7yotwh+kv1xyeme8_kgq_ejn70kz5ejzohkfyam...@mail.gmail.com

Bug#658065: RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge wire protocol library

[Ansgar Burchardt]

tag 658065 + confirmed
thanks

Hi,

"Stephen M. Webb"  writes:
>> I am looking for a sponsor for my package "atlas-cpp":
>> 
>>   dget -x
>> http://mentors.debian.net/debian/pool/main/a/atlas-cpp/atlas-cpp_0.6.2-1.dsc

 * There are files licensed under the GFDL in tutorial/example.

debian/changelog:

 * typo: rpsth -> rpath

 * What does "updated the -doc package files" mean?

 * Why "more" in "added more zlib and libbz build dependencies"?

Minor upstream nitpicks:

 * I find it helpful if license statements include the version of the
license explicitly (as the example ones in the GPL do), same for
explicitly stating that there are no invariant sections etc.

 * README claims this was atlas-c++ 0.7.x which does not seem to be true.

Regards,
Ansgar



-- 
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/87fwei5o4i@deep-thought.43-1.org

Processed: Re: Bug#658065: RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge wire protocol library

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tag 658065 + confirmed
Bug #658065 [sponsorship-requests] RFS: atlas-cpp/0.6.2-1 [ITA] -- WorldForge 
wire protocol library
Added tag(s) confirmed.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
658065: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658065
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132891228918139.transcr...@bugs.debian.org

Bug#659416: RFS: u-boot/2011.12-2.1 [NMU with maintainer permission] -- boot loader for embedded systems

[Jonathan Nieder]

Package: sponsorship-requests

Hi,

I am looking to upload the package "u-boot".

 dget -u 
http://alioth.debian.org/~jrnieder-guest/temp/u-boot/u-boot_2011.12-2.1.dsc

It builds a bootloader (Das U-Boot), some companion tools, and some
transitional packages.  The purpose of this upload is to fix boot
failures on the kirkwood platform with compressed 3.2.y kernels:

 http://bugs.debian.org/658904

The only change relative to 2011.12-2 is to apply the relevant
upstream patch.

Clint Adams wrote:

> Feel free to commit and upload; it's in collab-maint.

so the change has been pushed to

 git://git.debian.org/git/collab-maint/u-boot.git

and I would be happy if someone gets a chance to look it over and
upload.

Cc-ing Ian Campbell, who did all the actual work of finding the
patch, and debian-arm@, since someone there might be interested to
pick this up or test it.

Looking forward to your thoughts,
Jonathan



-- 
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/20120210221713.GM19216@burratino

Processed: tagging 658835, bug 658204 has no owner, severity of 658772 is wishlist, tagging 659243

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> tags 658835 - confirmed fixed
Bug #658835 [sponsorship-requests] RFS: aspsms-t (try 4) [NEW] -- sms transport 
for your xmpp/jabber server
Removed tag(s) confirmed and fixed.
> noowner 658204
Bug #658204 [sponsorship-requests] RFS: bibtool [ITA] -- tool for BibTeX 
database manipulation
Removed annotation that Bug was owned by calcu...@rezozer.net.
> severity 658772 wishlist
Bug #658772 [sponsorship-requests] RFS: burp/1.3.0-4 -- backup and restore 
program [ITP]
Severity set to 'wishlist' from 'normal'

> tags 659243 - moreinfo
Bug #659243 [sponsorship-requests] RFS: sweethome3d and sunflow [DM uploads to 
bpo]
Removed tag(s) moreinfo.
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
659243: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659243
658204: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658204
658835: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658835
658772: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658772
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.13289009785729.transcr...@bugs.debian.org

RFS: burp -- A cross platform network backup and restore program.

[Bas van den Dikkenberg]

hi fEnIo,


I did complete rebuild of the packages and fixed all of the isues,

Can you please re evaluate the package and when it is oke sponsor it bye
uploading it for me?

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

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

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

  dget -x http://mentors.debian.net/debian/pool/main/b/burp/burp_1.3.0-1.dsc

With kind regards,

Bas van den Dikkenberg


-- 
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/4f35662b.8040...@dikkenberg.net

Re: How to convince maintainer to use --as-needed?

[Russ Allbery]

Dmitry Smirnov  writes:

> I seek your advice regarding the best practice with using --as-needed.

> Recently I tried to convince two package maintainers to use --as-needed
> in order to reduce overlinking. Surprisingly this time this idea was
> opposed with great resistance as none of maintainers but me had previous
> experience with -- as-needed.

> Because in their eyes I have neither expertise nor reputation I couldn't
> convince them that benefits are outweight risks. (--as-needed removes
> dozen of packages from Depends)

> I've been asked to provide a document or a quote from reputable DD
> regarding using --as-needed as recommended practice in Debian, if such.

I use --as-needed for all of my packages that do excessive shared library
linking, including some of my own when avoiding that inside the upstream
build system was excessively complex.  It works great.

I don't like having it be the default (as it is in Ubuntu), but as an
option for the packager, it is quite frequently exactly the right tool.
For several of those packages, I used to maintain complex and annoying
local patches and workarounds to relink binaries with the correct
dependencies, changes that upstream was completely uninterested in since
from their perspective there was no upside and it just made the build
system more fragile.  I was able to drop a ton of that cruft by switching
over to --as-needed.

For packages that use Automake and Libtool, dh-autoreconf makes using the
flag very easy.

-- 
Russ Allbery (r...@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/87pqdmeer8@windlord.stanford.edu

Processed: preload/0.6.4-2 [ITA] -- adaptive readahead daemon

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> retitle 658306 RFS: preload/0.6.4-2 [ITA] -- adaptive readahead daemon
Bug #658306 [sponsorship-requests] RFS: preload [ITA] -- adaptive readahead 
daemon
Changed Bug title to 'RFS: preload/0.6.4-2 [ITA] -- adaptive readahead daemon' 
from 'RFS: preload [ITA] -- adaptive readahead daemon'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
658306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658306
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


-- 
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/handler.s.c.132889493228378.transcr...@bugs.debian.org

Bug#658306: preload/0.6.4-2 [ITA] -- adaptive readahead daemon

[Daniel Martí]

retitle 658306 RFS: preload/0.6.4-2 [ITA] -- adaptive readahead daemon
thanks

I've been working further on this package. The changelog now looks as follows:

   * New Maintainer (Closes: #646216)
   * Switched to 3.0 (quilt) source format.
   * Corrected the logrotate location. Thanks to Tobias for the patch.
 (Closes: #619384)
   * Improved init.d script
 + Add init.d status support. Thanks to Peter Eisentraut for the patch.
 (Closes: #645156)
 + The script now provides itself.
   * Created debian/watch.

You can get the source files as usual:

dget -x http://mentors.debian.net/debian/pool/main/p/preload/preload_0.6.4-2.dsc

The new changes since the first mentors upload are the watch file and the
init.d script providing itself. Apart from that, there's another error I
haven't been able to solve:

  I: preload: spelling-error-in-manpage usr/share/man/man8/preload.8.gz 
configuratoin configuration

When a quilt patch is created for that purpose, for some reason it doesn't
work. Maybe because debian/rules contains the following in "clean:"?

  rm -f src/preload.8 # generated at build time by help2man

Here is the "dpkg-buildpackage -sa" report:

  patching file src/preload.8
  Unreversed patch detected!  Skipping patch.
  1 out of 1 hunk ignored -- saving rejects to file src/preload.8.rej
  dpkg-source: error: LC_ALL=C patch -R -t -N -p1 -u -V never -g0 -E 
--no-backup-if-mismatch < preload-0.6.4/debian/patches/manpage-spelling.patch 
gave error exit status 1
  dpkg-buildpackage: error: dpkg-source --after-build preload-0.6.4 gave error 
exit status 1

And then there's --pedantic, showing another small bit:

  P: preload: copyright-refers-to-symlink-license usr/share/common-licenses/GPL

Should I solve it? I would very much like to, but then, which GPL license
should I refer to when I don't know which one to choose? (GPL-[123])

Thanks for your time,

Daniel

PS: Still looking for a sponsor, thus I would really appreciate it if someone
helped me through this adoption :-)

-- 
Daniel Martí - mvdan.cc - 0x58BF72C3


signature.asc
Description: Digital signature

Re: How to convince maintainer to use --as-needed?

[Bernhard R. Link]

* Dmitry Smirnov  [120210 07:18]:
> Because in their eyes I have neither expertise nor reputation I couldn't
> convince them that benefits are outweight risks. (--as-needed removes dozen of
> packages from Depends)
>
> I've been asked to provide a document or a quote from reputable DD regarding
> using --as-needed as recommended practice in Debian, if such.

I personally strongly recommend against using --as-needed unless you
understand very well what it does. It may change the runtime behaviour of a
program without any signs at link time.

Unless you are entangled in libraries ignoring usual best practises and
ignoring library borders in their headers (libglib, libboost), there
might be better solutions than --as-needed.

That is not to say there might not be cases where --as-needed is the
best solution, but it is definitely not something one should apply
blindly.

Bernhard R. Link


-- 
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/20120210121522.gb2...@client.brlink.eu

Re: How to convince maintainer to use --as-needed?

[Jakub Wilk]

* Stephen M. Webb , 2012-02-10, 07:12:

I seek your advice regarding the best practice with using --as-needed.
The --as--needed flag is automatically added to package builds in 
Ubuntu. If you do not want your package to fail to build from source 
(and thus not be included in the Ubuntu GNU/Linux distribution), you 
will at least test your project builds with that linker flag.


That's not a very strong argument, to be honest.

Here are some flam^H^H^H^Hthreads that discuss both pros and cons of 
--as-needed:

http://lists.debian.org/debian-devel/2007/12/msg00265.html
http://lists.debian.org/debian-amd64/2010/11/msg2.html

--
Jakub Wilk


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

Re: How to convince maintainer to use --as-needed?

[Stephen M. Webb]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/10/2012 01:17 AM, Dmitry Smirnov wrote:
> Dear mentors,
> 
> I seek your advice regarding the best practice with using
> --as-needed.

The --as--needed flag is automatically added to package builds in
Ubuntu.  If you do not want your package to fail to build from source
(and thus not be included in the Ubuntu GNU/Linux distribution), you
will at least test your project builds with that linker flag.

- -- 
Stephen M. Webb  
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk81CY4ACgkQTLRKqWcl7vP4vwCguvpd173VQXJj479DnF2AkV0W
ngcAnRy2RanmGF724xPMPG1U3G2kK5Zh
=hhCV
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f350993.7040...@bregmasoft.ca

Re: How to tell users that ia32-libs will go away

[Goswin von Brederlow]

Dear ftp-master,

I wonder if the solution below for transitioning ia32-libs to multiarch
would be OK in regards to DAK and testing transition etc. Any technical
problems why we couldn't make an exception for the 3 ia32-libs* packages
for this?


Steve Langasek  writes:

> On Thu, Feb 09, 2012 at 04:43:04PM +0100, Thibaut Paumard wrote:
>> Le 09/02/12 15:53, Goswin von Brederlow a écrit :
>
>> > now that a multiarch dpkg has been uploaded to experimental it looks
>> > like we can finaly get rid of ia32-libs* for wheezy.
>
>> > !!!HURAY!!!
>
>> > The problem now is the transition:
>
>> > 1) multiarch and ia32-libs are incompatible
>> >[...]
>> > What this means is that users that want to use multiarch should remove
>> > ia32-libs (and lib32* really) soonest.
>
>> Couldn't you make ia32-libs a meta-package pulling the multiarch version
>> of the libs it used to include ?
>
> This would require something like
>
>   Depends: libpam0g:i386, libssl098:i386, [...]
>
> and this syntax is not yet supported (intentionally, because there's a lot
> of policy that needs to be put in place before we allow such things).
>
> Ubuntu, faced with the same issue, kludged a bit to make upgrades possible.
>
>   Package: ia32-libs
>   Architecture: amd64
>   Depends: ia32-libs-multiarch
>
>   Package: ia32-libs-multiarch
>   Architecture: i386
>   Multi-Arch: foreign
>   Depends: libpam0g, [...]
>
> This doesn't require us to support :arch syntax for dependencies anywhere
> yet; it just requires that the i386 arch is enabled via multiarch, and that
> the package manager is able to resolve the fact that ia32-libs' dependency
> is satisfied by the only copy of ia32-libs-multiarch available, the i386
> one.
>
> However, this still introduces at least some of the same policy problems -
> for instance, britney has to be taught that this is ok if you want to be
> able to migrate this package to testing automatically.  And you need a
> multiarch-capable package manager installed and configured *before* you can
> upgrade this package, so that requires a two-step upgrade of some variety:
> either holding ia32-libs back until after the dist-upgrade, or upgrading the
> package manager before the dist-upgrade.

MfG
Goswin


-- 
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/87wr7vgc2x.fsf@frosties.localnet

Re: RFS: policyd-weight

[Werner Detter]

Anyone ? :)


Am 08.02.12 12:53, schrieb Werner Detter:
> Hi everybody
> 
> I've received an email from Thomas. He proposed that it would make sense to
> have not only one sponsor for my package but maybe two  So if one is busy
> the other one can do the sponsoring.
> 
> Thomas had no time to upload my package which I've uploaded on Januar 24th.
> But he suggested to ask on the mentors list for a second sponsor :)
> 
> So I'm asking the list if any DD could sponsor this upload for me? In 
> principal
> the new package includes little fixes with the init-script, and closes a bug.
> 
> Thanks for your help.
> 
> Regards from Munich,
> Werner Detter
> 
> 
> 
> 
> Am 07.02.12 15:33, schrieb Werner Detter:
>> Hi everybody,
>>
>> as Thomas is non responsive since about two weeks I'll try to find somebody 
>> that uploads the package for me.
>>
>>  * Package name: policyd-weight
>>Version : 0.1.15.2-2
>>Upstream Author : Robert Felber
>>  * URL : www.policyd-weight.org
>>  * License : GPL-2+
>>Section : mail
>>
>> It builds those binary packages:
>>
>> policyd-weight - Perl policy daemon for the Postfix MTA
>>
>> To access further information about this package, please visit the following 
>> URL:
>>
>>   http://mentors.debian.net/package/policyd-weight
>>
>> Alternatively, one can download the package with dget using this command:
>>
>>   dget -x 
>> http://mentors.debian.net/debian/pool/main/p/policyd-weight/policyd-weight_0.1.15.2-2.dsc
>>
>> Thanks,
>> Werner Detter
> 
> 


-- 
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/4f34f9d3.9080...@aloah-from-hell.de

Re: RFS: burp -- A cross platform network backup and restore program.

[Bartosz Feński]

W dniu 07.02.2012 22:06, Bas van den Dikkenberg pisze:
>
>  
>
>  
>
> *Van:*Bartosz Feński [mailto:bart...@fenski.pl]
> *Verzonden:* dinsdag 7 februari 2012 21:20
> *Aan:* Bas van den Dikkenberg
> *CC:* Daniel Martí; debian-mentors@lists.debian.org
> *Onderwerp:* Re: RFS: burp -- A cross platform network backup and
> restore program.
>
>  
>
> W dniu 07.02.2012 15:51, Bas van den Dikkenberg pisze:
>
> Three uploads,
>
>  
>
> The initial, the one you gave some comments.
>
>  
>
> Today a second one, then I notisid that there was no watch file so
> created one en uploaded a new version.
>
>  
>
>
> Did you try to build it under pbuilder/cowbuilder?
>
> No i didn’t i run dpkg-buildpackage -rfakeroot -kC9710323
>
> To build without a problem
>
>  
>
>
> I tried, without success.
>
> Starting tests
> Server output log: /tmp/buildd/burp-1.3.0/test/logs/server-system.log
> Server system log: /tmp/buildd/burp-1.3.0/test/logs/server-output.log
>Client log: /tmp/buildd/burp-1.3.0/test/logs/client.log
> Bedup log: /tmp/buildd/burp-1.3.0/test/logs/bedup.log
>  Diff log: /tmp/buildd/burp-1.3.0/test/logs/diff.log
> More logs can be found in:
> /tmp/buildd/burp-1.3.0/test/target/var/spool/burp/testclient/ number>
>
> Starting test server
>
> Test 1
> First backup/restore comparison
> Starting test client backup
>
> Test failed: client backup returned 127
>
> Killing test server
> ./run_test: line 37: kill: (2420) - No such process
> make[2]: *** [test] Error 1
> make[2]: Leaving directory `/tmp/buildd/burp-1.3.0/test'
> make[1]: *** [test] Error 2
> make[1]: Leaving directory `/tmp/buildd/burp-1.3.0'
> dh_auto_test: make -j1 test returned exit code 2
> make: *** [build] Error 29
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
>
>
> This has to be fixed before we're going to upload it to the archive.
>
> I understand but it doesn’t do it at my sight what kind pro are you
> running
>
>

As stated before I'm using cowbuilder and you should really start to
using it.
Either cowbuilder or pbuilder.

If the package doesn't build under pbuilder then uploading it to archive
is useless cause autobuilders will create similar environment for
building and that build is going to fail.


>
> Other things around debian/* files.
>
> TODO - I suppose it's upstream TODO, not yours, so remove it.
> README - the same, we don't have to include info how to build the
> package... you're trying to include built package, right?
>
> Will remove them
>
>  
>
> init.d / init.d.DEBIAN what's that?
>
>  
>
> The init.d  is overwriten bye build script I can’t find where so made
> init.d.DEBIAN and made a entry in rules to overwrite the init file .
>
>
>
> changelog - we've got new lintian warning ;)
>
> W: burp: latest-debian-changelog-entry-without-new-date
>
>  
>
> Oke I will do
>
>
>
> Really start using dch tool ;)
>
> postinst / postrm seem to be to unnecessary too
>
> control:
>  Burp is a backup and restore program. It uses librsync in order to
> save onr
>
> *onr* looks like a typo, everything else looks like good example to be
> proofreaded by native English speakers. debian-i...@lists.debian.org
>  is good place to ask for such
> proofreading.
>
> rules:
>
> Please check if these overrides are really necessary, this one looks
> strange for me:
>
> override_dh_auto_configure:
> ./configure
>
> dh_auto_configure basically does this + --prefix=something
>
> overrid_dh_fixperms:
>
> You've just changed permissions of all files to be world readable.
> I guess upstream wanted them to be private for some reason.
>
> Consult with it what are the correct permissions and if they have to
> be 600 then add lintian override file and not make them world readable
> only to make lintian happy.
>
> regards
> fEnIo
>
>
> Bas
>
>  
>
>  
>
> *Van:*Daniel Martí [mailto:danielmarti.deb...@gmail.com]
> *Verzonden:* dinsdag 7 februari 2012 15:04
> *Aan:* Bas van den Dikkenberg; Bartosz Feński
> *CC:* debian-mentors@lists.debian.org
> 
> *Onderwerp:* RE: RFS: burp -- A cross platform network backup and
> restore program.
>
>  
>
> Also, might I ask why are there three changelog entries? Or has there
> been *three* uploads in a two day period?
>
> Cheers!
>
>  
>