Re: New make is breaking several packages

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> Err, what are you trying to do? You have demonstrated here
>  that with the new make, you can concatenate words, the old make did
>  not. 
[...]
>> So it seems that it is not possible to make shell commands with line
>> continuation work with both make versions, and one has to resort to
>> the make variable solution.
>
> Trivial to make a makefile that echoes two words in the old
>  and the new version -- unless I am missing what you are trying to do? 

Daniel claimed that it was possible to write a Makefile that echos one
word with both versions.  That was what Robert was trying out and didn't
work with Daniel's first suggestion, and with his second neither.

You are right that it's hardly useful - just break the line elsewhere.
But still that's the topic of the thread, and just telling people "there
is no problem" without telling them why their imagined problem isn't
real won't help out soon.  It takes three mails by me and two by you... 


Thanks anyway,
Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: not getting CCs from the bugs I reported

[Lionel Elie Mamane]

On Wed, Dec 28, 2005 at 11:49:31PM -0600, Adam Heath wrote:
> On Thu, 29 Dec 2005, kamaraju kusumanchi wrote:

>>I might be acting paranoid here but just want to clarify couple
>> of things. I was under the impression that, if I report a bug to
>> bugs.debian.org, any future correspondence on that bug will be CCed
>> to me automatically. Is this correct?

> You'll only get mails if the sender sends to ###-submitter.  Mail sent to just
> ### is not forwarded, and only stored.

> This is not a bug in the software, but in the person sending the mail.

Note, however, that you can explicitly subscribe to the bug to get
everything; send mail to [EMAIL PROTECTED] .

-- 
Lionel


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

Re: not getting CCs from the bugs I reported

[Thijs Kinkhorst]

On Wed, 2005-12-28 at 23:49 -0600, Adam Heath wrote:
> You'll only get mails if the sender sends to ###-submitter.  Mail sent to just
> ### is not forwarded, and only stored.
> 
> This is not a bug in the software, but in the person sending the mail.

I'd consider this a bug in the software, the principle of least surprise
would suggest that one gets copied on updates to bugs one submits. I've
seen this on every BTS I've encountered and it makes sense to do so. Of
course it should be easy to unsubscribe.


Thijs


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

Stop Wasting Time........the key to Googles backdoor

[Jen R.]

You don't have to unlock it.

We already have


http://www.adminder.com/c.cgi?gotwood&salehoo


I made $5400 in my first 3 weeks using this

Re: switching to vim-tiny for standard vi?

[Toni Mueller]

Hello,

On Thu, 22.12.2005 at 17:20:42 +0100, Henning Makholm <[EMAIL PROTECTED]> wrote:
> Yes; therefore it is not bloat to have nvi and nano both in base; they
> satisfy different needs (having a vi because we're unix resp. having a
> non-modal editor for the rest of us).

I'm not used to nano, but the editor in base expected to be used for
working on system config files is imho required to respect tabs and eg.
*not* convert them to spaces unless told to do so, and also provide
means to enter new tabs.

Other than that, vim is much closer to non-modality than is nvi - you
can often stay in insert mode while using cursor and delete keys to
your heart's content.


Best,
--Toni++


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

Re: not getting CCs from the bugs I reported

[Guilherme de S. Pastore]

Hi there,

Em Qua, 2005-12-28 às 23:49 -0600, Adam Heath escreveu:
> You'll only get mails if the sender sends to ###-submitter.  Mail sent to just
> ### is not forwarded, and only stored.

Not that this really matters for the points in this discussion, but just
for the record, messages to [EMAIL PROTECTED] get forwarded to the
package maintainer.

> This is not a bug in the software, but in the person sending the mail.

Agreed.

-- 
Guilherme de S. Pastore (fatalerror)
<[EMAIL PROTECTED]>


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

Re: stable aliases for CD drives

[Marco d'Itri]

On Dec 29, Steve Langasek <[EMAIL PROTECTED]> wrote:

> > Some component of debian will have to install a rules file with static
> > aliases, and so far I think that this should be a task for d-i.
> > Comments and other ideas are welcome.
> What will provide this for systems upgraded from sarge?
Good point. So it looks like that this will have to be managed by an
installed package.
I do not expect to be pratical to do this e.g. at boot time, so we need
a script to be run by a catch-all rule for devices without an alias.

BTW, does d-i actually need the /dev/cdrom symlink at all?

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Archive architecture qualification

[Aurelien Jarno]

On Thu, Dec 29, 2005 at 03:32:43AM +1000, Anthony Towns wrote:

[snip]

> Anyway, that's the general idea; hopefully it'll become clearer
> later. Given release architectures have de-facto requalified, candidates
> for archive (re)qualification are ttbomk:
> 
>   * arm, m68k, s390, sparc
>   * amd64, armeb
>   * hurd-i386, hurd-powerpc
>   * *bsd-i386

AFAIK, only kfreebsd-i386 (ie GNU/kFreeBSD on i386) is a candidate for 
archive. Other BSD ports are the NetBSD ports, which are almost stopped.
However most of the fixes done for GNU/kFreeBSD will help the NetBSD
ports.

>   * opensolaris
> 

-- 
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


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

dependencies on makedev

[Marco d'Itri]

To prepare for the eventual removal of makedev, I propose that packages
currently depending on it will add an alternative dependency to udev.
Also, policy should be amended accordingly.

The affected packages are:

alevt
camstream
cdrecord
dvb-utils
fbset
gnupg
gnupg2
irda-utils
isdnutils-base
joystick
libcomedi0
libggi-target-fbdev
libraw1394-5
libsane
lm-sensors
mdadm
microcode.ctl
mkinitrd-cd
mwavem
nvram-wakeup
openswan
powermgmt-base
powertweakd
ppp
thinkpad-base
toshutils
tpb
udftools
uml-utilities
vdr
watchdog
x86info
xcdroast
z8530-utils2


These packages have already been fixed:

dvbtune
rng-tools

-- 
ciao,
Marco


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

Re: stable aliases for CD drives

[Joey Hess]

Marco d'Itri wrote:
> Good point. So it looks like that this will have to be managed by an
> installed package.
> I do not expect to be pratical to do this e.g. at boot time, so we need
> a script to be run by a catch-all rule for devices without an alias.
> 
> BTW, does d-i actually need the /dev/cdrom symlink at all?

d-i needs it to be available in the installed system so apt can install
from CDs etc, it's not needed in the d-i environment though; d-i scans
all CDs on its own to find the one with the Debian disk in.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: switching to vim-tiny for standard vi?

[Lars Wirzenius]

to, 2005-12-29 kello 11:01 +0100, Toni Mueller kirjoitti:
> I'm not used to nano, but the editor in base expected to be used for
> working on system config files is imho required to respect tabs and eg.
> *not* convert them to spaces unless told to do so, and also provide
> means to enter new tabs.

Does nano not do that for you?

-- 
Pity the sysadmin


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

Re: dependencies on makedev

[Lars Wirzenius]

to, 2005-12-29 kello 13:39 +0100, Marco d'Itri kirjoitti:
> To prepare for the eventual removal of makedev, I propose that packages
> currently depending on it will add an alternative dependency to udev.
> Also, policy should be amended accordingly.
> 
> The affected packages are:

This is the same list, run through dd-list (from devscripts) to make it
easier to find yourself (helpful for those who have lots of packages):

Martin Albert <[EMAIL PROTECTED]>
   libggi

Richard Atterer <[EMAIL PROTECTED]>
   udftools

Julien BLACHE <[EMAIL PROTECTED]>
   sane-backends

Edward Betts <[EMAIL PROTECTED]>
   joystick

Markus Braun <[EMAIL PROTECTED]>
   tpb

Mark Brown <[EMAIL PROTECTED]>
   powertweak
   x86info

Giacomo Catenazzi <[EMAIL PROTECTED]>
   microcode.ctl

Ben Collins <[EMAIL PROTECTED]>
   libraw1394

Hector Garcia <[EMAIL PROTECTED]>
   xcdroast

Chris Hanson <[EMAIL PROTECTED]>
   powermgmt-base

Thomas Hood <[EMAIL PROTECTED]>
   mwavem
   thinkpad

Alberto Gonzalez Iniesta <[EMAIL PROTECTED]>
   irda-utils

Aurelien Jarno <[EMAIL PROTECTED]>
   camstream
   lm-sensors

Joerg Jaspert <[EMAIL PROTECTED]>
   cdrtools

Guillem Jover <[EMAIL PROTECTED]>
   fbset

Rene Mayrhofer <[EMAIL PROTECTED]>
   openswan

Rene Mayrhofer <[EMAIL PROTECTED]>
   gibraltar-bootcd

Michael Meskes <[EMAIL PROTECTED]>
   watchdog

Andreas Rottmann <[EMAIL PROTECTED]>
   alevt

Roberto C. Sanchez <[EMAIL PROTECTED]>
   toshutils

David Schleef <[EMAIL PROTECTED]>
   comedilib

Paul Slootman <[EMAIL PROTECTED]>
   isdnutils

Joop Stakenborg <[EMAIL PROTECTED]>
   z8530-utils2

Debian VDR Team <[EMAIL PROTECTED]>
   linuxtv-dvb-apps
   nvram-wakeup
   vdr

James Troup <[EMAIL PROTECTED]>
   gnupg

Matthias Urlichs <[EMAIL PROTECTED]>
   gnupg2

Matt Zimmerman <[EMAIL PROTECTED]>
   uml-utilities

Marco d'Itri <[EMAIL PROTECTED]>
   ppp

Debian/Ubuntu mdadm maintainers
<[EMAIL PROTECTED]>
   mdadm



-- 
Fundamental truth #1: Complexity is the enemy.


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

Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Frank Lichtenheld]

Package: wnpp
Severity: wishlist
Owner: Frank Lichtenheld <[EMAIL PROTECTED]>

* Package name: libgpod
  Version : 0.3.0
  Upstream Author : Jorg Schuler (jcsjcs at users dot sourceforge dot net)
* URL : http://www.gtkpod.org
* License : GPL
  Description : a library to read and write songs and artwork to an iPod

libgpod is a library meant to abstract access to an iPod content. It
provides an easy to use API to retrieve the list of files and playlist
stored on an iPod, to modify them and to save them back to the iPod.

This is a shared library evolved from the code from gtkpod (which I
already maintain) and is need to package the newest upstream versions
thereof.

Ubuntu already has packages of this so I will probably use them as
starting point unless I find reasons to do otherwise.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-powerpc
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)


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

Re: Thoughts on Debian quality, including automated testing

[Lars Wirzenius]

ke, 2005-12-28 kello 02:00 +0100, Moritz Muehlenhoff kirjoitti:
> Why don't we add a status field into the PTS, where a maintainer
> can denote her "NMU policy" for a given source package? E.g.
> a selection box, ranging from "Don't dare to touch this, I bite"
> to "Feel free to 0d-NMU for every severity as long a you send the
> patch". Or a free-form field, if that doesn't suffice.

I started a list on wiki.debian.org for people who welcome low threshold
NMUs for their packages.

http://wiki.debian.org/LowThresholdNmu

-- 
When in doubt, use brute force.


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

Re: stable aliases for CD drives

[Finn-Arne Johansen]

Joey Hess wrote:
> Marco d'Itri wrote:
> 
>>Good point. So it looks like that this will have to be managed by an
>>installed package.
>>I do not expect to be pratical to do this e.g. at boot time, so we need
>>a script to be run by a catch-all rule for devices without an alias.
>>
>>BTW, does d-i actually need the /dev/cdrom symlink at all?
> 
> 
> d-i needs it to be available in the installed system so apt can install
> from CDs etc, it's not needed in the d-i environment though; d-i scans
> all CDs on its own to find the one with the Debian disk in.

Would it not be enough for apt if d-i created an fstab that linked
 /dev/hdX -> /media/cdrom ?


-- 
Finn-Arne Johansen
[EMAIL PROTECTED] http://bzz.no/
Debian-edu developer and solution provider


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

Re: dependencies on makedev

[Mark Brown]

On Thu, Dec 29, 2005 at 01:39:01PM +0100, Marco d'Itri wrote:

> To prepare for the eventual removal of makedev, I propose that packages
> currently depending on it will add an alternative dependency to udev.
> Also, policy should be amended accordingly.

It might be useful to tell the maintainers of the packages and/or post
on -devel-announce - people might not be reading -devel or -policy.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


signature.asc
Description: Digital signature

Re: dependencies on makedev

[Henrique de Moraes Holschuh]

On Thu, 29 Dec 2005, Marco d'Itri wrote:
> These packages have already been fixed:
> rng-tools

Huh? rng-tools certainly takes benefit of MAKEDEV.  It doesn't bork if
MAKEDEV has disappeared, though.  Is that what you mean?

rng-tools postinst does this:
(cd /dev && ./MAKEDEV hwrandom || ./MAKEDEV intel_rng || true)

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

Re: dependencies on makedev

[Marco d'Itri]

On Dec 29, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:

> Huh? rng-tools certainly takes benefit of MAKEDEV.  It doesn't bork if
> MAKEDEV has disappeared, though.  Is that what you mean?
No. I mean that it currently depends on makedeva while it should depend
on makedev | udev.

> rng-tools postinst does this:
> (cd /dev && ./MAKEDEV hwrandom || ./MAKEDEV intel_rng || true)
I can't see the point. It already depends on a specific makedev release,
so the commands are supposed to work.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Thoughts on Debian quality, including automated testing

[Lionel Elie Mamane]

On Thu, Dec 29, 2005 at 03:46:08PM +0200, Lars Wirzenius wrote:
> ke, 2005-12-28 kello 02:00 +0100, Moritz Muehlenhoff kirjoitti:

>> Why don't we add a status field into the PTS, where a maintainer
>> can denote her "NMU policy" for a given source package? E.g.  a
>> selection box, ranging from "Don't dare to touch this, I bite" to
>> "Feel free to 0d-NMU for every severity as long a you send the
>> patch". Or a free-form field, if that doesn't suffice.

> I started a list on wiki.debian.org for people who welcome low
> threshold NMUs for their packages.

> http://wiki.debian.org/LowThresholdNmu

Thanks, but I can't find the "edit" link or button. Is it well hidden
or am I going blind?

-- 
Lionel


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

Re: Thoughts on Debian quality, including automated testing

[Steinar H. Gunderson]

On Thu, Dec 29, 2005 at 04:31:22PM +0100, Lionel Elie Mamane wrote:
>> http://wiki.debian.org/LowThresholdNmu
> Thanks, but I can't find the "edit" link or button. Is it well hidden
> or am I going blind?

wiki.debian.org uses MoinMoin, which is this odd sort of psuedo-wiki; you
have to register and log in before it will let you edit anything.

/* Steinar */
-- 
Homepage: http://www.sesse.net/


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

Re: New make is breaking several packages

[Manoj Srivastava]

On Thu, 29 Dec 2005 09:04:09 +0100, Frank Küster <[EMAIL PROTECTED]> said: 

> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> Err, what are you trying to do? You have demonstrated here that
>> with the new make, you can concatenate words, the old make did not.
> [...]
>>> So it seems that it is not possible to make shell commands with
>>> line continuation work with both make versions, and one has to
>>> resort to the make variable solution.
>> 
>> Trivial to make a makefile that echoes two words in the old and the
>> new version -- unless I am missing what you are trying to do?

> Daniel claimed that it was possible to write a Makefile that echos
> one word with both versions.  That was what Robert was trying out
> and didn't work with Daniel's first suggestion, and with his second
> neither.

As far as I can tell, this is new functionality in the current
 make, which can do both one word and two word out put with
 continuation lines.

> You are right that it's hardly useful - just break the line
> elsewhere.  But still that's the topic of the thread, and just
> telling people "there is no problem" without telling them why their
> imagined problem isn't real won't help out soon.  It takes three
> mails by me and two by you...

Err, while this documentation shall be included well before
 the final release (which is, according to schedule, about an year
 away), complaining that I did not test out the package and discern
 all little documentation issues with the new functionality that
 people other than I would have a problem with is childish. While the
 continuation issues did not affect my makefiles directly, I did not
 consider the stanza in NEWS unclear (I know how POSIX shellshandle
 newlines, I assume most DD's do as well). It is not easy to provide
 helpful documentation for unclear areas when the areas are not
 unclear to one.

Debian developers, and others using Sid, should be prepared
 for minor lacunae in documentation; this is why we have unstable --
 so minor mistakes and deficiencies can be uncovered.

People who can't figure out what is happening with the new
 continuation behaviour should really consider running Sarge until we
 have added the spoon feeding and training wheels to Etch.

In other words, if you want release quality stuff, don't use
 Sid, and don't hector people who upload to Sid early, and often, and
 use the feedback to improve packages and documentation.

manoj
-- 
"You know, of course, that the Tasmanians, who never committed
adultery, are now extinct."- M. Somerset Maugham
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: debian-devel@lists.debian.org

[Adrian von Bidder]

Hi Milan, Jon,

As discussed, 'the Debian project' as such has huge difficulties accepting 
hardware donations - offers are often turned down. (tangent - in my opinion 
donations should be accepted more liberally and if the Debian 
administrators can not be bothered to administer yet another machine, I'm 
sure somebody can be found on case-by-case basis to administer these 
machines and give out accounts to developers as needed.)

For Sun machines, the best place to ask is probably the Debian sparc porters 
mailing list (debian-sparc@lists.debian.org) - if anybody is interested in 
this machine, he's bound to hang out there.  I guess you could donate the 
machine to the Debian project and have it be taken care of some individual 
developers.  Especially since you (Milan) are ready to host it, you can 
somewhat control that it's really being used for Debian work (or at least, 
you can cut access again and donate it to somebody else or whatever.)

Another possibility is local Linux user groups - especially since (I'm 
thinking of Milan) international shipping may be a major problems.

cheers
-- vbi

-- 
According to my calculations the problem doesn't exist.


pgp8XsWhMdAJt.pgp
Description: PGP signature

Re: stable aliases for CD drives

[Adrian von Bidder]

On Thursday 29 December 2005 14.45, Finn-Arne Johansen wrote:

> Would it not be enough for apt if d-i created an fstab that linked
>  /dev/hdX -> /media/cdrom ?

Won't work because the problem at hand is exactly that /dev/hdX won't 
necessarily be stable anymore.

(and, once more, and much worse: network interfaces need a solution to the 
same problem...)

>
>
> --
> Finn-Arne Johansen
> [EMAIL PROTECTED] http://bzz.no/
> Debian-edu developer and solution provider

-- 
Beware of the FUD - know your enemies. This week
* The Alexis de Toqueville Institue *
http://fortytwo.ch/opinion/adti


pgpHqkYDV0jDE.pgp
Description: PGP signature

Re: stable aliases for CD drives

[Marco d'Itri]

On Dec 29, Adrian von Bidder <[EMAIL PROTECTED]> wrote:

> Won't work because the problem at hand is exactly that /dev/hdX won't 
> necessarily be stable anymore.
No: the /dev/[sh]d* devices are as stable as they have always been.
ONLY rules using %e (the /dev/cdrom-like aliases) are unreliable.

> (and, once more, and much worse: network interfaces need a solution to the 
> same problem...)
This is a possible solution, but somebody would need to add to ifupdown
whatever is needed to support this:

# find the interface name using the MAC address
SUBSYSTEM=="net", SYSFS{address}=="?*", \
IMPORT{program}="/sbin/ifup --mac-to-name $sysfs{address}"

# if it did not work, try using other properties
SUBSYSTEM=="net", ENV{IF_NAME}!="?*", ..., \
IMPORT{program}="..."

# set the interface name, if found
ENV{IF_NAME}=="?*", NAME="$env{IF_NAME}"

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: dependencies on makedev

[Henrique de Moraes Holschuh]

On Thu, 29 Dec 2005, Marco d'Itri wrote:
> On Dec 29, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> No. I mean that it currently depends on makedeva while it should depend
> on makedev | udev.

I see.

> > rng-tools postinst does this:
> > (cd /dev && ./MAKEDEV hwrandom || ./MAKEDEV intel_rng || true)
> I can't see the point. It already depends on a specific makedev release,
> so the commands are supposed to work.

It was either to ease backports, or because I forgot to remove that line
when I bumped up the makedev versioned dependency.  Anyway, I will revisit
this package soon for some packaging cleanup.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh


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

ITK: debmake

[Santiago Vila]

Greetings.

There are less than 80 packages in unstable still using it, and there
is an excellent package called debhelper which can do everything that
debmake does and probably much better, so it does not make much sense
to keep debmake alive forever.

Therefore, I hereby announce my Intention To Kill debmake.

The current plan is as follows:

Stage 1. "Please do not create new packages using debmake".

This started a year ago when deb-make was removed from the debmake
binary package, leaving just the debstd tool. However, there are a few
more things that could be done, and this is where help would be welcome,
for example:

*) If you are a sponsor, you are welcome to refuse to upload a package
that uses debmake.

*) If you are a ftp-master, you are more than welcome to reject a package
in the NEW queue if it's a completely new package and it uses debmake.

*) If you maintain documentation from the DDP, you are welcome to
remove any documentation or howto explaining how to use debmake to
create a debian package. This includes translations.


Stage 2. "Please switch away from debmake".

This is the stage that starts today. So, everybody please, switch away
from debmake. From past experience converting orphaned packages to
debhelper, I would say that debhelper is the logical choice, but every
person has his preferences regarding helper packages.

In addition to the items listed above, I suggest this:

*) If you are the maintainer of lintian or a similar tool, you are welcome
to add a check that gives a warning if a package uses debmake.

*) Please don't file any bugs yet.


Stage 3 will start when the number of packages using debmake is "low enough".
If the release managers agree, RC bugs would be filed against any
remaining packages. When the number is zero, I'll ask ftp-master to
remove debmake from the archive.

As a realistic goal, I estimate that etch will be the last release
containing debmake, but of course, I would be deligthed to see it
happen sooner.

Thanks.


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

Re: dependencies on makedev

[Adam Heath]

On Thu, 29 Dec 2005, Marco d'Itri wrote:

> To prepare for the eventual removal of makedev, I propose that packages
> currently depending on it will add an alternative dependency to udev.
> Also, policy should be amended accordingly.

Er, why is makedev being removed?  Please clue me in.


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

Re: debian-devel@lists.debian.org

[Adam Heath]

On Thu, 29 Dec 2005, Adrian von Bidder wrote:

> Hi Milan, Jon,
>
> As discussed, 'the Debian project' as such has huge difficulties accepting
> hardware donations - offers are often turned down. (tangent - in my opinion
> donations should be accepted more liberally and if the Debian
> administrators can not be bothered to administer yet another machine, I'm
> sure somebody can be found on case-by-case basis to administer these
> machines and give out accounts to developers as needed.)
>
> For Sun machines, the best place to ask is probably the Debian sparc porters
> mailing list (debian-sparc@lists.debian.org) - if anybody is interested in
> this machine, he's bound to hang out there.  I guess you could donate the
> machine to the Debian project and have it be taken care of some individual
> developers.  Especially since you (Milan) are ready to host it, you can
> somewhat control that it's really being used for Debian work (or at least,
> you can cut access again and donate it to somebody else or whatever.)
>
> Another possibility is local Linux user groups - especially since (I'm
> thinking of Milan) international shipping may be a major problems.

A machine *donated* to the debian project has to be *maintained* and *hosted*.
The DSA(Debian System Administrators) do not want to maintain machines, unless
it can be shown that the machine in question is of great benefit to the entire
project, at large.

Also, hosting can be a sticky situation.  First, bandwidth issues, due to
people downloading packages, is there a local mirror for the arch, etc.  Then,
a machine allowing 1000+ people may be an issue to some hosting companies.

In addition, a machine for use by the project at large generally needs to be
able to support lots of random developers logging in, and leaving stuff lying
around.  This means disk space.

Another problem is who does the work when the hardware fails?  All hardware
will fail, at some point.  This requires a local admin to tend to the machine.
It is also helpful if the local admin knows a bit about the architecture in
question(altho, this isn't always a requirement).

These reasons outline(1), in a nutshell, why individual people donating
individual random old machines get turned down, time and time again.

1: this list is not complete, and only has the most obvious items.


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

Re: ITK: debmake

[Daniel Kobras]

On Thu, Dec 29, 2005 at 07:13:05PM +0100, Santiago Vila wrote:
> There are less than 80 packages in unstable still using it, and there
> is an excellent package called debhelper which can do everything that
> debmake does and probably much better, so it does not make much sense
> to keep debmake alive forever.
>
> Therefore, I hereby announce my Intention To Kill debmake.
(...)
> Stage 2. "Please switch away from debmake".
> 
> This is the stage that starts today. So, everybody please, switch away
> from debmake. From past experience converting orphaned packages to
> debhelper, I would say that debhelper is the logical choice, but every
> person has his preferences regarding helper packages.

For reference, this is the list of the 58 packages in unstable that
still build-depend on debmake:

Stefan Alfredsson <[EMAIL PROTECTED]>
   biew
   cksfv

Hakan Ardo <[EMAIL PROTECTED]>
   libcompface

Malc Arnold <[EMAIL PROTECTED]>
   af
   ucbmpeg-play

Eric Van Buggenhaut <[EMAIL PROTECTED]>
   vsound

Debian Hamradio Maintainers 
   fbb

Bernd Eckenfels <[EMAIL PROTECTED]>
   cadaver

Mark W. Eichin <[EMAIL PROTECTED]>
   lx-gdb

Oliver Elphick <[EMAIL PROTECTED]>
   verse

Jochen Friedrich <[EMAIL PROTECTED]>
   liveice
   snmptrapfmt

Richard A. Hecker <[EMAIL PROTECTED]>
   set6x86

Michael Holzt <[EMAIL PROTECTED]>
   obexserver

Morten Hustveit <[EMAIL PROTECTED]>
   kwavecontrol

LaMont Jones <[EMAIL PROTECTED]>
   xdelta

Tibor Koleszar <[EMAIL PROTECTED]>
   falselogin

Antonin Kral <[EMAIL PROTECTED]>
   fmirror

Anand Kumria <[EMAIL PROTECTED]>
   gtk-gnutella

Corrin Lakeland <[EMAIL PROTECTED]>
   gnubg

Frederic Lepied <[EMAIL PROTECTED]>
   xinput

Jonathan McDowell <[EMAIL PROTECTED]>
   fidogate

David H. Munro <[EMAIL PROTECTED]>
   yorick

Kenshi Muto <[EMAIL PROTECTED]>
   xjokes

Cajus Pollmeier <[EMAIL PROTECTED]>
   gnarwl

Tomas Pospisek <[EMAIL PROTECTED]>
   xxdiff

Filip Van Raemdonck <[EMAIL PROTECTED]>
   xmon

Anibal Monsalve Salazar <[EMAIL PROTECTED]>
   translate
   xtranslate

Alain Schroeder <[EMAIL PROTECTED]>
   wmsmpmon

Nathan Scott <[EMAIL PROTECTED]>
   acl
   attr
   dmapi
   xfsdump

Paul Slootman <[EMAIL PROTECTED]>
   linpopup

Joop Stakenborg <[EMAIL PROTECTED]>
   baken
   baycomepp
   colrconv
   cwdaemon
   fbbdoc
   gcb
   hamsoft
   ibp
   twclock
   twlog
   xcall
   xconvers
   xdx
   z8530-utils2

David Starner <[EMAIL PROTECTED]>
   music123

Warren Stramiello <[EMAIL PROTECTED]>
   xdrawchem

Marcela Tiznado <[EMAIL PROTECTED]>
   gtkgo

Matthew Vernon <[EMAIL PROTECTED]>
   floppybackup

Jim Westveer <[EMAIL PROTECTED]>
   barcode
   ean13

Martin Wuertele <[EMAIL PROTECTED]>
   kdc2tiff

James R. Van Zandt <[EMAIL PROTECTED]>
   flip
   libwn6



Regards,

Daniel.


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

Re: ITK: debmake

[Russ Allbery]

Daniel Kobras <[EMAIL PROTECTED]> writes:

> Corrin Lakeland <[EMAIL PROTECTED]>
>gnubg

I've adopted gnubg with Corrin's permission and this is now fixed in the
version just uploaded yesterday.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: dependencies on makedev

[Marco d'Itri]

On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:

> > To prepare for the eventual removal of makedev, I propose that packages
> Er, why is makedev being removed?  Please clue me in.
"Eventual" is the key word here.
Because /eventually/ it will not be needed anymore (at least by most
users, which then will be able to remove it from their systems).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: dependencies on makedev

[Adam Heath]

On Thu, 29 Dec 2005, Marco d'Itri wrote:

> On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
>
> > > To prepare for the eventual removal of makedev, I propose that packages
> > Er, why is makedev being removed?  Please clue me in.
> "Eventual" is the key word here.
> Because /eventually/ it will not be needed anymore (at least by most
> users, which then will be able to remove it from their systems).

**Why?**

Is there something to replace it, completely, in *all* situations?


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

Re: ITK: debmake

[Daniel Kobras]

On Thu, Dec 29, 2005 at 10:59:22AM -0800, Russ Allbery wrote:
> I've adopted gnubg with Corrin's permission and this is now fixed in the
> version just uploaded yesterday.

Here's an updated and now hopefully complete list that also takes into
account build-depends-indep.  Removing gnubg from the list, this makes
it a total of 78 packages affected.

Regards,

Daniel.

---[snip]---

Stefan Alfredsson <[EMAIL PROTECTED]>
   biew
   cksfv

Hakan Ardo <[EMAIL PROTECTED]>
   avr-libc
   ftpwatch
   libcompface
   picon-domains
   picon-misc
   picon-news
   picon-unknown
   picon-usenix
   picon-users
   picon-weather

Malc Arnold <[EMAIL PROTECTED]>
   af
   ucbmpeg-play

James Bromberger <[EMAIL PROTECTED]>
   cvsweb

Eric Van Buggenhaut <[EMAIL PROTECTED]>
   vsound

Debian Hamradio Maintainers 
   fbb

Ludovic Drolez <[EMAIL PROTECTED]>
   tkusr
   websec

Bernd Eckenfels <[EMAIL PROTECTED]>
   cadaver

Mark W. Eichin <[EMAIL PROTECTED]>
   lx-gdb

Oliver Elphick <[EMAIL PROTECTED]>
   verse

Jochen Friedrich <[EMAIL PROTECTED]>
   liveice
   snmptrapfmt

Christian Garbs <[EMAIL PROTECTED]>
   whatsnewfm

John Goerzen <[EMAIL PROTECTED]>
   pilot-template

Richard A. Hecker <[EMAIL PROTECTED]>
   set6x86

Michael Holzt <[EMAIL PROTECTED]>
   obexserver

Morten Hustveit <[EMAIL PROTECTED]>
   kwavecontrol

LaMont Jones <[EMAIL PROTECTED]>
   xdelta

Tibor Koleszar <[EMAIL PROTECTED]>
   falselogin

Antonin Kral <[EMAIL PROTECTED]>
   fmirror

Anand Kumria <[EMAIL PROTECTED]>
   gtk-gnutella

Mario Lang <[EMAIL PROTECTED]>
   crypt++el

Frederic Lepied <[EMAIL PROTECTED]>
   xinput

Eduardo Marcel Macan <[EMAIL PROTECTED]>
   fortunes-br

Jonathan McDowell <[EMAIL PROTECTED]>
   fidogate

A Mennucc1 <[EMAIL PROTECTED]>
   hp-ppd

David H. Munro <[EMAIL PROTECTED]>
   yorick
   yorick-doc

Kenshi Muto <[EMAIL PROTECTED]>
   xjokes

Cajus Pollmeier <[EMAIL PROTECTED]>
   gnarwl

Tomas Pospisek <[EMAIL PROTECTED]>
   xxdiff

Filip Van Raemdonck <[EMAIL PROTECTED]>
   xmon

Anibal Monsalve Salazar <[EMAIL PROTECTED]>
   translate
   xtranslate

Alain Schroeder <[EMAIL PROTECTED]>
   wmsmpmon

Nathan Scott <[EMAIL PROTECTED]>
   acl
   attr
   dmapi
   xfsdump

Paul Seelig <[EMAIL PROTECTED]>
   ethiop
   localepurge

Paul Slootman <[EMAIL PROTECTED]>
   linpopup

Joop Stakenborg <[EMAIL PROTECTED]>
   baken
   baycomepp
   colrconv
   cwdaemon
   fbbdoc
   gcb
   hamsoft
   ibp
   twclock
   twlog
   xcall
   xconvers
   xdx
   z8530-utils2

David Starner <[EMAIL PROTECTED]>
   music123

Warren Stramiello <[EMAIL PROTECTED]>
   xdrawchem

Marcela Tiznado <[EMAIL PROTECTED]>
   gtkgo

Matthew Vernon <[EMAIL PROTECTED]>
   floppybackup

Jim Westveer <[EMAIL PROTECTED]>
   barcode
   ean13

Martin Wuertele <[EMAIL PROTECTED]>
   kdc2tiff

James R. Van Zandt <[EMAIL PROTECTED]>
   emacspeak
   flip
   libwn6


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

Re: dependencies on makedev

[Marco d'Itri]

On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:

> > Because /eventually/ it will not be needed anymore (at least by most
> > users, which then will be able to remove it from their systems).
> Is there something to replace it, completely, in *all* situations?
udev, at least for the general case of users using devices in /dev,
fully replaces MAKEDEV.

The only exceptions I can think about are broken drivers which have not
been ported to the device model (but I could not name any) and people
who create device nodes out of /dev for weird reasons (usually because
they need multiple copies of the same device with different owners).

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: stable aliases for CD drives

[Darren Salt]

I demand that Marco d'Itri may or may not have written...

> On Dec 29, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
>> Won't work because the problem at hand is exactly that /dev/hdX won't
>> necessarily be stable anymore.

> No: the /dev/[sh]d* devices are as stable as they have always been.

Which is, in itself, good.

> ONLY rules using %e (the /dev/cdrom-like aliases) are unreliable.

I remember them being reliable. Sacrificing their reliability at the altar of
boot speed (AIUI) wasn't really a good idea...

[snip]
-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   Kill all extremists!

People who can least afford to pay rent pay rent.


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

Re: dependencies on makedev

[Adam Heath]

On Thu, 29 Dec 2005, Marco d'Itri wrote:

> On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
>
> > > Because /eventually/ it will not be needed anymore (at least by most
> > > users, which then will be able to remove it from their systems).
> > Is there something to replace it, completely, in *all* situations?
> udev, at least for the general case of users using devices in /dev,
> fully replaces MAKEDEV.
>
> The only exceptions I can think about are broken drivers which have not
> been ported to the device model (but I could not name any) and people
> who create device nodes out of /dev for weird reasons (usually because
> they need multiple copies of the same device with different owners).

Ok, pardon the noob questions, but here they come:

How does persistance of the permission model work?  Can I do chown/chmod on
the dynamic files in /dev, and have them remain the next time?  Even if a
device node changes it's name?  Or do I have to edit some alternative
database?

I've been running 2.6 for a while now.  Lots of our servers do(all our xen
machines).  We've had no use for any dynamic device anything; in fact, I'd
much prefer to not have anything dynamic on a server; stable names is all I
want(which means the kernel renaming scsi devices is broken, but C'est La
Vie).


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

Re: Size matters. Debian binary package stats

[Darren Salt]

I demand that Benjamin Seidenberg may or may not have written...

[snip]
> I read 120.000 as 120 dollars, I'm not used to the European '.' as the
> seperator, but the US ','.

Hmm? You'd better file a bug against locales wrt en_GB, then ;-)

-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk  Say NO to UK ID cards
|   http://www.no2id.net/

They took some of the Van Goghs, most of the jewels, and all of the Chivas!


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

[RESOLVED] Re: dependencies on makedev

[Adam Heath]

On Thu, 29 Dec 2005, Adam Heath wrote:

> On Thu, 29 Dec 2005, Marco d'Itri wrote:
>
> > On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
> >
> > > > Because /eventually/ it will not be needed anymore (at least by most
> > > > users, which then will be able to remove it from their systems).
> > > Is there something to replace it, completely, in *all* situations?
> > udev, at least for the general case of users using devices in /dev,
> > fully replaces MAKEDEV.
> >
> > The only exceptions I can think about are broken drivers which have not
> > been ported to the device model (but I could not name any) and people
> > who create device nodes out of /dev for weird reasons (usually because
> > they need multiple copies of the same device with different owners).
>
> Ok, pardon the noob questions, but here they come:
>
> How does persistance of the permission model work?  Can I do chown/chmod on
> the dynamic files in /dev, and have them remain the next time?  Even if a
> device node changes it's name?  Or do I have to edit some alternative
> database?
>
> I've been running 2.6 for a while now.  Lots of our servers do(all our xen
> machines).  We've had no use for any dynamic device anything; in fact, I'd
> much prefer to not have anything dynamic on a server; stable names is all I
> want(which means the kernel renaming scsi devices is broken, but C'est La
> Vie).

Ok, well, I've talked to Marco on irc for a bit.  I'd summarize what he said
here, but he didn't actually say anything.

So, these people pushing these automatic whizzywigs are just blowing smoke.
Nothing to see here, move along.


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

Re: stable aliases for CD drives

[Andrew Suffield]

On Thu, Dec 29, 2005 at 05:55:03PM +0100, Adrian von Bidder wrote:
> On Thursday 29 December 2005 14.45, Finn-Arne Johansen wrote:
> 
> > Would it not be enough for apt if d-i created an fstab that linked
> >  /dev/hdX -> /media/cdrom ?
> 
> Won't work because the problem at hand is exactly that /dev/hdX won't 
> necessarily be stable anymore.
> 
> (and, once more, and much worse: network interfaces need a solution to the 
> same problem...)

nameif, ifrename - really, this problem has been solved so many times
that it's just not funny any more.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: something strange with rsh/ssh + bash/tcsh is happening. Please advise

[Brian May]

> "Yaroslav" == Yaroslav Halchenko <[EMAIL PROTECTED]> writes:

Yaroslav> rsh node19 '/bin/echo ; /bin/echo 123'
Yaroslav> rsh node19 /bin/sh -c '/bin/echo ; /bin/echo 123'

I think the problem has already been explained.

The solutions appear to be:

* rsh node19 '/bin/echo ; /bin/echo 123'
(as running the shell inside the shell seems to be a dumb thing anyway)

* rsh node19 /bin/sh -c '"/bin/echo ; /bin/echo 123"'
(also works, but gets increasingly complex)

Also if you are curious try:

* rsh node19 '/bin/echo *; /bin/echo 123'
(the * will be expanded by the implicit shell at the remote end) 

* rsh node19 '/bin/echo 111 > /tmp/out; /bin/echo 123'
(the > will be take effect in the implicit shell at the remote end) 

Is there anyway you can disable this implicit shell, either with ssh
or rsh? I really don't like it. I would rather each parameter be
passed straight to the remote executable via exec without being parsed
by sh first. Then, if I want to use the shell, I can say so. I don't
like this business of the command line being parsed by two shells as
the default.
-- 
Brian May <[EMAIL PROTECTED]>


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

Re: dependencies on makedev

[Roger Leigh]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Adam Heath <[EMAIL PROTECTED]> writes:

> On Thu, 29 Dec 2005, Marco d'Itri wrote:
>
>> On Dec 29, Adam Heath <[EMAIL PROTECTED]> wrote:
>>
> How does persistance of the permission model work?  Can I do chown/chmod on
> the dynamic files in /dev, and have them remain the next time?  Even if a
> device node changes it's name?  Or do I have to edit some alternative
> database?

You edit or add to the udev rules.  These are usually used to set
policy for whole categories of devices, but you can of course fine
tune it, or replace all the standard rules with your own.  The default
gives you all the standard names, as with a static /dev.  (I
personally switched it to the devfs-style rules.)

> I've been running 2.6 for a while now.  Lots of our servers do(all
> our xen machines).  We've had no use for any dynamic device
> anything; in fact, I'd much prefer to not have anything dynamic on a
> server; stable names is all I want

The names are stable, but the devices are created dynamically.  The
only exceptions are hotplug events which may not always occur/complete
in the same order.  This will not be an issue for a server where you
are not e.g. constantly plugging and unplugging lots of USB storage
devices.

I've been running udev on all my systems for some time now without any
problems at all.  The fact that the available devices nodes actually
matches your hardware is quite useful.

Even if you never use udev yourself (though I would recommend at least
trying it), Marco's proposal does make sense: even if you never use
it, we do need to allow for the eventual removal of makedev on systems
using udev--when all the device nodes are already created, it's no
longer useful; this will not preclude it being installed by hand on
systems with a static /dev.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ 

iD8DBQFDtIeWVcFcaSW/uEgRAtjLAJ9HLHtBHVHgIdPGOSrh8hcAYlcjNQCgz7TV
LPOXYQIlPZXVt++UMCFoY1c=
=6GLm
-END PGP SIGNATURE-


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

Bug#345275: ITP: maypole -- Perl framework for MVC-oriented web applications

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings <[EMAIL PROTECTED]>


* Package name: maypole
  Version : 2.10
  Upstream Author : Simon Cozens <[EMAIL PROTECTED]> and others
* URL : http://maypole.cpan.org/
* License : dual GPL/Artistic
  Description : Perl framework for MVC-oriented web applications

Maypole is a Perl framework for MVC-oriented web applications, similar
to Jakarta's Struts. Maypole is designed to minimize coding requirements
for creating simple web interfaces to databases, while remaining flexible
enough to support enterprise web applications.


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

Bug#345277: ITP: memories -- a web-based photo sharing application

[Ben Hutchings]

Package: wnpp
Severity: wishlist
Owner: Ben Hutchings <[EMAIL PROTECTED]>


* Package name: memories
  Version : 1.1
  Upstream Author : Simon Cozens <[EMAIL PROTECTED]>
* URL : http://maypole.perl.org/?Applications
* License : to be established
  Description : a web-based photo sharing application

Memories allows multiple users to browse and share photos.  Each
user's photos can be seen in blog format or as albums.  Each photo can
be tagged with names, places, and other descriptive terms, and found
through these tags.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686
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]

Re: ITK: debmake

[Anthony Towns]

On Thu, Dec 29, 2005 at 07:13:05PM +0100, Santiago Vila wrote:
> Stage 2. "Please switch away from debmake".
> This is the stage that starts today. So, everybody please, switch away
> from debmake. [...]
> *) If you are the maintainer of lintian or a similar tool, you are welcome
> to add a check that gives a warning if a package uses debmake.
> *) Please don't file any bugs yet.

Personally, I'd suggest filing wishlist bugs now, saying something like
"debmake will be removed from the archive soon, please switch to debhelper
or use some other means of building your package", and tracking the bugs
you file with a usertag like [EMAIL PROTECTED] / rev-deps.

> As a realistic goal, I estimate that etch will be the last release
> containing debmake, but of course, I would be deligthed to see it
> happen sooner.

It would be pretty lame if we couldn't do this in less than a year...

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Felipe Sateler]

There is already a libgpod0 package on Christian Marillat's archive, so I 
guess there must be an issue regarding this package's relation with debian.
-- 


 Felipe Sateler


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

Re: dependencies on makedev

[Adam Heath]

On Fri, 30 Dec 2005, Roger Leigh wrote:

> > How does persistance of the permission model work?  Can I do chown/chmod on
> > the dynamic files in /dev, and have them remain the next time?  Even if a
> > device node changes it's name?  Or do I have to edit some alternative
> > database?
>
> You edit or add to the udev rules.  These are usually used to set
> policy for whole categories of devices, but you can of course fine
> tune it, or replace all the standard rules with your own.  The default
> gives you all the standard names, as with a static /dev.  (I
> personally switched it to the devfs-style rules.)

That's the wrong answer.

What ever happened to standard unix tools?  chmod/mkdir/chown/mv?

You're suggesting doing things like some other OS(like Windows, were you have
to edit a registry).


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

Re: dependencies on makedev

[Matthew Garrett]

Adam Heath <[EMAIL PROTECTED]> wrote:

> That's the wrong answer.
> 
> What ever happened to standard unix tools?  chmod/mkdir/chown/mv?
> 
> You're suggesting doing things like some other OS(like Windows, were you have
> to edit a registry).

Indeed. Editing plain text configuration files has never been the Unix
way, and vi certainly isn't a standard unix tool.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: stable aliases for CD drives

[Joey Hess]

Finn-Arne Johansen wrote:
> Would it not be enough for apt if d-i created an fstab that linked
>  /dev/hdX -> /media/cdrom ?

Hmm, that's what it does, so maybe things will be ok. I don't know
really what else might depend on there being a /dev/cdrom.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: dependencies on makedev

[Anthony DeRobertis]

Matthew Garrett wrote:

> Indeed. Editing plain text configuration files has never been the Unix
> way, and vi certainly isn't a standard unix tool.
>

I think the right question for him to ask is, "what ever happened to the
 unix way?"

chmod, chown, etc. are all simple tools that do one job and do it well.
If I want to change the group of /dev/hdc to "foo" from its current
"cdrom", it is _very_ self-evident how to do that with chgrp.

Now, since my system actually runs udev, let's figure out how to do it
with vim... First, I take a look at /etc/udev.d. I see a udev.conf as
well as a bunch of other files. Open it up, nothing there. So next I go
look at rules.d (after trying to figure out where there is a rules.d as
well as a bunch of .rules files; aparently a less-clean version of
apache2's foo-available/foo-enabled. Should probably fix this. Whishlist
bug filed.) Next, it looks like you edit 020_permissions.rules (or
rather the file it is symlinked to). Maybe you change this line:

ENV{ID_CDROM}=="?*",GROUP="cdrom"

to

ENV{ID_CDROM}=="?*", KERNEL!="hdc"  GROUP="cdrom"

but I'm not sure.

I like udev overall (after all, I'm running it), however, this is
definitely not one of its strong points. It fails to keep simple things
simple.


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

Re: dependencies on makedev

[Adam Heath]

On Fri, 30 Dec 2005, Matthew Garrett wrote:

> Adam Heath <[EMAIL PROTECTED]> wrote:
>
> > That's the wrong answer.
> >
> > What ever happened to standard unix tools?  chmod/mkdir/chown/mv?
> >
> > You're suggesting doing things like some other OS(like Windows, were you 
> > have
> > to edit a registry).
>
> Indeed. Editing plain text configuration files has never been the Unix
> way, and vi certainly isn't a standard unix tool.

No, I'm saying why are people attempting to replace what already works with
something new and obfusicated?


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

Re: Bug#345160: ITP: libgpod -- a library to read and write songs and artwork to an iPod

[Frank Lichtenheld]

On Thu, Dec 29, 2005 at 11:55:17PM -0300, Felipe Sateler wrote:
> There is already a libgpod0 package on Christian Marillat's archive, so I 
> guess there must be an issue regarding this package's relation with debian.

I can see no evidence for that, especially since most of the code
is already in Debian, in the gtkpod package...

Gruesse,
-- 
Frank Lichtenheld <[EMAIL PROTECTED]>
www: http://www.djpig.de/


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

Work-needing packages report for Dec 30, 2005

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 172 (new: 3)
Total number of packages offered up for adoption: 96 (new: 1)
Total number of packages requested help for: 20 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   poppler (#344738), orphaned 4 days ago
 Reverse Depends: libpoppler-glib-dev libpoppler-dev abiword-plugins
   libpoppler-qt-dev libkpathsea4 evince libpoppler0c2-qt tetex-bin
   libpoppler0c2-glib
 Installations reported by Popcon: 2915

   psh (#344748), orphaned 4 days ago
 Description: interactive shell with the power of perl
 Installations reported by Popcon: 47

   tinycdb (#344572), orphaned 6 days ago
 Description: a package for creating and reading constant databases
 Installations reported by Popcon: 36

169 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   tinycdb (#344572), offered 6 days ago
 Description: a package for creating and reading constant databases
 Installations reported by Popcon: 36

95 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   aboot (#315592), requested 189 days ago
 Description: Alpha bootloader: Looking for co-maintainers
 Reverse Depends: aboot-cross ltsp-server dfsbuild aboot
 Installations reported by Popcon: 54

   athcool (#278442), requested 429 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 205

   debtags (#321654), requested 145 days ago
 Description: Enables support for package tags
 Reverse Depends: debtags-edit
 Installations reported by Popcon: 411

   dselect (#282283), requested 404 days ago
 Description: a user tool to manage Debian packages

   fetchmail (#331642), requested 86 days ago
 Description: SSL enabled POP3, APOP, IMAP mail gatherer/forwarder
 Reverse Depends: fetchmail-ssl fetchmailconf webmin-fetchmail
 Installations reported by Popcon: 2507

   grub (#248397), requested 598 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: webmin-grub grubconf replicator dfsbuild
   grub-splashimages
 Installations reported by Popcon: 6798

   gtkpod (#319711), requested 158 days ago
 Description: manage songs and playlists on an Apple iPod
 Installations reported by Popcon: 227

   lib (#329966), requested 96 days ago
 Description: Perl interfaces to the Gtk and Gnome libraries

   lsdvd (#316922), requested 178 days ago
 Description: read the contents of a DVD
 Installations reported by Popcon: 707

   mwavem (#313369), requested 199 days ago (non-free)
 Description: Mwave/ACP modem support software
 Installations reported by Popcon: 3

   openssl (#332498), requested 84 days ago
 Description: Secure Socket Layer (SSL) binary and related
   cryptographic tools
 Reverse Depends: openssh-server-udeb libslp1 libaqbanking0c2a
   libecpg-compat2 heimdal-kdc nsd apache-ssl pound webmin
   aqbanking-tool avscan nessus bzflag-server wpasupplicant dsniff
   libneon24 fetchmail slapd libnet-ssleay-perl python2.4-pyopenssl
   liblasso3 ultrapossum-tls ssmtp sqlrelay-sqlite cacti-cactid d4x
   perdition-mysql sylpheed hplip sylpheed-claws-gtk2 sylpheed-gtk1
   libapache-mod-php4 php4-cgi postgresql-contrib-8.1 libpq3
   libaqbanking-ofx0 python2.2-pyopenssl libopensc2
   sylpheed-claws-gtk2-clamav libldap-2.2-7 lwresd newpki-server hula
   ardour-gtk-altivec davfs2 xine-ui heartbeat-2 libaqgeldkarte0
   php5-cli ohphone-basic libecpg-dev racoon irssi postfix
   cyrus21-common t38modem pyca ftpd-ssl fireflier-server siege
   perdition-ldap nagios-plugins-basic libpq4 libyaz
   sylpheed-claws-spamassassin pantomime-dev libzorpll-dev grip libaws2
   usermin libpam-mount python2.3-sqlrelay apache2-mpm-prefork
   mozilla-opensc kannel-extras aria libkeynote0 sslwrap simph323
   libsope-ldap4.4 postgresql-7.4 conserver-client
   libwvstreams4.2-extras xsupplicant xmms-scrobbler proftpd
   newpki-client ipppd tellico webauth-utils ca-certificates
   italc-client qca-tls dovecot-pop3d libsnmp9-dev isync nmap
   dovecot-imapd libpam-musclecard proftpd-mysql postgresql-client-8.1
   libc-client-dev libaws-dev ipopd gambas-gb-net-curl telnet-ssl
   libwww-curl-perl apac

Re: dependencies on makedev

[Anthony Towns]

On Fri, Dec 30, 2005 at 12:40:37AM -0600, Adam Heath wrote:
> > Indeed. Editing plain text configuration files has never been the Unix
> > way, and vi certainly isn't a standard unix tool.
> No, I'm saying why are people attempting to replace what already works with
> something new and obfusicated?

Because dynamic device nodes have lots of benefits. (Less clutter,
better support of dynamic devices, better device names, better API for
writing drivers) In short, hardcoded /dev nodes don't "already work".

Though I have to say, that was a pretty amusing remark coming from one
of the upstream authors of "shoop".

Cheers,
aj



signature.asc
Description: Digital signature