Re: Linux image packages going to depend on python

[Florian Weimer]

* Manoj Srivastava:

> It seems to be that a better approach is to inform the user, and
>  let the admin make the changes needed.

This is probably true.  After all, it could make more sense to change
from hd* to UUIDs or labels instead of from hd* to sd*, to compensate
for the lack of stable naming of sd* device nodes.


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

Re: Linux image packages going to depend on python

[Andreas Metzler]

Florian Weimer  wrote:
> * Manoj Srivastava:
>> It seems to be that a better approach is to inform the user, and
>>  let the admin make the changes needed.

> This is probably true.  After all, it could make more sense to change
> from hd* to UUIDs or labels instead of from hd* to sd*, to compensate
> for the lack of stable naming of sd* device nodes.

uuid, label, et.al do not work for VFAT or NTFS, do they?
cu andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'


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

Re: Linux image packages going to depend on python

[Marco d'Itri]

On Nov 28, Bastian Blank  wrote:

> The Linux image packages needs to do some modifications to core
> configuration files like fstab in the future to allow newer kernels to
> work. To do this and the planned further extension I intend to make all
> linux image packages depend on python.
This is not justified.
I will be happy to rewrite in perl whatever you need.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#558587: general: Keep last package version in archives

[O.C.]

Package: general
Severity: wishlist

Hello,

I use Debian Testing. Every time a package is fucked up, I would like to test 
the former version of that package, but to my knowledge, it is not kept 
anywhere any thus it is not available.

Taking Debian Stable package is of course not possible because of a huge number 
of dependancies which would break.

Why don't you keep the last version somewhere ? It would make debugging more 
easy and efficient.


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

Kernel: Linux 2.6.30-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/dash




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

Re: [Pkg-utopia-maintainers] Bug#558570: Missing autoreconf to fix 554821 or similar bugs in the future

[Peter Fritzsche]

Michael Biebl wrote:
> Peter Fritzsche wrote:
> > Source: libatasmart
> > Version: 0.17-1
> > Severity: minor
> > User: peter.fritzs...@gmx.de
> > Usertags: missing-libtool-update
> >
> > I did a rebuild of all packages which are affected by bug #554821. As it
> > seems your package doesnt do the needed autoreconf needed for libtool.
> > When doing autoreconf or the needed sequence of different
> > autotools/libtool utilities the package should be able to fix the problem
> > automatically.
> 
> Hm, I'm not sure if it is a good idea to do a mass bug filing when there is
>  no libtool version available yet,  which fixes the problem.
Correct there is no libtool version available which fixes 554821, but this bug 
was only used as example why it is a good idea to do a autoreconf and a way to 
find packages which uses libtool but doesn't do what is explained in 
/usr/share/doc/autotools-dev/README.Debian.gz

> I'm also not a big fan of running autoreconf during build, as this will
>  blow up the diff.gz, so I guess I'd have to say WONTFIX for now.
I showed a way how to do it without adding any autoreconf generated overhead 
to diff.gz. I have also found a package which demonstrate how to do that - 
g3dviewer.

> Imho such changes are best pushed upstream aggressively so they will
>  trickle down eventually.
So that we have to wait for a new upstream release which fixes that problem 
and it gets propagated to Debian. Somebody on that list already said that he 
things that such changes would need 10 or more years until they are fixed in 
debian.

> Another idea would, that binutils-gold changes its version string in a way,
>  that existing libtool scripts will detect it as a libtool implementation
>  which supports anon_versioning. This way you wouldn't have to change
>  hundreds of existing packages.
binutils-gold is no libtool implementation - it is a linker. It is a GNU 
binutils linker and uses the correct version string also used by the old 
binutils linker. It was shown that libtool checks the version string wrong.


Best regards,
Peter


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

Re: Linux image packages going to depend on python

[Ben Hutchings]

On Sun, 2009-11-29 at 13:52 +0100, Andreas Metzler wrote:
> Florian Weimer  wrote:
> > * Manoj Srivastava:
> >> It seems to be that a better approach is to inform the user, and
> >>  let the admin make the changes needed.
> 
> > This is probably true.  After all, it could make more sense to change
> > from hd* to UUIDs or labels instead of from hd* to sd*, to compensate
> > for the lack of stable naming of sd* device nodes.
> 
> uuid, label, et.al do not work for VFAT or NTFS, do they?

Of course they do.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.


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

Bug#558587: Addition

[OC]

Well, in fact I was not totally honest, because I know that sometimes, 
it is possible to get the former version. For example, today, I can 
download these two versions :

http://ftp.fr.debian.org/debian/pool/main/a/acpid/acpid_1.0.10-3_i386.deb
http://ftp.fr.debian.org/debian/pool/main/a/acpid/acpid_1.0.10-4_i386.deb

However, it is nowhere written that acpid_1.0.10-3 can still be 
downloaded. I am sure that many people would be interested to see a link 
to the former version (the one before the current one).





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

Bug#558587: marked as done (general: Keep last package version in archives)

[Debian Bug Tracking System]

Your message dated Sun, 29 Nov 2009 15:11:55 +0100
with message-id <200911291512.14959.hol...@layer-acht.org>
and subject line Re: Bug#558587: general: Keep last package version in archives
has caused the Debian Bug report #558587,
regarding general: Keep last package version in archives
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
558587: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558587
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: general
Severity: wishlist

Hello,

I use Debian Testing. Every time a package is fucked up, I would like to test 
the former version of that package, but to my knowledge, it is not kept 
anywhere any thus it is not available.

Taking Debian Stable package is of course not possible because of a huge number 
of dependancies which would break.

Why don't you keep the last version somewhere ? It would make debugging more 
easy and efficient.


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

Kernel: Linux 2.6.30-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/dash



--- End Message ---
--- Begin Message ---
Hi,

On Sonntag, 29. November 2009, O.C. wrote:
> I use Debian Testing. Every time a package is fucked up, I would like to
> test the former version of that package, but to my knowledge, it is not
> kept anywhere any thus it is not available.
>
> Taking Debian Stable package is of course not possible because of a huge
> number of dependancies which would break.
>
> Why don't you keep the last version somewhere ? It would make debugging
> more easy and efficient.

First of all, the testing distribution is not officially supported.

Second, there is snapshot.debian.net and there will be snapshot.debian.org 
soo, providing what you ask for :-)

s.d.n can be accessed with URLs like http://snapshot.debian.net/archive/2009/ 
(mind the trailing slash) and goes back to 2005, IIRC. It doesnt have 
packages after march 2009 - this will be fixed with s.d.o eventually :)

I'm closing this bug as the DSA RT queue would be the appropriate place for 
this - however they know and are activly working in this, so opening such a 
ticket would be useless as well.


regards,
Holger


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

Best practice for packaging *spell

[Alexander GQ Gerasiov]

Hi there.

I'd like to adopt rus-ispell - Russian dictionary for
aspell/ispell/hunspell/myspell [1]

I'm not familiar with all this *spell staff and like to ask:
is there any Policy or best practice for such packages? Is there
somewhere the description of formats and tools used to generate one
dictionary from another?

E.g. I'd like to generate 2 versions of dictionaries with diacritical
marks and without, how to do this in more natural way? To put both
dictionary into one binary package and allow user's to choose one of
them in there cli/gui?


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542011
-- 
Best regards,
 Alexander GQ Gerasiov

 Contacts:
 e-mail:g...@cs.msu.su Jabber:  g...@jabber.ru
 Homepage:  http://gq.net.ru ICQ: 7272757
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1


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

Re: Bits from the NM people

[Nuno Paquete]

Very good news for people like me that want to be part of the best team in
the worl.
I'm reading a lot this days, preparing myself to help the best as I can the
magnific Debian community.
My goal is to be a DD some day.
Step by step!!

Cheers,
Nuno Paquete

On Nov 29, 2009 1:27 PM, "Joerg Jaspert"  wrote:

Hello world,

during this weekend FD/DAM had a meeting in Essen to discuss various
things and issues around the New Maintainer process.

Good news
-

The queues are (almost) empty:

   * The DAM queue has only 2 people left. 14 have been approved and
 will now get an account.

   * Yes, this really means that we're going to have 14 new DDs as soon
 as their accounts are created!

   * The two people currently in the DAM queue are waiting for issues
 not fully related to the NM process that should be dealt with in
 the next few days.

   * The frontdesk queue is empty!

   * There are only 3 people waiting to get an AM assigned. With a few
 more AMs we could reach the ideal situation of having the AM queue
 empty and the AMs not overworking.

   * There are various people on hold at the DAM or the FD stage. These
 have all been pinged, and will either move on, or their
 application will be cancelled.


No more rejections!
---

Canceling an application is currently called a "rejection". We are
actually very rarely rejecting people from Debian, and the most common
case is that an application is canceled because a person is not ready,
and is invited to join again after they gain some experience. This
wording issue has causes bad feelings in the past.

For this reason we have decided to refer to what was previously called
"soft rejection" as "cancelling the application". In most cases,
applicants can re-apply after a while, and "cancelling the application"
more clearly communicates this fact.

People who are not knowledgeable or experienced enough are not rejected
by Debian: they are instead provided with more appropriate ways of
joining, such as finding mentors who help them gain experience and
sponsor their packages into the archive.

What was known as a "strong rejection" will however still be referred to
as a "rejection", because that is what it is.


Account name rules
--

A new account name should be at least 3 characters long, and must be
reasonable, according to the DAM's judgement. We've rejected account
names in the past that were trolling attempts, or things like "root".


Website rewrite
---

We started to rewrite our website at nm.debian.org. This cleans up the
internal implementation and allows for future improvements in the NM
process handling.


GPG keysigning coordination
---

FD/DAM would like to to move the GPG keysiging coordination over to
someone else. It's not really part of FrontDesk work; and as we are
rewriting the webpage anyhow we feel this is a right time to move it
over to someone else and not make it part of the new page. Volunteers to
pick up this job are welcome.


Advocation in the NM process


We discussed how advocation of New Maintainers should be done. We agreed
that advocation should be done on a public mailing list and more than
one advocations are appreciated. This is the same as in the DM process
and gives a much better picture about applications. In order for this to
be effective immediately, we ask prospective advocates that for now,
they explicitly Cc the debian-newma...@lists.debian.org mailinglist; the
rewritten website will make this automatic, once it goes live.

More and well-motivated advocacy messages make the whole process
faster. Though the current NM website does not allow for more than one
advocate, the mailinglist process will, and this is another reason why
we think the process should be made public. Note that after a person has
been advocated, additional advocates need not go through the website; a
simple signed reply on the mailinglist will suffice. This process is
certainly suboptimal, but we are working on this for the new website.

When you advocate a person, you are saying that they need and should get
unsupervised upload rights on the entire archive, right now. In the past
some people were advocated who at the time had not yet done any Debian
related work. Please only advocate people who have contributed to Debian
already, don't advocate someone that you expect will get involved in
Debian later on. Having to cancel an application, or having someone
disappear while in the NM process, is a waste of time and motivation for
everyone involved.

As such, we prefer that people who want to apply to NM have been active
in Debian for a while already, and have built up some experience. In the
last few months, we've already redirected some people to the DM process
when we felt that they were not ready to become a DD yet, and we will
continue to do so. Please consider this an official policy as of now.


More AMs wanted

Bug#558647: ITP: pythonocc -- pythonocc is a computer program whose purpose is to provide a complete set of python bindings for the OpenCascade library as well as the GEOM Salome package

[Heath Matlock]

Package: wnpp
Severity: wishlist
Owner: Heath Matlock 

This particular build doesn't include the GEOM Salome package and is intended 
to be used with another package which I plan to build shortly. Should this be 
noted somewhere?

* Package name: pythonocc
  Version : 0.3
  Upstream Author : Heath Matlock 
* URL : http://www.pythonocc.org/
* License : GPL3
  Programming Lang: C++, Python
  Description : pythonocc is a computer program whose purpose is to provide 
a complete set of python bindings for the OpenCascade library as well as the 
GEOM Salome Package

pythonocc is a 3D CAD/PLM development library for the Python programming 
language. It's built upon the OpenCASCADE 3D modeling kernel and the SalomeGEOM 
package. Some high level packages (parametric modeling, topology, data 
exchange, webservices etc.) extend the builtin features of those libraries to 
enable a highly dynamic and modular programming of your CAD apps thanks to the 
magic of python.

-- System Information:
Debian Release: 5.0.3
  APT prefers stable
  APT policy: (700, 'stable'), (600, 'unstable')
Architecture: i386 (i686)



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

Re: Linux image packages going to depend on python

[Petter Reinholdtsen]

[Manoj Srivastava]
>  This is fine. /etc/fstab is used by mountall.sh, mount, and
>  swapon explicitly

I believe fsck and dump tools also use it to decide when to check and
back up the file systems. :)

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: Bits from the NM people

[Andreas Marschke]

> As such, we prefer that people who want to apply to NM have been active
> in Debian for a while already, and have built up some experience. In the
> last few months, we've already redirected some people to the DM process
> when we felt that they were not ready to become a DD yet, and we will
> continue to do so. Please consider this an official policy as of now.
> 

Hi,

what is previous activeness in Debian for this case?
- Wiki proofreading?
- Irc helper? 
- Developer sending patches relatively often?
- bugtriaging?

Thanks,

Andreas Marschke.


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

Re: Bits from the NM people

[Patrick Schoenfeld]

On Sun, Nov 29, 2009 at 06:55:58PM +0100, Andreas Marschke wrote:
> > As such, we prefer that people who want to apply to NM have been active
> > in Debian for a while already, and have built up some experience. In the
> > last few months, we've already redirected some people to the DM process
> > when we felt that they were not ready to become a DD yet, and we will
> > continue to do so. Please consider this an official policy as of now.
> > 
> 
> Hi,
> 
> what is previous activeness in Debian for this case?
> - Wiki proofreading?
> - Irc helper? 
> - Developer sending patches relatively often?
> - bugtriaging?

well, it somehow depends on what an applicant applies for, I'd say.
If one wants to become a packager it would help if the person
in question is already maintaining packages. As a documentation
person there are other activities that are of interest.

Best Regards,
Patrick


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

Re: Bits from the NM people

[Andreas Marschke]

On Sunday 29 November 2009 19:54:02 Patrick Schoenfeld wrote:
> On Sun, Nov 29, 2009 at 06:55:58PM +0100, Andreas Marschke wrote:
> > > As such, we prefer that people who want to apply to NM have been active
> > > in Debian for a while already, and have built up some experience. In
> > > the last few months, we've already redirected some people to the DM
> > > process when we felt that they were not ready to become a DD yet, and
> > > we will continue to do so. Please consider this an official policy as
> > > of now.
> >
> > Hi,
> >
> > what is previous activeness in Debian for this case?
> > - Wiki proofreading?
> > - Irc helper?
> > - Developer sending patches relatively often?
> > - bugtriaging?
> 
> well, it somehow depends on what an applicant applies for, I'd say.
> If one wants to become a packager it would help if the person
> in question is already maintaining packages. As a documentation
> person there are other activities that are of interest.
> 
> Best Regards,
> Patrick
> 
Lets say this package is maintained on Launchpad that also "maintainance" for 
debian or would this have to be on mentors.debian.org to be a valid 
maintainance? (Just curios as there use to be some discussion between the 
bloggers about that some time back) 


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

Re: Linux image packages going to depend on python

[Frank Lin PIAT]

On Sun, 2009-11-29 at 13:56 +0100, Marco d'Itri wrote:
> On Nov 28, Bastian Blank  wrote:
> 
> > The Linux image packages needs to do some modifications to core
> > configuration files like fstab in the future to allow newer kernels to
> > work. To do this and the planned further extension I intend to make all
> > linux image packages depend on python.
> This is not justified.
> I will be happy to rewrite in perl whatever you need.

Find attached an initial attempt to use shell only. Let me know if you
are interested.

The script is configurable, so a sysadmin can decide to re-rewrite fstab
using DM/LVM names rather than UUID, or volume LABEL, or legacy /dev/hd*
names.

Known bugs/limitation:
 * Should accept command line arguments
 * Some devices may need to be blacklisted
 * What about removable media? (UUID of media in CDROM? ouch)
 * Should actually write fstab ;)

I have hesitated to probe the current /dev or to use blkid... I can
change that easily.

I think this script should have a companion, to insert/update a comments
line above each fstab entry (à-la Debian-Installer)

Franklin
#!/bin/sh
set -e
# update-fstab-persistent-names - Rewrite current fstab
# (Using your prefered device naming).
#
# Copyright 2009, Frank Lin PIAT 
# Licensed under GPLv2 or later
#
# Known bugs/limitation
#  * Should actually _write_ fstab ;)
#  * Doesn't accept command line arguments
#  * Some devices may need to be blacklisted
#  * What about removable media?


# == User configurable variables == #

# Prefered device naming scheme to use in fstab. **Order matters**.
#dm : use /dev/grpname/logvolname for LVM volumes
#   : or /dev/mapper/dmname for CRYPT and other.
#uuid   : use UUID=cafecafe (based on the FS's volume UUID)
#label  : use LABEL=foo (based on the FS's volume name)
#plaindev   : use legacy /dev/ devices.
PREFERED_NAME='dm uuid label plaindev'

# Rewrite existing LABEL=foo lines in fstab
REWRITE_LABELS=1

# Rewrite existing UUID=foo lines in fstab
REWRITE_UUIDS=1

# == End of user configurable variables == #

# Let's declare some functions...

# Initialise a sed file to rewrite fstab, based on device major/minor IDs.
# (this temporary sed file search and replace all possible names for the
# local devices, with a fake unique ID "#DEVICE=X.Y" where X and Y are 
# the device's major and minor numbers)
generate_simple_fstab_sed() {

# Sed rule to rewrite /dev/* entry as #DEVICE=X:Y
find /dev/ \( -type b -o -type l \)  \
\! -path '/dev/.udev/*' \! -path '/dev/.static/*' \
-iregex '^[a-z0-9./_-]*$' -printf '%Y\t%p\n' \
| sed -n -e 's/^b\t\(.*\)/\1/p' \
| while read s ; do
printf 's\t^%s\>\t#DEVICE=%d:%d\t\n' \
"$s" \
"$(stat -L -c '0x%t' "$s")" \
"$(stat -L -c '0x%T' "$s")"
done

# Sed rule to rewrite existing LABELS=* entry as #DEVICE=X:Y
if [ "$REWRITE_LABELS" = "1" -a -d /dev/disk/by-label ]; then
find /dev/disk/by-label/ -type l -iregex '^[a-z0-9./_-]*$' \
| while read s ; do \
printf 's\t^%s\>\t#DEVICE=%d:%d\t\n' \
"LABEL=$(basename $s)" \
"$(stat -L -c '0x%t' "$s")" \
"$(stat -L -c '0x%T' "$s")"
done
fi

# Sed rule to rewrite existing UUID=* entry as #DEVICE=X:Y
if [ "$REWRITE_UUIDS" = "1" -a -d /dev/disk/by-uuid ]; then
find /dev/disk/by-uuid/ -type l -iregex '^[a-z0-9./_-]*$' \
| while read s ; do \
printf 's\t^%s\>\t#DEVICE=%d:%d\tg\n' \
"UUID=$(basename $s)" \
"$(stat -L -c '0x%t' "$s")" \
"$(stat -L -c '0x%T' "$s")"
done
fi
}



# create a list of device-major-minor -> /dev/vg/lv for LVM.
use_dm_legacy() {
which vgs 2>&1 > /dev/null || return 0

LVM_VGS="$(vgs --all -o vg_name --noheadings | sed -e 's#^\s*#/dev/#')"
[ ! "$LVM_VGS" ] && return 0

find $LVM_VGS -maxdepth 1 -type l -iregex '^[a-z0-9./_-]*$' \
| while read s ; do \
printf 's\t#DEVICE=%d:%d\t%s\t\n' \
"$(stat -L -c '0x%t' "$s")" \
"$(stat -L -c '0x%T' "$s")" \
"$s"
done
}

# create a list of device-major-minor -> /dev/vg/lv
# or -> /dev/mapper/name for dmsetup (LVM/DM/CRYPT...)
use_dm_new() {
which dmsetup 2>&1 > /dev/null || return 0

dmsetup info -c --noheadings --separator="$(printf "\

Re: Linux image packages going to depend on python

[Manoj Srivastava]

Hi,

On Sun, Nov 29 2009, Frank Lin PIAT wrote:

> Find attached an initial attempt to use shell only. Let me know if you
> are interested.
>
> The script is configurable, so a sysadmin can decide to re-rewrite fstab
> using DM/LVM names rather than UUID, or volume LABEL, or legacy /dev/hd*
> names.
>
> Known bugs/limitation:
>  * Should accept command line arguments
>  * Some devices may need to be blacklisted
>  * What about removable media? (UUID of media in CDROM? ouch)
>  * Should actually write fstab ;)
>
> I have hesitated to probe the current /dev or to use blkid... I can
> change that easily.
>
> I think this script should have a companion, to insert/update a comments
> line above each fstab entry (à-la Debian-Installer)

Perhaps you should consider making the script just create a
 ./fstab.new file, and not overwriting /etc/fstab?  makes it easier to
 test the script out without altering current setup.

manoj
-- 
There's such a thing as too much point on a pencil. Allen Smith, "Let
the Crabgrass Grow"
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Bits from the NM people

[Julien Cristau]

On Sun, Nov 29, 2009 at 20:21:02 +0100, Andreas Marschke wrote:

> Lets say this package is maintained on Launchpad that also "maintainance" for 
> debian or would this have to be on mentors.debian.org to be a valid 
> maintainance? (Just curios as there use to be some discussion between the 
> bloggers about that some time back) 
> 
Neither as far as I can tell...  The relevant archive is ftp.debian.org.

Cheers,
Julien


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

Re: Bits from the NM people

[The Fungi]

On Sun, Nov 29, 2009 at 08:21:02PM +0100, Andreas Marschke wrote:
> Lets say this package is maintained on Launchpad that also
> "maintainance" for debian or would this have to be on
> mentors.debian.org to be a valid maintainance? (Just curios as
> there use to be some discussion between the bloggers about that
> some time back) 

Whether its code repository lives in Launchpad or Alioth or servers
in the package maintainer's basement is immaterial to the discussion
(well, not entirely if you're talking about participation in
collaboratively-maintained packages, but in that case the group
would standardize on a location anyway). What matters for purposes
of the NM process is the condition of the package as uploaded to
Debian itself, and how the packager deals with bugs filed against
it.

The Mentors repository is just a convenient place to stick packages
for a prospective mentor to retrieve, as a stepping stone to that
package's inclusion in the distribution (and provides some automated
QA to assist with this goal). It doesn't have a lot to do with the
topic of ongoing package maintenance, however... mainly just initial
acceptance by a mentor.
-- 
{ IRL(Jeremy_Stanley); PGP(9E8DFF2E4F5995F8FEADDC5829ABF7441FB84657);
SMTP(fu...@yuggoth.org); IRC(fu...@irc.yuggoth.org#ccl); ICQ(114362511);
AIM(dreadazathoth); YAHOO(crawlingchaoslabs); FINGER(fu...@yuggoth.org);
MUD(fu...@katarsis.mudpy.org:6669); WWW(http://fungi.yuggoth.org/); }


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

Re: Depends/Recommends?: Linux image packages going to depend on python

[Raphael Geissert]

Osamu Aoki wrote:

> 
> Why not keep the main maintainer script to be /bin/sh and use python
> within optional compoent.  I mean:
> 

In any case C could be used to avoid any other sort of dependency.

Regards,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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

Re: Depends/Recommends?: Linux image packages going to depend on python

[Russ Allbery]

Raphael Geissert  writes:
> Osamu Aoki wrote:

>> Why not keep the main maintainer script to be /bin/sh and use python
>> within optional compoent.  I mean:

> In any case C could be used to avoid any other sort of dependency.

Yeah, but doing string manipulation in C is fairly painful and difficult
to maintain in the long run.  I suspect that shell, sed, and awk, despite
its disadvantages, would still be easier and clearer than using C for this
sort of transformation.  (And all of those tools are already essential and
likely to be present even on most embedded platforms that would use a full
dpkg implementation since they aren't particularly large.)

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


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

Re: Bits from the NM people

[Ralf Treinen]

On Sun, Nov 29, 2009 at 02:26:55PM +0100, Joerg Jaspert wrote:

> GPG keysigning coordination
> ---
> 
> FD/DAM would like to to move the GPG keysiging coordination over to
> someone else. It's not really part of FrontDesk work; and as we are
> rewriting the webpage anyhow we feel this is a right time to move it
> over to someone else and not make it part of the new page. Volunteers to
> pick up this job are welcome. 

GPG keysigning coordination is since a long time done by a small
group of people independendent from FrontDesk. Currently this is
basically me, with an offer from Patrick Schoenfeld to help. In 
the past tbm and Luk have been part of that team.

I agree that the infrastructure could (and should) be independent
of the rest of nm. Which doesn't mean that I volunteer to implement
it ...

-Ralf.


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

Bug#558684: ITP: envstore -- save and restore environment variables

[Maximilian Gass]

Package: wnpp
Severity: wishlist
Owner: Maximilian Gass 

* Package name: envstore
  Version : 2.0
  Upstream Author : Daniel Friesel 
* URL : https://derf.homelinux.org/~derf/projects/envstore/
* License : WTFPL
  Programming Lang: C
  Description : save and restore environment variables

envstore allows you to save environment variables into a seperate store, list
them, and reload them into the shell again.



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

Re: Depends/Recommends?: Linux image packages going to depend on python

[Neil Williams]

On Sun, 29 Nov 2009 12:32:22 -0800
Russ Allbery  wrote:

> Raphael Geissert  writes:
> > Osamu Aoki wrote:
> 
> >> Why not keep the main maintainer script to be /bin/sh and use
> >> python within optional compoent.  I mean:
> 
> > In any case C could be used to avoid any other sort of dependency.
> 
> Yeah, but doing string manipulation in C is fairly painful and
> difficult to maintain in the long run.  I suspect that shell, sed,
> and awk, despite its disadvantages, would still be easier and clearer
> than using C for this sort of transformation.  (And all of those
> tools are already essential and likely to be present even on most
> embedded platforms that would use a full dpkg implementation since
> they aren't particularly large.)

I know the intended meaning but I can't help but see the irony of
recommending tools written in C as a solution for the difficulties of
handling strings in C . . . 

Proven code etc. etc. but still.

-- 


Neil Williams
=
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/



pgpuEPmrX00PO.pgp
Description: PGP signature

Re: Depends/Recommends?: Linux image packages going to depend on python

[Russ Allbery]

Neil Williams  writes:
> Russ Allbery  wrote:

>> Yeah, but doing string manipulation in C is fairly painful and
>> difficult to maintain in the long run.  I suspect that shell, sed, and
>> awk, despite its disadvantages, would still be easier and clearer than
>> using C for this sort of transformation.  (And all of those tools are
>> already essential and likely to be present even on most embedded
>> platforms that would use a full dpkg implementation since they aren't
>> particularly large.)

> I know the intended meaning but I can't help but see the irony of
> recommending tools written in C as a solution for the difficulties of
> handling strings in C . . . 

> Proven code etc. etc. but still.

Well, yes.  :)  But it's about the language in which the code we're
writing for Debian is expressed, since that's the code that we have to
maintain.  sed and awk (and Perl and Python, which are also written in C)
get the benefit of lots of other people maintaining them.

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


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

Bug#558690: ITP: aptdaemon -- transaction based package management service

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode 

* Package name: aptdaemon
  Version : 0.10
  Upstream Author : Sebastian Heinlein ,
Michael Vogt 
* URL : https://launchpad.net/aptdaemon
* License : GPL-2+
  Programming Lang: Python
  Description : transaction based package management service

 Aptdaemon allows normal users to perform package management tasks, e.g. 
 refreshing the cache, upgrading the system, installing or removing software 
 packages.
 .
 Currently it comes with the following main features:
 .
  - Programming language independent D-Bus interface, which allows to
write clients in several languages
  - Runs only if required (D-Bus activation)
  - Fine grained privilege management using PolicyKit, e.g. allowing all
desktop user to query for updates without entering a password
  - Support for media changes during installation from DVD/CDROM
  - Support for debconf (Debian's package configuration system)
  - Support for attaching a terminal to the underlying dpkg call

The package itself is based on the Ubuntu one, with some changes:
  - Converted the package to 3.0 (quilt) source format
  - Converted the package from cdbs to debhelper 7
  - Converted debian/copyright to DEP-5 format
  - Rebased against current trunk of aptdaemon

Sebastian, could we get a 0.11 release tomorrow; with the state
of the current trunk and the attached patch for Python 2.5
support? This would be helpful; as I would like to upload
the package tomorrow.
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


signature.asc
Description: Digital signature

Bug#558692: ITP: software-center -- Utility for browsing, installing, and removing applications (Ubuntu Software Center)

[Julian Andres Klode]

Package: wnpp
Severity: wishlist
Owner: Julian Andres Klode 

* Package name: software-center
  Version : 1.1~bzr
  Upstream Author : Michael Vogt 
* URL : https://launchpad.net/software-center
* License : GPL-3+
  Programming Lang: Python
  Description : Utility for browsing, installing, and removing applications 
(Ubuntu Software Center)

 The Ubuntu Software Center lets you browse and install thousands of 
 free applications available for Ubuntu. You can view available 
 applications by category, or search quickly by name or description. 
 You can also examine the applications already installed, and remove
 those you no longer need.
 .
 To install or remove software using the Center, you need administrator
 access on the computer.

I am branching off software-center trunk (UNRELEASED 1.1); and plan to
upload it to unstable tomorrow. It will continue some strings from Ubuntu,
this will be fixed later on.

I plan to add a gnome-app-install transitional package depending on
gnome-codec-install and software-center; as they together provide
the same functionality. After it gets accepted, I would request the
removal of gnome-app-install.

PS. I am not subscribed to debian-devel, so people reading this there
should CC me and/or the bug report.
-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.


signature.asc
Description: Digital signature

Re: bug #551926: python-pip and pip: error when trying to install together

[Tim Retout]

[Resending to the *actual* debian-devel address. :) D'oh.]

According to Debian Policy 10.1 [*], when two binaries have different
functionality but the same name, this should be reported to the
debian-devel mailing list.

[*] http://www.debian.org/doc/debian-policy/ch-files.html#s10.1

In this case, 'pip' and 'python-pip' both ship /usr/bin/pip, but one is
for Perl and one is for Python. The 'python-pip' package has precedence
in Debian (and indeed, is the only one in testing), so I propose that
the Perl pip package must pick a pseudonym for its program.

My first suggestion is 'pip-perl', so that it's still possible to find
via tab-completion on 'pip'.  Better ideas welcomed, otherwise I'll make
the change in a few days.

This isn't ideal for having the same name for the Perl pip on all
platforms, I know - but until we fix this, there will be a serious bug
on 'pip', and it will not be released with Debian.

Regards,

-- 
Tim Retout 



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

Re: Best practice for packaging *spell

[Agustin Martin]

On Sun, Nov 29, 2009 at 05:20:46PM +0300, Alexander GQ Gerasiov wrote:
> Hi there.
> 
> I'd like to adopt rus-ispell - Russian dictionary for
> aspell/ispell/hunspell/myspell [1]
> 
> I'm not familiar with all this *spell staff and like to ask:
> is there any Policy or best practice for such packages? Is there
> somewhere the description of formats and tools used to generate one
> dictionary from another?

Please look at dictionaries-common-dev package, dsdt-policy.html file. For
aspell you should also look the aspell package documentation.

There is a site dedicated to spellchecking coordination, please see

http://dict-common.alioth.debian.org

and resources there,
 
-- 
Agustin


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

Re: Bits from the NM people

[Joerg Jaspert]

> Lets say this package is maintained on Launchpad that also "maintainance" for 
> debian or would this have to be on mentors.debian.org to be a valid 
> maintainance? (Just curios as there use to be some discussion between the 
> bloggers about that some time back) 

Where it is maintained is irrelevant. What is important is the track
record within Debian, and that can be seen by tools like minechangelogs
and PTS for example. Or the handling of the bugs for this package that
you see via our BTS.

-- 
bye, Joerg
 also dies ist so ziemlich der einzige chanel wo ich meist 0 peile
 ich schreibe etwas dann rennen se alle gegen die wand und schreien 
aua


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

Re: Bits from the NM people

[Andreas Marschke]

On Monday 30 November 2009 00:08:20 Joerg Jaspert wrote:
> > Lets say this package is maintained on Launchpad that also "maintainance"
> > for debian or would this have to be on mentors.debian.org to be a valid
> > maintainance? (Just curios as there use to be some discussion between the
> > bloggers about that some time back)
> 
> Where it is maintained is irrelevant. What is important is the track
> record within Debian, and that can be seen by tools like minechangelogs
> and PTS for example. Or the handling of the bugs for this package that
> you see via our BTS.
> 
But if I remember right ftp.debian.org is an official debian repository to 
which 
only the DDs/Maintainers of a package have access to. 
Doesn't that mean I cant upload packages to this repository? Are there 
exceptional places on ftp.debian.org a non-maintainer can upload his packages 
to without triggering the alarmbells? 
If there is a documentation page I haven't yet seen please do tell. I really 
really want to get packages into debian. 


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

Re: Bits from the NM people

[Ryan Niebur]

On Mon, Nov 30, 2009 at 12:49:31AM +0100, Andreas Marschke wrote:
> On Monday 30 November 2009 00:08:20 Joerg Jaspert wrote:
> > > Lets say this package is maintained on Launchpad that also "maintainance"
> > > for debian or would this have to be on mentors.debian.org to be a valid
> > > maintainance? (Just curios as there use to be some discussion between the
> > > bloggers about that some time back)
> > 
> > Where it is maintained is irrelevant. What is important is the track
> > record within Debian, and that can be seen by tools like minechangelogs
> > and PTS for example. Or the handling of the bugs for this package that
> > you see via our BTS.
> > 
> But if I remember right ftp.debian.org is an official debian repository to 
> which 
> only the DDs/Maintainers of a package have access to. 
> Doesn't that mean I cant upload packages to this repository? Are there 
> exceptional places on ftp.debian.org a non-maintainer can upload his packages 
> to without triggering the alarmbells? 
> If there is a documentation page I haven't yet seen please do tell. I really 
> really want to get packages into debian. 
> 

non-DDs must send a request to the debian-mentors mailing list with a
link to their package (whether it be on mentors.debian.net or
elsewhere), and ask for a DD to sponsor their package for them. A DD
will then upload the package to ftp.debian.org for them. See the docs
on mentors.debian.net and debian.org/devel.

-- 
_
Ryan Niebur
ryanrya...@gmail.com


signature.asc
Description: Digital signature

Re: Bits from the NM people

[Bernd Zeimetz]

Ralf Treinen wrote:
> GPG keysigning coordination is since a long time done by a small
> group of people independendent from FrontDesk. Currently this is
> basically me, with an offer from Patrick Schoenfeld to help. In 
> the past tbm and Luk have been part of that team.
> 
> I agree that the infrastructure could (and should) be independent
> of the rest of nm. Which doesn't mean that I volunteer to implement
> it ...

In my opinion the easiest way would be to use a page in the Debian wiki,
probably with some links to biglumber and/or other useful resources.
And it would be really easy to maintain it - in the best case it maintains 
itself.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprints: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
   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

Re: bug #551926: python-pip and pip: error when trying to install together

[Adam Kennedy]

http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/

The Perl package predates the Python one by several years.

The author was made aware of the clash well before it was shipped to
Debian and chose to continue anyway.

Adam K

2009/11/30 Tim Retout :
> [Resending to the *actual* debian-devel address. :) D'oh.]
>
> According to Debian Policy 10.1 [*], when two binaries have different
> functionality but the same name, this should be reported to the
> debian-devel mailing list.
>
> [*] http://www.debian.org/doc/debian-policy/ch-files.html#s10.1
>
> In this case, 'pip' and 'python-pip' both ship /usr/bin/pip, but one is
> for Perl and one is for Python. The 'python-pip' package has precedence
> in Debian (and indeed, is the only one in testing), so I propose that
> the Perl pip package must pick a pseudonym for its program.
>
> My first suggestion is 'pip-perl', so that it's still possible to find
> via tab-completion on 'pip'.  Better ideas welcomed, otherwise I'll make
> the change in a few days.
>
> This isn't ideal for having the same name for the Perl pip on all
> platforms, I know - but until we fix this, there will be a serious bug
> on 'pip', and it will not be released with Debian.
>
> Regards,
>
> --
> Tim Retout 
>
>


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

Bug#558715: ITP: xappy -- easy-to-use interface to the Xapian search engine

[Jonas Smedegaard]

Package: wnpp
Severity: wishlist
Owner: Jonas Smedegaard 

* Package name: xappy
  Version : 0.5
  Upstream Author : Richard Boulton 
* URL : http://code.google.com/p/xappy/
* License : GPL-2+
  Programming Lang: Python
  Description : easy-to-use interface to the Xapian search engine

 Xapian provides a low level interface, dealing with terms and
 documents, but not really worrying about where terms come from, or how
 to build searches to match the way in which data has been indexed.  In
 contrast, Xappy allows you to design a field structure, specifying what
 kind of information is held in particular fields, and then uses this
 field structure to index data appropriately, and to build and perform
 searches.

The library is used by upcoming release 0.9.x of the MoinMoin wiki
engine.



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

Re: bug #551926: python-pip and pip: error when trying to install together

[Jonathan Yu]

Hi:

[Cc'ing Adam Kennedy since I'm not sure if he's subscribed to debian-devel]

Since Adam mentions that Perl's pip predates Python's pip by a
significant margin, I think we should close this issue by renaming
Python's installer back to pyinstall. It doesn't seem fair for someone
who came on the scene later (who didn't do the appropriate research,
and who, when prompted with the problem, decided to proceed with pip
anyway) to be able to usurp the namespace from Perl.

I'd personally object to renaming Perl's pip to anything else given
these issues.

An alternative arrangement I'd be open to is:
/usr/bin/pip points to a sh script, which tells the user that `pip'
has been renamed to perl-pip and python-pip in Debian. This way,
neither pip gets the /usr/bin/pip name. However, I'm not sure about
how to do this (I guess it'd need to be handled like the dual-life
Perl modules are, via divert and all that...). Again, I don't think
it's fair for Perl's pip to lose `pip' just because some other author
is a jerk (even if Python's pip just so happened to be packaged
first).

Cheers,

Jonathan

On Sun, Nov 29, 2009 at 8:01 PM, Adam Kennedy
 wrote:
> http://blog.ianbicking.org/2008/10/28/pyinstall-is-dead-long-live-pip/
>
> The Perl package predates the Python one by several years.
>
> The author was made aware of the clash well before it was shipped to
> Debian and chose to continue anyway.
>
> Adam K
>
> 2009/11/30 Tim Retout :
>> [Resending to the *actual* debian-devel address. :) D'oh.]
>>
>> According to Debian Policy 10.1 [*], when two binaries have different
>> functionality but the same name, this should be reported to the
>> debian-devel mailing list.
>>
>> [*] http://www.debian.org/doc/debian-policy/ch-files.html#s10.1
>>
>> In this case, 'pip' and 'python-pip' both ship /usr/bin/pip, but one is
>> for Perl and one is for Python. The 'python-pip' package has precedence
>> in Debian (and indeed, is the only one in testing), so I propose that
>> the Perl pip package must pick a pseudonym for its program.
>>
>> My first suggestion is 'pip-perl', so that it's still possible to find
>> via tab-completion on 'pip'.  Better ideas welcomed, otherwise I'll make
>> the change in a few days.
>>
>> This isn't ideal for having the same name for the Perl pip on all
>> platforms, I know - but until we fix this, there will be a serious bug
>> on 'pip', and it will not be released with Debian.
>>
>> Regards,
>>
>> --
>> Tim Retout 
>>
>>
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>


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

Re: bug #551926: python-pip and pip: error when trying to install together

[Cyril Brulebois]

Jonathan Yu  (29/11/2009):
> An alternative arrangement I'd be open to is: /usr/bin/pip points to
> a sh script, which tells the user that `pip' has been renamed to
> perl-pip and python-pip in Debian. This way, neither pip gets the
> /usr/bin/pip name.

Mentioning $LANG in the binary is the way to go. Bonus points if
obfuscated. What about pip, pipp, and ppip? Then, you even get room
for php!

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bits from the NM people

[Jeremy T. Bouse]

Bernd Zeimetz wrote:
> Ralf Treinen wrote:
>> GPG keysigning coordination is since a long time done by a small
>> group of people independendent from FrontDesk. Currently this is
>> basically me, with an offer from Patrick Schoenfeld to help. In 
>> the past tbm and Luk have been part of that team.
>>
>> I agree that the infrastructure could (and should) be independent
>> of the rest of nm. Which doesn't mean that I volunteer to implement
>> it ...
> 
> In my opinion the easiest way would be to use a page in the Debian wiki,
> probably with some links to biglumber and/or other useful resources.
> And it would be really easy to maintain it - in the best case it maintains 
> itself.
> 

I'd hold on using biglumber as I've seen several people, and I myself
have confirmed, problems logging into the site to manage your listings.
There is already https://nm.debian.org/gpg.php that people should be
pointed to as a good starting place.



signature.asc
Description: OpenPGP digital signature

Re: Bits from the NM people

[Cyril Brulebois]

Jeremy T. Bouse  (29/11/2009):
> There is already https://nm.debian.org/gpg.php that people should be
> pointed to as a good starting place.

Did you actually read the thread?

(Either one more mail than the one you replied to; or only that one,
but including the quoted message in there should be a good starting
place.)

Mraw,
KiBi.


signature.asc
Description: Digital signature

linkexchange request !

[Narinder Kaur]

Hello m narinder


i need travel shopping education computer seo fianance bussines releted
sites pr 3 obl 55
if do u have plz contect me at chat


narin...@gdtechindia.com

Re: Bits from the NM people

[Ralf Treinen]

On Mon, Nov 30, 2009 at 01:22:09AM +0100, Bernd Zeimetz wrote:
> Ralf Treinen wrote:
> > GPG keysigning coordination is since a long time done by a small
> > group of people independendent from FrontDesk. Currently this is
> > basically me, with an offer from Patrick Schoenfeld to help. In 
> > the past tbm and Luk have been part of that team.
> > 
> > I agree that the infrastructure could (and should) be independent
> > of the rest of nm. Which doesn't mean that I volunteer to implement
> > it ...
> 
> In my opinion the easiest way would be to use a page in the Debian wiki,
> probably with some links to biglumber and/or other useful resources.

Bernd,

the main resource is a psql database with offers and requests, and the
gpg coordination web pages are mainly interfacing to these web pages.

Did you actually look at how gpg coordination works?

> And it would be really easy to maintain it - in the best case it maintains 
> itself.

Nothing maintains itself.

-Ralf.


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

Re: New source package formats now available

[Brian May]

On Mon, Nov 23, 2009 at 04:12:58PM +1100, Brian May wrote:
> Am I doing something wrong?

Just a general observation, it is rather painful to have to set and maintian
QUILT_PATCHES by hand everytime I want to modify a patch. There have been a
number of times now I have accidentally created the patch in the wrong
directory, which can be very confusing (mess two projects up in one go!).

Maybe this is now fixed in unstable, last I checked it wasn't.
-- 
Brian May 


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

Re: New source package formats now available

[Russ Allbery]

Brian May  writes:

> Just a general observation, it is rather painful to have to set and
> maintian QUILT_PATCHES by hand everytime I want to modify a patch. There
> have been a number of times now I have accidentally created the patch in
> the wrong directory, which can be very confusing (mess two projects up
> in one go!).

> Maybe this is now fixed in unstable, last I checked it wasn't.

If the only thing you use quilt for is Debian packaging and you perform
quilt operations from the top of the tree, then this setting in ~/.quiltrc
works fine:

QUILT_PATCHES=debian/patches

There's a more complex recipe in the quilt documentation that handles more
cases.

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


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

Re: Bits from the NM people

[Raphael Geissert]

Ralf Treinen wrote:
> 
> I agree that the infrastructure could (and should) be independent
> of the rest of nm. Which doesn't mean that I volunteer to implement
> it ...
> 

I could probably help implementing a basic system, but I don't know if it
wouldn't be easier to use a ticket-based system so that it is easy to
follow up keysigning requests.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net


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