Re: [Pkg-xen-devel] Xen status in lenny?

[Ian Campbell]

On Thu, 2008-07-10 at 21:53 +0200, Lucas Nussbaum wrote:
> Hi,
> 
> AFAIK, the status of Xen in lenny is currently the following:
> - no dom0 kernel
> - domU kernel only for i386 (no domU kernel for amd64)
> 
> I was told (I don't remember where) that this is because the vanilla
> kernel only supports domU for i386, and has no dom0 support, so distros
> have to port the patches to their kernels (please correct me if I'm
> wrong).

That is correct.

The upstream -tip tree currently has some 64 bit domU patches queued
(probably for 2.6.27). They are rather new and far reaching since they
make some some nice infrastructure cleanups along the way etc. There's a
rather slim chance they might make it in for Lenny but given their young
age I'm not quite happy to say we could support a kernel with them for
the lifetime of Lenny.

dom0 support is being worked on by Fedora people (I think) but there are
no patches upstream yet.

> However:
> - etch shipped with dom0 and domU kernels on i386 and amd64
> - all major distros shipped with "full" Xen support

FWIW fc9 didn't ship with dom0 support -- that is targeted for fc10.
For now I think they recommend you stick with fc8 for dom0.

I think we will be in a similar situation -- recommending sticking with
Etch for dom0 (or at least the Etch kernel, which I run on sid for my
Xen uses just fine) is probably the best we can do at the moment.

> What are the plans for Xen for lenny? Is this situation likely to change
> before the release?

Without a massive injection of manpower (Debian side or upstream) I
don't see much changing. I've heard that maybe a Lenny + 1/2 kernel
might be able to add the features (64bit + dom0) which are missed this
time around if they are available upstream, but that isn't my call to
make.

Ian.
-- 
Ian Campbell

People usually get what's coming to them ... unless it's been mailed.


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

Bug#490281: ITP: darcs-server -- Tool (client and server) to authenticate darcs push/pulls.

[Nathaniel Wesley Filardo]

Package: wnpp
Severity: wishlist
Owner: Nathaniel Wesley Filardo <[EMAIL PROTECTED]>

* Package name: darcs-server
  Version : 0.0.20070209
  Upstream Author : Daan Leijen
* URL : http://www.equational.org/darcs-server/
* License : BSD
  Programming Lang: Perl, Haskell
  Description : Tool (client and server) to authenticate darcs push/pulls.

 Darcs server extends the Darcs revision control system to push and pull
 changes to and from remote repositories. The Darcs server has minimal
 dependencies on the host system and can work on any account that can run CGI
 scripts, or has SSH access. Furthermore, it can restrict the users that can
 push or pull from the repository, and even encrypt all communication with the
 server. (Description taken from homepage,
 http://www.equational.org/darcs-server/)



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

Re: [Pkg-xen-devel] Xen status in lenny?

[Bastian Blank]

On Thu, Jul 10, 2008 at 09:53:25PM +0200, Lucas Nussbaum wrote:
> AFAIK, the status of Xen in lenny is currently the following:
> - no dom0 kernel

Yep. There are some preliminary patches but they break non-paravirt
usage for now.

> - domU kernel only for i386 (no domU kernel for amd64)

x86_64 is currently worked on, but the stuff in fedora 9 is rather
unclean.

> However:
> - etch shipped with dom0 and domU kernels on i386 and amd64

Well, it ships a slightly broken variant.

> - all major distros shipped with "full" Xen support

RHEL5/FC8 are 2.6.18 based and ships full support. SLES10 is 2.6.16 based
and ships full support. FC9 is 2.6.24 based and ships only domU support.
Anything else can be considered more or less broken.

> What are the plans for Xen for lenny? Is this situation likely to change
> before the release?

It will ship the hypervisor and a domU kernel. For dom0 it will need
either the etch or my own[1] kernel. This may be changed later if we can
get a new kernel in the stable release.

Bastian

[1]:
deb http://kernel-archive.buildserver.net/debian-kernel/waldi/xen-extra all main

-- 
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3


signature.asc
Description: Digital signature

Re: [Pkg-xen-devel] Xen status in lenny?

[Paul van der Vlis]

Ian Campbell schreef:
> On Thu, 2008-07-10 at 21:53 +0200, Lucas Nussbaum wrote:
>> Hi,
>>
>> AFAIK, the status of Xen in lenny is currently the following:
>> - no dom0 kernel
>> - domU kernel only for i386 (no domU kernel for amd64)
>>
>> I was told (I don't remember where) that this is because the vanilla
>> kernel only supports domU for i386, and has no dom0 support, so distros
>> have to port the patches to their kernels (please correct me if I'm
>> wrong).
> 
> That is correct.
> 
> The upstream -tip tree currently has some 64 bit domU patches queued
> (probably for 2.6.27). They are rather new and far reaching since they
> make some some nice infrastructure cleanups along the way etc. There's a
> rather slim chance they might make it in for Lenny but given their young
> age I'm not quite happy to say we could support a kernel with them for
> the lifetime of Lenny.
> 
> dom0 support is being worked on by Fedora people (I think) but there are
> no patches upstream yet.
> 
>> However:
>> - etch shipped with dom0 and domU kernels on i386 and amd64
>> - all major distros shipped with "full" Xen support
> 
> FWIW fc9 didn't ship with dom0 support -- that is targeted for fc10.
> For now I think they recommend you stick with fc8 for dom0.
> 
> I think we will be in a similar situation -- recommending sticking with
> Etch for dom0 (or at least the Etch kernel, which I run on sid for my
> Xen uses just fine) is probably the best we can do at the moment.
>
>> What are the plans for Xen for lenny? Is this situation likely to change
>> before the release?
> 
> Without a massive injection of manpower (Debian side or upstream) I
> don't see much changing. I've heard that maybe a Lenny + 1/2 kernel
> might be able to add the features (64bit + dom0) which are missed this
> time around if they are available upstream, but that isn't my call to
> make.

Some Fedora-links about Xen:
http://fedoraproject.org/wiki/Features/XenPvopsDom0
http://fedoraproject.org/wiki/Features/XenPvops
http://www.redhat.com/archives/fedora-xen/2008-March/msg00013.html
http://www.redhat.com/archives/fedora-xen/2008-March/thread.html
http://git.et.redhat.com/?p=xen-pvops-64.git
http://git.et.redhat.com/?p=linux-2.6-fedora-pvops.git;a=summary
http://cvs.fedora.redhat.com/viewcvs/rpms/kernel-xen-2.6/devel/
http://fedoraproject.org/wiki/Releases/10/Schedule

Eventually we could support the Etch-kernel in Lenny until there is
another solution?

Maybe we could make some publicity about this situation in Debian
Project News. Maybe there is someone who can help.
http://wiki.debian.org/ProjectNews/Issues/Current

With regards,
Paul van der Vlis.




-- 
http://www.vandervlis.nl/


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

x11proto-core 7.0.13 will break Tk

[Sergei Golovan]

Hi!

I'd like to ask if there are plans to update x11proto-core to version
7.0.13 before lenny release?

Upstream maintainers have added a new event GenericEvent which breaks
Tk toolkit because Tk uses hardcoded event numbers and adds its own
events (see [1]). Gentoo system is already affected (see [2]).

As far as I can see there's no fix which would retain binary compatibility yet.

Certainly affected packages are tk8.3, tk8.4, tk8.5, blt, tile. Also
perl-tk and ruby are likely to break after possible upgrade of
x11proto-core. (May be other packages which use Tk.)

So, if the upgrade of x11proto-core is planned then we have to find an
acceptable fix for Tk now. Otherwise we have some time to wait for a
solution from upstream.

[1] 
http://sourceforge.net/tracker/index.php?func=detail&aid=2010422&group_id=12997&atid=112997
[2] http://bugs.gentoo.org/show_bug.cgi?id=225999
Cheers!
-- 
Sergei Golovan


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

Re: x11proto-core 7.0.13 will break Tk

[Julien Cristau]

On Fri, Jul 11, 2008 at 14:07:02 +0400, Sergei Golovan wrote:

> Hi!
> 
> I'd like to ask if there are plans to update x11proto-core to version
> 7.0.13 before lenny release?
> 
No, x11proto-core in lenny will be 7.0.12.

Cheers,
Julien


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Lucas Nussbaum]

Hi,

On 11/07/08 at 11:24 +0200, Bastian Blank wrote:
> > - all major distros shipped with "full" Xen support
> 
> RHEL5/FC8 are 2.6.18 based and ships full support. SLES10 is 2.6.16 based
> and ships full support. FC9 is 2.6.24 based and ships only domU support.
> Anything else can be considered more or less broken.

It seems that Ubuntu 8.04 shipped with a 2.6.24 domU. So Ubuntu is
the only distro shipping a dom0 based on Linux >> 2.6.18? How did they
achieve this? :-)

> > What are the plans for Xen for lenny? Is this situation likely to change
> > before the release?
> 
> It will ship the hypervisor and a domU kernel. For dom0 it will need
> either the etch or my own[1] kernel. This may be changed later if we can
> get a new kernel in the stable release.

The problem I see with that is that people will be left without a
supported dom0 kernel at some point during the etch lifetime. Do we have
a plan to address that? Shouldn't we make it clear that we will support
the etch kernel until a lenny+1/2 kernel is available, for example?

Also, can you use the Xen 3.2 features with the etch kernel, or are you
somehow limited?

Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
for dom0, so it's clear that it is supported?

Thank you,
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: x11proto-core 7.0.13 will break Tk

[Sergei Golovan]

On 7/11/08, Julien Cristau <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 11, 2008 at 14:07:02 +0400, Sergei Golovan wrote:
>  > I'd like to ask if there are plans to update x11proto-core to version
>  > 7.0.13 before lenny release?
>
> No, x11proto-core in lenny will be 7.0.12.

OK. Then there's no hurry in fixing Tk. Thanks!

-- 
Sergei Golovan


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

Re: [Pkg-xen-devel] Xen status in lenny?

[Bastian Blank]

On Fri, Jul 11, 2008 at 12:18:51PM +0200, Lucas Nussbaum wrote:
> On 11/07/08 at 11:24 +0200, Bastian Blank wrote:
> > Anything else can be considered more or less broken.
> It seems that Ubuntu 8.04 shipped with a 2.6.24 domU. So Ubuntu is
> the only distro shipping a dom0 based on Linux >> 2.6.18? How did they
> achieve this? :-)

FC8 ships a forward ported 2.6.22, Ubuntu 8.04 a forward ported 2.6.24.
They pushed work into it and got something which works more or less
good. The Ubuntu patch never worked for me.

> > It will ship the hypervisor and a domU kernel. For dom0 it will need
> > either the etch or my own[1] kernel. This may be changed later if we can
> > get a new kernel in the stable release.
> The problem I see with that is that people will be left without a
> supported dom0 kernel at some point during the etch lifetime.

Which is at least lenny + 1 year, which gives us some time.

>   Do we have
> a plan to address that? Shouldn't we make it clear that we will support
> the etch kernel until a lenny+1/2 kernel is available, for example?

-security is needed for this.

> Also, can you use the Xen 3.2 features with the etch kernel, or are you
> somehow limited?

It does not support power management, but otherwise it works.

> Wouldn't it be a good idea to ship a linux 2.6.18 kernel in lenny, only
> for dom0, so it's clear that it is supported?

This needs redefining of the rule that we don't longer want multiple
kernels in a stable release. But should be possible if -release and
-security don't veto it.

Bastian

-- 
Where there's no emotion, there's no motive for violence.
-- Spock, "Dagger of the Mind", stardate 2715.1


signature.asc
Description: Digital signature

Re: [Pkg-xen-devel] Xen status in lenny?

[Lucas Nussbaum]

On 11/07/08 at 12:18 +0200, Lucas Nussbaum wrote:
> Hi,
> 
> On 11/07/08 at 11:24 +0200, Bastian Blank wrote:
> > > - all major distros shipped with "full" Xen support
> > 
> > RHEL5/FC8 are 2.6.18 based and ships full support. SLES10 is 2.6.16 based
> > and ships full support. FC9 is 2.6.24 based and ships only domU support.
> > Anything else can be considered more or less broken.
> 
> It seems that Ubuntu 8.04 shipped with a 2.6.24 domU. So Ubuntu is
   dom0 (well, they
  shipped with a 2.6.24 domU, but my question is about the dom0)
> the only distro shipping a dom0 based on Linux >> 2.6.18? How did they
> achieve this? :-)
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature

Re: Help: Strange 64bit issue

[Manuel Prinz]

Hi Andreas!

Am Dienstag, den 08.07.2008, 14:26 +0200 schrieb Andreas Tille:
> On Mon, 7 Jul 2008, William Pitcock wrote:
> 
> > If you do build-depends on gcc-multilib and g++-multilib, it should fix
> > this problem.
> 
> As I said it fixes the build problem - but now I have a package with a
> not working executable.  I guess it is also a simple 64 bit problem which
> might be easily solved by people with multiarch experience:

With these fixes it still did not build on my system. I needed to change
the Build-Depends on lib64z1-dev into zlib1g-dev to get it to build in a
clean pbuilder chroot.

> > On Mon, 2008-07-07 at 22:56 +0200, Andreas Tille wrote:
> >>
> >>  svn://svn.debian.org/svn/debian-med/trunk/packages/maq/trunk/
> 
> If I build this stuff I get a package containing /usr/bin/maq (besides
> some Perl scripts).  The problem is:
> 
> 
> $ /usr/bin/maq
> -bash: /usr/bin/maq: cannot execute binary file
> $ ldd /usr/bin/maq
> ldd: exited with unknown exit code (126)

I cannot reproduce this on my amd64 machine. With the change mentioned
above it builds fine and I'm able to run /usr/bin/maq on both lenny and
sid. Some output:

$ /usr/bin/maq 2>&1 | head -n 4 

Program: maq (Mapping and Assembly with Qualities)
Version: 0.6.7
Contact: Heng Li <[EMAIL PROTECTED]>

$ file /usr/bin/maq 
/usr/bin/maq: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for
GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped

$ ldd /usr/bin/maq 
linux-vdso.so.1 =>  (0x7fff2d7fe000)
libz.so.1 => /usr/lib/libz.so.1 (0x2abe7d4cd000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x2abe7d6e4000)
libm.so.6 => /lib/libm.so.6 (0x2abe7d9f)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2abe7dc7)
libc.so.6 => /lib/libc.so.6 (0x2abe7de87000)
/lib64/ld-linux-x86-64.so.2 (0x2abe7d2b1000)

Best regards
Manuel



signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Package management unsafe?

[Ron Johnson]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html

What are people's thoughts on this?

- --
Ron Johnson, Jr.
Jefferson LA  USA

"Kittens give Morbo gas.  In lighter news, the city of New New
York is doomed."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkh3U88ACgkQS9HxQb37Xmf+2wCgvdLRdxkvuooBUTfp3hDdmpuQ
VQsAoKROsnp8K0/OUiXlQBYD51JK3cLN
=lhx1
-END PGP SIGNATURE-


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

Re: Help: Strange 64bit issue

[Andreas Tille]

On Fri, 11 Jul 2008, Manuel Prinz wrote:


With these fixes it still did not build on my system. I needed to change
the Build-Depends on lib64z1-dev into zlib1g-dev to get it to build in a
clean pbuilder chroot.


Well, I guess that lib64z1-dev will not exist for amd64 and that this
whole mess is just caused by the multiarch stuff.  It's the first time
that I have to deal with this and I have the impression that I try to
add just problems with no real profit for the user of the program.
Probably I should just exclude the -m64 switch when building for i386
and everything will work fine.

BTW, how could I specify arch dependant Build-Depends (in case some
hint might reveal a multiarch solution)?


I cannot reproduce this on my amd64 machine. With the change mentioned
above it builds fine and I'm able to run /usr/bin/maq on both lenny and
sid. Some output:


I expect this in 64bit machines - but Charles had problems on hie PowerPC
as well ...

Kind regards

Andreas.

--
http://fam-tille.de


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

Re: Package management unsafe?

[Steinar H. Gunderson]

On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson wrote:
> http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html
> 
> What are people's thoughts on this?

It's been known for quite a while. (I asked one of the guys publishing it,
and he was fully aware of that, but felt it was still important to bring
light to it.)

In any case, it's pretty hard to exploit as long as you have security updates
on a different (trusted) server. The best thing you can do is DoS the process
so the user's package management software crashes, or simply never update
your mirror so users don't get updates.

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


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

Re: Help: Strange 64bit issue

[Mark Brown]

On Fri, Jul 11, 2008 at 02:40:17PM +0200, Andreas Tille wrote:
> On Fri, 11 Jul 2008, Manuel Prinz wrote:

> >With these fixes it still did not build on my system. I needed to change
> >the Build-Depends on lib64z1-dev into zlib1g-dev to get it to build in a
> >clean pbuilder chroot.

> Well, I guess that lib64z1-dev will not exist for amd64 and that this
> whole mess is just caused by the multiarch stuff.  It's the first time

It doesn't exist for AMD64 - it is 64 bit native so there is no need to
produce a 64 bit cross verson of anything.  There is lib32z1 on amd64, 
allowing 32 bit binaries to be built in an amd64 environment.

> that I have to deal with this and I have the impression that I try to
> add just problems with no real profit for the user of the program.
> Probably I should just exclude the -m64 switch when building for i386
> and everything will work fine.

That is almost certainly what you want to do.  If you build with -m64
you will produce an amd64 binary.  This can be run on i386 systems with
an appropriate processor, kernel and runtime environment but won't run
on systems where one or more of those isn't available and shouldn't be
the standard thing for the Debian port.

Depending on the needs of the package it may make sense to provide both
an i386 native and a cross-built amd64 binary in the i386 port.

> >I cannot reproduce this on my amd64 machine. With the change mentioned
> >above it builds fine and I'm able to run /usr/bin/maq on both lenny and
> >sid. Some output:

> I expect this in 64bit machines - but Charles had problems on hie PowerPC
> as well ...

PowerPC also supports mixed 64/32 bit environments so the situation is
similar to that on x86 and x86-64.  When running on a G5 or other 64 bit
processor with an appropriate kernel it is possible to execute 64 bit
PowerPC programs, even using the 32 bit PowerPC port.

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


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

Re: Help: Strange 64bit issue

[Arthur Loiret]

On Thu, Jul 10, 2008 at 11:37:10AM +0200, Andreas Tille wrote:
>> Do you have the right kernel and libc installed?
>
> What is "the right" kernel / libc???
>
> $ uname -a
> Linux wr-linux02 2.6.22-3-686 #1 SMP Sun Feb 10 20:20:49 UTC 2008 i686 
> GNU/Linux
>
> It was installed via the the Debian kernel package:
>
> $ dpkg -l linux-image* | grep ^ii.*2\.6\.2
> ii  linux-image-2.6-686 2.6.24+13 
>Linux 2.6 image on PPro/Celeron/PII/PIII/P4
> ii  linux-image-2.6.22-3-6862.6.22-6.lenny1   
>Linux 2.6.22 image on PPro/Celeron/PII/PIII/
> ii  linux-image-2.6.24-1-6862.6.24-7  
>Linux 2.6.24 image on PPro/Celeron/PII/PIII/
>
> (the host was not rebootet after installing 2.6.24, but the same happens
> on another boc running 2.6.24)
>
> $ dpkg -l libc6* | grep ^ii
> ii  libc6   2.7-10
>GNU C Library: Shared libraries
> ii  libc6-amd64 2.7-10
>GNU C Library: 64bit Shared libraries for AM
> ii  libc6-dev   2.7-10
>GNU C Library: Development Libraries and Hea
> ii  libc6-dev-amd64 2.7-10
>GNU C Library: 64bit Development Libraries f
> ii  libc6-i686  2.7-10
>GNU C Library: Shared libraries [i686 optimi

You can build 64-bit executables on any machine if supported in the toolchain
but you need a 64-bit kernel to run them, as linux-image-2.6.x-y-amd64. And of
course you need a 64-bit capable CPU to use those kernels.



signature.asc
Description: Digital signature

Re: .desktop files of GNOME apps and path to these applications

[Joey Hess]

Vincent Lefevre wrote:
> Depending on the environment makes the system less predictable.

So does accepting input from the keyboard and network.

Also, I've found that systems without a regular input of electrons have
a much more reliable behavior.

-- 
see shy jo


signature.asc
Description: Digital signature

menu applications-merged

[Anthony]

hi everybody..!

i am trying to add my personal menu in the gnome menu and kde menu.

so i have created a my.menu and the .directory and associated a .desktop.
This is OK in KDE


BUT


In gnome, the my.menu in /etc/xdg/menus/applications-merged don't seems 
to be read


does anybody have already try to add a menu.


Rq : if i use the xdg-desktop-menu utility, the menu appear... !

Thanks

anthony


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

Bug#490343: ITP: libgetopt-long-descriptive-perl -- Getopt::Long with usage text

[eloy]

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


* Package name: libgetopt-long-descriptive-perl
  Version : 0.074
  Upstream Author : http://search.cpan.org/dist/Getopt-Long-Descriptive/
* URL : Hans Dieter Pearcey <[EMAIL PROTECTED]>.
* License : Perl: GPL/Artistic
  Programming Lang: Perl
  Description : Getopt::Long with usage text

Convenient wrapper for Getopt::Long and program usage output

Package needed for new version of libmoosex-getopt-perl.

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

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



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

RFC: Removal of user/groups

[Carl Fürstenberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Per an discussion in IRC about removal of user or groups when purging
packages, I though of asking for comments about a proposal of updating
the policy.

Basically the idea is that, if a package is creating an user or an
group, that is dynamically allocated, then the package may not remove
that user/group when purging the package.

The reason is that, first, for dynamically allocated user/groups, more
than one package might use/create the same user/group.
Second, the package in question might create files using that
user/group during it's execution.
Third, recreating the user/group later might not result in the same ID
(I assume at least).

For static allocated user/groups, I don't think it's a much of a
problem to remove the user/group, as only one package is going to
create that user/group, and it will always have the same ID.

What do you think?

- --
/Carl Fürstenberg

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

iEYEARECAAYFAkh3eOIACgkQPJieVlqrawLZQgCfdTkXZK6WPL0LP/CvnDy09FOj
hZ8AnA2KXvYJvPserW2E5cRe7epXfGKA
=1uQr
-END PGP SIGNATURE-

Re: RFC: Removal of user/groups

[Stephen Gran]

This one time, at band camp, Carl Fürstenberg said:
> Per an discussion in IRC about removal of user or groups when purging
> packages, I though of asking for comments about a proposal of updating
> the policy.
> 
> Basically the idea is that, if a package is creating an user or an
> group, that is dynamically allocated, then the package may not remove
> that user/group when purging the package.
> 
> The reason is that, first, for dynamically allocated user/groups, more
> than one package might use/create the same user/group.
> Second, the package in question might create files using that
> user/group during it's execution.
> Third, recreating the user/group later might not result in the same ID
> (I assume at least).
> 
> For static allocated user/groups, I don't think it's a much of a
> problem to remove the user/group, as only one package is going to
> create that user/group, and it will always have the same ID.
> 
> What do you think?

I think it would be helpful to use the previous 400 discussions of the
same topic as a starting point, and only bring it up again if there are
new arguments.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: Package management unsafe?

[Michael Casadevall]

Maybe a check should be added to APT to flag a warning if there has been no
updates for a significant period of time? That way if a mirror ever does
that, its more detectable.
Michael

On Fri, Jul 11, 2008 at 8:55 AM, Steinar H. Gunderson <
[EMAIL PROTECTED]> wrote:
> On Fri, Jul 11, 2008 at 07:36:44AM -0500, Ron Johnson wrote:
>>
http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html
>>
>> What are people's thoughts on this?
>
> It's been known for quite a while. (I asked one of the guys publishing it,
> and he was fully aware of that, but felt it was still important to bring
> light to it.)
>
> In any case, it's pretty hard to exploit as long as you have security
updates
> on a different (trusted) server. The best thing you can do is DoS the
process
> so the user's package management software crashes, or simply never update
> your mirror so users don't get updates.
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact
[EMAIL PROTECTED]
>
>

Re: Package management unsafe?

[Florian Weimer]

* Ron Johnson:

> http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html
>
> What are people's thoughts on this?

HTTPS doesn't help against non-trusted mirrors.

The difficult question is how to tell an APT source which is not updated
regularly from an APT source that has been rolled back in a replay
attack.

Apart from that, this is clearly a PR stunt.  Next, we might see someone
who tries to get into the project, with the intent to upload Trojanized
packages--all in the name of academic research.


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

Re: RFC: Removal of user/groups

[Carl Fürstenberg]

On Fri, Jul 11, 2008 at 17:25, Stephen Gran <[EMAIL PROTECTED]> wrote:
>
> I think it would be helpful to use the previous 400 discussions of the
> same topic as a starting point, and only bring it up again if there are
> new arguments.

Have problem finding such discussion. Do you have any references to
any discussion made the last two years?
-- 
/Carl Fürstenberg <[EMAIL PROTECTED]>

Re: RFC: Removal of user/groups

[Jonas Meurer]

On 11/07/2008 Carl Fürstenberg wrote:
> On Fri, Jul 11, 2008 at 17:25, Stephen Gran <[EMAIL PROTECTED]> wrote:
> >
> > I think it would be helpful to use the previous 400 discussions of the
> > same topic as a starting point, and only bring it up again if there are
> > new arguments.
> 
> Have problem finding such discussion. Do you have any references to
> any discussion made the last two years?

http://wiki.debian.org/AccountHandlingInMaintainerScripts might be
helpful.

greetings,
 jonas


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

Re: gnome, kde, xfce use non-policy main menu

[Gunnar Wolf]

Wouter Verhelst dijo [Wed, Jul 09, 2008 at 12:12:23AM +0200]:
> The separation of a Debian menu and a "desktop" menu has been seen by
> some as a feature. I remember a post on Planet Debian by one of the
> GNOME maintainers (although I don't recall who it was) who explicitly
> said that he would not like to see non-GNOME applications in the GNOME
> menu but outside the Debian section. It is not unreasonable to state
> that it may be confusing for people to have a menu containing both GNOME
> and non-GNOME applications on a shared system; after all, different UI
> toolkits often have different UI guidelines and concepts; mixing those
> is not necessarily a good idea.

Maybe the menu name should be changed - All of the applications that
appear both in the desktop-specific and in the Debian menu are
Debian-provided. I think the Debian section should be renamed, to
avoid confusion, to "not desktop-integrated" or such.

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF


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

Re: DPL teams survey summary summary

[gregor herrmann]

On Sun, 29 Jun 2008 16:20:00 +0100, Steve McIntyre wrote:

> As you may remember, back before I started the DPL job I promised to
> run a survey. 

Thanks for your work!

> 2. On the flip side of that, I'd also like to ask the members of the
>teams that are acknowledged to perform well to help us with ideas
>for good practices to follow. Obviously, some working methods may
>not transfer well from team to team as they face different
>problems. But it's also clear that some methods *will* work well in
>a wider context, and it would be nice to see them tried.

Just a short note on this point:

At DebConf8 there will be a BOF about "Best practises in
team-maintaining packages" whichs aims at exchanging experiences
between packaging teams and learning from each other.

Attending this BOF (or reading the results afterwards) might be helpful
for those interested in getting ideas from other teams.

Cheers,
gregor

-- 
 .''`.   http://info.comodo.priv.at/ | gpg key ID: 0x00F3CFE4
 : :' :  debian gnu/linux user, admin & developer - http://www.debian.org/
 `. `'   member of https://www.vibe.at/ | how to reply: http://got.to/quote/
   `-NP: Rebekka Bakken: Why Do All The Good Guys Get The Dragons?


signature.asc
Description: Digital signature

Re: [Pkg-xen-devel] Xen status in lenny?

[Vincent Bernat]

OoO Pendant  le temps de midi  du vendredi 11 juillet  2008, vers 12:18,
Lucas Nussbaum <[EMAIL PROTECTED]> disait :

> The problem I see with that is that people will be left without a
> supported dom0 kernel at some point during the etch lifetime. Do we have
> a plan to address that? Shouldn't we make it clear that we will support
> the etch kernel until a lenny+1/2 kernel is available, for example?

The problem also appears for vserver kernel.
-- 
printk("VFS: Busy inodes after unmount. "
"Self-destruct in 5 seconds.  Have a nice day...\n");
2.3.99-pre8 /usr/src/linux/fs/super.c


pgpActwGNs88S.pgp
Description: PGP signature

Re: status of default syslog daemon for lenny

[Petter Reinholdtsen]

[Jonas Meurer]
> Forwarding the mail to debian-devel. Are there any objections by
> developers against rsyslog as default syslog daemon?

No objection.  Just a small report that Debian Edu already switched to
rsyslog for our Lenny based version, and it seem to work just fine.
Because debootstrap claim sysklogd is needed, it is installed by
base-installer, and replaced automatically by tasksel when our tasks
are installed.

Happy hacking,
-- 
Petter Reinholdtsen


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

Re: [RFH] #486212 reportbug-ng segfaults

[Adeodato Simó]

* Bastian Venthur [Thu, 10 Jul 2008 11:39:16 +0200]:

> Thanks for the hint, unfortunately that didn't help. I've rebuild  
> python-qt3 with CXXFLAGS="-Wall -g -O0" but rng is still segfaulting.

> There is also no bugreport in python-qt3 indicating that someone else  
> has this problem.

FWIW several users have reported crashes in minirok, so it may as well
be the same issue.

Cheers,

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
Truth is the most valuable thing we have, so let's economize it.
-- Mark Twain


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

Kernel 2.6.25 broke iPod support for me, but who to bug?

[Frank Lichtenheld]

Hi.

While testing some updates to my gtkpod/libgpod packages I noticed that
I couldn't actually play any songs anymore from my iPod. Which worked
fine some weeks ago.

I traced the error back to a change in kernel 2.6.25: Apparently vfat
file system can now become case sensitive in some cases
("FAT: utf8 is not a recommended IO charset for FAT filesystems,
filesystem will be case sensitive!") which the mentioned applications
are totally not prepared for. They try to access files with their name
in upper case, but since the default for vfat is "shortname=lower" this
doesn't actually work anymore for files and directories that have no
long name saved on the file system.

So my question now is where to file the bug and I would be grateful
for recommendations:

- kernel: I find it unlikely that the mentioned change was done without
  a good reason given its obvious behavioural change. So I guess the
  chances that it can be reversed are slim. But I might be wrong?
- hal/util-linux: Maybe it would be a good idea to mount case sensitive
  vfat filesystems with shortname=winnt in the hope that would disturb
  fewer users. It would have fixed the problem at least in my case,
  but I'm not so sure it would be the right solution for most cases?
- applications (libgpod in this case): The application could try to
  normalize the filename to lower case if it knows that it handles data
  on a file system that could cause problems like this. But that sounds
  like a awful lot of special casing to me.

Any ideas?
Any other examples of applications broken by this change?

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]

Re: Package management unsafe?

[Michael Casadevall]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It doesn't have to have updated packages, maybe have something like this

APT-Ping: *timestamp*

and then push out a new packages file with just an updated timestamp in it.
Michael


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

iD8DBQFId//JpblTBJ2i2psRAu6uAJ48+knPTzxi1InA/Wg3AN4m2Rt8WwCfa/ES
rddl6+w/Kw+7UBVNQLjLplE=
=fGdJ
-END PGP SIGNATURE-
On Fri, Jul 11, 2008 at 8:39 PM, Frank Lichtenheld <[EMAIL PROTECTED]> wrote:

> On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote:
> > Maybe a check should be added to APT to flag a warning if there has been
> no
> > updates for a significant period of time? That way if a mirror ever does
> > that, its more detectable.
>
> That really doesn't make any sense for stable users since our point
> releases aren't exactly weekly ;)
>
> Gruesse,
> --
> Frank Lichtenheld <[EMAIL PROTECTED]>
> www: http://www.djpig.de/
>

Re: Package management unsafe?

[Frank Lichtenheld]

On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote:
> Maybe a check should be added to APT to flag a warning if there has been no
> updates for a significant period of time? That way if a mirror ever does
> that, its more detectable.

That really doesn't make any sense for stable users since our point
releases aren't exactly weekly ;)

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]

Re: Package management unsafe?

[Don Armstrong]

On Sat, 12 Jul 2008, Frank Lichtenheld wrote:

> On Fri, Jul 11, 2008 at 11:48:03AM -0400, Michael Casadevall wrote:
> > Maybe a check should be added to APT to flag a warning if there has been no
> > updates for a significant period of time? That way if a mirror ever does
> > that, its more detectable.
> 
> That really doesn't make any sense for stable users since our point
> releases aren't exactly weekly ;)

It wouldn't be a huge deal to re-sign the package list every n days
and warn if the package list was signed more than n+r days ago. [This
would even be useful to handle properly mirrors which are just out of
date even without nefarious behavoir.]


Don Armstrong

-- 
Quite the contrary; they *love* collateral damage. If they can make
you miserable enough, maybe you'll stop using email entirely. Once
enough people do that, then there'll be no legitimate reason left for
anyone to run an SMTP server, and the spam problem will be solved.
 -- Craig Dickson in <[EMAIL PROTECTED]>

http://www.donarmstrong.com  http://rzlab.ucr.edu


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

Re: Kernel 2.6.25 broke iPod support for me, but who to bug?

[James Vega]

On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
> Hi.
> 
> While testing some updates to my gtkpod/libgpod packages I noticed that
> I couldn't actually play any songs anymore from my iPod. Which worked
> fine some weeks ago.
> 
> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!")

Are you sure this is a kernel change and not just a change in your
kernel config?  I brought up what seems to be the same (or at least
closely related) problem 4 years ago on lkml[0].

[0] - http://lkml.org/lkml/2004/4/5/209
-- 
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: correct definition of localhost?

[s. keeling]

["Followup-To:" header set to linux.debian.devel.]
sean finney <[EMAIL PROTECTED]>:
>  On Tuesday 08 July 2008 06:40:05 pm Steve Langasek wrote:
> 
> > Ulrich made the change, and he's not exactly known for giving helpful
> > explanations.  Apparently he thinks bug ping-pong is a better use of his
> > time.
> 
>  it sounds like we have another contender for the annual j=F6rg schilling=20
>  award[1].

Let's just be thankful he's not as odd as Reiser.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*)http://blinkynet.net/comp/uip5.html  Linux Counter #80292
- -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me.


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

Re: correct definition of localhost?

[s. keeling]

Ralf Hildebrandt <[EMAIL PROTECTED]>:
>  * Martijn van Oosterhout <[EMAIL PROTECTED]>:
> > On Tue, Jul 8, 2008 at 2:37 AM, Joey Hess <[EMAIL PROTECTED]> wrote:
> > > http://sourceware.org/bugzilla/show_bug.cgi?id=4980
> > 
> > I just find it wierd that there doesn't appear to be a single person
> > who can explain the reasoning for the change...
> 
>  That bugtracker entry sure makes some interesting reading

Yeah, and for lurkers, don't be tempted to add to the discussion there
(looking at it in a browser, I was tempted, you may be too).  It's a
bug report, not a forum.  Do that elsewhere.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*)http://blinkynet.net/comp/uip5.html  Linux Counter #80292
- -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me.


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

Re: DPL teams survey summary summary [METOO]

[s. keeling]

Per Andersson <[EMAIL PROTECTED]>:
>  On Sun, Jun 29, 2008 at 5:20 PM, Steve McIntyre <[EMAIL PROTECTED]> wrote:
> > 8. Publicise more clearly the places where new people could help
> >   out. I'm commonly asked by people how they could get involved in
> >   Debian, or what tasks most urgently need help, and those are quite
> >   difficult things to answer. A more focussed set of web pages and/or
> >   wiki pages targeting these questions would be a great thing to
> >   have.
> 
>  A new usertag was introduced into the BTS a while ago, the
>  gift tag. [0] [1] Being a newbie in Debian, the BTS and
>  contributing to the free software community I thought this
>  was a great idea. It seems that the gift tag isn't used that
>  much though [2]. It would be great if the gift tag gained
>  popularity.
> 
>  There exists pages on w.d.o that targets how to get started
>  with help out. [3] [4] Perhaps there is a need for a more
>  clean path to finding out how to get started, a start would be
>  to put links on the frontpage of w.d.o and [5] to get directly
>  to the help guide [4]. As it is now, the path there is quite
>  long and IMHO you need to know what you are looking for.
> 
>  [0] http://wiki.debian.org/qa.debian.org/GiftTag
>  [1] http://lists.debian.org/debian-devel/2007/12/msg00679.html
>  [2] http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED];tag=gift
>  [3] http://debian.org/devel/join/
>  [4] http://wiki.debian.org/HelpDebian
>  [5] http://debian.org/devel/

Excellent info, thanks.  [4] is very useful.


-- 
Any technology distinguishable from magic is insufficiently advanced.
(*)http://blinkynet.net/comp/uip5.html  Linux Counter #80292
- -http://www.faqs.org/rfcs/rfc1855.htmlPlease, don't Cc: me.


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

Re: Kernel 2.6.25 broke iPod support for me, but who to bug?

[Frank Lichtenheld]

On Fri, Jul 11, 2008 at 09:11:57PM -0400, James Vega wrote:
> On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:
> > Hi.
> > 
> > While testing some updates to my gtkpod/libgpod packages I noticed that
> > I couldn't actually play any songs anymore from my iPod. Which worked
> > fine some weeks ago.
> > 
> > I traced the error back to a change in kernel 2.6.25: Apparently vfat
> > file system can now become case sensitive in some cases
> > ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> > filesystem will be case sensitive!")
> 
> Are you sure this is a kernel change and not just a change in your
> kernel config?  I brought up what seems to be the same (or at least
> closely related) problem 4 years ago on lkml[0].

To be precise the upgrade from the current (i.e. today) 2.6.24 testing
kernel to the current 2.6.25 unstable kernel causes the problem.

So yeah, both code and config changed I guess.

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]

Re: Kernel 2.6.25 broke iPod support for me, but who to bug?

[Steve Langasek]

On Sat, Jul 12, 2008 at 02:19:58AM +0200, Frank Lichtenheld wrote:

> While testing some updates to my gtkpod/libgpod packages I noticed that
> I couldn't actually play any songs anymore from my iPod. Which worked
> fine some weeks ago.

> I traced the error back to a change in kernel 2.6.25: Apparently vfat
> file system can now become case sensitive in some cases
> ("FAT: utf8 is not a recommended IO charset for FAT filesystems,
> filesystem will be case sensitive!") which the mentioned applications
> are totally not prepared for. They try to access files with their name
> in upper case, but since the default for vfat is "shortname=lower" this
> doesn't actually work anymore for files and directories that have no
> long name saved on the file system.

vfat has never supported case-insensitivity when using utf8.  You have to
pick either case-insensitivity, or unicode.  If the kernel has changed the
behavior of vfat when using iocharset=utf8, this merely makes the problems
more explicit; it was already broken in various subtle ways before this.

> So my question now is where to file the bug and I would be grateful
> for recommendations:

> - kernel: I find it unlikely that the mentioned change was done without
>   a good reason given its obvious behavioural change. So I guess the
>   chances that it can be reversed are slim. But I might be wrong?

I don't think this will do any good.  As James mentions, there have been
known problems with vfat+utf8 for years, that have gone unaddressed; I don't
think one more bug report will change things.

> - hal/util-linux: Maybe it would be a good idea to mount case sensitive
>   vfat filesystems with shortname=winnt in the hope that would disturb
>   fewer users. It would have fixed the problem at least in my case,
>   but I'm not so sure it would be the right solution for most cases?

I don't think there's any way to detect at mount time whether a filesystem
*is* case-sensitive or not; if shortname=winnt will work around this
behavior, then we should instead probably use this as a default any time
utf8 is being used as the iocharset.

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


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

A few Questions: Creating an arch indep pkg.

[Brian]

Q1)
What's the difference between Build-Depends-Indep and Build-Depends?

I am creating a new package.
* The source package requires i386 to build and has many dependencies.
* The binary package is architechure independent and has no dependencies.

How should I use Build-Depends?
I was thinking:
Build-Depends: nothing
Build-Depends-Indep: debhelper (>= 5), perl (>= 5.8.4), 
libxml-sax-expat-perl, libxml-sax-machines-perl, etc.


Is that correct?

Q2)
What should my debian/rules .PHONY line look like?

I guess it to be??
.PHONY: build clean binary-indep binary install

Q3)
Are there any well built packages that are similar? So I can copy their 
templates?


- Brian



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

Re: A few Questions: Creating an arch indep pkg.

[Ben Finney]

Brian <[EMAIL PROTECTED]> writes:

[…]

Brian, the questions you asked are best asked on
[EMAIL PROTECTED] I'll follow up with some answers
there.

-- 
 \ “People's Front To Reunite Gondwanaland: Stop the Laurasian |
  `\  Separatist Movement!” —wiredog, http://kuro5hin.org/ |
_o__)  |
Ben Finney


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

Packages not removable because the `/etc/init.d/package stop' fails.

[Charles Plessy]

Hi all,

It seems that some packaged daemons use a combination of scripts that
sometimes makes them difficult to remove on Etch:

 - prerm stops the daemon and exits if it fails

 - /etc/init.d/package stops the daemon using start-stop-daemon and
   fails if it was not running.

As a result, if the daemon is not running, postrm fails and the package
can not be removed. See #489366 for example. Now I wonder how to deal
with that kind of problem. It could be solved at the package level,
except that such bug but is probably not grave enough for the package to
be updated in Etch. I reported a bug on start-stop-daemon on
its Etch version, but this was closed by the dpkg maintainers, as the
problem is not affecting Lenny.

I think that not being able to easily remove packages in Etch can be an
annoyance when upgrading to Lenny, and I suppose that other daemons are
affected. Do you think that submitting a paragraph to the release notes
would be appropriate or is there something better to do?

Have a nice day,

-- 
Charles Plessy
Debian-Med packaging team,
Tsurumi, Kanagawa, Japan


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

Re: Packages not removable because the `/etc/init.d/package stop' fails.

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> It seems that some packaged daemons use a combination of scripts that
> sometimes makes them difficult to remove on Etch:
>
>  - prerm stops the daemon and exits if it fails

This is generally correct.  If the daemon can't shut down cleanly,
continuing with the upgrade anyway could result in data corruption or loss
depending on the daemon.  I think it's the correct conservative behavior
to stop at that point and force manual intervention.

>  - /etc/init.d/package stops the daemon using start-stop-daemon and
>fails if it was not running.

This isn't correct.

> As a result, if the daemon is not running, postrm fails and the package
> can not be removed. See #489366 for example. Now I wonder how to deal
> with that kind of problem. It could be solved at the package level,
> except that such bug but is probably not grave enough for the package to
> be updated in Etch.

Well, it's an RC bug (violation of the must in Policy 9.3.2) for the stop
action of an init script to fail if the daemon is not running, which is
fairly serious.  I think it could well warrant a stable update if it's
causing problems for upgrades to lenny.

The other option is to work around it in the upgraded version of the
package; if the prerm script fails, there's an error handling case that
calls the new prerm script with the failed-upgrade argument and gives it
an opportunity to say "yes, I don't care, continue anyway."

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Packages not removable because the `/etc/init.d/package stop' fails.

[Russ Allbery]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Well, it's an RC bug (violation of the must in Policy 9.3.2) for the
> stop action of an init script to fail if the daemon is not running,
> which is fairly serious.  I think it could well warrant a stable update
> if it's causing problems for upgrades to lenny.

Actually, I take that back -- it's not on the lenny RC bug list, so it's
possibly not an RC bug.  It would be if Policy and the release goals were
synchronized and the must stayed in that case, but it's ambiguous right
now.  If this truly shouldn't be RC, Policy should be changed to make sane
init script behavior a should instead.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Package management unsafe?

[Joe Smith]

Florian Weimer  deneb.enyo.de> writes:

> 
> * Ron Johnson:
> 
> >
http://www.cs.arizona.edu/people/justin/packagemanagersecurity/attacks-on-package-managers.html
> >
> > What are people's thoughts on this?
> 
> HTTPS doesn't help against non-trusted mirrors.
> 
> The difficult question is how to tell an APT source which is not updated
> regularly from an APT source that has been rolled back in a replay
> attack.

Actually the attack works just fine without rolling back for a replay attack.
I have my mirror stop updating. If I can assume that most clients use only my
mirror, and not others, then once a major security flaw comes out in a package
version my mirror uses, then I have a list of IP addresses (from my server logs)
that may be exploitable. 

So there is no reason to differentiate between a stale mirror and a potential
attack mirror. Any mirror more than say 7-days out of date should be considered
potentially unsafe, and the user should be warned that the mirror is stale,
which may be an attack attempt, and that they should consider choosing a new
mirror. Having the signature on the package file update daily, even if the
package file contents have not changed would be an easy way to detect a stale
mirror. Just add a check on the signature time-stamp as part of checking the
package signature, and warning if signature is too old.

 
But the attack is not really applicable to Debian, where security updates come
from trusted security mirrors, and not the general mirrors. If this were not the
case, then the following statement from the site would be concerning:

>For example, it is known that an earlier version of OpenSSL for Debian has a
>security flaw. The list of files from the repository that previously included
>this package is still correctly signed. Using this old signed file list, a
>malicious mirror can keep a client on the insecure version of OpenSSL by
>responding to the client's package manager with the old list of files. 

As it is, the mirror can do no such thing. (Only a security mirror could do
this) This is a very good thing.

Indeed there is a second possible attack vector if the general mirrors were used
for security updates. I could set my mirror up to watch for people requesting a
specific security update. While the file is being downloaded, a script could
automatically attempt to exploit the vulnerability on the system that requested
the update. The idea is that there is a high probability that the system
requesting the update has the insecure version installed, and is thus
exploitable.

However, if the security updates come from trusted security mirrors rather than
a general mirror, that attack would fail too. So with the exception of Sid or
Testing users that do not use the testing-security system to receive security
updates, Debian really is not terribly vulnerable to this. 

But I still strongly recommend the signature time-stamp solution  (which Don
Armstrong suggested first) as it would let us notify users that a mirror is
stale regardless of whether this is malicious, and it would help protect Sid and
testing users. It would even add some additional security to Debian-derived
distros that do not use a separate security mirror system. (Although they would
still be vulnerable to the exploit while downloading issue.)




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

Re: Packages not removable because the `/etc/init.d/package stop' fails.

[Steve Langasek]

On Fri, Jul 11, 2008 at 10:52:36PM -0700, Russ Allbery wrote:
> Russ Allbery <[EMAIL PROTECTED]> writes:

> > Well, it's an RC bug (violation of the must in Policy 9.3.2) for the
> > stop action of an init script to fail if the daemon is not running,
> > which is fairly serious.  I think it could well warrant a stable update
> > if it's causing problems for upgrades to lenny.

> Actually, I take that back -- it's not on the lenny RC bug list, so it's
> possibly not an RC bug.  It would be if Policy and the release goals were
> synchronized and the must stayed in that case, but it's ambiguous right
> now.  If this truly shouldn't be RC, Policy should be changed to make sane
> init script behavior a should instead.

It was ambiguous before the latest policy commit because reasonable people
could disagree about what "sane" behavior of an init script was, but in
practice, bugs that prevent a package from being upgradeable (such as
missing conflicts/replaces, broken maintainer scripts that fail to handle
the previous package version, etc.) have always been considered de facto RC
in the past, regardless of whether they're policy violations.  I don't see
any evidence that the release team has changed this practice for lenny.

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


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

Re: Package management unsafe?

[Andrei Popescu]

On Sat,12.Jul.08, 06:12:33, Joe Smith wrote:
 
> However, if the security updates come from trusted security mirrors rather 
> than
> a general mirror, that attack would fail too. So with the exception of Sid or
> Testing users that do not use the testing-security system to receive security
> updates, Debian really is not terribly vulnerable to this. 
 
How about distributing the Release files *only* from a trusted server?

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature