Re: what about an special QA package priority?

[Miriam Ruiz]

2008/5/20 Luciano Bello <[EMAIL PROTECTED]>:
> Hi list,
>I was thinking about the Debian/OpenSSL debacle. Clearly it not easy to
> manage a hard meticulous QA process in all packages. In the other hand, there
> are packages more critical than others, which are more delicate to security.
>Sometimes, those packages have different priorities in the policy 
> meaning.
> Maybe we can implement this as an Optional header in the control.

Thinking about it again, I wonder if that could be implemented using
Enrico's DebTags. I think they would be perfect for this.

Miry


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Tue, 20 May 2008, Lars Wirzenius wrote:


I'm a fairly long-time Unix user. I find it much preferably when command
line tools are quiet by default when things are going well.


I completely agree.  I just have the feeling that some points were raised
in the discussion that things are not going that well, if patches of upstream
code are "kind of" hidden in the unpacked Debian source.  So this is rather
a definition what we understand as "going well".


Providing a
--verbose option rather than a --quiet option would be my preference.


If it is accompanied by a config file option for those people who might
forget to specify --verbose it is probably OK for this case.


Having a tool print out a lot of information that is peripheral to what
I'm doing is distracting, and if it happens often, I start mentally
ignoring the output until something breaks.


Important point!


Listing patches when I unpack source is one of those cases to me.


Summarizing the thread I would file a wishlist bug report saying
something like this:

  Subject: Please provide an option to list patches outside debian directory

  Please add a --verbose/-v option to 'dpkg-source -x' that performs

 lsdiff -z -x '*/debian/*' *.diff.gz

  to point potential maintainers / bug fixers to patches that reside
  outside of the debian directory.  It would be even better if a
  config file option would be parsed that enables to switch on this
  option by default.

Would you regard this as a useful bug report or not?

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: How to handle Debian patches

[Josselin Mouette]

Le mardi 20 mai 2008 à 23:03 -0500, Manoj Srivastava a écrit :
> > A quilt format package with a single combined patch. Get the
> > integration branch, get orig.tar.gz, build. dpkg-buildpackage will
> > automatically create a debian_version.patch for you. It is easy.
> 
> How is this better than the current diff.gz thing?

It is not better, but the point is that it is not *worse*.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Lars Wirzenius]

ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti:
> Would you regard this as a useful bug report or not?

I think that would be a rather excellently useful bug report. The only
way to improve it would be to include an actual patch to implement it.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Wed, 21 May 2008, Lars Wirzenius wrote:


ke, 2008-05-21 kello 09:09 +0200, Andreas Tille kirjoitti:

Would you regard this as a useful bug report or not?


I think that would be a rather excellently useful bug report.


OK, so I will go on filing it this way.


The only
way to improve it would be to include an actual patch to implement it.


... as always.  So I use the excuse (as always) that my time is currently
to limited to fiddle around with this things while trusting that the
implementation is easy enough for a person who knows the code much better
than me.  I had a look into dpkg-source before my proposal and it is
rather a matter of style how to resolve this bug and I would not try
to force my rude beginners style onto a perl professional.

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482162: ITP: haskell-safe -- Library for safe (pattern match free) functions.

[Magnus Therning]

Package: wnpp
Severity: wishlist
Owner: Magnus Therning <[EMAIL PROTECTED]>

* Package name: haskell-safe
  Version : 0.1
  Upstream Author : Neil Mitchell
* URL : 
http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Safe
* License : BSD
  Programming Lang: Haskell
  Description : Library for safe (pattern match free) functions.

A library for increasing the safety of your code, by wrapping Prelude
functions that potentially crash.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[Enrico Zini]

On Wed, May 21, 2008 at 09:00:45AM +0200, Miriam Ruiz wrote:

> Thinking about it again, I wonder if that could be implemented using
> Enrico's DebTags. I think they would be perfect for this.

Something like #436161 would be the place to start: it's about time to
resume that work.


Ciao,

Enrico

-- 
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Bug#482165: ITP: lxappearance -- a new feature-rich GTK+ theme switcher

[Andrew Lee]

Package: wnpp
Severity: wishlist
Owner: Andrew Lee <[EMAIL PROTECTED]>

* Package name: lxappearance
  Version : 0.1
  Upstream Authors: Hong Jen Yee (PCMan) <[EMAIL PROTECTED]>
Ying-Chun Liu (PaulLiu) <[EMAIL PROTECTED]>
* URL : http://lxde.sf.net
* License : (GPL)
  Programming Lang: (C)
  Description : a new feature-rich GTK+ theme switcher

 LXAppearance is a new feature-rich GTK+ theme switcher able to change
 GTK+ themes, icon themes, and fonts used by applications.
 .
 GNOME/KDE/XFce user may use build-in theme, this works for GTK+
 based lightweight desktop Environment.
 .
 Features:
  * Choose GTK+ theme
  * Choose icon theme
  * Install new icon theme
  * Choose their favorite font
  * Choose toolbar style
  * See changes immediately in preview area
 .
 LXAppearance is developed from LXDE(the Lightweight X11 Desktop
 Environment) project. But it works on other GTK+ based system too.

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Raphael Hertzog]

On Wed, 21 May 2008, Andreas Tille wrote:
>   Subject: Please provide an option to list patches outside debian directory
>
>   Please add a --verbose/-v option to 'dpkg-source -x' that performs
>
>  lsdiff -z -x '*/debian/*' *.diff.gz
>
>   to point potential maintainers / bug fixers to patches that reside
>   outside of the debian directory.  It would be even better if a
>   config file option would be parsed that enables to switch on this
>   option by default.
>
> Would you regard this as a useful bug report or not?

No. I'm currently evaluating a smooth transition from all orig+diff to the
3.0 (quilt) format and as such I'm not really interested in a new option
that only makes sense for the old format that I hope to deprecate in
lenny+1.

And I already said that the 3.0 (quilt) format list patches that it
applies during dpkg-source -x.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: package config

[Anthony]

Manoj Srivastava a écrit :
On Tue, 20 May 2008 08:34:10 +0200, Anthony  <[EMAIL PROTECTED]> said: 

  

Hello, everybody I have a little question about ucf (example with a
package which contains a file package_file.conf)



  

Can i use de package_file.conf.dpkg-old generate by the ucf utility?



Use it for what?

  
I would like to create a  package to configure my authentification on an 
ldap server.
All of my Debian Sarge Computer users are authenticated on a nis server 
or on passwd/group files.

AND i want to configure all of them on my ldap server.

So i need to install package :
libpam_ldap
libnss_ldap
ldap-utils
nss_updatedb
libnss-db

And change configurations :
pam_ldap.conf
libnss_ldap.conf
/etc/ldap/ldap.conf
nsswitch.conf
nss_updatedb cron.hourly



I would like to know how can i restore the old conf files after use
ucf.?



If this is in a maintainer script, just don't run ucf. If this
 is as an end user, you should have been asked a question had you
 modified the file -- and yes, you can recover the older version of the
 file.

  
I want to preserve my configuration, so i would like to use ucf (or 
dpkg-divert)


But maybe i don't understand the necessity of the ucf utility.
If the file is not a conffile, does i need to use it?
But, even if it is not a conffile, a upgrade can override it.?

What i have done :
My package install the files in /usr/share/site_configuration/.
My postinst script use ucf to install them in the right place.

It 's not a good job ?



I have created a package which manage some files with ucf BUT when i
remove the package i would like to restore the files before the
installation .  I could rename the file package_file.conf.dpkg-old in
package_file.conf in postrm script (remove)



The dpkg.old file might not exist at that point ( the user might
 have gotten rid of it, for one thing). If you want to reliably do that,
 copy the file somewhere safe, and restore from your cached location
 later.  Depending on the old file being around is risky.

  

So i could:
save the old configuration files (maybe in 
/usr/share/site_configuration_backup/.)

My package install the files in /usr/share/site_configuration/.
My postinst script use ucf to install them in the right place.
On postrm or prerm (remove) , restore the backup files.
(and on purge, purge the ucf stuff)


Thank you for your recommendations...


Anthony




manoj
  

Bug#482169: ITP: lxlauncher -- Easy-Mode launcher for subnotebook like EeePC

[Andrew Lee]

Package: wnpp
Severity: wishlist
Owner: Andrew Lee <[EMAIL PROTECTED]>


* Package name: lxlauncher
  Version : 0.1.6
  Upstream Author : 洪任諭 Hong Jen Yee (PCMan) <[EMAIL PROTECTED]>
* URL : http://lxde.org/
* License : (GPL, LGPL)
  Programming Lang: (C)
  Description : Easy-Mode launcher for subnotebook like EeePC

 LXLauncher is a lightweight GTK+ 2.x based Easy-Mode launcher for
 subnotebook like EeePC.
 .
 It is standard-compliant and desktop-independent. It follows
 freedesktop.org specs, so newly added applications will automatically
 show up in the launcher, and vice versa for the removed ones.
 .
 Drop the limieted Asus launcher and try LXLauncher today!

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Wed, 21 May 2008, Raphael Hertzog wrote:


Would you regard this as a useful bug report or not?


No.


Ups, it's just to late (#482166)


I'm currently evaluating a smooth transition from all orig+diff to the
3.0 (quilt) format and as such I'm not really interested in a new option
that only makes sense for the old format that I hope to deprecate in
lenny+1.


Hmmm, do you regard it as realistic that all maintainers will change to
a new format in Lenny+1?  I do not think of maintainers who are in principle
not happy about this format but those who maintain packages that might stay
untouched perfectly fine over years?  I would personally welcome your plan,
but I have certain doubts that such kind of transitions are faster than
for instance /usr/doc -> /usr/share/doc and something like that.


And I already said that the 3.0 (quilt) format list patches that it
applies during dpkg-source -x.


Which is nice - and thus I would love to see this implemented now for
every format if it can be approached fairly easy.  But the maintainer
has the last word and I have no real problem if you tag the bug wontfix
or just close it.  I personally do this anyway on my systems - I just
thought that the idea would add some tiny bit to help in the problem
we detected.

Kind regards

 Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: package config

[Josselin Mouette]

Le mercredi 21 mai 2008 à 10:39 +0200, Anthony a écrit :  
> I would like to create a  package to configure my authentification on
> an ldap server.
> All of my Debian Sarge Computer users are authenticated on a nis
> server or on passwd/group files.
> AND i want to configure all of them on my ldap server.
> 
> So i need to install package :
> libpam_ldap
> libnss_ldap
> ldap-utils
> nss_updatedb
> libnss-db
> 
> And change configurations :
> pam_ldap.conf
> libnss_ldap.conf
> /etc/ldap/ldap.conf
> nsswitch.conf
> nss_updatedb cron.hourly

> What i have done :
> My package install the files in /usr/share/site_configuration/.
> My postinst script use ucf to install them in the right place.
> 
> It 's not a good job ?

It is not possible for a package to change another package’s conffiles,
even by using ucf. The changes would be considered local by the next
upgrade of the package you are modifying the configuration.

The appropriate tool for modifying such configuration is a centralized
administration utility like puppet or cfengine.

Cheers,
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Ben Finney]

Andreas Tille <[EMAIL PROTECTED]> writes:

> On Wed, 21 May 2008, Raphael Hertzog wrote:
> > I'm currently evaluating a smooth transition from all orig+diff to
> > the 3.0 (quilt) format and as such I'm not really interested in a
> > new option that only makes sense for the old format that I hope to
> > deprecate in lenny+1.
> 
> Hmmm, do you regard it as realistic that all maintainers will change to
> a new format in Lenny+1?

"$FOO is deprecated in lenny+1" means that, in lenny+1, usage of $FOO
will be deprecated. It doesn't mean "no-one is permitted to use $FOO".

At some point *after* deprecation (i.e. "at some point after lenny+1",
in this example), $FOO becomes unsupported, but preferably only after
a significant proportion has responded to the deprecation by migrating
away from $FOO.

> but I have certain doubts that such kind of transitions are faster
> than for instance /usr/doc -> /usr/share/doc and something like
> that.

A perfect example. '/usr/doc' was deprecated for a long time, yet it
was not until most packages had migrated away from it that it became
mandatory to do so.

-- 
 \"If you continue running Windows, your system may become |
  `\unstable." —Microsoft, Windows 95 bluescreen error message |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Raphael Hertzog]

On Wed, 21 May 2008, Andreas Tille wrote:
> Hmmm, do you regard it as realistic that all maintainers will change to
> a new format in Lenny+1?  I do not think of maintainers who are in principle
> not happy about this format but those who maintain packages that might stay
> untouched perfectly fine over years?  I would personally welcome your plan,
> but I have certain doubts that such kind of transitions are faster than
> for instance /usr/doc -> /usr/share/doc and something like that.

Because if the new format is the default format built by dpkg-source, this
will happen automatically when you rebuild your packages... of course, it
means that all the .diff.gz (except the debian dir) will end up in a single
debian/patches/debian-changes-.diff if you don't take care to
put the changes in separate patches.

But the new source package will still be 3.0 (quilt) and at unpack time
you'll be informed that "debian-changes-.diff" is applied.

> Which is nice - and thus I would love to see this implemented now for
> every format if it can be approached fairly easy.  But the maintainer

What means now? dpkg in lenny is frozen... 

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Should dpkg-source -x list patches (Re: How to handle Debian patches)

[Andreas Tille]

On Wed, 21 May 2008, Raphael Hertzog wrote:


Because if the new format is the default format built by dpkg-source, this
will happen automatically when you rebuild your packages...


Yes.  But there is probably some statistics about packages that are not
rebuild inbetween two releases.  I admit that most probably those packages
are not really the candidates that might need extra care about security
patches.


Which is nice - and thus I would love to see this implemented now for
every format if it can be approached fairly easy.  But the maintainer


What means now? dpkg in lenny is frozen...


"Now" means what you can expect for a wishlist bug - just going to unstable
according to maintainers decision.  And unstable is the place were packages
you might like to change normaly reside - so it would perfectly fit.

But well, I suggest we just end this discussion here.  There are enough
threads running and after having filed the bug I turned my idea into the
shape I wanted it to be.  The dpkg-dev maintainers will decide ...

Kind regards

   Andreas.

--
http://fam-tille.de


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

vserver Linux image packages in Lenny ?

[Olivier Berger]

Hi.

The question seems to be discussed in several bug reports (#392015,
#478651), but I can't see any hints on Lenny shipping with some vserver
flavour of the Linux kernel.

What will be the proposed solution for deployed servers using vserver on
Debian once Lenny becomes stable (2.6.22 seems the latest version
supporting vserver patches, and it's apparently considered too old for
support by the Linux kernel maintainers in Debian) ?

Thanks in advance.

Best regards,
-- 
Olivier BERGER <[EMAIL PROTECTED]> (*NEW ADDRESS*)
http://www-inf.it-sudparis.eu/~olberger/ - OpenPGP-Id: 1024D/6B829EEC
Ingénieur Recherche - Dept INF
Institut TELECOM / TELECOM & Management SudParis (http://www.it-sudparis.eu/), 
Evry



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[martin f krafft]

also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.05.18.0401 +0100]:
> I won't speak for Joey, but I consider a divergence a bug in the sense
> that I'd use with a general bug-tracking system: it's something about the
> package and/or the packaged software that, in an ideal world, would be
> improved.  Nothing more (or less) than that.

Like making upstream software use something like sensible-browser?

I do see parallels between upstream divergence and bugs and keeping
your bug record down means having to feed upstream, but some changes
are Debian-specific and make the source diverge from upstream, and
yet they are not at all bugs, not even wishlists.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"my father, a good man, told me:
'never lose your ignorance; you cannot replace it.'"
   -- erich maria remarque


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: divergence from upstream as a bug

[martin f krafft]

also sprach Joey Hess <[EMAIL PROTECTED]> [2008.05.17.2238 +0100]:
> If you grab a patch from upstream that you know will be in a future
> upstream release, the divergence is temporary. You can choose not to
> file a bug report in our BTS about it, knowing that it will clear up.

... and suddenly the whole thing becomes useless because the
divergence isn't recorded in this instance. If a change is not in
0.2 but in 0.3, but 0.2-2 cherry-picked it, well, it's a divergence.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
never underestimate the power of human stupidity.


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

track bugs in VCS, not the other way around (was: divergence from upstream as a bug)

[martin f krafft]

also sprach Joey Hess <[EMAIL PROTECTED]> [2008.05.17.2201 +0100]:
> What if we just decide that changes made to upstream sources[1] qualify
> as a bug? A change might be a bug in upstream, or in the debianisation,
> or in Debian for requiring the change. But just call it a bug.
> Everything else follows from that quite naturally..

I am not even going to try to read this thread, so please excuse if
I repeat what others have said. We should make it policy that the
original proponent of a discussion (Joey here) becomes the chair and
has to keep a summary of the discussion up to date on a wiki. I know
you'll hate me, Joey, but I think it would make sense.

Let me say up front, that I agree with the parallels between bugs
and divergence, since we want to minimise diffs and keep bug counts
low.

However, I think Joey's idea would be a step backwards. Let me
explain.

> The BTS could be enhanced to allow opening a bug and forwarding it
> upstream in a single message. (IIRC currently, it takes two). This would
> allow a very simple workflow where a DD makes a change to a package,
> generates a patch, and sends it upstream while also recording the
> divergence in the BTS.

I love debbugs, dearly! It fits nicely into my workflow, or maybe it
welded my workflow, I don't care -- I like it.

But it's awfully brittle and a giant pile of hack. If we didn't have
Don and the few others who aren't entirely confused by the code
base, we wouldn't have bugs.debian.org anymore.

I cringe every time we make an enhancement to debbugs, pictures of
band aids and superglue come into my mind, and I fear the day when
our (over-)reliance on debbugs is going to hurt us *bad*.

We have a lot of "integration" in place between debbugs and other
parts of the project, like the PTS, debian/changelog parsing, etc
etc etc. They work for the most part, but they're horribly brittle
I find. It seems to me that a lot of information is stored in more
than one place, creating redundancy which will cause problems, or if
not, then at least require massive amounts of extra work to keep it
in sync.

Atomicity does not exist.

What we're trying to do right now is more or less keep track of
patches in Debian packages. Joey proposes to use bug reports for
that. It *does* make some sense, but it's far-fetched. Very
far-fetched. Yes, we want to minimise bug count *and* diversion from
upstream, but does that mean we have to map one onto the other?

Let's assume for a minute that we accept that VCSs are the way
forward and start to consider how we could track bugs in the VCS,
alongside the code.

Start to think about it this way, and stuff suddenly neatly aligns,
at least in my world.

Suddenly you can commit a patch and mark the bug fixed atomically.

Suddenly, bug reports become commits in a branch, and keeping the
branch empty is your goal.

Divergence from upstream is represented in topic branches, and you
want to keep the number of those minimal to not go insane.

You also get all the benefits of a distributed system and if we find
ways to cooperate with other distros via one and the same repository
[0], bugs would be shared, but done right from the start [1].

0. http://vcs-pkg.org
1. http://madduck.net/blog/2008.05.06:how-launchpad-got-it-wrong

I have no details on this yet, but the general idea. Let's not
create more dependence on our aging BTS, please.

And yes, I will try to create a wiki page summarising this subthread
in the next few weeks, if the idea isn't completely unrealistic.

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
"and if the cloud bursts, thunder in your ear
 you shout and no one seems to hear
 and if the band you're in starts playing different tunes
 i'll see you on the dark side of the moon."
   -- pink floyd, 1972


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

Re: what about an special QA package priority?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/20/08 23:11, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
>> even though it's "just" a command line utility.  Who knows what
>> weird, unexpected side effects there might be from running such an
>> app within a tight bash loop.
> 
> none*. And not cleaning up yourself also improves performance for short
> running apps.

How so?

> Gruss
> Bernd
> 
> * unless we talk persistent resources like files or ipc.

That's the point.  And what if there's a kernel (or would that be a
glibc?) bug?

Since you can't know the future of your software (more than once,
I've seen a one-off script or program morph-expand into an important
and much larger app) or the OS it will run on in the future, it's
always good to clean up after yourself.

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINCb2S9HxQb37XmcRAq4WAKCd+UGDDIKarUy7YuznusgS1ZxIeACfadoc
3uC4lFzrlrkckOFSJtJWJbQ=
=Z30s
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: divergence from upstream as a bug

[Russ Allbery]

martin f krafft <[EMAIL PROTECTED]> writes:
> also sprach Russ Allbery <[EMAIL PROTECTED]> [2008.05.18.0401 +0100]:

>> I won't speak for Joey, but I consider a divergence a bug in the sense
>> that I'd use with a general bug-tracking system: it's something about
>> the package and/or the packaged software that, in an ideal world, would
>> be improved.  Nothing more (or less) than that.

> Like making upstream software use something like sensible-browser?

If it were a configure option, we wouldn't need an upstream divergence and
could just add a configure option in debian/rules.

Any time we're actually patching upstream source, there's going to be some
way that we could avoid that by adding more configuration to upstream.
I'm not sure that's *always* a good idea, but in most cases it would be.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482269: ITP: libmath-sparsevector-perl -- Provides a sparse vector class for perl

[Bas Zoetekouw]

Package: wnpp
Severity: wishlist
Owner: Bas Zoetekouw <[EMAIL PROTECTED]>

* Package name: libmath-sparsevector-perl
  Version : 0.04
  Upstream Author : Amruta Purandare, Ted Pedersen, Mahesh Joshi
* URL : http://search.cpan.org/~tpederse/Math-SparseVector/
* License : GPL-2+ | Artistic
  Programming Lang: Perl
  Description : Provides a sparse vector class for perl

Supports sparse vector operations such as setting a value in a vector,
reading a value at a given index, obtaining all indices, addition and
dot product of two sparse vectors, and vector normalization.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482272: ITP: libmath-sparsematrix-perl -- Provides a sparse matrix class for perl

[Bas Zoetekouw]

Package: wnpp
Severity: wishlist
Owner: Bas Zoetekouw <[EMAIL PROTECTED]>

* Package name: libmath-sparsematrix-perl
  Version : 0.03
  Upstream Author : Ted Pedersen and Mahesh Joshi
* URL : http://search.cpan.org/~tpederse/Math-SparseMatrix/
* License : GPL-2+
  Programming Lang: Perl
  Description : Provides a sparse matrix class for perl

Math::SparseMatrix provides simple sparse matrix functionality such as
creation of sparse matrices, writing them out to a file, reading
matrices from files and reading transpose of a matrix stored in a
file.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-6-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482277: ITP: unbound -- validating, recursive, caching DNS resolver

[Robert Edmonds]

Package: wnpp
Owner: "Robert S. Edmonds" <[EMAIL PROTECTED]>
Severity: wishlist

* Package name: unbound
  Version : 1.0.0
  Upstream Author : NLnet Labs
* URL : http://libev.schmorp.de/
* License : BSD
  Programming Lang: C
  Description : validating, recursive, caching DNS resolver

 Unbound is a validating, recursive, and caching DNS resolver. 
 .
 The C implementation of Unbound is developed and maintained by NLnet
 Labs. It is based on ideas and algorithms taken from a java prototype
 developed by Verisign labs, Nominet, Kirei and ep.net. 
 .
 Unbound is designed as a set of modular components, so that also DNSSEC
 (secure DNS) validation and stub-resolvers (that do not run as a
 server, but are linked into an application) are easily possible.

-- 
Robert Edmonds
[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Bug#482278: ITP: libtext-csv-perl -- comma-separated values manipulator (using XS or PurePerl)

[Vincent Danjean]

Package: wnpp
Severity: wishlist
Owner: Vincent Danjean <[EMAIL PROTECTED]>

WARNING: mapping between CPAN packages and Debian packages changed
All maintainer of rdepends on the old libtext-csv-perl are in CC of this
mail. Please, read all this mail.

* Package name: libtext-csv-perl
  Version : 1.05
  Upstream Author : Alan Citterman and Makamaka Hannyaharamitu
* URL : http://search.cpan.org/dist/Text-CSV/
* License : Perl (GPL+Artistic)
  Programming Lang: Perl
  Description : comma-separated values manipulator (using XS or PurePerl)

 Text::CSV provides facilities for the composition and decomposition of
 comma-separated values. An instance of the Text::CSV class can combine
 fields into a CSV string and parse a CSV string into fields.
 .
 The module accepts either strings or files as input and can utilize any
 user-specified characters as delimiters, separators, and escapes so it is
 perhaps better called ASV (anything separated values) rather than just CSV.
 .
 To work, Text::CSV can use either Text::CSV_PP (a Pure Perl module present in
 this package) or Text::CSV_XS (a XS module, thus optimised, provided by the
 libtext-csv-xs-perl package).


Explainations:
  All of this follows a discussion on the pkg-perl-maintainers ML. The
  goal is to follow upstream and remove Debian specific patches.

From this version, this Debian package (libtext-csv-perl) will contain
  the perl CPAN package Text::CSV.
Before this version, this Debian package (libtext-csv-perl) contained
  the perl CPAN package Text::CSV_XS.
From now, Text::CSV_XS will be packaged in the debian package
  libtext-csv-xs-perl.
  
  Text::CSV is a generic perl package that can call Text::CSV_XS if available.
  Indeed, Text::CSV_XS provides a optimized version of Text::CSV routines.

  The old libtext-csv-perl (with Text::CSV_XS) had a patch to provide the
  Text::CSV interface. So replacing the old patched Text::CSV_XS by the
  new Text::CSV (ie only upgrading this 'libtext-csv-perl' package) should
  works. However, you are strongly encouraged to install the new
  libtext-csv-xs-perl package (recommended by this package) to keep previous
  performancies.


  Maintainers of rdepends package of libtext-csv-perl should check if
their package still work with this new package but without
libtext-csv-xs-perl (with, of course, degraded performances).
  If not, please add a new dependency on your packages to
libtext-csv-xs-perl (but keep libtext-csv-perl is you want to have to
Text::CSV interface) and tell me so that I can add a conflict with your
old versions.
  You can of course also add a dependency to libtext-csv-xs-perl if you
want to ensure good performencies but I will not add a conflict if there
is only degraded performencies.

  These two new packages will be available on my webpage[1,2] this
evening (when I will get this ITP number).

[1]: http://www-id.imag.fr/~danjean/deb.html#libtext-csv-perl
[2]: http://www-id.imag.fr/~danjean/deb.html#libtext-csv-xs-perl

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: track bugs in VCS, not the other way around

[Jelmer Vernooij]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Martin,

martin f krafft wrote:
[...]
> What we're trying to do right now is more or less keep track of
> patches in Debian packages. Joey proposes to use bug reports for
> that. It *does* make some sense, but it's far-fetched. Very
> far-fetched. Yes, we want to minimise bug count *and* diversion from
> upstream, but does that mean we have to map one onto the other?
>
> Let's assume for a minute that we accept that VCSs are the way
> forward and start to consider how we could track bugs in the VCS,
> alongside the code.
>
> Start to think about it this way, and stuff suddenly neatly aligns,
> at least in my world.
>
> Suddenly you can commit a patch and mark the bug fixed atomically.
>
> Suddenly, bug reports become commits in a branch, and keeping the
> branch empty is your goal.
>
> Divergence from upstream is represented in topic branches, and you
> want to keep the number of those minimal to not go insane.
>
> You also get all the benefits of a distributed system and if we find
> ways to cooperate with other distros via one and the same repository
> [0], bugs would be shared, but done right from the start [1].
>
> 0. http://vcs-pkg.org
> 1. http://madduck.net/blog/2008.05.06:how-launchpad-got-it-wrong
>
> I have no details on this yet, but the general idea. Let's not
> create more dependence on our aging BTS, please.
>
> And yes, I will try to create a wiki page summarising this subthread
> in the next few weeks, if the idea isn't completely unrealistic.
Have you seen bugs everywhere (http://www.bugseverywhere.org) ? It's a
distributed bug tracker that stores bug information as metadata in VCS
branches.

I don't think it's exactly what you're talking about but it may be a
source of inspiration.

Cheers,

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

iQCVAwUBSDQysgy0JeEGD2blAQJl2gP+N5bEFaZspXP/3ELAOL37dkCeU3mbzmAO
4S5glbsDXqSnesvxCqY9ZULAPPatkSOYFcFMnkbC4YN+AwXE4S6xx4RQBcUZcdeK
0oMobJp6k3JzwNmuFGCX/usF1lRvs1+sXnPLsAh+2FAamM7iuKcEZ8O7mkUyuJtQ
YsmfP5nmtbU=
=pjNx
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: track bugs in VCS, not the other way around

[martin f krafft]

also sprach Jelmer Vernooij <[EMAIL PROTECTED]> [2008.05.21.1633 +0200]:
> Have you seen bugs everywhere (http://www.bugseverywhere.org)
> ? It's a distributed bug tracker that stores bug information as
> metadata in VCS branches.

Yes, but I didn't remember the name on the plane. :)

-- 
 .''`.   martin f. krafft <[EMAIL PROTECTED]>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems
 
perl -e 'print "The earth is a disk!\n" if ( "a" == "b" );'
   (dedicated to nori)


digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)

FYI: VCS choice these days

[Osamu Aoki]

Hi, (Composed as UTF-8 mail with graphic characters)

I have been trying to update debian reference.  As a part of this
effort, I made snapshot of popularity of packages.

One of the most interesting thing I noticed by doing this was change in
popularity of VCS.  (Just 1/2 year r so).

When I started to track popcon data, CVS was used more than SVN.  GIT
was just had very minor portion of VCS user.

Here are a summary of the version control system (VCS) on the Debian system now:

Table 11.10.  List of version control system tools.

┌──┬┬─┬──┬───┬─┐
│ package  │ popcon │size │   tool   │ VCS type  │ comment  
   │
├──┼┼─┼──┼───┼─┤
│cssc  │V:0.01, │2168 │CSSC  │local  │Clone of the Unix SCCS
   │
│  │I:0.06  │ │  │   │(deprecated)  
   │
├──┼┼─┼──┼───┼─┤
│rcs   │V:1.9,  │756  │RCS   │local  │"Unix SCCS done right"
   │
│  │I:10│ │  │   │  
   │
├──┼┼─┼──┼───┼─┤
│cvs   │V:5,│3624 │CVS   │remote │The previous standard remote 
VCS │
│  │I:30│ │  │   │  
   │
├──┼┼─┼──┼───┼─┤
│subversion│V:9,│3456 │Subversion│remote │"CVS done right", the new de  
   │
│  │I:26│ │  │   │facto standard remote VCS 
   │
├──┼┼─┼──┼───┼─┤
│git-core  │V:3, I:5│6712 │Git   │distributed│fast DVCS in C (used by the 
Linux│
│  ││ │  │   │kernel and others)
   │
├──┼┼─┼──┼───┼─┤
│mercurial │V:0.6,  │372  │Mercurial │distributed│DVCS with python and some C.  
   │
│  │I:2 │ │  │   │  
   │
├──┼┼─┼──┼───┼─┤
│darcs │V:0.3,  │6168 │Darcs │distributed│DVCS with smart algebra of
   │
│  │I:1.8   │ │  │   │patches (slow).   
   │
├──┼┼─┼──┼───┼─┤
│bzr   │V:0.3,  │15012│Bazaar│distributed│DVCS with python (used by the 
   │
│  │I:1.8   │ │  │   │Ubuntu)   
   │
└──┴┴─┴──┴───┴─┘

V sands for vote (i.e. use)  and I stands for install.  Numbers are % of popcon 
votes.

CVS is not as used as SVN these days.  Within DVCS, GIT is 5-10 folds
popular than other ones.

So I can safely say that SVN is now the default VCS and GIT is getting
very popular in use and have 1/3 of top SVN.  (popcon data is diluted by
old machines so I think GIT use is a lot.)

See more on 
http://people.debian.org/~osamu/pub/getwiki/html/ch11.en.html#listofversioncontrolsystemtools

Osamu


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

elegant tgs tw Bitch total while then.

[freidafrankum772534]

sweet p yu Bolwjob businessman spoke shoulder thread shut tongue ink.
wu q http://tmissionggc.tripod.com answer tommorrow competition thus post might 
comfort compete slowly situation.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

packages up for adoption

[Joey Hess]

I'll no longer be maintaining the following packages. I plan to orphan
them next week and hope to find new maintainers for them before then.

aalib
acpi
analog
archivemail
fbreader (and liblinebreak, a dependency)
grepmail (whoever takes this will probably want to be on the perl team,
  it's tightly tied to libmail-mbox-messageparser-perl and releases
  sometimes need to be coordinated)
intercal
ixp4xx-microcode
longrun
metastore (David Härdeman has first dibs as an upstream connected with Debian)
procmeter3
rss2email
snowdrop
sparkline-php
splitvt
sysnews
uboot-mkimage
unclutter
xaos
xaoom
znc

I also have several games up for adoption. The games team has first
pick.

bsdgames
kobodeluxe
nestra
dgen (non-free)
oneko
uqm, uqm-content (already claimed by games team)
xbl
xemeraldia
xgalaga
xjewel
xtris

-- 
see shy jo


signature.asc
Description: Digital signature

Re: what about an special QA package priority?

[peter green]

none*. And not cleaning up yourself also improves performance for short
running apps.

How so?


The libraries request memory from the kernel in pages (4k on i386, will vary
on other architectures), they then run thier own heap management system within
those pages. Some memory managers will return pagess to the OS when they become
completely empty others will not.

When the application quits the kernel cleans it up, every page it owns is 
reclaimed
without having to even look at the memory manager structures inside.

in other words freeing the memory you have allocated before quitting takes time 
and achives nothing usefull.





--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Gutenprint 5.2 prerelease in experimental

[Roger Leigh]

Hi folks,

I have packaged the gutenprint 5.2 beta release in experimental.  If
anyone could take the time to let me know if it works with their
printer, that would be great.

I currently don't have access to an inkjet printer, so if someone
could take five minutes to install it and try printing, that would be
great.

BTW, I'm still looking for a maintainer, otherwise I'll be orphaning
it entirely within the month--I have no time to care for it and it
desperately needs a maintainer.


Thanks,
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.


pgpkLDRKzNhxW.pgp
Description: PGP signature

Re: FYI: VCS choice these days

[Steve Greenland]

On 21-May-08, 11:15 (CDT), Osamu Aoki <[EMAIL PROTECTED]> wrote: 
> Hi, (Composed as UTF-8 mail with graphic characters)
> 
> I have been trying to update debian reference.  As a part of this
> effort, I made snapshot of popularity of packages.
> 
> One of the most interesting thing I noticed by doing this was change in
> popularity of VCS.  (Just 1/2 year r so).
> 
> When I started to track popcon data, CVS was used more than SVN.  GIT
> was just had very minor portion of VCS user.
> 
> Here are a summary of the version control system (VCS) on the Debian system 
> now:
> [*snip*] 

FWIW, and I'm not sure it actually conflicts or invalidates or even
causes questions of the popcon data, but installs, at least, may not
mean that much. On my main home box, several years old now, I've got all
of cvs, svn, rcs[1], mercurial, git, and bzr installed, because at one
point or another I've need to grab source from a repository that used
that particular tool. Currently I only *use* mercurial. 

Steve

[1] Used to track changes to config files until mercurial came along.

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FYI: VCS choice these days

[Mike Hommey]

On Wed, May 21, 2008 at 03:10:14PM -0500, Steve Greenland wrote:
> On 21-May-08, 11:15 (CDT), Osamu Aoki <[EMAIL PROTECTED]> wrote: 
> > Hi, (Composed as UTF-8 mail with graphic characters)
> > 
> > I have been trying to update debian reference.  As a part of this
> > effort, I made snapshot of popularity of packages.
> > 
> > One of the most interesting thing I noticed by doing this was change in
> > popularity of VCS.  (Just 1/2 year r so).
> > 
> > When I started to track popcon data, CVS was used more than SVN.  GIT
> > was just had very minor portion of VCS user.
> > 
> > Here are a summary of the version control system (VCS) on the Debian system 
> > now:
> > [*snip*] 
> 
> FWIW, and I'm not sure it actually conflicts or invalidates or even
> causes questions of the popcon data, but installs, at least, may not
> mean that much. On my main home box, several years old now, I've got all
> of cvs, svn, rcs[1], mercurial, git, and bzr installed, because at one
> point or another I've need to grab source from a repository that used
> that particular tool. Currently I only *use* mercurial. 

Also, one can have, for instance, cvs or svn installed because they use
git-cvsimport or git-svn.

Mike


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FYI: VCS choice these days

[Michal Čihař]

Dne Wed, 21 May 2008 15:10:14 -0500
Steve Greenland <[EMAIL PROTECTED]> napsal(a):

> FWIW, and I'm not sure it actually conflicts or invalidates or even
> causes questions of the popcon data, but installs, at least, may not
> mean that much. On my main home box, several years old now, I've got all
> of cvs, svn, rcs[1], mercurial, git, and bzr installed, because at one
> point or another I've need to grab source from a repository that used
> that particular tool. Currently I only *use* mercurial. 

Well, popcon is not probably best source of such information, but there
is hard to find better one. For me, I have installed cvs, svn, bzr,
git and darcs (at least, I did not really check, but these I use
regularly), most of them just because I have to use them in some
projects...

-- 
Michal Čihař | http://cihar.com | http://blog.cihar.com


signature.asc
Description: PGP signature

Re: what about an special QA package priority?

[Luciano Bello]

El Mar 20 May 2008, Nicolas François escribió:
> It will be hard to define this list of "delicate" packages.
> For example, I'm not sure I would have put openssl in the list a few weeks
> ago.
> I would have first think about setuid/setgid programs, servers, with high
> popcon packages first.

I agree, we should sharpen the definition of "delicate" packages:
- setuid/setgid programs.
- network servers with high popcon (how much is high?)
- packages which implements cryptographic algorithms (like python-crypto)

What about compilers and interpreters (like gcc and perl)? Kernel and drivers?

luciano


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

Bug#482334: ITP: trac-git -- Git version control backend for Trac

[Jonny Lamb]

Package: wnpp
Severity: wishlist
Owner: Jonny Lamb <[EMAIL PROTECTED]>
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: trac-git
  Version : 0.0.20080122
  Upstream Author : Hans Petter Jansson <[EMAIL PROTECTED]>
* URL : http://nanosleep.org/git/trac-git-plugin
* License : GPL
  Description : Git version control backend for Trac
 
 A plugin that provides support for the Git source code management
 tool for Edgewall Software's Trac.

-- 
Jonny Lamb, UK   [EMAIL PROTECTED]
http://jonnylamb.com GPG: 0x2E039402


signature.asc
Description: Digital signature

Re: track bugs in VCS, not the other way around

[Ben Finney]

Jelmer Vernooij <[EMAIL PROTECTED]> writes:

> Have you seen bugs everywhere (http://www.bugseverywhere.org) ? It's a
> distributed bug tracker that stores bug information as metadata in VCS
> branches.

I'm currently working on http://bugs.debian.org/477125> a Debian
package for Bugs Everywhere
http://bzr.debian.org/bzr/collab-maint/bugs-everywhere/>.

> I don't think it's exactly what you're talking about but it may be a
> source of inspiration.

Bugs Everywhere is a simple idea that is a good way to have a BTS for
people whose main mode of collaborating is via a DVCS, and won't or
can't set up a central bug tracker. This fits enough projects that I'm
on that I was motivated to package it in Debian.

However, I think that for people who have 'debbugs' to work with (i.e.
the Debian project), Bugs Everywhere might actually be a step
*backward* from 'debbugs'.

Currently, a Bugs Everywhere database is visible only to those who use
the VCS to get a copy of the branch, and use the Bugs Everywhere
command-line tool to query the database. The 'debbugs' available to
Debian developers has a web interface that over the last few years
provides comprehensive order out of the chaos of our bug database.

Currently, a Bugs Everywhere database can be manipulated only be
people who will use the VCS to get a branch, use the command-line tool
to manipulate bugs, and use the VCS again to propagate their changes
to others. Using 'debbugs' requires only that one know how to send
email.

These interface issues alone are enough to disqualify something like
Bugs Everywhere from being proposed as a serious alternative to
Debian's 'debbugs' instance. Likely a quick look at the actual
features of Bugs Everywhere would easily come up with other
shortcomings compared to 'debbugs', but I won't.

-- 
 \ “I think there is a world market for maybe five computers.” |
  `\ —Thomas Watson, chairman of IBM, 1943 |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: FYI: VCS choice these days

[Ben Finney]

Steve Greenland <[EMAIL PROTECTED]> writes:

> FWIW, and I'm not sure it actually conflicts or invalidates or even
> causes questions of the popcon data, but installs, at least, may not
> mean that much. On my main home box, several years old now, I've got
> all of cvs, svn, rcs[1], mercurial, git, and bzr installed, because
> at one point or another I've need to grab source from a repository
> that used that particular tool. Currently I only *use* mercurial.

Exactly the same situation here, modulo "only use Bazaar".

I think tracking "installed" isn't of interest for this study.

-- 
 \“None can love freedom heartily, but good men; the rest love |
  `\   not freedom, but license.” —John Milton |
_o__)  |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#482342: ITP: madfuload -- Firmware loader for M-Audio DFU audio devices

[Free Ekanayaka]

Package: wnpp
Severity: wishlist
Owner: Free Ekanayaka <[EMAIL PROTECTED]>


* Package name: madfuload
  Version : 1.2
  Upstream Author : Clemens Ladisch <[EMAIL PROTECTED]>
* URL : http://usb-midi-fw.sourceforge.net/
* License : GPL
  Description : Firmware loader for M-Audio DFU audio devices

 This packages allows you to use M-Audio's DFU audio devices
 with Linux. These devices require a firmware download before
 an operating system driver (e.g. ALSA's snd-usb-audio) can
 access them.
 .
 Supported devices:
  - Sonica
  - Ozone
  - MobilePre USB (some newer models work without the loader)
  - Transit
 The loader is not required for some newer models of the above devices,
 like the Ozone Academic.

-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

IPhone big problem

[gusti]

Hello

Yesterday when I was changing the password in my IPhone. That work is 
possible editing the file "/etc/master.passwrd" as root (see the link 1 
below). In the middle of the work I lost the ssh session with the IPhone 
and now I can't ssh login to the IPhone using the old root IPhone 
password (alpine). And also I can't see the file "/etc/master.paswrd" 
from a IPhone terminal because I need root permission for that.


ANY IDEA PLEAS!!! WHAT CAN i DO NOW???


Thanks a lot in advance,
 Gustavo

link 1: 
http://blog.matsimitsu.nl/english/183/howto-fix-the-edit-home-screen-loop-for-iphone 



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

IPhone big problem

[ggusti.ar]

Hello

Yesterday when I was changing the password in my IPhone. That work is 
possible editing the file "/etc/master.passwrd" as root (see the link 1 
below). In the middle of the work I lost the ssh session with the IPhone 
and now I can't ssh login to the IPhone using the old root IPhone 
password (alpine). And also I can't see the file "/etc/master.paswrd" 
from a IPhone terminal because I need root permission for that.


ANY IDEA PLEAS!!! WHAT CAN i DO NOW???


Thanks a lot in advance,
  Gustavo

link 1: 
http://blog.matsimitsu.nl/english/183/howto-fix-the-edit-home-screen-loop-for-iphone



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[Andreas Bombe]

On Wed, May 21, 2008 at 08:43:19AM -0500, Ron Johnson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On 05/20/08 23:11, Bernd Eckenfels wrote:
> > In article <[EMAIL PROTECTED]> you wrote:
> >> even though it's "just" a command line utility.  Who knows what
> >> weird, unexpected side effects there might be from running such an
> >> app within a tight bash loop.
> > 
> > none*. And not cleaning up yourself also improves performance for short
> > running apps.
> 
> How so?

The cleanup is pointless and takes CPU time.  Consider a program that
does a lot of malloc()s which it uses until it exits.  If it really
wants to cleanup, it needs to free() every single one which means
updating memory allocation structures for every single block of memory
that gets freed.

And all that for nothing, as the process's whole memory space gets
unmapped on exit no matter its contents (including the state of the
malloc implementation's allocation management structures).

-- 
Andreas Bombe <[EMAIL PROTECTED]>GPG key 0x04880A44


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> What about compilers and interpreters (like gcc and perl)? Kernel and drivers?

Everything which is part of the TCB (libs, login, resolvercache, init, root
cron tools, etc).

And of course all network clients and all other programs :)

Gruss
Bernd


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Familien- Wellnessurlaub - Inteli Tours

[ungarn-info.de]

Donnerstag, 22. Mai 2008

--
http://www.ungarn-info.de
--

Familien-Sparangebot mit Frühbucher-Rabat

8 Tage Familien-Wellnessurlaub Hotel Park Inn* * * *

7 Nächte im klimatisierten Familienappartement (2 Zimmer)

2 Erwachsene + 2 Kinder unter 12 Jahre
--
Inklusive:

Großzügig angelegte Badelandschaft mit über 3.500 m² Wasserfläche

Kostenlose Kindergarten jeden Tag zwischen 10:00 - 18:00 Uhr mit
deutschsprachiger Betreuung

Bunte Programme für Groß und Klein im Bad, in der Stadt und in der Umgebung

- Halbpension als Geschenk
- Thermeentritt
- Fitnessraum
- Bademantel
- Innen- und Außenbadelandschaft
- Thermalbecken mit Heilwasser
- Erlebnisbecken
- Kinderbecken
- Parkplatz
- Internet (W-Lan)
- Zimmersafe
- Handtuch- und
- Bademantelbenutzung
- Wasserrutsche
- Wellen- und Heilbecken
- Babyplantschbecken
- Abenteuerbecken
- Piratenschiff für Kinder
- Beachvolleyballplatz
- Beachsoccerplatz
- Petanqueplatz
- Kopfsprungbucht

--

Termine 01.07.-31.08.2008

PREISE

Buchung bis 31. Mai € 1.179.- pro Familie*
Buchung bis 20. Juni... € 1.220.- pro Familie*
Buchung nach 20. Juni.. € 1.277.- pro Familie*

* Familie = 2 Erwachsene + 2 Kinder unter 12 Jahre

--

Weitere Infos finden Sie unter:

http://www.ungarn-info.de/pakets/familienurlaub/ungarn/50001465.html


Gern stehen wir Ihnen für Fragen von 10:00 - 20:00 Uhr zur Verfügung

--
INTELI TOURS ®
Email:[EMAIL PROTECTED]
Internet: http://www.ungarn-info.de
--
Vertretungen - Mobile Offices:
--
Deutschland: 0049 (171) 58 17 269
Österreich: 0043 (664) 634 61 61
Schweiz: 0041 (79) 30 66 821
--



debian-devel@lists.debian.org

Re: packages up for adoption

[Michael Meskes]

Sorry guys, apparently this email of mine didn't make it to the list.
Thus sending it again. Need to figure out what's going on as this
happened twice.

Am Mittwoch, 21. Mai 2008 20:53:51 schrieb Joey Hess:
> I'll no longer be maintaining the following packages. I plan to orphan
> them next week and hope to find new maintainers for them before then.
> ...
> acpi

I take this one. Hmm, thinking about it, I wonder if we should bring all acpi 
related packages into a pkg-acpi group and maintain them together.

Michael

-- 
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: what about an special QA package priority?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/21/08 20:08, Andreas Bombe wrote:
> On Wed, May 21, 2008 at 08:43:19AM -0500, Ron Johnson wrote:
>>
>> On 05/20/08 23:11, Bernd Eckenfels wrote:
>>> In article <[EMAIL PROTECTED]> you wrote:
 even though it's "just" a command line utility.  Who knows what
 weird, unexpected side effects there might be from running such an
 app within a tight bash loop.
>>> none*. And not cleaning up yourself also improves performance for short
>>> running apps.
>>
>> How so?
> 
> The cleanup is pointless and takes CPU time.  Consider a program that
> does a lot of malloc()s which it uses until it exits.  If it really
> wants to cleanup, it needs to free() every single one which means
> updating memory allocation structures for every single block of memory
> that gets freed.
> 
> And all that for nothing, as the process's whole memory space gets
> unmapped on exit no matter its contents (including the state of the
> malloc implementation's allocation management structures).

I guess that working in the "enterprise" attunes me to the real
possibility that little apps which do one thing then terminate can
easily morph into big apps that run "forever".  Cleaning up after
yourself just leaves fewer surprises for the guy who comes after you
and makes unanticipated modifications.

- --
Ron Johnson, Jr.
Jefferson LA  USA

ESPN makes baseball players better.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFINNxsS9HxQb37XmcRAlOQAKDO4woqICg8GGO8DMknhxVjJEjW2wCgjYtM
ON91J1pRnNvqsTg2eS4Mst4=
=gey7
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: packages up for adoption

[Lars Wirzenius]

to, 2008-05-22 kello 04:35 +0200, Michael Meskes kirjoitti:
> Am Mittwoch, 21. Mai 2008 20:53:51 schrieb Joey Hess:
> > I'll no longer be maintaining the following packages. I plan to orphan
> > them next week and hope to find new maintainers for them before then.
> > ...
> > acpi
> 
> I take this one. Hmm, thinking about it, I wonder if we should bring all acpi 
> related packages into a pkg-acpi group and maintain them together.

Is acpi better than acpitool?



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

RFH: Bug #481575: courier: FTBFS

[Christian Perrier]

During the l10n NMU campaign, some work was done on "courier", in the
usual "l10n NMU" way:

-send an intent to l10n NMU
-wait for 10 days to get a reaction
-send a call for l10n updates and new translations
-wait for 8 days
-build the NMU

However, building the NMU fails and lead to /me reporting #481575.

As of now, I got no news from Stefan, the package maintainer, about
this package.

So, the work is still pending in my spool...

From what I see, fixing that bug is probably fairly easy for anyone
with a little more clue than me. So, may I request for clued people to
have a look at this bug report and help me (and indirectly the package
maintainer) to find a solution?

I have no specific interest in courier. I just want to move along...:)

PS: the package has another RC bug as it apparently provides non free
RFC documents.

Many thanks in advance to people who will have a look at this.

-- 





signature.asc
Description: Digital signature

Re: packages up for adoption

[Anibal Avelar]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi Joey.

Im' very interested to adopt this packages:

> archivemail
> splitvt   - I use it.
> unclutter   - I use it.
> xaoom ? I think would be xzoom?


Regards.

- --
Anibal Avelar (FixXxeR) http://fixxxer.cc
GPG: 83B64656 - C143 4AD8 B017 53FA B742 D6AA CEEA F9F3 83B6 4656

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: http://getfiregpg.org

iD8DBQFINGLfzur584O2RlYRAr6UAJ0dw9JWHXPDApPsm+qXnn8U+TgHBwCfQSpy
NA7YoqFubfGdZNlcpeKxtY0=
=ql91
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]