Bug#528733: O: svn-buildpackage -- helper programs to maintain Debian packages with Subversion

[Eddy Petrișor]

(Please CC me, I am not subscribed to debian-devel)

Debian Bug Tracking System a scris:
> If you wish to submit further information on this problem, please
> send it to 528...@bugs.debian.org, as before.

It might be of interest to many people reading debian-devel to know that
svn-buildpackage is now orphaned and anybody wishing to take over
maintaining it, is more than welcome.

The package needs more attention than I can offer it now and Eduard
Bloch, the original author, hasn't touched the package for more time
than I did.





Here is again the initial orphaning mail:

=
Package: wnpp
Version: N/A; reported 2009-05-15
Severity: normal

It has been about a year and a half* since svn-buildpackage hasn't
been uploaded, the 0.6.24 is waiting in collab-maint's SVN for an
upload for quite some time now. I am slowly but surely giving up
on maintaining packages in SVN and, thus I lack the motivation to
maintain the package.


http://svn.debian.org/wsvn/collab-maint/deb-maint/svn-buildpackage/trunk/


Since there are multiple fixes for it and still people are using it
and neither I nor Eduard Bloch had the time to maintain it properly
I have decided is high time for this package to find another dedicated
maintainer.

People interested in maintaining it should be aware that there is a
non-interactive way of running the scripts and these must be kept
functional and there are several ways the scripts bend to accommodate
native and non-native packages. There are some patches in the BTS and
some of the scripts could use some love or maybe a full rewrite once
the bug count lowers.

Since the scripts were written in perl, a perl-er is desirable as a
maintainer (I don't consider myself a perl coder and, as I understood,
Eduard wrote the scripts in his early perl days, so you might expect
some code horror).



I really hope someone will step up fast to take over maintenance,
since this is an important package for many people.



*OTOH, there was a stable release with a long freeze during this time


-- 
Regards,
EddyP
=
"Imagination is more important than knowledge" A.Einstein



signature.asc
Description: OpenPGP digital signature

Re: i386.changes vs source.changes

[Malte Forkel]

Russ Allbery schrieb:
> Malte Forkel  writes:
> 
>> After some more checking and thinking, I guess I know what's causing
>> my problems: Its me, probably! I assume the source.changes files are
>> created while I setup everything for building a package, e.g. by
>> dh_make calling dpkg-buildpackage -S or whatever. I then use either
>> debuild and pdebuild to build the binary packages. But while debuild
>> replaces the source.changes file by an i386.changes file, pdebuild
>> places the i386.changes file in /var/cache/pbuilder/result and does
>> not replace the source.changes file.
> 
> The _source.changes file created by pdebuild is useless.  I always
> delete it in my shell alias that runs pdebuild.  I suppose I should have
> gotten around to filing a wishlist bug to have pdebuild delete it.
> 
Oh, so its only pdebuild that creates a superfluous _source.changes file
while all the other little helpers don't and consequently don't have to
replace later on?


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

Re: Bug#528733: O: svn-buildpackage -- helper programs to maintain Debian packages with Subversion

[Neil Williams]

On Fri, 15 May 2009 10:49:07 +0300
Eddy Petrișor  wrote:

> (Please CC me, I am not subscribed to debian-devel)
> 
> Debian Bug Tracking System a scris:
> > If you wish to submit further information on this problem, please
> > send it to 528...@bugs.debian.org, as before.
> 
> It might be of interest to many people reading debian-devel to know that
> svn-buildpackage is now orphaned and anybody wishing to take over
> maintaining it, is more than welcome.

I'll take a look at it - I use SVN heavily for developing various
packages/projects and use svn-bp to build them for Debian. My only
concern is that I haven't ever used the svn-upgrade or svn-inject
functionality, so if others with more experience of those areas want to
join the maintenance effort it would help.

Note that there is this bug which is an O: bug (which I'll retitle ITA
and take as owner) and an RFH: bug #377467 which I'll leave in place
because it is still valid due to the above.

> The package needs more attention than I can offer it now and Eduard
> Bloch, the original author, hasn't touched the package for more time
> than I did.

There are a few lintian reports and some bugs marked pending upload,
I'll investigate those first, as well as the current bug reports that
already have patches.

> People interested in maintaining it should be aware that there is a
> non-interactive way of running the scripts and these must be kept
> functional and there are several ways the scripts bend to accommodate
> native and non-native packages. There are some patches in the BTS and
> some of the scripts could use some love or maybe a full rewrite once
> the bug count lowers.

A full rewrite is not on my ToDo list for svn-bp. At least not until
after Squeeze. If anybody wants to help with a rewrite once the package
is back in routine maintenance, let me know.

> Since the scripts were written in perl, a perl-er is desirable as a
> maintainer (I don't consider myself a perl coder and, as I understood,
> Eduard wrote the scripts in his early perl days, so you might expect
> some code horror).

Doesn't look too bad at this stage but I haven't started hacking it
around yet. :-)
 
-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/



pgpFOme6DAcyE.pgp
Description: PGP signature

Re: Bug#528733: O: svn-buildpackage -- helper programs to maintain Debian packages with Subversion

[Eddy Petrișor]

Neil Williams a scris:
> On Fri, 15 May 2009 10:49:07 +0300
> Eddy Petrișor  wrote:
> 
>> (Please CC me, I am not subscribed to debian-devel)
>>
>> Debian Bug Tracking System a scris:
>>> If you wish to submit further information on this problem, please
>>> send it to 528...@bugs.debian.org, as before.
>> It might be of interest to many people reading debian-devel to know that
>> svn-buildpackage is now orphaned and anybody wishing to take over
>> maintaining it, is more than welcome.
> 
> I'll take a look at it - I use SVN heavily for developing various
> packages/projects and use svn-bp to build them for Debian. My only
> concern is that I haven't ever used the svn-upgrade or svn-inject
> functionality, so if others with more experience of those areas want to
> join the maintenance effort it would help.

For that part somebody from the GNOME or Perl teams might be useful.

> Note that there is this bug which is an O: bug (which I'll retitle ITA
> and take as owner) and an RFH: bug #377467 which I'll leave in place
> because it is still valid due to the above.

Ahem, I closed that bug since last night I wasn't that... inspired in
the first placed and sent an O bug, then realised these was an open RFH,
which meant it was sort of redundant and useless :-/ .

>> The package needs more attention than I can offer it now and Eduard
>> Bloch, the original author, hasn't touched the package for more time
>> than I did.
> 
> There are a few lintian reports and some bugs marked pending upload,
> I'll investigate those first, as well as the current bug reports that
> already have patches.

Note that in SVN trunk there is a pending 0.6.24 release which needs a
little bit of testing before the upload.


The change log is quite substantial:

Source: svn-buildpackage
Version: 0.6.24
Distribution: unstable-UNRELEASED
Urgency: low
Maintainer: Eddy Petrișor 
Date: Thu, 07 May 2009 10:13:18 +0300
Closes: 419005 451652 464840 467614 487648 502653 504233 506426 506965
Changes:
 svn-buildpackage (0.6.24) unstable-UNRELEASED; urgency=low
 .
   [ Eduard Bloch ]
   * Changed detection for tarball contents without root directory to
identify
 single files, even if mixed with symlinks
   * Use $(MAKE) in Makefile, avoid jobserver warnings with -j
 .
   [ Eddy Petrișor ]
   * updated TODO list
 - removed irrelevant/obsolete entries
 - s-u should be smart wrt origUrl
   * register the howto documents with doc-base (Closes: #451652)
 - added postinst and prerm maintainer scripts as a consequence
   * install svn-do in /usr/bin to be avilable by default; thanks Sean
Finney
 for the suggestion (Closes: #464840)
   * svn-inject no longer creates an invalid test file (Closes: 467614)
 .
   [ Damyan Ivanov ]
   * svn-upgrade: Drop "(NOT RELEASED YET)" from the created changelog
entry.
 Closes: #487648
   * Move all of build-dependencies except debhelper from D-B to D-B-I
 + replace obsolete tetex-extra with texlive
   * Replace build-dependency on transitional gd-gpl|gs packages with
 ghostscript
   * Fix typo in doc/svn-buildpackage-howto, thanks lintian
   * Change svn-build-package-howto section from non-existent
 Apps/Programming to Debian
 .
   [ Eddy Petrișor ]
   * improved copyright file
 .
   [ Jan Hauke Rahm ]
   * When files are ignored due to subversion ignore patterns the user gets
 prompted to skip or import those files; in noninteractive mode
those files
 are automatically skiped unless '--ignored-files-action=import'
(only in
 svn-upgrade) is set. (Closes: #504233)
   * Dropping support for linda (Closes: #502653)
   * Correcting typo in svn-buildpackage (Closes: #506426)
 .
   [ Eddy Petrișor ]
   * Added a helper script to ease up installation of the build-deps of
 the current source package (Closes: #506965)
   * drop option dbgsdcommon in favour of using $SVNBPPERLLIB for easier
 support for testing and debugging; since this option was hidden, no
 safety nets were provided for the drop
   * fix a bug that prevented execution of shell commands when the hidden
 option ignoreerrors was used; this option is still hidden since is
 not actually working as it should be and will be rethought
   * don't pretend a all commands fail in unknown directories;
 properly fixed #419005 in the way I initially proposed, since the
 way Gonéri proposed was broken in several ways (and I copied that
 without checking) correctly closes: #419005 instead of hiding it
   * add --svn-arch option, thanks to Julien Valroff  (Closes: #527302)



Note that the last bugfix (#527302) wasn't tested at all and that was
the trigger reason for this mail.


Also, I just finished writing a corresponding blog post about svn-bp and
 there are some useful notes there:

http://ramblingfoo.blogspot.com/2009/05/svn-buildpackage-is-now-orphaned.html

>> People interested in maintaining it should be aware that there is a
>> non-interactive way of running the scripts and these must be kept

Re: architecture wildcards, type-handling, etc.

[Riku Voipio]

On Thu, May 14, 2009 at 10:13:43AM +0300, Peter Eisentraut wrote:
> On Wednesday 13 May 2009 21:55:00 Guillem Jover wrote:
> > So, there's missing support in sbuild (#501230), which arguably is
> > a pretty recent bug report, but AFAIR I sent a mail to Ryan long time
> > ago when drafting the wildcard support and never heard back, but then
> > I never insisted again, so that's on me.
> >
> > Then the buildd network will need to be upgraded to use an sbuild
> > supporting that. I'm not sure if wanna-build might also need changes.
> > Lintian will need to be fixed as well once the buildd network supports
> > this. And then minor stuff like the vim debcontrol syntax highlighter
> > and similar.

> Would it be reasonable/acceptable to establish this issue as a squeeze 
> release 
> goal?

a release goal is IMHO something that needs fixes in a sweep of
packages in archive before release. This change OTOH just needs fixes
to sbuild and then some infrastructure work (deploying new sbuild/buildd
everywhere).

As the second part is already being worked on, all you need is to provide
patches to the sbuild/buildd maintainers :)


signature.asc
Description: Digital signature

Re: [buildd-tools-devel] architecture wildcards, type-handling, etc.

[Roger Leigh]

On Fri, May 15, 2009 at 12:28:07PM +0300, Riku Voipio wrote:
> On Thu, May 14, 2009 at 10:13:43AM +0300, Peter Eisentraut wrote:
> > On Wednesday 13 May 2009 21:55:00 Guillem Jover wrote:
> > > So, there's missing support in sbuild (#501230), which arguably is
> > > a pretty recent bug report, but AFAIR I sent a mail to Ryan long time
> > > ago when drafting the wildcard support and never heard back, but then
> > > I never insisted again, so that's on me.
> > >
> > > Then the buildd network will need to be upgraded to use an sbuild
> > > supporting that. I'm not sure if wanna-build might also need changes.
> > > Lintian will need to be fixed as well once the buildd network supports
> > > this. And then minor stuff like the vim debcontrol syntax highlighter
> > > and similar.
> 
> > Would it be reasonable/acceptable to establish this issue as a squeeze 
> > release 
> > goal?
> 
> a release goal is IMHO something that needs fixes in a sweep of
> packages in archive before release. This change OTOH just needs fixes
> to sbuild and then some infrastructure work (deploying new sbuild/buildd
> everywhere).
> 
> As the second part is already being worked on, all you need is to provide
> patches to the sbuild/buildd maintainers :)

If it's just a matter of applying the patch for #501230, that's easy
enough.  I should have applied it a while back, but it just slipped under
the radar.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: architecture wildcards, type-handling, etc.

[Peter Eisentraut]

On Friday 15 May 2009 12:28:07 Riku Voipio wrote:
> a release goal is IMHO something that needs fixes in a sweep of
> packages in archive before release. This change OTOH just needs fixes
> to sbuild and then some infrastructure work (deploying new sbuild/buildd
> everywhere).

Per upstream, this would still need fixes in pbuilder, lintian, possibly other 
build tools, and then sweep across all packages to replace type-handling or 
not+gnu-linux.


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

Re: postfix as default-mta? [Re: Bug#508644: new release goal default-mta?]

[Lionel Elie Mamane]

On Thu, May 07, 2009 at 09:25:59AM +0200, Luca Niccoli wrote:
> 2009/5/7 Brian May :

>> However, I very much dislike this Unix "feature" as it means mail can
>> accumulate on any {user,system} account on any computer and not get
>> noticed by the {user,system administrator}.

> Not getting mail from cron is worse I think...  I would instead like
> to have something popping up when I log in in X saying me "You have
> mail", like it happens by default if I log in from terminal (and in
> movies from the '80s).

Just add pam_mail to e.g. /etc/pam.d/gdm (if you use gdm).

-- 
Lionel


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

E: libactiviz: ldconfig-symlink-referencing-wrong-file

[Mathieu Malaterre]

Hello,

  I am trying to package a *binary* package. This is a commercial
software but for ease of installation I am simply repackaging it.

  I am getting closer to my goal, one of the remaining issue is:

E: libactiviz: ldconfig-symlink-referencing-wrong-file
usr/lib/libvtktiff.so.5.4 -> ./libvtktiff.so.5.4.0 instead of
libvtktiff.so.5.4.0

  I have not been able to figure out how to regenerate those symlinks
using ldconfig...

Ref:
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime

Thanks for help,
-- 
Mathieu


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

Re: E: libactiviz: ldconfig-symlink-referencing-wrong-file

[Mathieu Malaterre]

On Fri, May 15, 2009 at 5:38 PM, Mathieu Malaterre
 wrote:
> Hello,
>
>  I am trying to package a *binary* package. This is a commercial
> software but for ease of installation I am simply repackaging it.
>
>  I am getting closer to my goal, one of the remaining issue is:
>
> E: libactiviz: ldconfig-symlink-referencing-wrong-file
> usr/lib/libvtktiff.so.5.4 -> ./libvtktiff.so.5.4.0 instead of
> libvtktiff.so.5.4.0
>
>  I have not been able to figure out how to regenerate those symlinks
> using ldconfig...
>
> Ref:
> http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-runtime

Symply redoing the 'ln -s' command myself solve the issue. I needed to do:

 ln -s libfoo.1.2.3 libfoo.1.2

while apparently something like that was done:

 ln -s libfoo.1.2.3 ./libfoo.1.2

Sorry for the noise,
-- 
Mathieu


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

Re: Bug#494714: dpkg-dev - dpkg-genchanges should fold lines

[Raphael Hertzog]

tag 494714 + patch
thanks

On Mon, 11 Aug 2008, Bastian Blank wrote:
> dpkg-genchanges should fold lines in the output to a sane length. There
> is a package in the archive (linux-modules-extra-2.6) which produces a
> 25k long Binary line, which is cropped by gpg during signing.

I guess we should do the same for the Binary: field in the .dsc in that
case. Why did you mention only the .changes ?

CCing -devel to have input about possible stuff that would break if the
Binary field is split over multiple lines. I have checked
dak/process_unchecked.py and it seems to handle correctly a Binary: field
split over multiple lines. But we have many other tools that parses
.dsc and .changes.

The Binary: field in .dsc is the one that has the biggest impact since
it's copied over in Sources files on mirrors and parsed by many custom
scripts. The one in .changes concerns fewer tools probably.

CCing -policy, do we need to update policy to allow Binary: fields
over multiple lines? Currently it only says that the fields are
comma-separated and space-separated. Does "space" include newlines
like in the usual \s perl regexp or not ? (comma can also be followed by
spaces so the same reasoning applies)
http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Binary

A first patch for dpkg-dev is attached but I'll refrain from committing it
until I received some more feedback.

Cheers,
-- 
Raphaël Hertzog

Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny :
http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/
>From bc62fd60bb2347e4550bb3ccba701561cab5e1fe Mon Sep 17 00:00:00 2001
From: Raphael Hertzog 
Date: Fri, 15 May 2009 18:09:25 +0200
Subject: [PATCH] dpkg-source/dpkg-genchanges: split long Binary: field values

---
 scripts/dpkg-genchanges.pl |2 ++
 scripts/dpkg-source.pl |2 ++
 2 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/scripts/dpkg-genchanges.pl b/scripts/dpkg-genchanges.pl
index 32b5bff..2bbcd29 100755
--- a/scripts/dpkg-genchanges.pl
+++ b/scripts/dpkg-genchanges.pl
@@ -483,6 +483,8 @@ if (!defined($fields->{'Date'})) {
 }
 
 $fields->{'Binary'} = join(' ', map { $_->{'Package'} } $control->get_packages());
+# Avoid overly long line (>~1000 chars) by splitting over multiple lines
+$fields->{'Binary'} =~ s/(.{980,}?) /$1\n /g;
 
 unshift(@archvalues,'source') unless is_binaryonly;
 @archvalues = ('all') if $include == ARCH_INDEP;
diff --git a/scripts/dpkg-source.pl b/scripts/dpkg-source.pl
index 6ea264c..44d8bbb 100755
--- a/scripts/dpkg-source.pl
+++ b/scripts/dpkg-source.pl
@@ -247,6 +247,8 @@ if ($options{'opmode'} eq 'build') {
 }
 
 $fields->{'Binary'} = join(', ', @binarypackages);
+# Avoid overly long line (>~1000 chars) by splitting over multiple lines
+$fields->{'Binary'} =~ s/(.{980,}?), ?/$1,\n /g;
 
 # Generate list of formats to try
 my @try_formats = (@cmdline_formats);
-- 
1.6.3

Re: Bug#494714: dpkg-dev - dpkg-genchanges should fold lines

[Russ Allbery]

Raphael Hertzog  writes:

> CCing -policy, do we need to update policy to allow Binary: fields
> over multiple lines?

Yes.  (But I certainly have no objections to doing so.)

> Currently it only says that the fields are comma-separated and
> space-separated. Does "space" include newlines like in the usual \s
> perl regexp or not ?

No.

This needs to be clarified in Policy in general, since it's been
confusing to people in several different contexts.

-- 
Russ Allbery (r...@debian.org)   


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

Re: i386.changes vs source.changes

[Russ Allbery]

Malte Forkel  writes:
> Russ Allbery schrieb:
>> Malte Forkel  writes:

>>> After some more checking and thinking, I guess I know what's causing
>>> my problems: Its me, probably! I assume the source.changes files are
>>> created while I setup everything for building a package, e.g. by
>>> dh_make calling dpkg-buildpackage -S or whatever. I then use either
>>> debuild and pdebuild to build the binary packages. But while debuild
>>> replaces the source.changes file by an i386.changes file, pdebuild
>>> places the i386.changes file in /var/cache/pbuilder/result and does
>>> not replace the source.changes file.

>> The _source.changes file created by pdebuild is useless.  I always
>> delete it in my shell alias that runs pdebuild.  I suppose I should
>> have gotten around to filing a wishlist bug to have pdebuild delete
>> it.

> Oh, so its only pdebuild that creates a superfluous _source.changes file
> while all the other little helpers don't and consequently don't have to
> replace later on?

Calling dpkg-buildpackage -S produces a superfluous _sources.changes
file, so anything that uses that method to produce a source package for
build would either need to remove it or would leave it lying around.
pdebuild uses dpkg-buildpackage -S to generate a source package which it
then copies into the chroot to do the full build.

-- 
Russ Allbery (r...@debian.org)   


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

Re: i386.changes vs source.changes

[Cyril Brulebois]

Russ Allbery  (15/05/2009):
> Calling dpkg-buildpackage -S produces a superfluous _sources.changes
> file, so anything that uses that method to produce a source package
> for build would either need to remove it or would leave it lying
> around.  pdebuild uses dpkg-buildpackage -S to generate a source
> package which it then copies into the chroot to do the full build.

You call it superfluous. It's particularly helpful for source-only
uploads.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#443507: python-gobject: Importing gobject fails after libglib upgrade

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

Am Sa den 22. Sep 2007 um  0:18 schrieb Zakrn:
> On Sat, 2007-09-22 at 01:14 +0200, Josselin Mouette wrote:
> > I'm not talking about the libpcre3 package, but of the file
> > in /lib/libpcre.so.3 which was not brought by a Debian package.
> 
> My fault, I didn't think about it. And you are right,
> removing /lib/libpcre.so.3 and /lib/libpcre.so.3.12.0 has helped. But I
> really don't know what could install them.

Well, maybe I can help out with the solution.

I had similar problem today on one of my systems and found this bug
report. So the solution was also true for me. But I cannot live without
to know why a library was in the /lib without coming from a .deb. So I
did some search and found the reason.

Years ago there was a /bin/grep depending on libpcre.so which stay in
/usr. So it was necessary to copy the library to /lib to let the system
boot again. And that was it. Just a temporary bugfix.

The bad is that all tools used the old /lib/libpcre.so.0 and not the
updated one in /usr/lib. So the bug is a kind of handmade security bug.
(Maybe other has the same but did not see it!)

So maybe there can be a warning in the NEWS of grep or libpcre3 if the
workaround exists on recent systems.

Regards
   Klaus

Ps. This is just a note x post to debian-devel to rfc. The bug shouldn't
go open.
- -- 
Klaus Ethgenhttp://www.ethgen.de/
pub  2048R/D1A4EDE5 2000-02-26 Klaus Ethgen 
Fingerprint: D7 67 71 C4 99 A6 D4 FE  EA 40 30 57 3C 88 26 2B
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iQEVAwUBSg26S5+OKpjRpO3lAQr3WQgAsjdHNLbPjgb2XLgjJK9ye6AgRDsHGQwH
gv/UDUG6C0X9Llyv/OQxEpy6cfiJxLhvTP91NEx4bobj52LgOlUUP7Kz7NcGLROv
Hk/Bhjxet1xNJtEzGiHRmMRX+DycUQXcOsls3eclsVaqjuvTyaGy2TkQwFFsvlVP
8WvHyUHoPmhr/X/5sOxaantI5BbOOaPSZPyc9SYDaIJ+Dttz3NL6pRyOFl26tlhQ
I2glFpD4MhCIllwzJZ1kNpJ63GLLGn1xlMrl89Vc31FNREKPYJ9es0A4LO7G8azN
FYKLBoX4A01gBYg9Yibr/Lick0VbD/y8N4rXgzmerD6bHbbnnO/gpA==
=JThp
-END PGP SIGNATURE-


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

Re: i386.changes vs source.changes

[Russ Allbery]

Cyril Brulebois  writes:
> Russ Allbery  (15/05/2009):

>> Calling dpkg-buildpackage -S produces a superfluous _sources.changes
>> file, so anything that uses that method to produce a source package
>> for build would either need to remove it or would leave it lying
>> around.  pdebuild uses dpkg-buildpackage -S to generate a source
>> package which it then copies into the chroot to do the full build.

> You call it superfluous. It's particularly helpful for source-only
> uploads.

Well, yes, it's superfluous for Debian, which doesn't support
source-only uploads.

-- 
Russ Allbery (r...@debian.org)   


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

Re: i386.changes vs source.changes

[Philipp Kern]

On 2009-05-15, Russ Allbery  wrote:
> Cyril Brulebois  writes:
>> Russ Allbery  (15/05/2009):
>>> Calling dpkg-buildpackage -S produces a superfluous _sources.changes
>>> file, so anything that uses that method to produce a source package
>>> for build would either need to remove it or would leave it lying
>>> around.  pdebuild uses dpkg-buildpackage -S to generate a source
>>> package which it then copies into the chroot to do the full build.
>> You call it superfluous. It's particularly helpful for source-only
>> uploads.
> Well, yes, it's superfluous for Debian, which doesn't support
> source-only uploads.

Superfluous for Debian's main archive.

Mraw,
Philipp Kern


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

Re: i386.changes vs source.changes

[Ben Finney]

Russ Allbery  writes:

> Cyril Brulebois  writes:
> > You call it superfluous. It's particularly helpful for source-only
> > uploads.
> 
> Well, yes, it's superfluous for Debian, which doesn't support
> source-only uploads.

But not for hackers preparing packages for Debian, who want to present
those for others to inspect or collaborate on. A prime example being the
mentors.debian.net workflow.

-- 
 \ “I object to doing things that computers can do.” —Olin Shivers |
  `\   |
_o__)  |
Ben Finney


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

Re: i386.changes vs source.changes

[Russ Allbery]

Ben Finney  writes:
> Russ Allbery  writes:
>> Cyril Brulebois  writes:

>>> You call it superfluous. It's particularly helpful for source-only
>>> uploads.

>> Well, yes, it's superfluous for Debian, which doesn't support
>> source-only uploads.

> But not for hackers preparing packages for Debian, who want to present
> those for others to inspect or collaborate on. A prime example being
> the mentors.debian.net workflow.

So, y'all realize that pdebuild --buildresult .. by default breaks the
*_source.changes file that it generates because it regenerates a source
package as part of the regular build, right?  How are you actually using
that *_source.changes file?  Always having pdebuild put its build
results in a different location than where it generates the source
package?

-- 
Russ Allbery (r...@debian.org)   


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

Re: i386.changes vs source.changes

[Cyril Brulebois]

Russ Allbery  (15/05/2009):
> So, y'all realize that pdebuild --buildresult .. by default breaks the
> *_source.changes file that it generates because it regenerates a
> source package as part of the regular build, right?  How are you
> actually using that *_source.changes file?  Always having pdebuild put
> its build results in a different location than where it generates the
> source package?

I don't know what people do with all those wrapper thingies. I do that:
| debuild -S -i -uc -us
| # check everything, like building in cowbuilder, lintian, etc.
| debsign the _source.changes
| dput it

No clue about pdebuild, never used.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: i386.changes vs source.changes

[Ben Finney]

Russ Allbery  writes:

> So, y'all realize that pdebuild --buildresult .. by default breaks the
> *_source.changes file that it generates because it regenerates a
> source package as part of the regular build, right?

I've no idea about what pdebuild does, I don't use it. I was addressing
only the false assertion that a source-only upload is superfluous.

-- 
 \“I filled my humidifier with wax. Now my room is all shiny.” |
  `\—Steven Wright |
_o__)  |
Ben Finney


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

integrating PAM module into nss-ldapd (RFH)

[Arthur de Jong]

Hello list (I've put a couple of people in Bcc to try to get more
feedback),

I'm working on integrating a PAM module into nss-ldapd and am looking
for input on this. The PAM module was kindly provided by Howard Chu from
the OpenLDAP project but I'm still working on the server part.

(more info on nss-ldapd: http://packages.debian.org/nss-ldapd)

With this new functionality I'm planning to generate three binary
packages (instead of the now one): libnss-ldapd (the NSS module),
libpam-ldapd (the PAM module) and nslcd (the daemon). The reason for
this split is that some users may want to stick with the other PAM
module. Also the OpenLDAP people are working on an overlay that could
replace the nslcd part (but it's up to the OpenLDAP maintainers if they
want to provide such a package).

Also, I'm looking for people who are willing to spend some time on
nss-ldapd. I could use some help with the PAM packaging part, I know
libpam-runtime was changed recently so if anyone can help to get the the
PAM packaging into shape that would be great.

Since nss-ldapd seems to be used more often now, having a co-maintainer
for the package would really help. There is still enough development
work to be done but also packaging work with the upcoming split.

Another important part where I would really welcome suggestions is a
better name for the software. I've seen some confusion over the current
name (people not noticing the d at the end) and with the integration of
PAM functionality the name no longer covers the functionality.

Current work on integrating the PAM functionality can be tracked here:
http://arthurenhella.demon.nl/svn/nss-ldapd/nss-pam-ldapd/
http://arthurenhella.demon.nl/viewvc/nss-ldapd/nss-pam-ldapd/

Any comments and suggestions are very much appreciated. Thanks.

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


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