Re: Unable to ssh to alioth

[Andreas Metzler]

Andreas Tille  wrote:
[...]
> I can confirm that I was able to checkout and commit to svn.debian.org until
> yesterday evening.  Now it fails and the reason seems to be:

> ~$ ssh -v svn.debian.org
> ...
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: Roaming not allowed by server
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey
> debug1: Next authentication method: publickey
> debug1: Offering public key: /home/tillea/.ssh/id_rsa-debian
> debug1: Authentications that can continue: publickey
> debug1: No more authentication methods to try.
> Permission denied (publickey).
[...]

Hello,

I can confirm this. vasks.debian.org (aka (git|svn|...).d.o), seems
to have lost access to ssh keys in Debian LDAP. (wagner still has access).

> Any idea what to do?
[...]

gforge specific keys (uploaded through the web frontend) still work.

cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/lm79b8-9r3@argenau.downhill.at.eu.org

consolekit makes trouble

[Hans-J. Ullrich]

Hello list, 

I am really despaired! Due to a defective RAM, my /usr was corrupted, and so I 
had to reinstall the system from scratch. I installed debian/testing 
completely new (except /home, which is on a separate partition). As I am 
courious, I saved my package list by dpkg --get-selections > package.txt, and 
after the fresh installation, I could reinstall them again. I did this with 
the command: apt-get install $(cut -f1 package.txt), which worked fine.

But after that, I got a problem, and now working for hours to solve it:

As I am using kdm (and kde), I get an error:

kdm: :0[21175]: Cannot open ConsoleKit session: Unable to open session: Failed 
to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Succes

I can click it away, and I can use kde without any trouble.

Ok, to see, what hapend, I examined the log and found more information: 

May 29 09:33:43 localhost console-kit-daemon[22438]: WARNING: 
polkit_authority_get: Error getting authority: Error initializing authority: 
Error calling StartServiceByName for org.freedesktop.PolicyKit1: 
GDBus.Error:org.freedesktop.DBus.Error.Spawn.ExecFailed: Failed to execute 
program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Success 


So it looks like, there might be some authorization problem. I googled a lot, 
but found no usefull hints. Somebody solved it, by "unmerging glib-
networking", but that was in gentoo.

I will be very happy, if someone could help me, as I there is not much 
information about consolekit and dbus to find.

Thank you very much for any help.

Best regards

Hans-J. Ullrich


P.S. Sorry, if I sent this wrong, debian-u...@lists.debian.org claimed my e-
mail as spam. 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201105291008.23821.hans.ullr...@loop.de

Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Raphael Hertzog]

Hello,

from time to time I hear some rumblings about how "3.0 (quilt)" mixes
badly with VCS. Indeed, one of the primary goals of the format
was to not require prior knowledge of the patch system to be able to
modify a package. And it's the case since you can do:
- dpkg-source -x
- modify files
- debuild

But there are a few downsides:

Auto-application of patches
---

Since dpkg-source -x auto-applies the patch, the build part was
designed with the assumption that patches are pre-applied and this
assumption is often wrong for people using VCS. I have resolved this
by auto-applying the patch at the start of a build but (some) users of VCS
have been annoyed with it because it left the VCS unclean after the
build. The option --unapply-patches has been added as a way to change
the behaviour (and you can put it debian/source/local-options).

I would like to improve this situation and not force the majority of
people to add the unapply-patches option (if it turns out the majority
of people use this option or are annoyed by the patches being applied).

I see 2 ways to solve this:
a/ detect the common VCS and make --unapply-patches the default in that
   case (but it would require a --no-unapply-patches for the people who
   keep the patches applied in their VCS)
b/ modify dpkg-source --before-build to keep a trace of the fact that
   it applied the patches (for example by creating
   .pc/dpkg-source-auto-applied) and in that case have dpkg-source
   --after-build unapply the patches so that we're back to a clean
   state after a succesful build.
   If the build fails, we'd keep the patches applied.

My preference goes to b/ because it doesn't require changes for people
who like to keep the patches applied in their VCS too. And it's the
principle of least surprise, you keep the same state afer a build than
you had before the build (so it's still ok for people who rely
on the scenario unpack/hack/rebuild).

Comments? Does this look reasonable?


Automatic patches
-

Again to cope with the scenario explained at the start of this mail,
once a user has made modifications we must ensure that they end up in a
proper patch in debian/patches/. Right now this is entirely automatic,
the generated patches take the form of
debian/patches/debian-changes-.

Obviously this is a pretty poor name for a patch and given it's
automatically generated, it doesn't contain much useful description.
In general they are renamed by the maintainer who also adds a
description (or they are properly put in place before the build so that
dpkg-source doesn't have to create it).

But it still happens that those patches are generated[1] when the maintainer
did not expect any change at all. That's why we added the option
--abort-on-upstream-changes for maintainers who never wants dpkg-source
to auto-create a patch.

I wonder if I should not make this option the default and fail with an
error messages suggesting that the maintainer should run "dpkg-source
--record-changes" if he really wants to keep the current changes. It
would also leave the diff around somewhere in $TMPDIR if the user wants
to review it.

It would break the initial scenario but since the solution is given in the
error message, I believe it would be acceptable.

"dpkg-source --record-changes " would be an interactive command
because you would be asked to fill the patch description header.

We still have the case of people who keep all their changes in the VCS
without maintaining debian/patches/ and who uses --single-debian-patch.
In that case, --abort-on-upstream-changes would not apply.

What do you think of this? Do you have suggestions to improve this
workflow?

Ideally, if desired, dpkg-source --record-changes could be automatically
called in the build process but I'm wary of introducing something
interactive in the package build process.

Cheers,

[1] http://lintian.debian.org/tags/format-3.0-but-debian-changes-patch.html
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529085303.ga17...@rivendell.home.ouaza.com

Re: consolekit makes trouble

[Andrei Popescu]

On Du, 29 mai 11, 10:08:23, Hans-J. Ullrich wrote:
> 
> P.S. Sorry, if I sent this wrong, debian-u...@lists.debian.org claimed my e-
> mail as spam. 

- subscribe to whitelist@l.d.o
- if you still have troubles contact listmaster@l.d.o

Regards,
Andrei
-- 
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic


signature.asc
Description: Digital signature

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Josselin Mouette]

Le dimanche 29 mai 2011 à 10:53 +0200, Raphael Hertzog a écrit : 
> b/ modify dpkg-source --before-build to keep a trace of the fact that
>it applied the patches (for example by creating
>.pc/dpkg-source-auto-applied) and in that case have dpkg-source
>--after-build unapply the patches so that we're back to a clean
>state after a succesful build.
>If the build fails, we'd keep the patches applied.
> 
> My preference goes to b/ because it doesn't require changes for people
> who like to keep the patches applied in their VCS too. And it's the
> principle of least surprise, you keep the same state afer a build than
> you had before the build (so it's still ok for people who rely
> on the scenario unpack/hack/rebuild).

I’m not fond of the idea of having dpkg behave differently based on the
presence of a VCS. This should be orthogonal, especially given that
people have different usage patterns for their VCS.

Hence b/ looks much more reasonable.

> But it still happens that those patches are generated[1] when the maintainer
> did not expect any change at all. That's why we added the option
> --abort-on-upstream-changes for maintainers who never wants dpkg-source
> to auto-create a patch.
> 
> I wonder if I should not make this option the default

Yes please.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


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

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Cyril Brulebois]

Hi,

Raphael Hertzog  (29/05/2011):
> from time to time I hear some rumblings about how "3.0 (quilt)"
> mixes badly with VCS. Indeed, one of the primary goals of the format
> was to not require prior knowledge of the patch system to be able to
> modify a package.

thanks for trying to improve the situation.

> b/ modify dpkg-source --before-build to keep a trace of the fact that
>it applied the patches (for example by creating
>.pc/dpkg-source-auto-applied) and in that case have dpkg-source
>--after-build unapply the patches so that we're back to a clean
>state after a succesful build.
>If the build fails, we'd keep the patches applied.
> 
> My preference goes to b/ because it doesn't require changes for
> people who like to keep the patches applied in their VCS too. And
> it's the principle of least surprise, you keep the same state afer a
> build than you had before the build (so it's still ok for people who
> rely on the scenario unpack/hack/rebuild).
> 
> Comments? Does this look reasonable?

I think that from 1.0 format, a use case is still broken with that
approach:
 - build a package
 - install its binaries
 - check the behaviour is the same as with the package in the archive
   (i.e. rebuilding doesn't fix the issue magically)
 - hack hack hack
 - debuild|dpkg-buildpackage -b -nc
 → oh, files were patched/unpatched/changed, you get to rebuild a lot
   of things, instead of just the relevant files

Unfortunately I come empty-handed, but I wanted to mention that use
case anyway.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: consolekit makes trouble

[Simon McVittie]

On Sun, 29 May 2011 at 10:08:23 +0200, Hans-J. Ullrich wrote:
> kdm: :0[21175]: Cannot open ConsoleKit session: Unable to open session: 
> Failed 
> to execute program /usr/lib/dbus-1.0/dbus-daemon-launch-helper: Succes

Reinstall the package that owns that file (which is "dbus"). If that doesn't
help, check that it has the right permissions and ownership:

-rwsr-xr-- 1 root messagebus 48192 Apr 27 16:53 
/usr/lib/dbus-1.0/dbus-daemon-launch-helper

(size/date may vary depending on architecture)

We've seen problems where dbus-daemon-launch-helper mysteriously lost its
setuid bit as a result of filesystem trouble.

S


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110529105333.ga23...@reptile.pseudorandom.co.uk

Re: Bug#621833: System users: removing them

[Roger Leigh]

On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > I second your original proposal though, that packages must not delete
> > > system users that they have created.  I don't think anyone had objections
> > > to that, and the question is whether things should be taken further.
> > 
> > I do object to telling maintainers they must not delete system users,
> > without also giving guidance on how and when to lock the accounts.
> 
> Yes, I agree with this.
> 
> > Sorry, no time at the moment to propose verbiage to reconcile this with your
> > concerns.
> 
> I think the right thing to do would be to have deluser lock (rather
> than delete) system users when invoked in the way currently used by
> maintainer scripts.  Provided that doesn't make interactive use of
> deluser break somehow.

I've been looking at how this might be accomplished right now, and
have these observations to make.  (These are WRT my addition and
removal of the "sbuild" user in the sbuild package.)

1) Locking on removal.

  This is as simple as doing (in postrm)

# Lock sbuild account.
usermod -U -e 1 sbuild

However, one does now need to consider how "unlocking" will occur
if the package is reinstalled, which I don't think has been covered
as yet:

2) Reinstallation.

   I'm currently using this logic (in postinst)

 # Create dedicated sbuild user
 if ! getent passwd sbuild > /dev/null; then
 adduser --system --quiet --home /var/lib/sbuild --no-create-home \
 --shell /bin/bash --ingroup sbuild --gecos "Debian source builder" 
sbuild
 fi

  However, consider that if the account is locked, the user already
  exists and no unlocking will occur, leaving the reinstalled
  package broken.  This logic is common to many packages.

  I've added this after the above to unlock if locked:

# Unlock account in case it was locked from previous purge.
usermod -U -e '' sbuild

  This appears to reverse the locking, via inspection of the
  shadow record.  However, "" isn't documented as a valid
  value for EXPIRE_DATE (it's the default in /etc/default/useradd
  though).

Given the need to consider unlocking as well as locking, I'm not sure
it's worth adding special support to deluser: the typical logic used
to create the user will be insufficient to unlock, so it's no less
the effort to add an explict unlock/lock to the maintainer scripts,
dropping use of deluser entirely.

I do agree that a --local option would be a valuable and useful
addition to the adduser and deluser etc. tools, even if currently
a no-op.  However, due to the above I don't think that adding
special-case user locking to deluser is the correct course of action.


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.


signature.asc
Description: Digital signature

Re: Bug#621833: System users: removing them

[Roger Leigh]

On Sun, May 29, 2011 at 12:04:35PM +0100, Roger Leigh wrote:
> On Sun, May 01, 2011 at 03:06:00PM +0100, Ian Jackson wrote:
> > Steve Langasek writes ("Re: Bug#621833: System users: removing them"):
> > > On Tue, Apr 12, 2011 at 09:31:47PM +0200, sean finney wrote:
> > > > I second your original proposal though, that packages must not delete
> > > > system users that they have created.  I don't think anyone had 
> > > > objections
> > > > to that, and the question is whether things should be taken further.
> > > 
> > > I do object to telling maintainers they must not delete system users,
> > > without also giving guidance on how and when to lock the accounts.
> > 
> > Yes, I agree with this.
> > 
> > > Sorry, no time at the moment to propose verbiage to reconcile this with 
> > > your
> > > concerns.
> > 
> > I think the right thing to do would be to have deluser lock (rather
> > than delete) system users when invoked in the way currently used by
> > maintainer scripts.  Provided that doesn't make interactive use of
> > deluser break somehow.
> 
> I've been looking at how this might be accomplished right now, and
> have these observations to make.  (These are WRT my addition and
> removal of the "sbuild" user in the sbuild package.)
> 
> 1) Locking on removal.
> 
>   This is as simple as doing (in postrm)
> 
> # Lock sbuild account.
> usermod -U -e 1 sbuild

Oops, should of course be "usermod -L -e 1 sbuild"

-- 
  .''`.  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.


signature.asc
Description: Digital signature

DEP-5 format definition hell

[Sven Hoexter]

Hi,
I currently see a wild mix of different format definitions used by people
hitting debian-mentors. While I personally don't care as long as
the copyright file is complete I don't think this fulfills the goal of
this DEP.

It would be nice if the involved people would clarify what should be
used. So far I've seen the following referenced:

a) SVN revisions of the mdwn file (seems to be ok)
b) http://dep.debian.net/deps/dep5/ (seems to be not that wrong but
   exactly this current document claims that a revision of the mdwn file
   should be used)
c) a wiki page (rejected that one, seems wrong to me)
d) broken links (obviously rejected)

TIA,
Sven
-- 
And I don't know much, but I do know this:
With a golden heart comes a rebel fist.
 [ Streetlight Manifesto - Here's To Life ]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529115729.GB18249@marvin

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Benjamin Drung]

Am Sonntag, den 29.05.2011, 10:53 +0200 schrieb Raphael Hertzog:
> Again to cope with the scenario explained at the start of this mail,
> once a user has made modifications we must ensure that they end up in a
> proper patch in debian/patches/. Right now this is entirely automatic,
> the generated patches take the form of
> debian/patches/debian-changes-.
> 
> Obviously this is a pretty poor name for a patch [...]

The file should end with .patch
(debian/patches/debian-changes-.patch) so that your favorite text
editor uses the correct highlighting.

-- 
Benjamin Drung
Debian & Ubuntu Developer


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

Bug#628482: ITP: libunicode-linebreak-perl -- UAX #14 Unicode Line Breaking Algorithm

[Emmanuel Bouthenot]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bouthenot 

* Package name: libunicode-linebreak-perl
  Version : 0.0.20110426
  Upstream Author : Hatuka*nezumi - IKEDA Soji 
* URL : http://search.cpan.org/dist/Unicode-LineBreak/
* License : GPL2+ or Artistic
  Programming Lang: C / Perl
  Description : UAX #14 Unicode Line Breaking Algorithm

 Unicode::LineBreak performs Line Breaking Algorithm described in Unicode
 Standards Annex #14 [UAX #14]. East_Asian_Width informative properties
 defined by Annex #11 [UAX #11] will be concerned to determin breaking
 positions.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110529121831.770.33127.report...@gendo.asyd.net

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Bernhard R. Link]

* Raphael Hertzog  [110529 10:53]:
> I see 2 ways to solve this:
> a/ detect the common VCS and make --unapply-patches the default in that
>case (but it would require a --no-unapply-patches for the people who
>keep the patches applied in their VCS)

I'd be very disappointed if the more consistent way of having patches
applied in vcs would be punished this way just because some 'majority'
uses their vcs like svn was still state of the art.

> b/ modify dpkg-source --before-build to keep a trace of the fact that
>it applied the patches (for example by creating
>.pc/dpkg-source-auto-applied) and in that case have dpkg-source
>--after-build unapply the patches so that we're back to a clean
>state after a succesful build.
>If the build fails, we'd keep the patches applied.

That sounds a bit better, but it adds even more magic to dpkg-source.
I really miss some way to express: "In this account, do not use magic.
If things are not correct and need fixing, tell me what is wrong and
abort so I'll never miss it." (Actually I'd prefer it as default and
only have it enabled by some options, but a way to globally disable
and turn them into hard errors would would be good enough[tm].)

> But it still happens that those patches are generated[1] when the maintainer
> did not expect any change at all. That's why we added the option
> --abort-on-upstream-changes for maintainers who never wants dpkg-source
> to auto-create a patch.

There is still no way to get this behaviour account-wide, is there?

> I wonder if I should not make this option the default and fail with an
> error messages suggesting that the maintainer should run "dpkg-source
> --record-changes" if he really wants to keep the current changes. It
> would also leave the diff around somewhere in $TMPDIR if the user wants
> to review it.

Sounds nice.

Bernhard R. Link


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110529124544.ga9...@pcpool00.mathematik.uni-freiburg.de

ICU 4.8 in experimental

[Jay Berkenbilt]

[I am not currently subscribed to debian-devel, so please CC me on any
response that I need to see.]

I have uploaded ICU 4.8 to experimental.  If you have a package that
depends on ICU, please try testing with this version.  I will coordinate
with the release team to upload to unstable as soon as possible.  Thanks.

-- 
Jay Berkenbilt 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529084644.3019965905.qww314159@soup

Re: Multiarch bootstrapping

[Juliusz Chroboczek]

> Currently there are still some outstanding issues before we can really
> start using multiarch.

Is there anything upstream maintainers should be doing in order to help?
(Except writing makefiles that allow easy cross-compilation, of course.)

-- Juliusz


pgpmIaWRYiIGs.pgp
Description: PGP signature

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Goswin von Brederlow]

Cyril Brulebois  writes:

> Hi,
>
> Raphael Hertzog  (29/05/2011):
>> from time to time I hear some rumblings about how "3.0 (quilt)"
>> mixes badly with VCS. Indeed, one of the primary goals of the format
>> was to not require prior knowledge of the patch system to be able to
>> modify a package.
>
> thanks for trying to improve the situation.
>
>> b/ modify dpkg-source --before-build to keep a trace of the fact that
>>it applied the patches (for example by creating
>>.pc/dpkg-source-auto-applied) and in that case have dpkg-source
>>--after-build unapply the patches so that we're back to a clean
>>state after a succesful build.
>>If the build fails, we'd keep the patches applied.
>> 
>> My preference goes to b/ because it doesn't require changes for
>> people who like to keep the patches applied in their VCS too. And
>> it's the principle of least surprise, you keep the same state afer a
>> build than you had before the build (so it's still ok for people who
>> rely on the scenario unpack/hack/rebuild).
>> 
>> Comments? Does this look reasonable?
>
> I think that from 1.0 format, a use case is still broken with that
> approach:
>  - build a package
>  - install its binaries
>  - check the behaviour is the same as with the package in the archive
>(i.e. rebuilding doesn't fix the issue magically)
>  - hack hack hack
>  - debuild|dpkg-buildpackage -b -nc
>  → oh, files were patched/unpatched/changed, you get to rebuild a lot
>of things, instead of just the relevant files
>
> Unfortunately I come empty-handed, but I wanted to mention that use
> case anyway.
>
> Mraw,
> KiBi.

How is that? The default would still be that patches are applied, right?
So nothing would get unpatched in the default case.

For the case of having a VCS with patches unapplied you have conflicting
goals. You want the patches applied to keep rebuild minimal and
unapplied to be able to VCS commit without clean/unapply. You can't have
both. For that case I suggest using ccache. Or maybe a
"debuild|dpkg-buildpackage -b -nc --no-unapply"?

MfGGoswin


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h99y7c4.fsf@frosties.localnet

Re: Behaviour of dpkg-source with "3.0 (quilt)" and VCS and automatic patches

[Goswin von Brederlow]

Raphael Hertzog  writes:

> Hello,
>
> from time to time I hear some rumblings about how "3.0 (quilt)" mixes
> badly with VCS. Indeed, one of the primary goals of the format
> was to not require prior knowledge of the patch system to be able to
> modify a package. And it's the case since you can do:
> - dpkg-source -x
> - modify files
> - debuild
>
> But there are a few downsides:
>
> Auto-application of patches
> ---
>
> Since dpkg-source -x auto-applies the patch, the build part was
> designed with the assumption that patches are pre-applied and this
> assumption is often wrong for people using VCS. I have resolved this
> by auto-applying the patch at the start of a build but (some) users of VCS
> have been annoyed with it because it left the VCS unclean after the
> build. The option --unapply-patches has been added as a way to change
> the behaviour (and you can put it debian/source/local-options).

I really like that patches are applied by dpkg-source -x by default and
I hope you will keep it that way. If one finds a buggy package and wants
to check the source it is enough to apt-get source the package and load
the files into an editor to see what the actualy code is.

If patches weren't applied then you would first have to find out how to
apply them, just like with the myriad of patch systems in 1.0 format.

> I would like to improve this situation and not force the majority of
> people to add the unapply-patches option (if it turns out the majority
> of people use this option or are annoyed by the patches being applied).
>
> I see 2 ways to solve this:
> a/ detect the common VCS and make --unapply-patches the default in that
>case (but it would require a --no-unapply-patches for the people who
>keep the patches applied in their VCS)

The problem isn't that people use a VCS but that their workflow is based
on not having patches applied. There is also another group of people
that work with patches applied. Specifically when you have feature
branches and those branches merged into master. In that workflow you can
even exclude debian/patches/ from the VCS and generate it from the
branches.

I don't think you can automatically detect the workflow being used so
this option is a no-go.

> b/ modify dpkg-source --before-build to keep a trace of the fact that
>it applied the patches (for example by creating
>.pc/dpkg-source-auto-applied) and in that case have dpkg-source
>--after-build unapply the patches so that we're back to a clean
>state after a succesful build.
>If the build fails, we'd keep the patches applied.
>
> My preference goes to b/ because it doesn't require changes for people
> who like to keep the patches applied in their VCS too. And it's the
> principle of least surprise, you keep the same state afer a build than
> you had before the build (so it's still ok for people who rely
> on the scenario unpack/hack/rebuild).
>
> Comments? Does this look reasonable?

I would go one step further. Instead of recording wether you apply
patches or not record what patch the source is on before build. One
might be working on a patch halfway down the patch queue, run quilt
refresh, debuild -b -nc. That should return the working dir to the patch
it was before the build.

> Automatic patches
> -
>
> Again to cope with the scenario explained at the start of this mail,
> once a user has made modifications we must ensure that they end up in a
> proper patch in debian/patches/. Right now this is entirely automatic,
> the generated patches take the form of
> debian/patches/debian-changes-.
>
> Obviously this is a pretty poor name for a patch and given it's
> automatically generated, it doesn't contain much useful description.
> In general they are renamed by the maintainer who also adds a
> description (or they are properly put in place before the build so that
> dpkg-source doesn't have to create it).
>
> But it still happens that those patches are generated[1] when the maintainer
> did not expect any change at all. That's why we added the option
> --abort-on-upstream-changes for maintainers who never wants dpkg-source
> to auto-create a patch.
>
> I wonder if I should not make this option the default and fail with an
> error messages suggesting that the maintainer should run "dpkg-source
> --record-changes" if he really wants to keep the current changes. It
> would also leave the diff around somewhere in $TMPDIR if the user wants
> to review it.
>
> It would break the initial scenario but since the solution is given in the
> error message, I believe it would be acceptable.
>
> "dpkg-source --record-changes " would be an interactive command
> because you would be asked to fill the patch description header.

(In case you have a tty:) Instead of giving an error why not ask for the
patch name and abort on empty name?

> We still have the case of people who keep all their changes in the VCS
> without maintaining debian/patches/ and who uses --single-d

Re: Alioth status update, take 3

[Roland Mas]

Yaroslav Halchenko, 2011-05-23 22:39:48 -0400 :

> on a related note (although not as critical as restoration of
> git://git.d.o which I expect to impact  thousands:
>
> $> grep git:// 
> /var/lib/apt/lists/debian.lcs.mit.edu_debian_dists_sid_main_source_Sources | 
> wc -l
> 3716
>
> )
>
> where previously available could be now?
> http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file
>
> both
> http://anonscm.debian.org/viewvc/dep/
> http://anonscm.debian.org/viewvc/deps/
> seems to be empty
>
> ?
>
> Thanks in advance for clarifications

  Since the same tool (ViewVC) is used both for CVS and Subversion
repositories, and it operates on repository names, a Subversion
repository can be masked by a CVS repository of the same name.  In olden
times, every non-CVS repository had to be created by hand, because the
forge software didn't handle them, so a lot of projects got a CVS
repository even if they never actually used it; so there were lots of
empty CVS repositories, potentially masking Subversion ones.

  I removed those empties, so that problem shouldn't happen anymore.
(I'm offline as I write this email though, so I can't check for the
specific instances you wrote about.)

Roland.
-- 
Roland Mas

...sur un portable, quelque part dans le monde...
...on a laptop, somewhere in the world...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87wrh9bpu5@elastomir.internal.placard.fr.eu.org

Re: Multiarch bootstrapping

[Andreas Metzler]

Luk Claes  wrote:
> Currently there are still some outstanding issues before we can really
> start using multiarch. You can find the status at the wiki page [1].

> It seems that the main blocker at the moment is bug #618288 in apt.

> Please help to fix the outstanding bugs for the build tools (pmake,
> freebsd-buildutils, cmake) and apt so we can start using multiarch!
[...]

Just as a reminder: After the infrastructure is set up, multiarch
conversion will be blocked by packages shipping libtool files with
nonempty dependency_libs. - The libtool files contain absolute paths.

cu andreas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/oo3ab8-vm3@argenau.downhill.at.eu.org

Re: Multiarch bootstrapping

[Luk Claes]

On 05/29/2011 05:02 PM, Andreas Metzler wrote:
> Luk Claes  wrote:
>> Currently there are still some outstanding issues before we can really
>> start using multiarch. You can find the status at the wiki page [1].
> 
>> It seems that the main blocker at the moment is bug #618288 in apt.
> 
>> Please help to fix the outstanding bugs for the build tools (pmake,
>> freebsd-buildutils, cmake) and apt so we can start using multiarch!
> [...]
> 
> Just as a reminder: After the infrastructure is set up, multiarch
> conversion will be blocked by packages shipping libtool files with
> nonempty dependency_libs. - The libtool files contain absolute paths.

Probably just a coincidence that I mailed debian-devel about nonempty
dependency_libs about a week ago ;-)

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de26496.5050...@debian.org

Lintian auto-rejects

[Michael Meskes]

I received an auto-reject because of a lintian error message that, as my system
says, is correctly overridden. Could anyone please tell me which lintian
version we use to determine auto-rejection and also which lintian version we're
supposed to prepare overrides for?

Should the version be the same, I surely have to figure out what else is
running afoul here.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529153124.ga1...@feivel.credativ.lan

Re: Lintian auto-rejects

[Niels Thykier]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-05-29 17:31, Michael Meskes wrote:
> I received an auto-reject because of a lintian error message that, as my 
> system
> says, is correctly overridden. Could anyone please tell me which lintian
> version we use to determine auto-rejection and also which lintian version 
> we're
> supposed to prepare overrides for?
> 
> Should the version be the same, I surely have to figure out what else is
> running afoul here.
> 
> Michael

Hi

As far as I know, the FTP masters still use 2.4.3 (before the leading
"/" and "./" was removed from file names and before the merge of
embedded-$lib -> embedded-library).

~Niels


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

iQIcBAEBCAAGBQJN4mcMAAoJEAVLu599gGRCQacP+wR5Gfc4SBN6iwy1Z6p2F5eo
7ZGyfeFrVSJ8rHQLHMXKcd7gT4mm4qhr+mOeAY1dhRTpdILNAi+cAB6cEMDORiUZ
vZOsEBFK9ClJw8CECxrteicO2oNb2DsiwQc47sPyOova/LnpQOVoGmtRVy00d4gx
2AONPaL/m6wgpPP0Z6RAso24bnicg6jzFpXR9erMdBKUMdSOrD8jyDTowvtUDBeo
ikRduNe1VPLKwyJrSA2YOR2euEB/AWeFWb5FF6V9wrhSqS+pcRdn9hhg6z8mJFAt
4ndNtP9Moze2ABXrzvELtsrI9Rbywutw8uyInGy6GGWe601ptB/O3buCKLc/08Fu
MKlVSQE/SzcsMYHQKdYMgoaeJxd3Ap01ErjiRmsmLulIv3nEfMaPVwFUGw2P2JtC
SgPOQ7MFjN8RvAnUblsgv8YAk8JtQPErOnLV0eQRLpjXEupfUdDTQRnOgYyCsHqm
6brIvWlKfnYfvkUepusFywtClal0WE8qZN1ViFbMCohRM5rC8x+PJ7rg3vr+A64v
Lls58qIa6lFcPE6kxVNu2slgIfPcQASW4qeGnWJ1DxrjbJXYV55PG9WcIH3uIUaK
6CLyRZePV/vMSswBCsbQ64OO/gVSSQDd6UMPT/DPJUTJ6qZBHKPJCC23ZbNL/CQU
zQV5OdUgSChy4RgeOyfr
=pZbn
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de26712.5040...@thykier.net

Synching packaging-dev with Developers' Reference (Re: packaging-dev meta package)

[Osamu Aoki]

Hi,

I understand intent is a good one but the proposed list seems not so
well thought though.  Unless inclusion criteria is clearly defined, it
becomes just another random bloated list of packages.

My first reaction was that, if we are to have such package, we just need
to depends on build-essential and devscripts.  So why cdbs and
bzr-builddeb were listed there when I do not see devscripts and
git-buildpackage.   like others already posyed here.

I looked into Debian policy and developers-reference just to be sure.
Then, I realized that it may be a good idea to make a longer list of
packages for packaging as long as it is properly maintained together with
the list in the developers-reference APPENDIX.

Here is how I came to this conclusion.

Per policy: 4.2 Package relationships we all install build-essential
package:

Depends: libc6-dev | libc-dev, gcc (>= 4:4.4.3), g++ (>= 4:4.4.3), make,
 dpkg-dev (>= 1.13.5)

Adding Recommends/Suggests to build-essential may serve similar purpose
but may not be the right place.

There are another list in Developers reference "Appendix A. Overview of
Debian Maintainer Tools".  There, quite a bit of packages are listed for
each purpose.

Anyway, all DD should have read these and installed packages and
installed pertinent dependency packages.  "devscripts" is one of it and
that includes many dependency.  So they had good packages on their
system.

On Thu, May 26, 2011 at 10:05:42PM +0200, Benjamin Drung wrote:
> Hi,
> As a starting point packaging-dev would depend on
> 
> build-essential

Yes. But the rest seems too arbitrary.

> quilt
> debhelper
> cmake
> autoconf
> cdbs
> bzr-builddeb
> apt-file
> ubuntu-dev-tools (only on Ubuntu systems)

If this kind of list to be maintainable, I think it is good idea to be
packaged by the same party as the best practice document maintainer .., 
i,e, developers-reference using its content.  Then having such package
may have some reason.

For example, list should be more like:

Depends: build-essential
Recommends: and Suggests:
 Chose from list all the tools in Developers' reference Appendix.
 If needed, update document too.  Most of them should be "Suggests".

A.1.1. dpkg-dev (not needed since build-essential)
A.1.2. debconf
A.1.3. fakeroot
A.2.1. lintian (good candidate for Recommends)
A.2.2. debdiff
A.3.1. debhelper   (good candidate for Recommends)
A.3.2. dh-make
A.3.3. yada(maybe as dh-make|yada)
A.3.4. equivs  (This pulls in debhelper)
A.4.1. cvs-buildpackage
  (Here, git-buildpackage may needs to be added soon.)
A.4.2. debootstrap
A.4.3. pbuilder
A.4.4. sbuild
A.5.1. dupload
A.5.2. dput
A.5.1. dupload
A.5.2. dput (A.5.3. dcut)
A.6.1. devscripts   (good candidate for Recommends)
A.6.2. autotools-dev 
 (autoconf and automake are mentioned but cmake is not mentioned
 This may be a section to ask update to include cmake.)
A.6.3. dpkg-repack
A.6.4. alien
A.6.5. debsums
A.6.6. dpkg-dev-el
A.6.7. dpkg-depcheck
A.7.1. quinn-diff
A.7.2. dpkg-cross
A.8.1. docbook-xml
A.8.2. debiandoc-sgml  (Maybe not in suggests since it is deprecated.)
A.8.3. debian-keyring
A.8.4. debian-maintainers
A.8.5. debview
 
By making these 2 things linked, we have trackable rationale.
Otherwise, we will have badly maintained suggestions.

> Do you like the idea or not? Do you have a better name for the meta
> package? Should something added to or removed from the dependency list?

Please note that devscripts almost serves as a list of such de facto
list on Debian.   Many debated choices are already included there as
Recommends or Suggests and may have been pulled in against your will :-).

Recommends: at, curl | wget, dctrl-tools, debian-keyring, debian-maintainers,
dput | dupload, equivs, fakeroot, gnupg, libauthen-sasl-perl,
libcrypt-ssleay-perl, libparse-debcontrol-perl, libsoap-lite-perl,
libterm-size-perl, libtimedate-perl, liburi-perl, libwww-perl,
libyaml-syck-perl, lintian, lsb-release, bsd-mailx | mailx, man-db,
patch, patchutils, quilt, ssh-client, strace, unzip, wdiff,
www-browser, subversion | cvs | darcs | tla | bzr | git-core |
mercurial, lzma, xz-utils, sensible-utils, libjson-perl
Suggests: build-essential, cvs-buildpackage, devscripts-el, gnuplot,
  libfile-desktopentry-perl, libnet-smtp-ssl-perl (>= 1.01-2), mutt,
  svn-buildpackage, w3m

(Here I see some needs to update such as git-core -> git, ... too.)

I know we do not need debhelper nor quilt to make package.  But most
of us use them.  Having some list to pull these highly recommended
packages as recommends may be good idea as long as they are well
maintained.

Please note that developers-reference is maintained as group in very
methodical way.  The maintenance of this kind of list belongs to such
group.

Regards,

Osamu

PS: I have recently updated developer package list for novice developer
in "Debian New Maintainers' Guide". 
  http://www.debian.org/doc/man

Re: Lintian auto-rejects

[Luk Claes]

On 05/29/2011 05:31 PM, Michael Meskes wrote:
> I received an auto-reject because of a lintian error message that, as my 
> system
> says, is correctly overridden. Could anyone please tell me which lintian
> version we use to determine auto-rejection and also which lintian version 
> we're
> supposed to prepare overrides for?
> 
> Should the version be the same, I surely have to figure out what else is
> running afoul here.

Not all of the rejections are weak rejections you can override:

http://ftp-master.debian.org/#rejections

Cheers

Luk


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de267bf.1040...@zomers.be

Re: DEP-5 format definition hell

[Lars Wirzenius]

On Sun, May 29, 2011 at 01:57:29PM +0200, Sven Hoexter wrote:
> I currently see a wild mix of different format definitions used by people
> hitting debian-mentors. While I personally don't care as long as
> the copyright file is complete I don't think this fulfills the goal of
> this DEP.

This is because DEP5 is not finalized yet. When its inclusion into
the debian-policy package is final, the official copy of the spec
will be at a URL that will be like this:

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

When this is ready, there will be an announcement on debian-devel-announce
and every other Format: URL will need to be amended. Until then,
use whatever you feel best like. The spec suggests something like this:

http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=REVISION

which seems like a reasonable thing to do, since it documents what
version of the spec the file is written against.

-- 
Freedom-based blog/wiki/web hosting: http://www.branchable.com/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529155332.ga18...@havelock.liw.fi

Re: Alioth status update, take 3

[Andrew Starr-Bochicchio]

On Mon, May 23, 2011 at 4:35 PM, Roland Mas  wrote:
> - repository browsers for the major SCM tools are also available from
>  wagner, see http://anonscm.debian.org/ for the links.

There seems to be an issue with loggerhead (the VCS browser for bzr).
Some repositories show up, but not all. Notably, collab-maint seems to
not be available. Compare what can be seen on loggerhead
 with what exists on vasks.d.o
.

Thanks for all your work on this transition,

-- Andrew Starr-Bochicchio

   Ubuntu Developer 
   Debian Contributor

   PGP/GPG Key ID: D53FDCB1


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktik7gpm07mpldfkg6lixo8ynm_a...@mail.gmail.com

Re: System users: removing them

[Jonathan Nieder]

(culled cc list of a few people I know read -devel)
Roger Leigh wrote:

> Given the need to consider unlocking as well as locking, I'm not sure
> it's worth adding special support to deluser: the typical logic used
> to create the user will be insufficient to unlock, so it's no less
> the effort to add an explict unlock/lock to the maintainer scripts,
> dropping use of deluser entirely.

The obvious question then would be whether it's worth adding special
support to deluser *and* adduser, no?

I don't have an answer in mind, though the lazy person in me would
like it to work.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529170940.GA6574@elie

Re: DEP-5 format definition hell

[Thomas Goirand]

On 05/29/2011 11:53 PM, Lars Wirzenius wrote:
> On Sun, May 29, 2011 at 01:57:29PM +0200, Sven Hoexter wrote:
>   
>> I currently see a wild mix of different format definitions used by people
>> hitting debian-mentors. While I personally don't care as long as
>> the copyright file is complete I don't think this fulfills the goal of
>> this DEP.
>> 
> This is because DEP5 is not finalized yet. When its inclusion into
> the debian-policy package is final, the official copy of the spec
> will be at a URL that will be like this:
>
> http://www.debian.org/doc/debian-policy/copyright-format/1.0
>
> When this is ready, there will be an announcement on debian-devel-announce
> and every other Format: URL will need to be amended. Until then,
> use whatever you feel best like. The spec suggests something like this:
>
> http://svn.debian.org/wsvn/dep/web/deps/dep5.mdwn?op=file&rev=REVISION
>
> which seems like a reasonable thing to do, since it documents what
> version of the spec the file is written against.
>   
I think it'd be great if what you wrote above was also at:

http://dep.debian.net/deps/dep5/

Cheers,

Thomas

P.S: What's blocking DEP5 from reaching the policy?
I think it's great the way it is right now already...


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4de27cbe.8030...@debian.org

Re: Lintian auto-rejects

[Michael Meskes]

On Sun, May 29, 2011 at 05:35:27PM +0200, Luk Claes wrote:
> Not all of the rejections are weak rejections you can override:
> 
> http://ftp-master.debian.org/#rejections

Right, but my one is listed as nonfatal and the email even said I should
override if I need this.

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529175138.ga6...@feivel.credativ.lan

Re: Lintian auto-rejects

[Michael Meskes]

> As far as I know, the FTP masters still use 2.4.3 (before the leading
> "/" and "./" was removed from file names and before the merge of
> embedded-$lib -> embedded-library).

Right, this is wha I expected as the source of the problem. Is there a reason
why the system uses an older version? Are we supposed to add both ways of
writing the overrides?

Michael
-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529175241.gb6...@feivel.credativ.lan

Re: DEP-5 format definition hell

[Russ Allbery]

Thomas Goirand  writes:

> P.S: What's blocking DEP5 from reaching the policy?
> I think it's great the way it is right now already...

It's already in the Policy package and was aging there for one release to
be sure we didn't mess anything up when rewriting it to DocBook.  Please
review the version currently included in the debian-policy package and
report any issues.  The intention is to make it "official" with the next
Policy release (where "official" of course doesn't mean that people are
required to use it).

-- 
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
Archive: http://lists.debian.org/87k4d91j9u@windlord.stanford.edu

Re: Lintian auto-rejects

[Russ Allbery]

Michael Meskes  writes:

>> As far as I know, the FTP masters still use 2.4.3 (before the leading
>> "/" and "./" was removed from file names and before the merge of
>> embedded-$lib -> embedded-library).

> Right, this is wha I expected as the source of the problem. Is there a
> reason why the system uses an older version?

I suspect just lack of time plus the fact that 2.5.0 was a release
candidate until recently.

> Are we supposed to add both ways of writing the overrides?

For right now, that's probably the easiest thing to do.

-- 
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
Archive: http://lists.debian.org/87fwnx1j80@windlord.stanford.edu

Re: Synching packaging-dev with Developers' Reference (Re: packaging-dev meta package)

[Raphael Hertzog]

On Mon, 30 May 2011, Osamu Aoki wrote:
> I looked into Debian policy and developers-reference just to be sure.
> Then, I realized that it may be a good idea to make a longer list of
> packages for packaging as long as it is properly maintained together with
> the list in the developers-reference APPENDIX.

I disagree, the appendix of the developers-reference has really grown
somewhat arbitrarily and has not been correctly maintained over time.

The fact that the developers reference is maintained by a group doesn't
make it perfect. And I certainly don't see a compelling reason to require
that this new meta-package be maintained by the editors of the developers
reference.

> A.3.3. yada(maybe as dh-make|yada)

This alone proves my point. :-)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Follow my Debian News ▶ http://RaphaelHertzog.com (English)
  ▶ http://RaphaelHertzog.fr (Français)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529191837.gb22...@rivendell.home.ouaza.com

Re: Bug#621833: System users: removing them

[Roger Leigh]

On Sun, May 29, 2011 at 12:09:40PM -0500, Jonathan Nieder wrote:
> (culled cc list of a few people I know read -devel)
> Roger Leigh wrote:
> 
> > Given the need to consider unlocking as well as locking, I'm not sure
> > it's worth adding special support to deluser: the typical logic used
> > to create the user will be insufficient to unlock, so it's no less
> > the effort to add an explict unlock/lock to the maintainer scripts,
> > dropping use of deluser entirely.
> 
> The obvious question then would be whether it's worth adding special
> support to deluser *and* adduser, no?

We could add special behaviour to adduser to unlock the account
if it already exists when run in the postinst.  However, most
postinsts wrap the call to adduser with a check for whether the
account already exists, so it would not be called without an
update to every preinst employing this strategy.  It would also
alter the existing behaviour of adduser, which is to return nonzero
if the user already exists, which could cause breakage.

I dislike the fact that the behaviour of adduser and deluser would,
in effect, /not/ add or delete users as intended, which is rather
counter-intuitive.  Providing that we have consensus on a recommended
strategy for locking and unlocking accounts which can go into policy,
I think all we need are examples for how maintainer scripts are
expected to handle account creation and locking/unlocking.


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.


signature.asc
Description: Digital signature

Re: System users: removing them

[Jonathan Nieder]

Roger Leigh wrote:

> We could add special behaviour to adduser to unlock the account
> if it already exists when run in the postinst.  However, most
> postinsts wrap the call to adduser with a check for whether the
> account already exists, so it would not be called without an
> update to every preinst employing this strategy.

Ah, that's the piece I had forgotten about (and I should have thought
more clearly about it; sorry about that).  Thanks for explaining.

> Providing that we have consensus on a recommended
> strategy for locking and unlocking accounts which can go into policy,
> I think all we need are examples for how maintainer scripts are
> expected to handle account creation and locking/unlocking.

Makes sense, of course.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529194311.GB14141@elie

Bug#628528: ITP: aspell-sr -- Aspell dictionary for Serbian language

[Filip Brcic]

Package: wnpp
Severity: wishlist
Owner: Filip Brcic 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


* Package name: aspell-sr
  Version : 0.02
  Upstream Author : Goran Rakic 
* URL : http://srpski.org/aspell/
* License : LGPL
  Description : Aspell dictionary for Serbian language

Serbian dictionary for the aspell spell-checker package

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBAgAGBQJN4qkZAAoJEPH9x+slN8N5muMP/0LXAcZZ6q+/Q4ss6HNGqrho
p5rQcBaPEZiszxIOB/udR8d86/fJ7kd06JY3OgLTDtm1c2cVTBjMqhe/Ckf680Vh
xUepOD7Hvf572TAk37gAwrZsFLts3IOqOVs+QUkKzz1ZeBNSxOKZWuQFSgD4Ljmg
aJ+0fMs7eL/kibBh5PpXnfqYbBs3K+yygpoqhdFJ9C/gp4QOJSPkeZnHNZBJpN6B
caRZOE6LaSb5EF/FNMc1ASLFa3XzjMa+rhuA4Rjmd2s9n2H6N2SnfFwxqfn377gq
vUgccPyiun0joSo4GCHYVloOFqZgZQhy3v3o7HDcaJo/lS7Yr15z6N9FPpL08XRj
+w3alQn6kb9buHp3bf+uj/6IKJNKjyYOduO5N53osjV5cY4MulTMBwSd5ilfndxt
4zKX17P0ZN7UMjmd+H6ArQxsLLZhPEyJk/nuzQqyQkm4Dona3WD2IfWK6Ub4XQQA
b5X4E3Q6TIsmMk2oSLbTH4fVVA1q5wakkyuc7tPzI68KtVZd68L4Z5pIYBtSrr7d
5FnTCJ2XUqkVdhEVqWp6YSC7JmZsSIY9zb3ZiPJ8uV2bZuc9OSPkmbfv846iAw4f
uEcJ0XWqlv7f35X4+ZhrOnvAyHdi1jce3jbt5ra9UdxLCfOEq5H6Sg/psR1QR9my
FzH6ccgo+5Dy3qmeUd1g
=tmAV
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110529201424.10826.70647.reportbug@perun

Re: Multiarch bootstrapping

[Steve Langasek]

On Sat, May 28, 2011 at 04:06:28PM +0200, Luk Claes wrote:
> On 05/28/2011 03:32 PM, David Kalnischkies wrote:
> > On Sat, May 28, 2011 at 14:48, Luk Claes  wrote:
> >> It seems that the main blocker at the moment is bug #618288 in apt.

> > Fixed in branch for a while, just not yet uploaded. [0]

> > But it can't be a blocker as dpkg doesn't has full support for multiarch
> > in unstable currently - and if you can't install foreign packages its pretty
> > unlikely that you will hit this bug. ;)

> Can you please point me to the bug that still needs to be fixed in dpkg
> to be able to install foreign packages?

dpkg cross-install support has not yet been merged into dpkg mainline at
all.  We have a clear roadmap for modifying library packages that will let
them be usable in a multiarch context as soon as dpkg support is there, but
there's no bug report for dpkg since it's a pending feature merge.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#628548: ITP: r-bioc-limma -- linear models for microarray data

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

  Package name: r-bioc-limma
  Version : 3.8.2
  Upstream Author : Gordon Smyth 
  URL : http://bioinf.wehi.edu.au/limma/
  License : GPL, LGPL
  Programming Lang: R, C
  Description : linear models for microarray data

 A Bioconductor package for the analysis of gene expression microarray data,
 especially the use of linear models for analysing designed experiments and the
 assessment of differential expression. The package includes pre-processing
 capabilities for two-colour spotted arrays. The differential expression methods
 apply to all array platforms and treat Affymetrix, single channel and two
 channel experiments in a unified way.

r-bioc-limma is needed to package edgeR (r-bioc-edger), which is quite popular
for the analysis of high-throughput transcriptome sequencing experiments.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20110530050649.16986.1568.reportbug@localhost.localdomain