Re: Please test new sysvinit, sysv-rc, initscripts

[Graham Wilson]

On Sun, Dec 18, 2005 at 01:45:58AM +0100, Marco d'Itri wrote:
> On Dec 17, Thomas Hood <[EMAIL PROTECTED]> wrote:
> > After installation you should have a tmpfs mounted on /run.
> 
> I do not remember a consensus about this.

Changes in Debian are generally decided by package maintainers, not by
consensus.

-- 
gram


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

Debian menu entries(was Re: Debian and the desktop)

[Eduardo Silva]

As a lurker to debian-devel, I would like to point to
all a deficiency in the current KDE way of naming
menus, and hope that if Debian menu goes this way, it
should improve on it.

The current way KDE names programs is:
Type of Program (Application name)

So, for amarok it's:
Audio Player (amarok)

I find this actually bad, because it's almost a new
hierachy in the menu (one that Debian menu actually
has, I think). On the other hand, if the Gnome way was
used, it would be better, since it makes sense in
english:

Amarok Audio Player
Name of the app + program type.

But the position of program type should change
acording to the language used.

When using KDE in portuguese, it actually becomes
correct in syntax, although the parentesis () stops
making sense:

Leitor de Áudio (amarok)

So, my sugestion is, if this is done in Debian menu,
the position of the application type is moved before
or after the application type, according to the
language use and without the use of parethesis:

English: Amarok Audio Player
Portuguese: Leitor de Áudio Amarok

Eduardo

P.S.-Could you CC: me any replies? I'll also keep an
eye on the list archive site, for possible replies.

OH MY ... http://www.geocities.com/jobezone/index.html

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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

Re: buildd administration

[Thomas Bushnell BSG]

Anthony Towns  writes:

> Generally, experimental fits the above role. Unstable's for uploading new
> development of packages that will hopefully work, but might turn out not
> to. In particular, though, they need to be fixed pretty quickly -- six
> months in experimental, and another two so far in unstable isn't quickly.

So can you explain for me when this policy change was made and where
it was announced?  I must have missed it.  I refer specifically to the
statement that if a package in unstable does not work, in needs to be
fixed "pretty quickly".


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

Re: buildd administration

[Thomas Bushnell BSG]

Wouter Verhelst <[EMAIL PROTECTED]> writes:

> On Wed, Dec 14, 2005 at 03:51:06PM -0800, Thomas Bushnell BSG wrote:
>> Steve Langasek <[EMAIL PROTECTED]> writes:
>> > Rather, it seems much more likely that we would want to push such packages
>> > *out* of unstable.
>> 
>> Really?  So now, unstable should be maintained in a releasable state
>> *too*?
>
> Not necessarily; but as packages in testing can only arrive there after
> moving through unstable, unstable will need to be rather sane, too.

Explain why this is?  How does a package which is not yet releasable,
in unstable, cause a problem which requires pushing the package out of
unstable?



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

Re: congratulations to our ftp-master team

[Anand Kumria]

On Fri, Dec 16, 2005 at 03:56:30PM +0100, Goswin von Brederlow wrote:
> Anand Kumria <[EMAIL PROTECTED]> writes:
> 
> > I'd like to congratulate our ftp-master team on their ability to timely
> > process packages progressing through the NEW queue.
> >
> >  [1]
> >
> > I think you are an excellent example of people who are too busy for Debian.
> >
> > I must say that I am particularly impressed that you've managed to
> > frustrate our users for over 1 year with the package 'xvidcap'.
> 
> Guessing by the name alone I would say this is a patent issue like
> mplayer and therefore a problem package that is not likely to get
> resolved anytime soon.
> 
> But that is just a guess.

And it is an incorrect guess. xvidcap itself uses libraries already in
Debian. But thanks for playing "guess the mind of the ftp-masters".

Was it fun?

> For non problem cases the NEW queue was never as fast as now so
> congratulation of improving the NEW queue so much already. Giving your
> past month performance I'm sure the few remaining issues can be
> resolved in time as well. Ignoring anything 2 weeks or newer I count
> only 7 packages. This is great.

Maybe you are a fan of being left in limbo, or like the perverbial
Schrödinger's cat, but even a bad process can benefit from assurances.

A simple assurance that your package will be rejected from the NEW queue
if no ftp-master approves it within 2 weeks would actually be a benefit.

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: buildd administration

[Anthony Towns]

On Fri, Dec 16, 2005 at 11:24:39AM +0100, Frank Küster wrote:
> > No, that would be "unsuitable for release". Which is a problem that
> > should either be fixed quickly, or means you're trying to make a big
> > enough change that you should be working out how to get it done without
> > breaking other packages in a separate area, such as experimental.
> It's been in experimental for more than half a year.  

Err, that's kind of absurdly long too.

> We could have tried to install and use every depending, and build every
> build-depending package.  But that is simply not feasible with the
> manpower, time and machine power that's available to the teTeX
> maintainers. 

Six months is a lot of time; and experimental should provide you with
the space and machine power to handle the rebuilding. I don't know how
many source changes are necessary to do the rebuilding, though.

> So either we could have delayed teTeX 3.0 until
> god-knows-when, 

Uh, no. The whole point is to delay _less_, not more.

> Much worse, there are a couple of cases where we had to NMU the
> packages, either because the maintainers where inactive, or in one case
> because he said "no time here, just go ahead".  Except for this one case
> this couldn't have been done with the packages in experimental, since
> failing to cooperate with a package in experimental isn't RC, is it?

Not only do you not have to have an RC bug as an excuse to NMU; but
uploads to experimental (which these presumably would be) have even less
need for care and caution.

> Of course, in principle, we could have created our own
> "compatible_with_teTeX-3.0" repository and uploaded fixed packages
> there, and do all the testing there.  But then I don't understand what
> unstable is for...

Generally, experimental fits the above role. Unstable's for uploading new
development of packages that will hopefully work, but might turn out not
to. In particular, though, they need to be fixed pretty quickly -- six
months in experimental, and another two so far in unstable isn't quickly.

> Yes, the problem is that bugs in other packages keep popping up slowly.
> Like #341849 in debiandoc-sgml: We already had checked that
> debiandoc-sgml didn't have one of the "usual" incompatibility bugs, but
> then it turned out that there is still one, which is only triggered when
> a far-east document is typeset in a certain encoding.

"A far-east document is typeset in a certain encoding" doesn't sound like
an RC bug; and therefore not something that should hold up transitioning
to testing. Certainly, fix it ASAP once it's found, but that's the
desired result for any bug.

> > A year before sarge's release, we were at around 400 RC bugs in testing,
> > and 600 in unstable; 
> Err, that should read "3 months before everybody thought sarge would be
> released. 

Uh, no, it shouldn't. Next December is when sarge will be released,
it's not some random date plucked out of the air to try to make people
motivated when the real release is going to actually be nine months
or eighteen months after that. We're twelve months before we want to
actually release now, so it's appropriate to look at twelve months before
we actually released last time.

> That would be bad, but I can't see how I can speed up tetex's evolution
> to be releasable by letting it rot in experimental.

That's true; the idea isn't to let it rot in experimental, it's to have
a quick pass through experimental that catches the most obscene bugs,
then to put it in unstable where you catch a few more, then to let
things progress to testing naturally, if necessary by having the RMs
remove tetex related packages that aren't getting updated to the latest
version in a timely or successful fashion.

Cheers,
aj



signature.asc
Description: Digital signature

Re: congratulations to our ftp-master team

[Matthew Garrett]

Anand Kumria <[EMAIL PROTECTED]> wrote:
> On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote:

>> 5.5 hours for a package to make it through NEW. I think you owe some
>> people an apology.
> 
> -> 8126   T Oct 25 Debian Installe (  46) xmovie_1.9.13-0_i386.changes is N=
> EW
>10552   T Dec 14 Joerg Jaspert   (  23) xmovie_1.9.13-0_i386.changes REJ=
> ECTED
> 
> How many hours is that, David?

David's example is representative. Your one isn't.

Of all the people to pick on in Debian, the ftp-masters aren't the
obvious target. How about dealing with some more significant problems?
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: congratulations to our ftp-master team

[Anand Kumria]

On Wed, Dec 14, 2005 at 09:30:15AM +, David Pashley wrote:
> On Dec 14, 2005 at 00:25, Anand Kumria praised the llamas by saying:
> > I'd like to congratulate our ftp-master team on their ability to timely
> > process packages progressing through the NEW queue.
> > 
> >  [1]
> > 
> > I think you are an excellent example of people who are too busy for Debian.
> > 
> > I must say that I am particularly impressed that you've managed to
> > frustrate our users for over 1 year with the package 'xvidcap'.
> > 
> > Truly the works of Gods among both Debian users _and_ Debian developers.
> > 
> > If only more of the infrastructure teams displayed your attitude and
> > dedication to volunteering for the benefit of all Debian users and
> > developers.
> > 
> 2875   + Dec 13 18:17   Debian Installer  (   0) irssi_0.8.10-1_multi.changes 
> is NEW
> 2876   + Dec 13 23:48   Debian Installer  (   0) irssi_0.8.10-1_multi.changes 
> ACCEPTED
> 
> 5.5 hours for a package to make it through NEW. I think you owe some people 
> an apology.
> 

-> 8126   T Oct 25 Debian Installe (  46) xmovie_1.9.13-0_i386.changes is NEW
   10552   T Dec 14 Joerg Jaspert   (  23) xmovie_1.9.13-0_i386.changes REJECTED

How many hours is that, David?

Anand

-- 
 `When any government, or any church for that matter, undertakes to say to
  its subjects, "This you may not read, this you must not see, this you are
  forbidden to know," the end result is tyranny and oppression no matter how
  holy the motives' -- Robert A Heinlein, "If this goes on --"


signature.asc
Description: Digital signature

Re: /run vs /var/run

[Bernd Eckenfels]

In article <[EMAIL PROTECTED]> you wrote:
> The principle is the same: /lib is used only for the minimal system required
> for booting, and everything else should go in /usr/lib.  /run should be used
> only for junk that needs to be stored early in the boot sequence, and
> everything else should go in /var/run.

However there a big differences: /var/run is much smaller than /run, and if
it is placed in a tmpfs (which is really the best thing anyway) it doesnt
matter under which mountpoint it is located.

And then it is much cleaner to have only one.

Gruss
Bernd


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

Re: /run vs /var/run (was: Please test new sysvinit)

[Matthew Garrett]

Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote:
>> Under Linux, can't all of this be done with mount --move anyway? I'm not
>> convinced that we actually need a /run any more.
> 
> So you would have these files stored in /var/run from the beginning, and use
> mount --move to shuffle them around if /var is a separate mount point?  I'm
> pretty sure --move is a 2.6-only feature, too, and we haven't yet gotten rid
> of 2.4 for etch; and is there an equivalent solution for non-Linux ports?

Yeah, it's 2.6 only. Are we seriously expecting to ship etch with 2.4
kernels? Is anyone still doing active security support for it?

The linux-onlyness of it is a bit more awkward, but non-Linux OSs tend
to be lacking things like decent ram filesystems anyway, so the
semantics are going to vary in any case. But I guess if it's difficult,
sticking with /run might be easier. Has anyone talked to the FHS guys
about this? (I haven't actually checked whether it's in there, so the
answer may well be "yes" :) )
-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: /run vs /var/run (was: Please test new sysvinit)

[Steve Langasek]

On Sun, Dec 18, 2005 at 03:57:35AM +, Matthew Garrett wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:

> > The principle is the same: /lib is used only for the minimal system required
> > for booting, and everything else should go in /usr/lib.  /run should be used
> > only for junk that needs to be stored early in the boot sequence, and
> > everything else should go in /var/run.

> Under Linux, can't all of this be done with mount --move anyway? I'm not
> convinced that we actually need a /run any more.

So you would have these files stored in /var/run from the beginning, and use
mount --move to shuffle them around if /var is a separate mount point?  I'm
pretty sure --move is a 2.6-only feature, too, and we haven't yet gotten rid
of 2.4 for etch; and is there an equivalent solution for non-Linux ports?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: /run vs /var/run (was: Please test new sysvinit)

[Peter Samuelson]

[Steve Langasek]
> Given the reality of /lib, is there any need for a separate /usr/lib?
> 
> The principle is the same: /lib is used only for the minimal system
> required for booting, and everything else should go in /usr/lib.
> /run should be used only for junk that needs to be stored early in
> the boot sequence, and everything else should go in /var/run.

/var/run is *tiny*.  In fact on my system it's close to 4 orders of
magnitude smaller than /usr/lib.  I know why /usr isn't assumed to be
on the root filesystem, and it's not at all related to why a /run ramfs
that has to exist anyway might be inappropriate for /var/run.


signature.asc
Description: Digital signature

Re: /run vs /var/run (was: Please test new sysvinit)

[Matthew Garrett]

Steve Langasek <[EMAIL PROTECTED]> wrote:

> The principle is the same: /lib is used only for the minimal system required
> for booting, and everything else should go in /usr/lib.  /run should be used
> only for junk that needs to be stored early in the boot sequence, and
> everything else should go in /var/run.

Under Linux, can't all of this be done with mount --move anyway? I'm not
convinced that we actually need a /run any more.

-- 
Matthew Garrett | [EMAIL PROTECTED]


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

Re: /run vs /var/run (was: Please test new sysvinit)

[Steve Langasek]

On Sat, Dec 17, 2005 at 06:09:05PM -0600, Peter Samuelson wrote:

> [Thomas Hood]
> > After installation you should have a tmpfs mounted on /run.  This has
> > been created for the use of that handful of packages that need a
> > place to store run time state files independently of networking.

> Given the need, and now the reality, of /run, is there any need for a
> separate /var/run?  I vote we migrate to /var/run -> /run, at least in
> the default install.  Whether packages should continue to refer to
> /var/run is a matter of FHS touchy feely, and perhaps compatibility
> with other FHS distributions is more important than the ability to
> eliminate the /var/run symlink in the long run.

Given the reality of /lib, is there any need for a separate /usr/lib?

The principle is the same: /lib is used only for the minimal system required
for booting, and everything else should go in /usr/lib.  /run should be used
only for junk that needs to be stored early in the boot sequence, and
everything else should go in /var/run.

We should *not* be moving all of /var/run into /run; symlinking the former
to the latter should be left as a touchy feely exercise for the local admin.

(We also shouldn't need to specify a policy for mounting any particular
filesystem on /run, but merely mount /run early iff it's present in
/etc/fstab and leave the implementation details to the local admin.)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#343830: ITP: toycars -- physics based 2-D racer

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>


* Package name: toycars
  Version : 0.2.5
  Upstream Author : Ruben Zilibowitz <[EMAIL PROTECTED]>
* URL : Web Page: http://sourceforge.net/projects/toycars
* License : GPL
  Description : physics based 2-D racer

 Toy Cars is a physics based 2-D racer. The graphics and the interface use
 SDL and OpenGL.

 Toy Cars is partly inspired by Micromachines and partly by the old Atari ST
 game called Jupiter's Masterdrive.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

[EMAIL PROTECTED]: Re: Bug#343662: fsck errors halting boot after upgrade]

[Theodore Ts'o]

Fixing this the right way will require changing when Debian boot
scripts run hwclock (as the first very thing), and will require making
changes to util-linux, the installer (so that /etc/zoneinfo is not a
symlink, and so that the information about what the local timezone is
stored somewhere else other than the symlink), and libc (so that
/etc/zoneinfo can be refreshed as part of the postinstall package).

This is messy, but it's what Red Hat does, and fixes the bug reported
below.  It really is bad that the system clock is wrong for a large
part of the initial boot process (until possibly after
/etc/rcS.d/S50hwclock.sh is run, if /usr is a separately mounted
filesystem).  I can't see another way of fixing this, though; before I
start lobbying the maintainers of the above-mentioned packages, does
anyone have any suggestions about a better way to deal with this
issue?

Thanks, regards,

- Ted
--- Begin Message ---
On Fri, Dec 16, 2005 at 04:16:42PM -0800, Andrew Sackville-West wrote:
> Package: e2fsprogs
> Version: 1.39
> 
> This is specifically version 1.39 WIP (10-Dec-2005)
> 
> /dev/hda3: Superblock last mount time is in the future
> /dev/hda3: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
> 

Are you using your system with hardware time set to some non-GMT local
time zone?  (i.e. /etc/defaults/rcS has UTC="no")  

I didn't test for this case, and so I didn't realize a problem --- the
timezone offset isn't corrected at the time when fsck is run (at least
not on Debian systems) and e2fsck depends on the time being correct.
In the past, we more or less got by with the time being wrong (for
systems who use a non-GMT hardware clock); it meant that the last
checked time was set incorrectly, and inode delete times would also be
set correctly, but the failures were more or less harmless.

Unfortunately, I added this test in order to address problems caused
by the last mount time not being correct (see Debian bug #327580) only
to realize this was a much larger issue.

This isn't an issue on Red Hat systems, because /etc/localtime is not
a symlink (into possibly a not-yet mounted /usr filesystem), and they
make sure the system clock is correct *before* running fsck on the
root filesystem.  I personally keep my system clock on UTC, and so
this problem doesn't show up.

I think you can make the problem go away by making /etc/localtime
contain a copy of what it is currently symlinked to in
/usr/share/zoneinfo/, and renaming
/etc/rcS.d/S22hwclockfirst.sh to /etc/rcS.d/S09hwclockfirst.sh.  This
is obviously not the "proper" fix; since among other things if the
localtime file needs to get updated (for example if the US Congress
changes the definition of daylight savings time), we need a way to
make sure /etc/localtime gets updated when the package gets updated.  

But I believe if you were to apply the above as a workaround, it
should address your problem.  Fixing this in the more global sense
will require making changes in the overall Debian boot setup, and I'm
going to have to take this up on debain-devel and consult other Debian
developers.

Regards,

- Ted
--- End Message ---

Re: Access to svn.debian.org

[Russ Allbery]

Clint Adams <[EMAIL PROTECTED]> writes:

>> developer, and I can use it to access the pkg-perl repository on
>> svn.debian.org without any trouble.  When I became a Debian developer, I
>> got a new Alioth ID rra.  It's now also been added to the pkg-perl
>> repository.  But it doesn't work with svn.debian.org.

> Assuming nothing is wrong, you may need to wait up to 24 hours for that
> to take effect.

Hm, I *thought* it had been several weeks already, actually.  But maybe
I'm confused and I just got added and I'm misremembering thinking that was
done a while ago.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

udev event completion order (was: Re: Debian Installer team monthly meeting minutes (20051214 meeting))

[Darren Salt]

[CC'ing hotplug-devel]

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

> On Dec 17, Christian Perrier <[EMAIL PROTECTED]> wrote:
>> It is currently very likely that systems with two network interfaces will
>> end up with both switched on the installed system after the reboot. This
>> is of course a blocker.

>> The discussion showed that sticking with discover while udev is used may
>> be the main reason for this.

> No. This will happen no matter how the system was installed, because
> modules are loaded concurrently and the first one to finish its setup wins.
> This applies to the /dev/cdrom and similar links on systems with multiple
> CD readers too.

FWIW, I've seen this with both CD/DVD drives and both sound devices in one of
my machines. I have no doubt that the same applies to DVB cards etc., which
might cause problems when one's DVB-T and another's DVB-S or something.

> The solution so far appears to be writing a rules file which will
> statically assign the names.

An alternative appears to be to process events in series... or maybe delaying
naming until all modules have been loaded could help? I think that ordering
by bus address or kernel device name could help here.

Of course, adding some modules may trigger another round of events, causing
more modules to be loaded, but this shouldn't be a problem - it should be
just another batch of events to be buffered and processed after the current
batch is complete.

[snip]
-- 
| Darren Salt   | nr. Ashington, | linux (or ds) at
| sarge,| Northumberland | youmustbejoking
| RISC OS   | Toon Army  | demon co uk
|   We've got Souness, we don't want him

Buy! Amdahl Stock to go up 100 points next week.


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

Re: Access to svn.debian.org

[Clint Adams]

> developer, and I can use it to access the pkg-perl repository on
> svn.debian.org without any trouble.  When I became a Debian developer, I
> got a new Alioth ID rra.  It's now also been added to the pkg-perl
> repository.  But it doesn't work with svn.debian.org.

Assuming nothing is wrong, you may need to wait up to 24 hours for that
to take effect.


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

Re: Please test new sysvinit, sysv-rc, initscripts

[Marco d'Itri]

On Dec 17, Thomas Hood <[EMAIL PROTECTED]> wrote:

> After installation you should have a tmpfs mounted on /run.
I do not remember a consensus about this.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#343827: ITP: zeroc-ice -- ZeroC Internet Communications Engine

[Francisco Moya]

Package: wnpp
Severity: wishlist
Owner: Francisco Moya <[EMAIL PROTECTED]>


* Package name: zeroc-ice
  Version : 3.0.0
  Upstream Author : ZeroC, Inc.
* URL : http://www.zeroc.com/
* License : GPL
  Description : ZeroC Internet Communications Engine

Ice is a CORBAish middleware. It implements a few interesting
services for developers of robust distributed software. It includes
mappings for C++, Python, Java, PHP, C# and Visual Basic. It also
includes a version for embedded devices (J2ME and C++).

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (900, 'unstable'), (800, 'experimental'), (101, 'testing')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.13-marvin
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)



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

Re: xmcd

[Elimar Riesebieter]

On Sun, 18 Dec 2005 the mental interface of
Matthew Palmer told:

> On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote:
> > does one know why xmcd isn't upgraded since 31 of May in 2003? The
> > package is neither orphaned nor up for adoption, which I would do
> > then.
> 
> Have you asked the maintainer, Adrian Bridgett?  He's around (last made an
> upload less than a month ago, for tkdiff), so I don't see why he wouldn't be
> able to give you a reasonable answer to your question.
Done.

Elimar

-- 
  Experience is something you don't get until 
  just after you need it!


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

Re: Curso Interativo HP12C - Função da Máquina GRATIS

[Guilherme de S. Pastore]

English speakers: I am deeply sorry, I have already replied to this one,
but forgot to Cc: the person, who is obviously not subscribed.

Em Sáb, 2005-12-17 às 20:24 -0200, Hector R.Farias escreveu:
> Prezados senhores:Como devo proceder para obter este curso interativo
> e obter informações/manual de funcionalidades deste produto?
> Grato
> Héctor

Olá, Hector,

não sei como você chegou até esse endereço, mas a debian-devel é uma
lista de discussão que concentra o desenvolvimento do sistema
operacional universal e 100% livre Debian, e não tem nenhuma relação com
a calculadora financeira em que você tem interesse ou em cursos de
utilização dela. Para maiores informações sobre nós, visite
http://www.debian.org/

Por favor, se enviar mensagens para esta lista novamente, faça-o em
inglês, que é o idioma adequado devido ao fato de ela ser um meio de
comunicação que reúne pessoas de todo o mundo.

Atenciosamente,

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


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

/run vs /var/run (was: Please test new sysvinit)

[Peter Samuelson]

[Thomas Hood]
> After installation you should have a tmpfs mounted on /run.  This has
> been created for the use of that handful of packages that need a
> place to store run time state files independently of networking.

Given the need, and now the reality, of /run, is there any need for a
separate /var/run?  I vote we migrate to /var/run -> /run, at least in
the default install.  Whether packages should continue to refer to
/var/run is a matter of FHS touchy feely, and perhaps compatibility
with other FHS distributions is more important than the ability to
eliminate the /var/run symlink in the long run.


signature.asc
Description: Digital signature

Access to svn.debian.org

[Russ Allbery]

Okay, I'm stymied and I'm not sure where to ask.

I had an Alioth ID rra-guest from before I was approved as a Debian
developer, and I can use it to access the pkg-perl repository on
svn.debian.org without any trouble.  When I became a Debian developer, I
got a new Alioth ID rra.  It's now also been added to the pkg-perl
repository.  But it doesn't work with svn.debian.org.

Using the Alioth password for that account just results in rejected
authentication.  I've set a public key in Alioth for the account but that
doesn't seem to change anything.  (Whereas with rra-guest, setting a
public key in Alioth worked great and now I can use public key
authentication to svn.debian.org.)

What am I doing wrong?  Is there someone in particular I should contact
for help?  I'd like to switch my project memberships and other Alioth data
over to rra from rra-guest, but this is making that impossible.

Thanks in advance!

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Curso Interativo HP12C - Função da Máquina GRATIS

[Hector R.Farias]

Prezados senhores:Como devo proceder para obter 
este curso interativo e obter informações/manual de funcionalidades deste 
produto?
Grato
Héctor

Please test new sysvinit, sysv-rc, initscripts

[Thomas Hood]

A new version of sysvinit (binary packages sysvinit, sysv-rc and initscripts) 
has
just been uploaded to experimental.  The reason for sending it to experimental 
is
that a large number of changes were made, thus increasing the probability of 
errors.
And errors in sysvinit can be especially troublesome to users.  We would like 
the
release to get some testing by people who know what to do if things go wrong.  
If
you can, please give us a hand and install version 2.86.ds1-7.

After installation you should have a tmpfs mounted on /run.  This has been 
created
for the use of that handful of packages that need a place to store run time 
state
files independently of networking.  Recently mentioned as needing such a 
location
was the bootchart package.  Ifupdown and resolvconf can use it too, instead of
/dev/shm/.

After rebooting you should have logs of the fsck runs in 
/var/log/fsck/check{root,fs}.
You should have a rotated /var/log/dmesg, and /var/log/boot if you are using 
bootlogd.

Please check /etc/motd.  Is this now a symlink to /var/run/motd and are its 
contents
correct?

Try switching to runlevel 1.  Does this work as expected?

Now shut down.  Any problems?

Boot with INIT_VERBOSE=yes kernel parameter.  Is the boot more verbose?

Any glitches in any of the messages?
-- 
Thomas Hood


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

Re: xmcd

[Matthew Palmer]

On Sat, Dec 17, 2005 at 08:37:28PM +0100, Elimar Riesebieter wrote:
> does one know why xmcd isn't upgraded since 31 of May in 2003? The
> package is neither orphaned nor up for adoption, which I would do
> then.

Have you asked the maintainer, Adrian Bridgett?  He's around (last made an
upload less than a month ago, for tkdiff), so I don't see why he wouldn't be
able to give you a reasonable answer to your question.

If he's non-responsive, then that's a whole other kettle of fish, but we
should cross that bridge when (and if) we come to it.

- Matt


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

Your Confirmation Required

[eng]

This message is to verify that you wish to have your
email address: debian-devel@lists.debian.org added to the
Alharamain Sermon(english)
Subscribe Me mailing list.

You MUST click on the link below to have your address added
to our list.  This is to ensure that someone doesn't add your
address to our list without your knowledge or consent.

Thank you,

http://www.alharamainsermons.org/cgi-bin/subscribe/s.pl?a=1&l=1&[EMAIL 
PROTECTED]&p=894281

America Online users, please click: http://www.alharamainsermons.org/cgi-bin/subscribe/s.pl?a=1&l=1&[EMAIL 
PROTECTED]&p=894281">Here

Alharamain Sermon(english)


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

Re: Checking package builds on hppa/arm/m68k?

[Benjamin Mesing]

> "Please (re)check, if the package can be built by g++ > 3.4
>  on [hppa/arm/m68k]"?
> 
> Do I simply remove the explicit build dependency on g++,
> upload the package and wait if it succeeds (and probably
> create another package version with the build dependencies
> re-added again if it still fails)?


As Matthias Klose in his announce [1], this workaround is no longer
needed (if you are speaking about the issue affecting a lot of QT/KDE
programs).

Best regards Ben

[1] http://lists.debian.org/debian-devel-announce/2005/11/msg00010.html

-- 
Please do not send any email to [EMAIL PROTECTED] -- all email not
originating from the mailing list will be deleted. Use the reply to
address instead.


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

Re: Re: I need Wild FX Pro Demo serial key

[Murielle]

Can you help me as well please with the serial number to 
WildFX Pro

xmcd

[Elimar Riesebieter]

Hi,

does one know why xmcd isn't upgraded since 31 of May in 2003? The
package is neither orphaned nor up for adoption, which I would do
then.

Elimar


-- 
  We all know Linux is great... it does infinite loops in 5 seconds.
-- Linus Torvalds


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

Re: buildd administration

[Russ Allbery]

Goswin von Brederlow <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> Funny, I just did a Google search for

>> site:www.debian.org cvs repository www.debian.org

>> and there it was, plain as day.

> That implies that you already know/suspect it is in cvs.

Goswin, with all due respect, you really either have no idea what you're
talking about here or you're rather bad at using Google.  A search on:

site:www.debian.org repository www.debian.org

despite being for very generic terms turns up a page explaining the CVS
repository for www.debian.org in the third page of results.

Yes, you have to pick some good search terms, since finding the pages that
are about developing the Debian web pages rather than finding pages that
are about developing for Debian is tricky.  But that's just part of using
a search engine.

>> See, what you keep missing is that, regardless of the willingness of
>> the current buildd maintainers to work with you, you are using the
>> openness or not of your work as a bargaining point.  I have serious
>> philosophical problems with that.

> Where did I ever say "We must use this because it is free?"

You didn't.  If you were saying that, I'd actually have more respect for
your position.

You are instead saying "our stuff is proprietary and we'll only release
the source if the buildd.debian.org maintainers agree to play ball."
That's deeply messed up, and as far as I'm concerned that stops the
conversation cold.  I don't care how messed up the current stuff is -- I'm
very nervous about software written by someone with that attitude coming
anywhere near Debian core infrastructure.

> Both buildd.d.o and buildd.net are in exactly the same state regarding
> openness: You have to ask the maintainer for the scripts personaly.

And that's not sufficient for any replacement.  I don't think it's great
for the existing scripts either, but they have a few huge advantages:
they're already in place and they're already working.  If we're looking at
giving up those advantages and replacing them with something else, then
the *least* that the new stuff should do is be free software.

> My argument is that is has better functionality not better idiology.

If you want more people to support your argument, produce better ideology
too.  Otherwise, you can keep whining about this on debian-devel until the
end of time and as far as I'm concerned the right thing for everyone
involved in Debian to do is ignore you.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Packaging swftools for Debian

[Simo Kauppi]

On Sat, Dec 17, 2005 at 03:21:41PM +0100, Lionel Elie Mamane wrote:
> On Sat, Dec 17, 2005 at 10:36:38AM +0200, Simo Kauppi wrote:
> > On Sat, Dec 17, 2005 at 08:56:29AM +0100, Lionel Elie Mamane wrote:
> >> On Sat, Dec 17, 2005 at 09:24:25AM +0200, Simo Kauppi wrote:
> 
> > Did you notice there something else than the L.A.M.E issue. Lame can
> > be disabled at build time, so I guess that wouldn't prevent
> > packaging it (and maybe naming the Debian package
> > 'swftools-nolame').
> 
> No, you have to _remove_ the offending code. Not only "disable it at
> build-time", but not ship it at all, also not in the
> source. Distributing infringing source code, not only infringing
> binaries, is an infringement to the patent. (The right mailing list
> for discussing this particular point is debian-legal@lists.debian.org)

Sorry for being a little vague. What I meant was that it uses liblame
library by default and that dependency can be disabled at build time.

My understanding is that there is no offending code in the swftools
itself (at least I haven't noticed any, but I have to double check :)

So, by disabling lame, it compiles and runs without users needing to
install any non-free software (the liblame library). The only drawback
is, that two of its binaries, avi2swf and wav2swf, cannot be used. Since
it has many other useful tools, I would like to see a Debian package
from it anyway.

> >> You may want to do it yourself; see
> >> http://www.debian.org/devel/join/
> 
> > I will :) If not for anything else, I'll package it just for my own
> > use.
> 
> Please consider contributing it to the "common pot"; you get a fairly
> complete system from the common pot, if you are able to incrementally
> make the system better and "give back", it will be
> appreciated. (That's a very personal position of mine and no official
> line of Debian.)

I definitely want to give something back to the community :) after many
years of "just" using Debian. I have already read a lot of documentation
about becoming a new maintainer and my plan is to make the
swftools-nolame package so, that I disable lame and modify the
configuration so that wav2swf and avi2swf are not built.

BTW: This is probably a stupid question (and probably belongs to the
debian-legal), but how does one remove the offending code from the
original source? I mean, I understood from the Debian Policy, that files
must not deleted.  So, does one just delete the code and leave an empty
file? But in that case, doesn't the code still show up in the diff file?

> -- 
> Lionel

Simo
-- 
:r ~/.signature


signature.asc
Description: Digital signature

Bug#343734: ITP: libpar-perl -- Perl Archive Toolkit

[Krzysztof Krzyzaniak (eloy)]

Package: wnpp
Severity: wishlist
Owner: "Krzysztof Krzyzaniak (eloy)" <[EMAIL PROTECTED]>

* Package name: libpar-perl
  Version : 0.90
  Upstream Author : Autrijus Tang <[EMAIL PROTECTED]>
* URL : http://search.cpan.org/dist/PAR/
* License : Perl: GPL/Artistic
  Description : Perl Archive Toolkit

 This module lets you easily bundle a typical blib/ tree into a zip file, 
 called a Perl Archive, or PAR.
 .
 It supports loading XS modules by overriding DynaLoader bootstrapping 
 methods; it writes shared object file to a temporary file at the time it is
 needed.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-1-686
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)


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

Bug#343729: ITP: libjingle -- components to interoperate with Google Talk's P2P and voice calling capabilities

[Miriam Ruiz]

Package: wnpp
Severity: wishlist
Owner: Miriam Ruiz <[EMAIL PROTECTED]>

[B
* Package name: libjingle
  Version : 0.1.0
  Upstream Author : Google Inc.
* URL : http://sourceforge.net/projects/libjingle/
* License : BSD
  Description : components to interoperate with Google Talk's P2P and voice 
calling capabilities

Libjingle is a set of components provided by Google to interoperate with
Google Talk's peer-to-peer and voice calling capabilities. The package
includes source code for Google's implementation of Jingle and Jingle-Audio,
two proposed extensions to the XMPP standard that are currently available in
experimental draft form.

In addition to enabling interoperability with Google Talk, there are several
general purpose components in the library such as the P2P stack which can be
used to build a variety of communication and collaboration applications.

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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

Re: urgency='low' testing propogation only 5 days for gtk+2.0?

[Adeodato Simó]

* Kurt Roeckx [Sat, 17 Dec 2005 02:03:50 +0100]:

> On Fri, Dec 16, 2005 at 06:10:11PM -0500, Justin Pryzby wrote:
> > It is my understanding that an urgency='low' upload defines a 10 day
> > delay in testing propogation, unless overridden by hints.

> > However, yesterday's gtk+2.0 upload indications only a 5 day delay.
> > Why?

> > http://packages.qa.debian.org/g/gtk+2.0.html

> 2.6.10-2 was uploaded with urgency medium and didn't reach
> testing yet, it only has 2.6.10-1.  It keeps the highest urgency
> since the last version that reached testing.

  This is documented in dev-ref 5.13.2, "urgencies are sticky".

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
From the moment I picked your book up until I put it down I was
convulsed with laughter. Some day I intend reading it.
-- Groucho Marx

Bug#343719: ITP: libimdb-film-perl -- Perl extension for retrieving movie info from IMDB.com

[Bas Zoetekouw]

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

* Package name: libimdb-film-perl
  Version : 0.17
  Upstream Author : Mikhail Stepanov (stepanov.michael (at) gmail.com)
* URL : 
http://search.cpan.org/~stepanov/IMDB-Film-0.17/lib/IMDB/Film.pm
* License : dual GPL/Artistic
  Description : Perl extension for retrieving movie info from IMDB.com

 This package includes the IMDB::Films and IMDB::Persons perl modules.
 .
 IMDB::Film allows retrieval of information about movies by its IMDB code or
 title.
 .
 IMDB::Persons allows retrieval of  information about IMDB persons (actors,
 actresses, directors etc): full name, photo, date and place of birth, mini
 bio and filmography.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.3
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]

ALSA packager needed

[Thomas Hood]

First, thanks to those who responded to my earlier call.

In addition to people knowledgeable about the ALSA userspace library
I would like to find someone willing to help maintain the driver side.

ALSA drivers are included in Linux 2.6, but we still ship an alsa-source
package for use with Linux 2.4 and for those who want the very latest
drivers on 2.6.  When upstream makes a new release we make a new release
of alsa-source, which along with linux-sound-base and alsa-base is
generated from the alsa-driver source package.  Updating the Debian
packaging at such times is fairly easy, but it does involve some work.

There is a new upstream release candidate out now (1.0.11rc1) and I would
like to take the opportunity to go through the process with the new
volunteer.
-- 
Thomas Hood


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

Re: congratulations to our ftp-master team

[Moritz Muehlenhoff]

Jeroen van Wolffelaar wrote:
> I explicitely said that stripping it
> anyway will make the whole pondering on whether it can be in the
> (source) package at all moot for the question whether mpeg encoding
> would be legal to ship on ftp.debian.org. To the best of my knowledge,
> mpeg encoding stuff is nowhere near the core funcionality of mplayer
> anyway, isn't it?

The encoding functionality is built into a separate binary; mencoder.

Cheers,
Moritz


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

Re: Packaging swftools for Debian

[Lionel Elie Mamane]

On Sat, Dec 17, 2005 at 10:36:38AM +0200, Simo Kauppi wrote:
> On Sat, Dec 17, 2005 at 08:56:29AM +0100, Lionel Elie Mamane wrote:
>> On Sat, Dec 17, 2005 at 09:24:25AM +0200, Simo Kauppi wrote:

>>> Are there any obvious reasons why swftools can't/shouldn't be
>>> packaged for Debian?

>> Nobody has done it, that's the main reason. The RFP/ITP log says it
>> contains patent-encumbered code; one would have to remove it before
>> uploading to Debian.

> Did you notice there something else than the L.A.M.E issue. Lame can
> be disabled at build time, so I guess that wouldn't prevent
> packaging it (and maybe naming the Debian package
> 'swftools-nolame').

No, you have to _remove_ the offending code. Not only "disable it at
build-time", but not ship it at all, also not in the
source. Distributing infringing source code, not only infringing
binaries, is an infringement to the patent. (The right mailing list
for discussing this particular point is debian-legal@lists.debian.org)

>> You may want to do it yourself; see
>> http://www.debian.org/devel/join/

> I will :) If not for anything else, I'll package it just for my own
> use.

Please consider contributing it to the "common pot"; you get a fairly
complete system from the common pot, if you are able to incrementally
make the system better and "give back", it will be
appreciated. (That's a very personal position of mine and no official
line of Debian.)

-- 
Lionel


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

Re: display-dhammapada

[Wouter Verhelst]

On Thu, Dec 15, 2005 at 04:44:28PM +0100, Jakub Nadolny wrote:
> Hi,
> 
> I am new to the list and would like to ask you what can I do in
> following subject.
> There is a package called 'display-dhammapada'. It has not been updated
> since few years. But there is new version of this software since few
> years also. I have send long time ago request to the package owner if he
> could make new version. There was no answer, so I guess he is busy with
> some other work. 
> I have though that maybe I could help maintaining this package? I have
> never done it before, but I am debian user since years and I am software
> engineer working in IT company, so I think I could manage it.
> What do you think I should do?

* File a wishlist bug against the package to update to the new version,
  if someone else didn't already do so
* Read section 7.4 of the Developers' reference, which talks about how
  to handle inactive and/or unreachable maintainers, and do what's being
  suggested there
* Prepare an updated package and offer it to the maintainer (if you get
  some reaction from him) or to other Debian Developers (if not) with a
  request to sponsor an upload.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: buildd administration

[Wouter Verhelst]

On Wed, Dec 14, 2005 at 03:51:06PM -0800, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > Rather, it seems much more likely that we would want to push such packages
> > *out* of unstable.
> 
> Really?  So now, unstable should be maintained in a releasable state
> *too*?

Not necessarily; but as packages in testing can only arrive there after
moving through unstable, unstable will need to be rather sane, too.

-- 
.../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/
../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/
-.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ /
../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../
---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/


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

Re: Checking package builds on hppa/arm/m68k?

[Andreas Metzler]

Andreas Fester <[EMAIL PROTECTED]> wrote:
[...]
> what is the proper way to

> "Please (re)check, if the package can be built by g++ > 3.4
> on [hppa/arm/m68k]"?

> Do I simply remove the explicit build dependency on g++,
> upload the package and wait if it succeeds (and probably
> create another package version with the build dependencies
> re-added again if it still fails)?
> Or are there any sandboxes (I am no Debian Developer) to
> try it on specific architectures before uploading?
[...]

I'd ask on the respective porter mailinglists.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.(c) Jasper Ffforde


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

Re: Packaging swftools for Debian

[Simo Kauppi]

On Sat, Dec 17, 2005 at 08:56:29AM +0100, Lionel Elie Mamane wrote:
> On Sat, Dec 17, 2005 at 09:24:25AM +0200, Simo Kauppi wrote:
> 
> > I was wondering, if anybody has been working on getting swftools
> > (http://www.swftools.org/) into Debian?
> 
> Apparently, not recently.
> 
> > There seems to be an old RFP
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=187275 which has
> > been closed because of inactivity. Does anybody know what is the
> > status with that?
> 
> It has been reopened by Vedran Fura?? on 18 Sep 2005.

Ah, so it is, I missed that :)

> > Are there any obvious reasons why swftools can't/shouldn't be
> > packaged for Debian?
> 
> Nobody has done it, that's the main reason. The RFP/ITP log says it
> contains patent-encumbered code; one would have to remove it before
> uploading to Debian.

Did you notice there something else than the L.A.M.E issue. Lame can be
disabled at build time, so I guess that wouldn't prevent packaging it
(and maybe naming the Debian package 'swftools-nolame').

> You may want to do it yourself; see http://www.debian.org/devel/join/

I will :) If not for anything else, I'll package it just for my own use.
 
> If you just want to stay up-to-date on what happens with it, you can
> subscribe to the RFP "bug"; send mail to
> "[EMAIL PROTECTED]" .
> 
> -- 
> Lionel

Thanks,
Simo
-- 
:r ~/.signature


signature.asc
Description: Digital signature

Re: Debian Installer team monthly meeting minutes (20051214 meeting)

[Marco d'Itri]

On Dec 17, Christian Perrier <[EMAIL PROTECTED]> wrote:

> It is currently very likely that systems with two network interfaces
> will end up with both switched on the installed system after the
> reboot. This is of course a blocker.
> 
> The discussion showed that sticking with discover while udev is used may be
> the main reason for this.
No. This will happen no matter how the system was installed, because 
modules are loaded concurrently and the first one to finish its setup
wins. This applies to the /dev/cdrom and similar links on systems with
multiple CD readers too.
The solution so far appears to be writing a rules file which will
statically assign the names.

> A lot of more detailed issues about this topic can be seen in the meeting log.
I will try to read it later.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Checking package builds on hppa/arm/m68k?

[Andreas Fester]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

what is the proper way to

"Please (re)check, if the package can be built by g++ > 3.4
 on [hppa/arm/m68k]"?

Do I simply remove the explicit build dependency on g++,
upload the package and wait if it succeeds (and probably
create another package version with the build dependencies
re-added again if it still fails)?
Or are there any sandboxes (I am no Debian Developer) to
try it on specific architectures before uploading?

Thanks & Best Regards,

Andreas

- --
Andreas Fester
mailto:[EMAIL PROTECTED]
WWW: http://www.littletux.net
ICQ: 326674288
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDo8VzZ3bQVzeW+rsRApGoAJ0dyjxkOUxeUmCl7sY76v4D24ugKwCg2ANZ
UogPtvGck0JsTdU3j0QdO6k=
=Hesk
-END PGP SIGNATURE-


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