Re: More Vcs-Fields in debian/control?

[Vincent Bernat]

OoO En  cette aube naissante  du jeudi 07  avril 2011, vers  07:46, Joey
Hess  disait :

>> We (lindi, liw and me) had just a short discussion in #-devel, that it
>> would be nice to have some sort of Vcs-Upstream-* in debian/control, to
>> be able to get to upstreams vcs history if it is not imported in
>> debian's vcs (which is often the case when using svn-bp or git-bf with
>> import-orig). [background: lindi is doing some git-copyright checks and
>> it fails heavily if there is no upstream history as the debian
>> maintainer is asumed to be the copyright holder for everything]

> I would instead suggest we deprecate packages not including upstream
> source in their VCS. The weight of progress is against that practice;
> tools have improved so there is little excuse to do it, it increasingly
> violates expections and makes things harder.

> Some examples:

> * git cherry-pick cannot be used
> * pristine-tar cannot be used
> * apt-get source now suggests running debcheckout when VCS fields are
>   present. But for such a package, debcheckout won't result in the same
>   source tree as does apt-get source.

> Adding baroque complications to the VCS fields doesn't deal with these
> problems consistently, and while it might help this style of VCS use
> linger a while longer, it will be an unnecessary complication going
> forward.

Large SVN  repositories containing only debian/  directories are already
quite slow (at  least on alioth). Adding upstream  sources (and history)
would not improve this part.

Moreover, do we have space to cope with this?
-- 
I AM NOT MY LONG-LOST TWIN
I AM NOT MY LONG-LOST TWIN
I AM NOT MY LONG-LOST TWIN
-+- Bart Simpson on chalkboard in episode 4F03


pgp3JGLhwZXHe.pgp
Description: PGP signature

Re: Moving bash from essential/required to important?

[Philip Hands]

On Wed, 06 Apr 2011 16:37:28 +0100, Lars Wirzenius  wrote:
...
> Obviously, checkbashisms is not infallible, so the numbers may well be
> off. If I remove all the "not bash" scripts from bash2.list, I get a
> much shorter file: http://files.liw.fi/temp/bash2-isbash.list
> 
> Summary:
> 
> 1775 files
> 621 packages
...
> Obviously, doing these changes earlier rather than later in the release
> cycle would be good, if they are to be done at all.
> 
> Opinions?

I think you've demonstrated exactly why we should do this -- at present,
since bash is essential, it would seem that many people have decided
that it's easiest to just use /bin/bash for their scripts, regardless of
whether they need it or not, which is fine on a full blown Debian system
but creates a lot of unnecessary work for EmDebian folks.

It wouldn't surprise me if the need to add a bash dependency would
provoke many of the developers of the packages in question to reexamine
those scripts, realise that in many cases they could be trivially
POSIX-ised, and so reduce that number further.  That'll not happen if we
don't make bash non-essential.

On the other hand, my perspective is that of a crusty old git who had to
port stuff to all sorts of not-quite-POSIX systems for years, so I may
just be having a "youngsters need to be taught proper discipline" moment ;-)

Cheers, Phil.
-- 
|)|  Philip Hands [+44 (0)20 8530 9560]http://www.hands.com/
|-|  HANDS.COM Ltd.http://www.uk.debian.org/
|(|  10 Onslow Gardens, South Woodford, London  E18 1NE  ENGLAND


pgpAyDXO3LmrE.pgp
Description: PGP signature

Re: More Vcs-Fields in debian/control?

[Charles Plessy]

Le Wed, Apr 06, 2011 at 10:53:55PM -0700, Russ Allbery a écrit :
> 
> However, is the control file really the right place for that?  I guess we
> don't have a better place right now, but this doesn't feel like package
> metadata that needs to be put into the Sources file.

Hi,

there is my pet project about upstream metadata:

http://wiki.debian.org/UpstreamMetadata

The key concept is to store ‘Field: value’ data in a file called
debian/upstream-metadata.yaml, and to access it from the VCS where
the package is stored (that is, not from the source package itself).

This allows:

 - To update the data without uploading the package;
 - to distribute a reasonnably up-to-date copy with our source packages.

I have not yet found time to push for finishing the proof of principle, which
is to collect bibliographic information for the Blends websites through that
system via the UDD, but it would be straightforward to use it right now for
packages managed in Git and Subversion.  Adding support for other VCSes should
be trivial.  For packages that are not managed in a VCS, I think that the most
realistic solution would be to maintain the metadata in a special flat file on
collab-maint. (And I also support deprecating the non-use of VCS for managing
source packages).

The biggest difficulty would be to agree on field names.  The best would be to
be compatible with some pre-existing RDF ontologies, like DOAP.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan


-- 
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/20110407081113.gd9...@merveille.plessy.net

Re: More Vcs-Fields in debian/control?

[Paul Wise]

On Thu, Apr 7, 2011 at 1:46 PM, Joey Hess  wrote:

> I would instead suggest we deprecate packages not including upstream
> source in their VCS. The weight of progress is against that practice;
> tools have improved so there is little excuse to do it, it increasingly
> violates expections and makes things harder.

As someone who works in pkg-games where upstreams commonly include
non-free material, many embedded code copies and hundreds of megabytes
of data, I don't agree with this.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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/BANLkTinm=81avi6qtfwyjjvp_ybgw+k...@mail.gmail.com

Bash-completion with triggers

[David Paleino]

Hello everybody,
I've implemented a new revision of bash-completion, which uses debtriggers(5)
to load only relevant completions, and symlink them when something
touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so on.

For this to work, the completions have been moved out from /etc/ -- they would
be in /usr/share/bash-completion/completions/, but /etc/bash_completion.d/ is
being kept not to break tons of other packages installing files there.

However, I'm writing to get comments about the triggers issue. When a package
installs an executable in one of the above directories, bash-completion's
postinst removed all symlinks in /etc/bash_completion.d/triggered/, and
re-creates them. The speed of such operation varies greatly depending on the
installed packages -- on my system, it takes about 10s -- but the shell loading
seems much faster too.

Is there any objection to bash-completion using triggers to "watch" the
aforementioned directories?

I have a package ready, and would upload it to experimental before going
to unstable.

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Shipping /bin/sh [Re: Moving bash from essential/required to important?]

[Goswin von Brederlow]

Carsten Hey  writes:

> System shells would (de)register themselves by calling add-system-shell
> in postinst and remove-system-shell in prerm.  'system-shell' would also
> be a virtual package provided by bash, dash and so on.  Although I don't

How would that work with (c)debootstrap/multistrap when creating a
chroot for a foreign architecture? No maintainer script will be run in
those cases nor can they be run in general.

Some package needs to initially ship a /bin/sh binary or symlink, which
I would think dash should do (being the default sh). And the registering
in postinst could then later replace this with the proper mechanism
(which would still just be a symlink to dash by default I guess).

> think this would be a problem, using /bin/$SHELL in the shebang of
> postinst and prerm could prevent possible problems if /bin/sh changes
> whilst these scripts are running.

In postinst and prerem there is no problem in using /bin/$SHELL since
the shell is already/still present. But what about preinst and postrm?

We can probably assume there will allways be one system shell present so
/bin/sh for postrm is fine. But for preinst we are back to the above
problem. When bootstraping no postinst of any system shell has yet run
so there is no /bin/sh configure. Yet we still need one. Even using an
elf binary as preinst to create the initial /bin/sh link would be ugly
because then bootstraping tools (second stage) need the special
knowledge to run that first.

Which brings us back to the need for some (dash :) package to ship an
initial /bin/sh before the proper (de)registering mechanism takes over.

Please keep that in mind when designing it.

MfG
Goswin


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

Re: Bash-completion with triggers

[David Paleino]

Hello Goswin,
re-putting debian-devel in the loop, since I believe you forgot it.

On Thu, 07 Apr 2011 12:20:34 +0200, Goswin von Brederlow wrote:

> David Paleino  writes:
> 
> > Hello everybody,
> > I've implemented a new revision of bash-completion, which uses
> > debtriggers(5) to load only relevant completions, and symlink them when
> > something touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so
> > on.
> >
> > For this to work, the completions have been moved out from /etc/ -- they
> > would be in /usr/share/bash-completion/completions/,
> > but /etc/bash_completion.d/ is being kept not to break tons of other
> > packages installing files there.
> 
> Shouldn't they be in /var/?

The symlinks created by the trigger?
I'd tend to agree -- but what sub-hierarchy would be best? /var/run/ isn't kept
across reboots, so it's not suitable; /var/cache/ smells a bit (one is supposed
to be able to purge the cache whenever she wants); maybe
/var/lib/bash-completion?

> Both /etc and /usr are writable during package installation so it won't fail.
> But is /usr really the right place for this?

They won't be written to /usr/ -- they will be written to /etc/.

This is mostly because of backwards-compatibility: bash-completion has been
in /etc/ since ages, and users are used to find completions there. I'd like
to avoid changing the layout too much in a single step :). But, at a second
thought, /var/lib/ is really the best choice to me -- so maybe I'll just
document it and do the relevant changes.

Thanks for your input,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)

[Hendrik Sattler]

Zitat von Stanislav Maslovski :


On Wed, Apr 06, 2011 at 10:51:08PM +0200, Hendrik Sattler wrote:

Am Mittwoch 06 April 2011, 19:05:11 schrieb Stanislav Maslovski:
> > On Wed, Apr 06, 2011 at 07:29:05AM +0200, Josselin Mouette wrote:
> > > Then you can stack all soft of stuff on top of it, and get them to
> > > work manually for your specific setup, and since it’s not event-based
>
>  
>
> > > you have to hard-code the way your network is set up.
>
> ^^
> The underlined claims, btw, are also false.

You made clear that you think of yourself as the ultimate master of  
ifupdown.

So what? That tells us _nothing_ about the rest of the world...


First of all, that is only your interpretation which is wrong. Second,
there is no point in turning a discussion about ifupdown vs. NM into a
discussion of my abilities/disabilities.


I am also not totally happy about network-manager but I still use it  
as it gives me a working wireless network on my laptop without having  
to spend hours reading endless documentation and writing multiple  
configuration files (hey, just for the purpose of getting _one_  
network device running at two different locations!). Been there, done  
that for quite some time, with wired and wireless networking,  
analog/2G/3G modem and ISDN dialup. It was always a pain to setup and  
working if not too much goes wrong. Still I was switching to  
network-manager once available as for me it's not painless but much  
less pain.


I remember one difficult case: my university was using cisco equipment  
to do the VPN. So I used vpnc to connect. How do you tell ifupdown to  
only start vpnc once wpa_supplicant made the connection to a specific  
network? Additionally, they used a different SSID for each AP, so no  
roaming but manual selection. That was a nightmare to setup as you had  
to have one entry for each AP!
Additionally, wpa_supplicant was only working when the interface was  
not down, I had to manually figure that out to add a proper pre-up  
entry line. Yummy.


I currently use ifupdown only for a 3G connection but only because the  
integration of plasma-widget-networkmanagement with network-manager's  
use of modemmanager is not working (already solved upstream according  
to the developers blog but not in Debian). So I am using pon/poff for  
that. However, the example gprs chat script for PIN entry is not  
correct (not even according to the applicable standard and my modem  
happens to take that part very strictly). I am currently using another  
solution to correctly enter the PIN code (a program that I wrote years  
ago happens to do that). Believe it or not but modemmanager would have  
been my preferred solution. No, I didn't file a bug about that, not  
until I found a working solution for that chat script.


The network-manager solution still suffers from lots of bugs e.g. the  
KDE applet not being able to reconnect to network-manager after an  
upgrade of the latter, or a capable CLI solution (cnetworkmanager  
cannot do everything, nothing useful is shipped with network-manager).


I am with you that ifupdown should always be available as fallback but  
it's not _my_ preferred solution for a desktop. It's ok that some like  
to read hundreds of lines to setup something that should be a  
no-brainer, I don't.
For a server, ifupdown is preferrable but there, even a simple shell  
script would always be sufficient!


HS

PS: You are missing one important thing from your wpa-roam snippets:  
you really should restrict each SSID entry to the MAC address of the AP.



--
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/20110407125633.140870takqbbd...@v1539.ncsrv.de

Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)

[Michelle Konzack]

Hello Philip Hands,

Am 2011-04-06 10:13:19, hacktest Du folgendes herunter:
> I think this is the vital difference -- those that prefer ifupdown do so
> because they prefer to be in tight control of what is happening on their
> systems, whereas those that prefer NM don't want to be bothered about
> networking, they just want things to work.

This is exactly what I mean!  I do not want to be bothered on  a  server
with a tool which does not work and break all the times!

Yes I have tried NM, but isnstalling this crap by default break  my  Sun
and IBM Sevrers.

I do not wan to to be bothered by Seting up NM and want o have a  SIMPLE
ifupdownd which does not bother me with forcimg me to drive 2x 500km  to
the datacenter (I am in Strasbourg and the datacenter  is  in  Nürnberg)
the get my server back running

> When someone wanders into an Internet cafe and plugs a wire into their
> Ethernet port, they just want a notification to tell them that they're
> online.

I want the same to which is not possibel with NM.

Installing NM by default will break systems which where running the last
12 years without flaws.

> If some dimwit sysadmin at my co-lo plugs something new into my server I
> want _absolutely_ _nothing_ to occur, not even a new process -- a syslog
> message would be fine.

And what s if NM Cut-Off our Internet conenction?  This is  what  happen
to me.  NM is NOT ROCKSOLID!  ifupdown is proofen to work perfectly.

> We then seem to have a choice of installing something that works well
> for one group, and giving the others the chance to add the other (say,
> by including NM in the desktop task)

ACK!

>, or installing the other and
> getting the people who want less to remove it -- given that we've
> already implemented the first,

This will not work, becase installing NM by default will break server
systems and you will have no access manymore the the server.

> and it seems to work fine, why would we
> want to force server installs of Debian (which may well be in the
> majority) to uselessly default to installing software that will either
> do a poor job for the life of the server, or incur the additional effort
> of removing it?

Because it does not work and we definitively have not ANY  event  driven
things on a server.

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: network-manager as default? No! (was: Bits from the Release Team - Kicking off Wheezy)

[Michelle Konzack]

Hello Hendrik Sattler,

Am 2011-04-07 12:56:33, hacktest Du folgendes herunter:
> I am also not totally happy about network-manager but I still use it
> as it gives me a working wireless network on my laptop without
> having to spend hours reading endless documentation and writing
> multiple configuration files

This is Exacly what I mean with NM.  I do not wan to  be  bothered  with
reading some hours documentations on how to tweek NM  to  work  with  my
four 10GE NICs.

NM refused to setup 2 external interfaces and two internal ones.

Fortunately I had the server @home in my office and not in adistance  of
500km in the datacenter!

Thanks, Greetings and nice Day/Evening
Michelle Konzack

-- 
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil
Tel: +33-9-52705884 fix

  
 

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/


signature.pgp
Description: Digital signature

Re: More Vcs-Fields in debian/control?

[Andreas Tille]

On Thu, Apr 07, 2011 at 08:22:06AM +0200, Raphael Hertzog wrote:
> 
> There are lots of upstream-metadata that we might want to have available
> and we need to find a proper solution that doesn't involve debian/control.

In Debian Med and Debian Science we are just using

   http://wiki.debian.org/UpstreamMetadata

for keeping scientific references.  Bu tthe idea is not restricted to
this.  There exists an UDD importer for these data.
 
> It should be outside of the package and probably shared accross
> all Linux distributions. It seems to me to be a good extension of the work
> done/planned on the cross-distribution app-store.

I do not see a reason why this should not be possible with the proposed
solution.  It's just not (yet) widely adopted in Debian.
 
Kind regards

 Andreas.

-- 
http://fam-tille.de


-- 
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/20110407122039.gf15...@an3as.eu

Re: Bits from the 4th Debian Groupware Meeting

[Guido Günther]

Hi Andrew,

On Thu, Apr 07, 2011 at 06:15:15PM +1200, Andrew McMillan wrote:
> Hi Guido,
> 
> I have an interest in calendaring & contacts myself, and while I
> probably can't make it to such meetings very often in Europe I'd
> appreciate being aware of plans, just in case I can participate in some
> useful way, even if remotely.

I noticed that the cross groupware list (which got the announcement)
wasn't mentioned in the wiki at:

http://wiki.debian.org/Groupware

I changed that. The announcement also went out to:

To: pkg-evolution-maintain...@lists.alioth.debian.org,
pkg-kolab-de...@lists.alioth.debian.org, debian-qt-...@lists.debian.org,
calendarserver-disc...@lists.alioth.debian.org,
pkg-mozilla-maintain...@lists.alioth.debian.org,
pkg-citadel-de...@lists.alioth.debian.org,
pkg-roundcube-maintain...@lists.alioth.debian.org

Sorry I missed davical. Subscribing to the list is probably safest. It's
almost zero volume.
Cheers,
 -- Guido

> 
> Thanks,
>   Andrew.
> 
> On Wed, 2011-04-06 at 23:11 +0200, Guido Günther wrote:
> > The fourth Debian Groupware Meeting[1] was held in the LinuxHotel,
> > Essen, Germany[2]. This is a short summary of what happened during the
> > weekend:
> > 
> > * We pushed new versions of icedove and iceowl to unstable fixing
> >   several issues with gnome-shell in the later. Unstable now ships
> >   packages based on Thunderbird's current 3.1 branch.
> > 
> > * The iceowl-l10n language package got resurrected (currently sitting
> >   in NEW) providing translations for iceowl-extension and (in a yet
> >   incomplete way) for iceowl.
> > 
> > * We've done Citadel ↔ ice{dove,owl} interop testing and bug
> >   fixing.
> > 
> > * Work was done on Citadel's event driven SMTP client and IPv6
> >   compatibility
> > 
> > * The z-push package got updated[3] to 1.5.1. The patent restrictions
> >   are resolved now and we're closer to resolving the trademark issues.
> >   So hopefully an upload to main can happen real soon now.
> > 
> > * SOGo packaging made nice progress[4]. Remaining issues involve linking
> >   against GNUTLS to resolve the OpenSSL GPL license incompatibility,
> >   and handling of the embedded copies of JavaScript libraries.
> > 
> > * We updated the groupware overview[5] page.
> > 
> > * We were invited by the FrOSCon[6] organizers to join their barbecue.
> >   Many thanks for that!
> > 
> > Cheers,
> >  -- Guido
> > 
> > [1]: http://wiki.debian.org/GroupwareMeeting2011-04-01to03
> > [2]: http://www.linuxhotel.de/community.html
> > [3]: http://git.debian.org/?p=users/wolfi-guest/z-push.git
> > [4]: http://www.mail-archive.com/users@sogo.nu/msg04832.html
> > [5]: http://wiki.debian.org/Groupware
> > [6]: http://www.froscon.org/
> 
> -- 
> 
> andrew (AT) morphoss (DOT) com+64(272)DEBIAN
> The only thing better than love is milk.
> 
> 



-- 
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/20110407121438.ga...@bogon.sigxcpu.org

Re: More Vcs-Fields in debian/control?

[Bernd Zeimetz]

On 04/07/2011 10:11 AM, Charles Plessy wrote:
> http://wiki.debian.org/UpstreamMetadata
> 
> The key concept is to store ‘Field: value’ data in a file called
> debian/upstream-metadata.yaml, and to access it from the VCS where
> the package is stored (that is, not from the source package itself).

Uh please not yet another file in yet another format.
If you really need yet another file, please don't use yet another markup
language, use something RFC822ish.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F


-- 
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/4d9db751.1060...@bzed.de

Re: Bash-completion with triggers

[Raphael Hertzog]

Hi,

On Thu, 07 Apr 2011, David Paleino wrote:
> Hello everybody,
> I've implemented a new revision of bash-completion, which uses debtriggers(5)
> to load only relevant completions, and symlink them when something
> touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so on.
> 
> For this to work, the completions have been moved out from /etc/ -- they would
> be in /usr/share/bash-completion/completions/, but /etc/bash_completion.d/ is
> being kept not to break tons of other packages installing files there.
> 
> However, I'm writing to get comments about the triggers issue. When a package
> installs an executable in one of the above directories, bash-completion's
> postinst removed all symlinks in /etc/bash_completion.d/triggered/, and
> re-creates them. The speed of such operation varies greatly depending on the
> installed packages -- on my system, it takes about 10s -- but the shell 
> loading
> seems much faster too.
> 
> Is there any objection to bash-completion using triggers to "watch" the
> aforementioned directories?

I feel uneasy about this. It means the trigger is going to be activated
for any package installation and all packages are going to be put in
triggers-awaited state.

The trigger is going to happen very often (like the man-db one) and
with a 10s impact it's very noticable...

Even if we change apt to actually keep trigger processing to the end of
the APT run, I fear that the dependency resolution logic is going to
force the trigger to run sooner and more often because a package
in trigger-awaited status does not satisfy the dependencies.

If file triggers could also specify the --no-await option that
dpkg-triggers supports, things might be different.

But in the current state, I think it's a bad idea to use file triggers
in your case.

You'd better use some apt hook to do the task you envision. A file
trigger that is activated for a majority of package installation is
probably better dealt with such a solution.

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/20110407131620.gd2...@rivendell.home.ouaza.com

Nuevos cursos!!! Redes Sociales, Email Marketing y Posicionamiento Google

[Cursos de Google-Olivia Figueroa]

El posicionamiento web es una estrategia usada para dar a conocer tu sitio web 
o marca por internet.

El objetivo es tener mayor presencia en la web que tus competidores,y conseguir 
que tu sitio aparezca en la 1ra. pagina de Google, Yahoo y principales 
buscadores.

Si ya usas Google Adwords, aprende como optimizar tu campana y pagar menos por 
click

Curso Marketing en Google-Posicionamiento Web

* 26 de Abril- Curso ONLINE
* 03 de Mayo Santiago de Chile.
* 06 de Mayo  Temuco, Chile.
* 13 de Mayo  Cancun
* 21 de Mayo  Monterrey
* 17 de Junio  Guadalajara.

Curso Email Marketing

* 08 de Abril  Guadalajara.
* 20 de Mayo  Monterrey.

Curso Redes Sociales enfocado a Empresas

Nivel Basico

* 14 de Abril Mexico, D.F.
* 18 de Mayo Monterrey.
* 15 de Junio  Guadalajara.

Nivel Avanzado

* 15 de Abril Mexico, D.F.
* 19 de Mayo Monterrey.
* 16 de Junio Guadalajara.


Si tu ciudad no aparece programada, contactanos, tenemos una opcion para ti.

Pregunta por nuestros atractivos descuentos por pronto pago y por volumen.

GRATIS ASESORIA Personalizada acerca del posicionamiento de tu sitio web. 
Exclusivo asistentes a curso Posicionamiento en Google

Informes, temario, inscripciones y descuentos especiales

A. Olivia Figueroa D.
Cursos de Google 
Mexico-Chile
oli...@cursosdegoogle.com
DF(55)8421-5396
MTY(81)8421-1100
GDL(33)8421-1406
L-V 10:30 a 18:00 hrs.
www.cursosdegoogle.com
Skype: laolyfd
Twitter.com/cursosdegoogle
Facebook: Cursos de Posicionamiento Olivia

�Son las redes sociales una moda?
http://www.youtube.com/watch?v=rALMzE8n-qA&feature=fvsr

Nota: Si usted no quiere recibir mas correos de este tipo solo responda
este correo con el asunto: DAR de BAJA desde  la cuenta donde recibio la
informacion.

*Los acentos y de este correo fueron removidos deliberadamente






-- 
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/e1q7emd-0004nb...@cl-t008-341cl.privatedns.com

Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)

[brian m. carlson]

On Wed, Apr 06, 2011 at 12:15:49PM +0200, Vincent Caron wrote:
>That's a nice explanation that would fit on
> http://keyring.debian.org/creating-key.html

If someone would like to put it up there, he or she should feel free to
do so.

>   Thanks for your help.

Sure.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

Re: Moving bash from essential/required to important?

[Lars Wirzenius]

On ke, 2011-04-06 at 16:37 +0100, Lars Wirzenius wrote:
> Obviously, doing these changes earlier rather than later in the release
> cycle would be good, if they are to be done at all.

OK, so assuming anything is to be done about this at all, here's what I
suggest:

  * add a lintian test that detects scripts that are needlessly
#!/bin/bash according to checkbashisms; the test can't be
extremely reliable, but would probably be good enough
  * get project consensus on whether bash should remain essential or
not (so far my reading of this thread indicates it is
inconclusive); if there is no consensus, stop here
  * add lintian test for packages that contain bash scripts but
don't declare a dependency on bash
  * inform the project of bash losing essentialness (mail to d-d-a)
  * do a mass bug filing on all packages that a) contain bash
scripts that checkbashisms confirms have bashisms b) do not
depend on bash
  * do another mass bug filing on all packages that contain bash
scripts that checkbashisms does not think contain any bashisms
  * wait some months for package maintainers to fix their packages
  * NMU all packages that have not been fixed

Opinions? I assume it would be the release team's decision about bash
essentialness?

-- 
Blog/wiki/website hosting with ikiwiki (free for free software):
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/1302187274.2441.34.ca...@havelock.liw.fi

Re: throw away debs and source only uploads

[Stefano Zacchiroli]

[ Bcc:-ing ftpmasters ]

Time to wrap up the current state of this discussion, at least as far as
I see it.

- going ahead with throw away debs seems to be largely uncontroversial;
  can we haz zem please? :-)

- there seems to be no substantial objections either on the fact the
  source only upload would be fine, as long as they are not the default
  but can be enabled upon request


What's still largely undecided is how uploaders would require a source
only upload. Several presented use cases --- both here on list and in
private replies to me --- show that my proposal, as well as all possible
source-based solutions, are suboptimal. In other words, people seem to
really need per-upload, or even per-batch upload, white listing.

FWIW, I wouldn't like much the idea of introducing yet another list of
people which are allowed to do source only uploads as that would be a
potential bottleneck which seems unwarranted here (at least if you buy
my argument that for what concerns the risk of non-buildable-uploads,
the defaults matter more than strict controls).

How about just relying on "dpkg-buildpackage -S", maybe coupling it with
the need of using "dput -f" (extending a bit the current semantics of
-f) which would refuse to upload a source only binary by default?

Cheers.
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: More Vcs-Fields in debian/control?

[Jelmer Vernooij]

On Thu, 2011-04-07 at 16:33 +1000, Ben Finney wrote:
> Joey Hess  writes:
> > * pristine-tar cannot be used
> 
> The assumptions of ‘pristine-tar’ seem very Git-centric and are quite at
> odds with my chosen VCS (Bazaar). It demands a “treeish object”, I have
> no idea what that relates to in Bazaar.
"pristine-tar checkout" is git specific as far as I can tell, but the
other commands are very well usable without git.

bzr-builddeb supports pristine tar and uses it to import and export
upstream tarballs if you have a packaging branch that includes the
upstream source.

Cheers,

Jelmer


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

Re: Bash-completion with triggers

[David Paleino]

On Thu, 7 Apr 2011 15:16:20 +0200, Raphael Hertzog wrote:

> Hi,
> 
> On Thu, 07 Apr 2011, David Paleino wrote:
> > Hello everybody,
> > I've implemented a new revision of bash-completion, which uses
> > debtriggers(5) to load only relevant completions, and symlink them when
> > something touches /usr/bin/, /usr/games/, /usr/sbin/, /sbin/, /bin/, and so
> > on.
> > 
> > For this to work, the completions have been moved out from /etc/ -- they
> > would be in /usr/share/bash-completion/completions/,
> > but /etc/bash_completion.d/ is being kept not to break tons of other
> > packages installing files there.
> > 
> > However, I'm writing to get comments about the triggers issue. When a
> > package installs an executable in one of the above directories,
> > bash-completion's postinst removed all symlinks
> > in /etc/bash_completion.d/triggered/, and re-creates them. The speed of
> > such operation varies greatly depending on the installed packages -- on my
> > system, it takes about 10s -- but the shell loading seems much faster too.
> > 
> > Is there any objection to bash-completion using triggers to "watch" the
> > aforementioned directories?
> 
> I feel uneasy about this. It means the trigger is going to be activated
> for any package installation and all packages are going to be put in
> triggers-awaited state.

"Only" those installing executables in these directories:

$ cat debian/triggers 
interest /sbin
interest /usr/sbin
interest /usr/local/sbin
interest /bin
interest /usr/bin
interest /usr/local/bin
interest /usr/games
interest /usr/local/games
$

> The trigger is going to happen very often (like the man-db one) and
> with a 10s impact it's very noticable...

That's on my system, heh :)
(for comparison, it's faster than other triggers here. You might want to try
yourself, package at [1] -- beware, lots of messages regarding removed
conffiles)

[1]: http://people.debian.org/~dapal/debs/bash-completion_1.3-2_all.deb

Unfortunately, I have to remove and re-create all the symlinks upon trigger
activation: in fact, only the directory name is being passed (/usr/bin); if
my postinst had passed the file name activating the trigger (/usr/bin/foo); it
would really be much faster.

> Even if we change apt to actually keep trigger processing to the end of
> the APT run, I fear that the dependency resolution logic is going to
> force the trigger to run sooner and more often because a package
> in trigger-awaited status does not satisfy the dependencies.
> 
> If file triggers could also specify the --no-await option that
> dpkg-triggers supports, things might be different.

That would be great; ideas how to do it?

> But in the current state, I think it's a bad idea to use file triggers
> in your case.

A named trigger isn't better in any case, I believe.

> You'd better use some apt hook to do the task you envision. A file
> trigger that is activated for a majority of package installation is
> probably better dealt with such a solution.

Which hook would you suggest?

Reading apt.conf(5), I find: Dpkg::Pre-Invoke, Dpkg::Post-Invoke and
Dpkg::Pre-Install-Pkgs. I think the first two are run at each unpacking (thus
are unsuitable to me, it would be much slower than now), and the latter is
_before_ installing packages.
Why there's no Dpkg::Post-Install-Pkgs? :)


I believe that passing --no-await for file triggers, or letting the maintainer
specify that in debian/triggers, would be the best solution.

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: time based freezes

[Stefano Zacchiroli]

[ Bcc:-ing release team ]

On Sun, Apr 03, 2011 at 06:15:52PM +0200, Stefano Zacchiroli wrote:
> Since other follow-ups have avoided this topic up to now, let me be the
> reckless guy who jumps into it with both feet: time based freezes!

Another thread, another thread summary! Here is a summary about where we
are on this discussion, at least as far as I can tell.

- The general of concept of time-based freeze seems to be
  uncontroversial. Apparently (and unsurprisingly, if I may) people
  would love to have a date early on to base their roadmaps upon.

- The choice of having a specific date seems to be more controversial
  (although honestly I don't see how it could do any harm). Anyhow, it
  seems noone would object to have a target freeze month at the
  beginning of a release cycle, seeing it refined later on. Various
  people have argued that the target freeze month shouldn't be larger
  than one month, and I personally agree with that: having a larger
  period has IMHO the potential to introduce back some of the planning
  issues we have seen during the Squeeze cycle.

I would love if we can summarize the above part by saying that we have
consensus on: 1) announcing at the beginning of a release cycle a target
freeze month, 2) refining it later on.

Regarding a more precise definition of "later on", I agree that for DDs
it wouldn't make much of a difference, but things might be different
from usptream, on which we have way less control. As a rule of thumb, I
believe it would be useful to put a limit like the following: the exact
freeze date will be announced 6 months before the freeze, the
latest. That would IMHO enable those upstream who care about Debian to
reliably plan their releases in order to better collaborate with us.

- The question of "what" to freeze seems to be uncontroversial as well,
  the scheme of pre-approving packages used for the Squeeze freeze
  (which I overlooked in my kickstart mail) seems to be appreciated.

- On the other hand, a wide open front of the discussion is *when* to
  freeze, with various people arguing in favor of having a specific
  period, such as "we freeze on $month every even/odd year".

  I've sympathies for such a schemes myself, if only for the simplicity
  to grasp and remember it "by heart". Let's look at some data about
  that. I observe that Debian has released every 24 months (+/-2) since
  the days of Etch in 2007. Even if we include Sarge, which has had a
  particularly long release cycle, the average is still around 25
  months. Freezing every 24 months will be compatible with such a trend
  (assuming it will continue, see below for a related question). If for
  instance we say we freeze in August (or pick your month) every
  even/odd year, that would allow us to release in February, in case RC
  squashing would proceed as it did for Squeeze.

  No objections have been raised to such a scheme up to now and I would
  welcome it as well, as it could bring roadmap advantages for both DDs
  and upstreams. The only problem is ...

- ... what to do if a development cycle (i.e. the period from the
  previous release to the next freeze date) would turn out to be "too
  short"? That could happen when the previous release takes more than 6
  month to stabilize and to get RC bug cleaned. I believe the figures we
  are talking about give enough margin not to worry too much about it.

  Let's assume for example that Wheezy would freeze (as an entirely
  hypothetical scenario) on August 2012 and that it would take a whole
  year to stabilize and release it on August 2013. That would reduce by
  6 months the release cycle of Wheezy + 1, but still leave 1 full year
  of development from August 2013 to August 2014, the "standard" freeze
  date. Considering that 1 full year for stabilize a release should lead
  us to worry in general about the well-being of our project (or about
  the specific software choices we made in that cycle) and that even in
  that case there will be 1 full year of development to catch up, I
  think such a scheme would be a reasonably safe bet.

  I do think it's worth going there (freeze every 24 months on a
  specific month), but I wanted to mention the above risk nonetheless,
  as it is an important one to keep in mind.


Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: time based freezes

[Stefano Zacchiroli]

Hi Carsten, just a few more comments on your mail which I haven't
covered in the separate "summary" mail I've just sent.

On Mon, Apr 04, 2011 at 08:38:18AM +0200, Carsten Hey wrote:
> We are in the good position to have a very experienced release team that
> is be able to decide whether testing is in a good condition to be
> frozen.  It should also have option to adapt their time planing to the
> team's responses to "what are your plans for stable+1?" mails or to
> events that can't be known a few weeks after the prior stable release
> has happened.

I couldn't agree more, but TBH in setting a release scheme for the
future, I don't think we should make any assumption on the experience of
the release time. I believe the scheme should have its own merit, no
matter who will be called to put it into use. That would also have the
additional advantage of putting a bit less responsibility on the release
team (OK, just a little bit less, but it could make a difference on
whose who need to explicitly volunteer to take on their shoulders a
highly sensitive task).

That's also part of the reason why I don't think we should rely *only*
on "what are your plans for stable+1" mails. Those are of course very
good and I'm sure answers to those questions would help a lot the
release team anyhow. But at the same time if we could find a scheme
where a release period precise enough to enable DDs to define their own
roadmaps work "by default", without having to wait for specific human
intervention, I believe it would be better. Of course nothing will stop
the release team to make exceptions on the basis of those answers or on
the basis on any other factor they see fit, but seeing them as
exceptions would hopefully induce them, and the project as a whole, to
think twice about the consequences.

> This time frame could be rather imprecise at first and narrowed over
> time.

Fair enough, I've integrated this comment in an updated proposal.
(Although I've taken into account there several other comments of people
who proposed a specific threshold of 1 month to the imprecision.)

> This seems to be suboptimal (probably it's just your wording).  The
> following quote from a mail sent by the release team in 2008 describes
> how it also has been handled for Squeeze:
> | Packages that are present in unstable the day we freeze will be
> | automatically allowed into testing, that is, the freeze date ... does
> | not mean your package should be in testing by then, but only in
> | unstable.

ACK-ed as well in my other mail, thanks to yours and other comments.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Bash-completion with triggers

[Goswin von Brederlow]

David Paleino  writes:

> On Thu, 7 Apr 2011 15:16:20 +0200, Raphael Hertzog wrote:
>
>> You'd better use some apt hook to do the task you envision. A file
>> trigger that is activated for a majority of package installation is
>> probably better dealt with such a solution.
>
> Which hook would you suggest?
>
> Reading apt.conf(5), I find: Dpkg::Pre-Invoke, Dpkg::Post-Invoke and
> Dpkg::Pre-Install-Pkgs. I think the first two are run at each unpacking (thus
> are unsuitable to me, it would be much slower than now), and the latter is
> _before_ installing packages.
> Why there's no Dpkg::Post-Install-Pkgs? :)

Dpkg::Post-Invoke would be the right (best available) one. That would
call your trigger after every dpkg invocation, what Raphael fears will
hapen with our trigger anyway but without the trigger-waiting state.

But those hooks would only wotk for apt/aptitude. Not for invoking dpkg
or cupt or others, which I think rules them out anyway.

MfG
Goswin


-- 
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/8739luqbpl.fsf@frosties.localnet

Re: /run support for wheezy?

[Luca Capello]

Hi Roger!

Please do not Cc: me, I read the list.

NB, this reply is maybe too late and useless, but I thought it was
better to do that anyway, at least to thank Roger for the time he spent.

On Fri, 01 Apr 2011 16:24:28 +0200, Roger Leigh wrote:
> On Fri, Apr 01, 2011 at 04:06:16PM +0200, Luca Capello wrote:
>> On Fri, 01 Apr 2011 15:33:44 +0200, Roger Leigh wrote:
>> > I would also appreciate any testing, especially if you're using a
>> > nonstandard setup e.g. tmpfs on /var/run and/or /var/lock.
>> 
>> Without having looked/tested your packages and being a bit naive, but
>> given that tmpfs for /var/run and /var/lock can be configured through
>> /etc/default/rcS, maybe it is more used than you think (and I would not
>> completely call it nonstandard), thus it requires a bit more caution.
>
> Not entirely sure what you mean here.  We detect and deal with this
> sort of setup automatically.  I said "nonstandard" because TTBOMK this
> feature is not widely used, and (I am given to understand) somewhat
> broken.

What is "broken"?  /var/run and /var/lock on tmpfs?  I have been using
them for quite a while now (at least four years) and everything is now
fine (obviously after various bugs about sub-directories not being
created by daemons were fixed).

And I actually think it is more "standard" than what you believe because
AFAIK it is the easiest way to avoid excessive writeouts to any disks,
especially on SSDs.  FWIW, I started using it long before I moved my
everyday sid to an SSD, also because there was an easy way to setup it,
i.e. through /etc/default/rcS (and I have also thought about /tmp, see
).

> If you're using RAMRUN/RAMLOCK, then you'll get the same setup, but
> mounted under /run and /run/lock, with compatibility symlinks in place.

This is what I wanted to hear, thank you.

Thx, bye,
Gismo / Luca


pgp9lt52MVrEw.pgp
Description: PGP signature

Re: Moving bash from essential/required to important?

[Luca Capello]

Hi Lars!

On Thu, 07 Apr 2011 16:41:14 +0200, Lars Wirzenius wrote:
> On ke, 2011-04-06 at 16:37 +0100, Lars Wirzenius wrote:
>> Obviously, doing these changes earlier rather than later in the release
>> cycle would be good, if they are to be done at all.
>
> OK, so assuming anything is to be done about this at all, here's what I
> suggest:
>
>   * add a lintian test that detects scripts that are needlessly
> #!/bin/bash according to checkbashisms; the test can't be
> extremely reliable, but would probably be good enough
>   * get project consensus on whether bash should remain essential or
> not (so far my reading of this thread indicates it is
> inconclusive); if there is no consensus, stop here

Given how far you have already gone with the analysis, I would stop here
in no case, especially considering...

>   * do another mass bug filing on all packages that contain bash
> scripts that checkbashisms does not think contain any bashisms

...there is no point using #!/bin/bash when the script is
POSIX-compliant, since the default #!/bin/sh on Debian (dash) is faster
than bash.

Thx, bye,
Gismo / Luca


pgpPp4TJXZe7R.pgp
Description: PGP signature

Re: time based freezes

[Ben Hutchings]

On Thu, Apr 07, 2011 at 06:00:09PM +0200, Stefano Zacchiroli wrote:
> [ Bcc:-ing release team ]

Why Bcc?!

[...]
> I would love if we can summarize the above part by saying that we have
> consensus on: 1) announcing at the beginning of a release cycle a target
> freeze month, 2) refining it later on.

I think you're missing step 0: the release team consults with the whole
body of developers, presumably with a suggested freeze date/month as a
starting point.  This would also mean step 1 would be delayed slightly.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
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/20110407164248.gz2...@decadent.org.uk

Re: time based freezes

[Stefano Zacchiroli]

On Thu, Apr 07, 2011 at 05:42:48PM +0100, Ben Hutchings wrote:
> > I would love if we can summarize the above part by saying that we have
> > consensus on: 1) announcing at the beginning of a release cycle a target
> > freeze month, 2) refining it later on.
> 
> I think you're missing step 0: the release team consults with the whole
> body of developers, presumably with a suggested freeze date/month as a
> starting point.  This would also mean step 1 would be delayed slightly.

Well, it depends. If for instance we go for the "fixed-period" scheme
(proposed in this thread and discussed in the latter part of my mail)
the specific freeze month is fixed in advance.  I agree that the
decision of that specific month should go through a "we propose this"
first, but it will happens once and for all (barring the need of
reviewing it which of course might arise in the future).

Cheers.
-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Quando anche i santi ti voltano le spalle, |  .  |. I've fans everywhere
ti resta John Fante -- V. Capossela ...| ..: |.. -- C. Adams


signature.asc
Description: Digital signature

Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)

[Jonathan McDowell]

On Wed, Apr 06, 2011 at 12:15:49PM +0200, Vincent Caron wrote:
> On Wed, 2011-04-06 at 01:09 +, brian m. carlson wrote:
> > On Tue, Apr 05, 2011 at 05:15:15PM +0200, Vincent Caron wrote:
> > >   2/ It is suggested to update gnupg.conf with:
> > > 
> > >   personal-digest-preferences SHA256
> > >   cert-digest-algo SHA256
> > >   default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES 
> > > CAST5 ZLIB BZIP2 ZIP Uncompressed
> > > 
> > >   Is it still needed with GnuPG 1.4.11 ?
> > 
> > This isn't strictly needed with any version of GnuPG.  However, these
> > settings choose algorithms which are known to be stronger (avoiding MD5
> > and the mandatory but somewhat weakened SHA1).  Setting
> > default-preference-list specifies which algorithms you prefer in your
> > key's self-signature (which you can always change later).
> > Implementations are forbidden from using algorithms (other than the
> > default must-implement ones) that you do not specify in your
> > self-signature.  Using cert-digest-algo chooses the algorithm you will
> > use in signing keys.  And finally, personal-digest-preferences is the
> > algorithm you will use when signing data.
> 
>That's a nice explanation that would fit on
> http://keyring.debian.org/creating-key.html

It's not entirely accurate. The point of those lines are to ensure that
older (certainly lenny and earlier, I'm not sure when the default
changed) versions of GnuPG don't use SHA1 when signing keys (either your
own or others).

J.

-- 
It's ten o'clock; do you know where your processes are?
This .sig brought to you by the letter L and the number 13
Product of the Republic of HuggieTag


-- 
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/20110407172610.go4...@earth.li

Re: Moving bash from essential/required to important?

[Tollef Fog Heen]

]] Luca Capello 

Hi,

| >   * do another mass bug filing on all packages that contain bash
| > scripts that checkbashisms does not think contain any bashisms
| 
| ...there is no point using #!/bin/bash when the script is
| POSIX-compliant, since the default #!/bin/sh on Debian (dash) is faster
| than bash.

There might very well be, such as upstream shipping scripts that are
written to work on both solaris and linux.  (Solaris's /bin/sh isn't
POSIX.)  Changing this to deviate from upstream would be silly, IMO.

Also, lots of scripts aren't speed-sensitive and people don't want to
think about whether something uses bashisms or not, so they use «#!
/bin/bash» to rather be safe than sorry.

(I think the whole «make bash optional» thing is pointless and a waste
of developer resources.  It makes embedded developers's lives slightly
easier at the cost of lots of manual checking, time I think would be
better spent fixing real bugs.)

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87oc4ivu9c@qurzaw.varnish-software.com

MBF Re: Bug#621277: ggz-grubby: Getting rid of unneeded *.la / emptying dependency_libs

[Andreas Metzler]

On 2011-04-06 codeh...@debian.org wrote:
> Package: ggz-grubby
> Severity: normal
> User: codeh...@debian.org
> Usertags: la-file-removal

> To finish an old release goal from Squeeze, to comply with Policy
> 10.2 and to ease the introduction of MultiArch, I'm filing bugs
> against packages which contain .la files which can be either removed
> or stripped of the dependency_libs variable.
[...]

Hello,

Please stop this mass bug filing. 
a) There were duplicate bugs filed.
b) Bugs were filed for issues recently solved.
c) The bugs reports are unversioned.

I can completely understand that a and b can occassionally happen due
to timing issues. However imnsho a MBF with unversioned bug-reports is
not acceptable.

cu and- closing three invalid reports in ggz-* -dreas


-- 
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/20110407171343.gb2...@downhill.g.la

Re: MBF Re: Bug#621277: ggz-grubby: Getting rid of unneeded *.la / emptying dependency_libs

[Neil Williams]

On Thu, 7 Apr 2011 19:13:43 +0200
Andreas Metzler  wrote:

> On 2011-04-06 codeh...@debian.org wrote:
> > Package: ggz-grubby
> > Severity: normal
> > User: codeh...@debian.org
> > Usertags: la-file-removal
> 
> > To finish an old release goal from Squeeze, to comply with Policy
> > 10.2 and to ease the introduction of MultiArch, I'm filing bugs
> > against packages which contain .la files which can be either removed
> > or stripped of the dependency_libs variable.
> [...]
> 
> Hello,
> 
> Please stop this mass bug filing. 

It'll pause whilst I add a few more checks to the process.

> a) There were duplicate bugs filed.

It would have been helpful to list some of those. I've found one out of
the bugs submitted against the packages you mention.

> b) Bugs were filed for issues recently solved.

I do try and avoid that by constantly updating the source data prior to
each phase, but as you describe, some lag is inevitable.

> c) The bugs reports are unversioned.
> 
> I can completely understand that a and b can occassionally happen due
> to timing issues. However imnsho a MBF with unversioned bug-reports is
> not acceptable.

I've been updating the process at this end and I'll be able to add the
version information for the next runs. However, the original data does
not include a version so the only version number available is what can
be retrieved from either an apt-cache on sid or rmadison. That
therefore suffers from the same timing problems as the other issues
you've described.

Some duplicates come from the Ubuntu changes and those have usertags,
so I'll add that check to the processing. I missed that, so apologies
on that score.

That led to #621246 being missed and #620742 being added.

> cu and- closing three invalid reports in ggz-* -dreas

The three bugs I reported against ggz* yesterday were #621246, #621277
and #621339. The other two are not duplicates but have had recent
uploads which might not have got into the source data. Certainly for
#621246, the upload which is currently 1 day old in sid has the dependency_libs 
emptied. I don't think there's any way that the process can reliably catch 
uploads that new but thanks for fixing that package.

I'll add the version available on the mirrors at the time of processing,
albeit that the version may not be the very latest version uploaded.

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgp2rqn6W87uJ.pgp
Description: PGP signature

Re: MBF Re: Bug#621277: ggz-grubby: Getting rid of unneeded *.la / emptying dependency_libs

[Neil Williams]

On Thu, 7 Apr 2011 19:13:43 +0200
Andreas Metzler  wrote:

Forgot to add, the current version of the script is here:
http://people.debian.org/~codehelp/la-file-bugs.pl.txt

(simply because it was convenient for me to work on the script from
more than one machine)

I've not updated that with the version retrieval or to check for the
ubuntu usertag yet. Patches are welcome (despite this not actually being
in version control anywhere - I could be persuaded to put this into
Emdebian SVN but it seems like overkill to create an Alioth project).

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpNodoBa3RuU.pgp
Description: PGP signature

Re: Bash-completion with triggers

[Eugene V. Lyubimkin]

On 2011-04-07 18:15, Goswin von Brederlow wrote:
> Dpkg::Post-Invoke would be the right (best available) one. That would
> call your trigger after every dpkg invocation [...]

This is not true, 'Dpkg::*-Invoke' script chain are called once
before/after all dpkg invocations.

> But those hooks would only wotk for apt/aptitude. Not for [...] cupt

This is not true as well.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


-- 
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/20110407191431.GA5613@r500-debian

Re: Bash-completion with triggers

[Raphael Hertzog]

On Thu, 07 Apr 2011, David Paleino wrote:
> "Only" those installing executables in these directories:

I know, I do not have stats but I expect this to be a very important
percentage of packages.

> Unfortunately, I have to remove and re-create all the symlinks upon trigger
> activation: in fact, only the directory name is being passed (/usr/bin); if
> my postinst had passed the file name activating the trigger (/usr/bin/foo); it
> would really be much faster.

I know the limitations of triggers. :-)

Still, you can do better than recreating everything each time. Like
scanning the non-installed completion files, extract some metadata
listing which program's completion this file provide, and verify if
you can find the binary before deciding to install it.

Removing completion for uninstalled packages is not important to have in
real-time, you can do it in a weekly cron or something like this.

> > If file triggers could also specify the --no-await option that
> > dpkg-triggers supports, things might be different.
> 
> That would be great; ideas how to do it?

Extend the syntax of the triggers file and patch dpkg to support it.

> > But in the current state, I think it's a bad idea to use file triggers
> > in your case.
> 
> A named trigger isn't better in any case, I believe.

Indeed, they are of no use.

> > You'd better use some apt hook to do the task you envision. A file
> > trigger that is activated for a majority of package installation is
> > probably better dealt with such a solution.
> 
> Which hook would you suggest?
> 
> Reading apt.conf(5), I find: Dpkg::Pre-Invoke, Dpkg::Post-Invoke and
> Dpkg::Pre-Install-Pkgs. I think the first two are run at each unpacking (thus
> are unsuitable to me, it would be much slower than now), and the latter is
> _before_ installing packages.
> Why there's no Dpkg::Post-Install-Pkgs? :)

Pre/Post-Invoke are called (as their name suggest it) before and after
dpkg has been called no matter the operation requested (unpack,
configure).

I was indeed thinking there was some sort of hook that would run after apt
had completed its work but it's not the case (you could still ask APT
developers if they can do it).

Still I think using Dpkg::Post-Invoke with an update-bash-completion
program intelligent enough to not do useless work is preferable over
using a file trigger given the current limitations of triggers.

File triggers are useful to replace calls to update-foo in postinst
but in your case the data is already centralized in a package and you
have the somewhat oppposite problem of knowing which of those files are
useful.

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/20110407191733.gd6...@rivendell.home.ouaza.com

Re: Bash-completion with triggers

[David Paleino]

On Thu, 7 Apr 2011 22:14:31 +0300, Eugene V. Lyubimkin wrote:

> On 2011-04-07 18:15, Goswin von Brederlow wrote:
> > Dpkg::Post-Invoke would be the right (best available) one. That would
> > call your trigger after every dpkg invocation [...]
> 
> This is not true, 'Dpkg::*-Invoke' script chain are called once
> before/after all dpkg invocations.

So it's just like a trigger monitoring /? (without the implications of triggers
in terms of sequence of operations)

This is meaningless to me. This way, my postinst would be run at *every* package
installation, not only those installing files in /usr/bin/ and companions.

Kindly,
David

-- 
 . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
 : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
 `. `'`  GPG: 1392B174 | http://deb.li/dapal
   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174


signature.asc
Description: PGP signature

Re: Bash-completion with triggers

[Eugene V. Lyubimkin]

On 2011-04-07 21:19, David Paleino wrote:
> > This is not true, 'Dpkg::*-Invoke' script chain are called once
> > before/after all dpkg invocations.
> 
> So it's just like a trigger monitoring /? (without the implications of 
> triggers
> in terms of sequence of operations)

No, I phrased it badly probably. Let me try again:

Dpkg::Pre-Invoke are called once. Then all dpkg invocations are called.
The Dpkg::Post-Invoke is called.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer


-- 
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/20110407192730.GC5613@r500-debian

Re: Bash-completion with triggers

[Raphael Hertzog]

On Thu, 07 Apr 2011, Eugene V. Lyubimkin wrote:
> On 2011-04-07 18:15, Goswin von Brederlow wrote:
> > Dpkg::Post-Invoke would be the right (best available) one. That would
> > call your trigger after every dpkg invocation [...]
> 
> This is not true, 'Dpkg::*-Invoke' script chain are called once
> before/after all dpkg invocations.

Ah, good to know. I thought the same than Goswin and did not verify it.

I guess the existence of Dpkg::Pre-Install-Pkgs led me to believe that
the difference with Dpkg::Pre-Invoke would be the number of time it's run
when in fact it's only the data passed to the program that changes...
since both are called at the same place in the code.

Thanks for correcting our mistakes!

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/20110407192810.ge6...@rivendell.home.ouaza.com

Re: time based freezes

[gregor herrmann]

On Thu, 07 Apr 2011 18:00:09 +0200, Stefano Zacchiroli wrote:

> - On the other hand, a wide open front of the discussion is *when* to
>   freeze, with various people arguing in favor of having a specific
>   period, such as "we freeze on $month every even/odd year".

Count me in.
 
> - ... what to do if a development cycle (i.e. the period from the
>   previous release to the next freeze date) would turn out to be "too
>   short"? 

Or "too long", if we manage to make the freeze shorter ...

>   that even in
>   that case there will be 1 full year of development to catch up, I
>   think such a scheme would be a reasonably safe bet.

Me too.
And in the opposite case we have a bit more time; that might even be
an incentive to fix more RC bugs during the freeze :)
 

Cheers,
gregor
 
-- 
 .''`.   http://info.comodo.priv.at/ -- GPG key IDs: 0x8649AA06, 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT & SPI, fellow of Free Software Foundation Europe
   `-NP: Sting: Fields Of Gold


signature.asc
Description: Digital signature

Bug#621632: O: hyperlatex

[Roland Stigge]

Package: wnpp
Severity: normal

Hi,

I'm orphaning the package hyperlatex. It's unmaintained upstream for years now
and it depends on an old emacs version (for emacs lisp in which it is
implemented).  Therefore, it is RC-buggy now. I'm not a lisp programmer so I
won't port it to current emacs23.

The package is not in testing nor in squeeze.

If someone picks up the porting (and fixing) work, she would also need to take
over upstream maintenance in some way.

Otherwise, I propose the removal of hyperlatex.

Thanks!

bye,
  Roland



-- 
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/20110407195757.13181.42557.reportbug@newk

Re: Bash-completion with triggers

[David Kalnischkies]

On Thu, Apr 7, 2011 at 21:19, David Paleino  wrote:
> On Thu, 7 Apr 2011 22:14:31 +0300, Eugene V. Lyubimkin wrote:
>
>> On 2011-04-07 18:15, Goswin von Brederlow wrote:
>> > Dpkg::Post-Invoke would be the right (best available) one. That would
>> > call your trigger after every dpkg invocation [...]
>>
>> This is not true, 'Dpkg::*-Invoke' script chain are called once
>> before/after all dpkg invocations.
>
> So it's just like a trigger monitoring /? (without the implications of 
> triggers
> in terms of sequence of operations)

JFTR:
1. All scripts configured in DPKG::Pre-Invoke are called
2. All scripts configured in DPKG-Pre-Install-Pkgs are called
(and they get the information which packages will be installed).
3. APT does all the crazy stuff it does with dpkg
4. All scripts configured in DPKG::Post-Invoke are called

So in a way Post-Invoke could really be seen as a trigger on /.
And its not before/after every dpkg invocation, but before the first
and after the last dpkg invocation (as APT calls dpkg multiple times).


> This is meaningless to me. This way, my postinst would be run at *every* 
> package
> installation, not only those installing files in /usr/bin/ and companions.

Most real world operations include at least one package with a binary in
these locations. After all, i am installing or upgrading an application and
all its dependencies are just there because they are needed for it…

As all applications ship a manpage (lets dream that all are lintian clean)
we would have two triggers called again and again and properly multiple
times in a single APT operation…


If you would use the APT hooks users of plain dpkg would be out of luck.
Same for people with very obscure packagemanagers (e.g. smart),
but after all its completion and not something mission critical -
even if i can't live without completion myself - so its properly okay to
ignore these cases as people who really use it on a regular basis
will properly know how to set something up on their own.


If you want to, you can properly get along with searching for
accessed/modified files in those directories to get the knowledge
if something was changed and if yes you know even what.


Best regards

David Kalnischkies


--
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/BANLkTiJbkJ~m3-l5yd1wfzjked...@mail.gmail.com

Re: Updating GPG howto (http://keyring.debian.org/creating-key.html)

[brian m. carlson]

On Thu, Apr 07, 2011 at 10:26:10AM -0700, Jonathan McDowell wrote:
> It's not entirely accurate. The point of those lines are to ensure that
> older (certainly lenny and earlier, I'm not sure when the default
> changed) versions of GnuPG don't use SHA1 when signing keys (either your
> own or others).

From looking at the source code, it seems that the default digest
algorithm for signing both data and keys is still SHA-1.  There is some
special code to handle DSA keys with the size of q > 160 bits, since
SHA-1 wouldn't work in those cases.  This makes sense since it is the
must-implement hash algorithm.  So setting these preferences is still
recommended for current use.  While these preferences do affect key
signatures, they also affect other uses as well—uses where SHA-1 is
still a bad choice.

-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187


signature.asc
Description: Digital signature

compiling without -O2 ld shared lib errors

[Brian May]

Hello,

Am trying to compile Heimdal in unstable without -O2 optimization, so I can
debug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618992

To do this, I have inserted the line in debian/rules:

CFLAGS := "-g"

Unfortunately, when ever I do, I get the following error:

/bin/bash ../libtool --tag=CC   --mode=link gcc  -Wall -Wmissing-prototypes
-Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs
 -g   -o digest-service digest-service.o libkdc.la ../lib/ipc/
libheim-ipcs.la ../lib/hdb/libhdb.la ../lib/krb5/libkrb5.la  -lcrypto
 ../lib/asn1/libasn1.la ../lib/vers/libvers.la
../lib/roken/libroken.la-lcrypt  -ldb  -lresolv -pthread -lpthread
libtool: link: gcc -Wall -Wmissing-prototypes -Wpointer-arith
-Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -o
.libs/digest-service digest-service.o -pthread  ./.libs/libkdc.so
../lib/ipc/.libs/libheim-ipcs.a
/home/brian/tree/heimdal/git/heimdal/lib/roken/.libs/libroken.so
../lib/hdb/.libs/libhdb.so ../lib/krb5/.libs/libkrb5.so -lcrypto
../lib/asn1/.libs/libasn1.so ../lib/vers/.libs/libvers.a
../lib/roken/.libs/libroken.so -lcrypt -ldb -lresolv -lpthread -pthread
/usr/bin/ld: digest-service.o: undefined reference to symbol
'heim_ntlm_calculate_ntlm1@@HEIMDAL_NTLM_1.0'
/usr/bin/ld: note: 'heim_ntlm_calculate_ntlm1@@HEIMDAL_NTLM_1.0' is defined
in DSO //home/brian/tree/heimdal/git/heimdal/lib/ntlm/.libs/libheimntlm.so.0
so try adding it to the linker command line
//home/brian/tree/heimdal/git/heimdal/lib/ntlm/.libs/libheimntlm.so.0: could
not read symbols: Invalid operation
collect2: ld returned 1 exit status
make[2]: *** [digest-service] Error 1
make[2]: Leaving directory `/home/brian/tree/heimdal/git/heimdal/kdc'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/brian/tree/heimdal/git/heimdal'
make: *** [debian/stamp-makefile-build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1329:
dpkg-buildpackage -rfakeroot -D -us -uc failed


At first glance this appears be clear, except the error goes away when
compiling everything with -O2.

Any ideas?

What does the "Invalid operation" mean?
-- 
Brian May 

Liliana Silva desea chatear

[Liliana Silva]

Soy usuario de Google Talk y he pensado que quizás te gustaría
probarlo. Podemos utilizarlo para llamarnos de forma gratuita a través
de Internet. Te envío una invitación para que te descargues Google
Talk. ¡Pruébalo!

---
Liliana Silva quiere estar en contacto utilizando algunos productos
nuevos de Google.

Si ya tienes Gmail o Google Talk, visita:
http://mail.google.com/mail/b-78e40cb3bb-241dac7a85-bwO3hllVzdPHnH8O7pxG0VG2sGo
Tendrás que hacer clic en este enlace para poder chatear con Liliana Silva.

Para hacerte con Gmail (una cuenta de correo electrónico gratuita de
Google, con más de 2.800 megabytes de capacidad de almacenamiento) y
chatear con Liliana Silva, visita:
http://mail.google.com/mail/a-78e40cb3bb-241dac7a85-bwO3hllVzdPHnH8O7pxG0VG2sGo

Gmail ofrece:
- mensajería instantánea dentro de Gmail,
- protección eficaz frente a spam,
- una función de búsqueda integrada para buscar mensajes y un útil
sistema para organizar los mensajes en "conversaciones",
- además es una aplicación sin anuncios emergentes ni banners no
orientados; sólo tiene anuncios de texto e información relacionada que
son relevantes dado el contenido de tus mensajes.

Todo esto de manera gratuita. Pero espera, ¡aún hay más! Al abrir una
cuenta de Gmail, podrás acceder a Google Talk, el servicio de
mensajería instantánea de Google:

http://www.google.com/talk/intl/es/

Google Talk te ofrece:
- un servicio de chat web que podrás utilizar desde cualquier sitio,
sin necesidad de descargar nada,
- una lista de contactos sincronizada con tu cuenta de Gmail,
- llamadas de voz de PC a PC gratuitas y de alta calidad, al descargar
el cliente de Google Talk.

Trabajamos duro para añadir nuevas funciones y realizar mejoras, así
que es posible que te pidamos que nos envíes comentarios o sugerencias
de forma periódica. Agradecemos tu ayuda para mejorar nuestros
productos.
  Gracias,
El equipo de Google

Para obtener más información sobre Gmail y Google Talk, visita:
http://mail.google.com/mail/help/intl/es/about.html
http://www.google.com/talk/intl/es/about.html

 Si al hacer clic en las URL de este
mensaje no se abren los enlaces correspondientes, cópialas y pégalas
en la barra de direcciones de tu navegador.


--
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/banlktimxpyegfo2dj8ge8aahpjtezrs...@mail.gmail.com