Bug#517027: ITP: liblwp-protocol-socks-perl -- adds support for the socks protocol and proxy facility to perl LWP

[Pierre Neyron]

Package: wnpp
Severity: wishlist
Owner: Pierre Neyron 

* Package name: liblwp-protocol-socks-perl
  Version : 1.1
  Upstream Author : Sheridan C. Rawlins 
* URL : http://search.cpan.org/~scr/LWP-Protocol-socks-1.1/
* License : Same as Perl
  Programming Lang: Perl
  Description : adds support for the socks protocol and proxy facility to 
perl LWP

Perl module to add to Perl LWP the capability to talk through a socks proxy.

-- System Information:
Debian Release: 5.0
  APT prefers stable
  APT policy: (990, 'stable'), (200, 'testing'), (100, 'unstable'), (10, 
'experimental')
Architecture: amd64 (x86_64)



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

Re: xcdroast does no longer work with wodim: Who to blame?

[Joerg Schilling]

>xcdroast is looking for cdrecord, which does no longer exist in Debian 
>Sid (apparently). And wodim does no longer provide a symlink as cdrecord 
>or something (apparently).

>So: xcdroast does no longer work. Who is to blame (Bug entry): xcdroats 
>or wodim?

You need to blame the people who are responsible for removing cdrecord
and who started to include a fork (wodim) that cannot be legally distributed.

Just add cdrecord from:

ftp://ftp.berlios.de/pub/cdrecord/alpha/

and you get a legal and working system.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily


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

bonvacance.nl now links to you

[John Palmen]

Dear Debian,

I have visited your site and I think that the content of  bonvacance.nl 
could be of interest to our web site visitors.

I have already placed a link to your site along with a description at 
"http://www.bonvacance.nl/partnerbase/accommodaties.htm";. If you want 
the description of your site modified or if you have any other 
cross-promotion ideas, let me know.

I would appreciate if you placed a link back to my site:

URL: http://www.bonvacance.nl
Titel: Bonvacances Vakantiehuizen
Beschrijving: Verhuur vakantiehuizen en vakantiewoningen. Huren van een 
vakantiehuis in Frankrijk.

Best regards,

John Palmen
Bonvacances

http://www.bonvacance.nl - j...@bonvacance.nl
Sweelinkcplein 21
2517 GM DEN HAAG
Tel. 070-3520700


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

Proposal to improve package configuration upgrades

[Dominique Dumont]

[ this discussion was started on debian-perl. I'm restarting it on
debian-devel following Gregor Hermann suggestion ]

Hello

The other day, I was upgrading cups and dpkg did ask me the usual way
if I wanted to keep my cups config file or take the upstream version.

Like always, I asked for a diff and was quite puzzled because I did
not remember anything about editing this file. Then I remembered that
I did a modification through cups admin web interface.

Previous common story you might say. But for a casual user (like my
mother-in-law which now use Debian Lenny ;-) ), this can be
frustrating:
- I did modify the config through a nice web interface
- during the upgrade, I either have to look at all the gory details of
  the config file or I have to loose my configuration.

So I was thinking that this is a typical case where the upgrade could
be smoothly handled by Config::Model. 

Either in automatic mode where user data and upstream modifications
are merged (*) or in manual mode where the graphical (or curses)
interface is fired up so the user can check what's going on.

Of course, there's no miracle. For the merge to work automatically and
the result to be valid, the semantic of the configuration file must be
known by Config::Model. This is done by describing the structure and
constraints of the configuration file in a model (hence the
Config::Model name). 

What do you think about this ?

All the best

(*) If you want I can go more in details on how an upgrade can be done

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Steve Langasek]

On Wed, Feb 25, 2009 at 09:28:28AM +0100, Joerg Schilling wrote:
> >xcdroast is looking for cdrecord, which does no longer exist in Debian 
> >Sid (apparently). And wodim does no longer provide a symlink as cdrecord 
> >or something (apparently).

> >So: xcdroast does no longer work. Who is to blame (Bug entry): xcdroats 
> >or wodim?

It's a bug in the xcdroast package.  There is a 'cdrecord' dummy package in
unstable which provides a cdrecord compatibility symlink to wodim, so if a
package invokes cdrecord it's possible to still depend on it.  Whoever
updated xcdroast to depend on wodim should have made it call wodim, at the
same time.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


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

Re: Security Issue of .desktop files

[Josselin Mouette]

Le mardi 24 février 2009 à 22:53 +0100, Yves-Alexis Perez a écrit :
> Not exactly. The “safe” .desktop file was in the link I pasted on
> another mail in the thread:
> 
>  /* check if the file tries to look like a regular document (i.e.
>   * a display name of 'file.png'), maybe a virus or other malware.
>   */

> Basically, when the .desktop tries to trick the user, it won't be
> executed.

So this amounts to approximately the same level as the patched nautilus
currently in Debian. However this is insufficient, since it is easy to
trick the user into launching a “safe” .desktop file which is actually
malware.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


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

Re: xcdroast does no longer work with wodim: Who to blame?

[gregor herrmann]

On Wed, 25 Feb 2009 01:00:48 -0800, Steve Langasek wrote:

> > >So: xcdroast does no longer work. Who is to blame (Bug entry): xcdroats 
> > >or wodim?
> It's a bug in the xcdroast package.  There is a 'cdrecord' dummy package in
> unstable which provides a cdrecord compatibility symlink to wodim, so if a
> package invokes cdrecord it's possible to still depend on it.  Whoever
> updated xcdroast to depend on wodim should have made it call wodim, at the
> same time.

That's what happened until 0.98+0alpha15-11* [0]; 0.98+0alpha16-1 still
has the patch in the source package but it's commented out in
debian/patches/series [1].

[0] http://bugs.debian.org/386251
[1] http://patch-tracking.debian.net/package/xcdroast

Cheers,
gregor, cc'ing the maintainer
 
-- 
 .''`.   Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
 : :' :  Debian GNU/Linux user, admin, & developer - http://www.debian.org/
 `. `'   Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
   `-Warp 7 -- It's a law we can live with. 


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

Re: xcdroast does no longer work with wodim: Who to blame?

[Josselin Mouette]

Le mardi 24 février 2009 à 21:14 +0100, Andreas Tscharner a écrit :
> So: xcdroast does no longer work. Who is to blame (Bug entry): xcdroats 
> or wodim?

In the end, the one you have to blame is Joerg Schilling, for forcing us
to change the name of the binary.

-- 
 .''`.  Debian 5.0 "Lenny" has been released!
: :' :
`. `'   Last night, Darth Vader came down from planet Vulcan and told
  `-me that if you don't install Lenny, he'd melt your brain.


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

Re: Proposal to improve package configuration upgrades

[Jonas Smedegaard]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, Feb 25, 2009 at 09:28:52AM +0100, Dominique Dumont wrote:

>Of course, there's no miracle. For the merge to work automatically and 
>the result to be valid, the semantic of the configuration file must be 
>known by Config::Model. This is done by describing the structure and 
>constraints of the configuration file in a model (hence the 
>Config::Model name).

Do Config::Model support migration from one model to another?

Example: CUPS 2.x has boolean option foo, which is changed in CUPS 3.x 
to numeric option foobar.


  - Jonas

P.S. Please cc me on responses, I am not subscribed to -devel

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

  [x] quote me freely  [ ] ask before reusing  [ ] keep private
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmlHtcACgkQn7DbMsAkQLjcSACfSHHm6+wMFVanffFsDWr9brsl
1gkAoJRQWvyvmGEuRxA7aC3iqhkHfIsc
=V7EK
-END PGP SIGNATURE-


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

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Jonas Smedegaard  writes:

> Do Config::Model support migration from one model to another?

Yes. In fact model version n can include specific attribute to deal
with migration from n-1 to n.

> Example: CUPS 2.x has boolean option foo, which is changed in CUPS 3.x 
> to numeric option foobar.

In such a case, CUPS3.x model would need to speficy that:
- boolean option foo is status deprecated (which means the value can
  be managed, but the option foo is hidden from the user in the
  interfaces)
- the default value of foobar can be computed from foo value (using
  compute attribute of Value object. See [1] for gory details)

More complex value migration scenarios are possible.

All the best

[1] http://search.cpan.org/dist/Config-Model/lib/Config/Model/ValueComputer.pm

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Mutual business relationship.

[Koffi Gilbert]

I have a new email address!You can now email me at: gilbertkoffi...@yahoo.com



- Attn: I got your information in a professional database when I was searching 
through 

apt-get update seems to fail getting SourceIndex Re: Bug#517054: Cannot update sid image via pbuilder update/apt-get fails.

[Junichi Uekawa]

Hi,

Sending to a wider audience in case someone knows how to fix it.

At Wed, 25 Feb 2009 14:45:00 +0100,
Artur R. Czechowski wrote:
> 
> On Wed, Feb 25, 2009 at 10:20:22PM +0900, Junichi Uekawa wrote:
> > Hi,
> > 
> > Does it happen outside of chroot too?
> No. But I have current Packages/Sources outside of chroot.
> 
> If I login into chroot and update indices in other way (aptitude update),
> then run apt-get update problem does not exist.
> 
> BTW, if you wish to fetch 115MB I can put my image for pbuilder on
> a server with fast uplink.

Actually, I've been seeing the problem too.  It looked like a bad
interaction between approx and cdn.debian.net mirrors (and
http.us.debian.org too, since it's a load-balanced mirror, which
means, individual files can be fetched from different server).
Retrying 'apt-get update' several times inside chroot seemed to
succeed sometimes.

instead of 
apt-get update
doing
apt-get update -o Acquire::PDiffs=false

seems to help, since it's failing in getting the correct diff index
for Sources file, but it's just making things less flakey.


---
r...@szczaw:~# apt-get update
Get:1 http://http.us.debian.org unstable Release.gpg [189B]
[...]
Get:100 http://http.us.debian.org unstable/non-free 2009-02-19-1435.55.pdiff
[490B]
Fetched 8476kB in 2min23s (58.9kB/s)   
W: Failed to fetch
http://http.us.debian.org/debian/dists/unstable/contrib/source/SourcesIndex
MD5Sum mismatch
---



regards,
junichi
-- 
dan...@{netfort.gr.jp,debian.org}


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

Bug#517079: ITP: webboard -- graphical frontend for sending text to pastebin servers

[Siegfried-Angel Gevatter Pujals]

Package: wnpp
Severity: wishlist
Owner: "Siegfried-Angel Gevatter Pujals" 

* Package name: webboard
  Version : 0.2.2
  Upstream Author : Olivier Le Thanh Duong 
* URL : https://launchpad.net/webboard
* License : GPL-2+
  Programming Lang: Python
  Description : graphical frontend for sending text to pastebin servers

 Publish text notes and source code on a pastebin server
 for collaborative debugging.
 .
 WebBoard includes a standalone application and an applet for the 
 GNOME panel.



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

Re: Should 32-bit apps work with a 64-bit kernel?

[Goswin von Brederlow]

Ron Johnson  writes:

> On 02/09/2009 08:04 AM, Ron Johnson wrote:
>> On 02/09/2009 12:28 AM, Martin Langhoff wrote:
>>> On Mon, Feb 9, 2009 at 2:19 PM, Ben Hutchings 
>>> wrote:
 If jed can deal with files that large, sure.  But if it expects to be
 able to load the entire file into memory - as most text editors do -
 stat() will be only the first of its problems.
>>>
>>> Old vi was able to work with files larger than available RAM. I wonder
>>> if any modern text editor today can still handle that.
>>
>> I've got a 23GB text file that vim 7.2.079-1 just won't "see".
>>
>> more(1) processes it, file(1) processes it, but vim displays an
>> empty screen with "[New File]" at the bottom.
>
> Bug #514617.
>
> stat64("ACCOUNT_TOLL_V20_200408.UNL", {st_mode=S_IFREG|0640,
> st_size=23726916643, ...}) = 0
> stat64("ACCOUNT_TOLL_V20_200408.UNL", {st_mode=S_IFREG|0640,
> st_size=23726916643, ...}) = 0
> access("ACCOUNT_TOLL_V20_200408.UNL", W_OK) = 0
> open("ACCOUNT_TOLL_V20_200408.UNL", O_RDONLY) = -1 EOVERFLOW (Value
> too large for defined data type)
> readlink("ACCOUNT_TOLL_V20_200408.UNL", 0xfff19c4c, 4095) = -1
> EINVAL (Invalid argument)
>

Maybe we need a mass bug filing for programs not using 64bit file
offsets.

Anyone up for hacking libc to always fail on the 32bit wrappers for
seek, stat, ...?

MfG
Goswin


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

Re: Should 32-bit apps work with a 64-bit kernel?

[Samuel Thibault]

Goswin von Brederlow, le Wed 25 Feb 2009 16:16:53 +0100, a écrit :
> Anyone up for hacking libc to always fail on the 32bit wrappers for
> seek, stat, ...?

Or looking for binaries with a U lseek ?

Samuel


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

Re: Forthcoming changes in kernel-package

[Goswin von Brederlow]

Manoj Srivastava  writes:

> On Wed, Feb 18 2009, Theodore Tso wrote:
>
>> On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote:
>>> Hi,
>>> 
>>> This is a heads up for a major change in kernel-package, the
>>>  tool to create user packaged kernel images and headers; which will
>>>  make the make-kpkg script far less error prone, and far more
>>>  deterministic.
>>> 
>>>a. Every invocation of kernel-package will remove ./debian directory,
>>>   and regenerate the changelog and control files. This will get rid
>>>   of any remaining issues with the ./debian directory getting out of
>>>   sync with the kernel sources; and will allow people to make small
>>>   tweaks to the kernel sources and have  make-kpkg reflect those
>>>   changes.
>>
>> Is there going to be a way for people to replace the changelog with
>> one that contains useful information in that case?  I've been doing
>> this by doing a make-kpkg configure and then editing the
>> debian/changelog file afterwards...>
>
> I have a plan for something like this, though currently there is
>  no code. I was thinking of doing an "overlay" for ./debian, kind of
>  like what ikiwiki and request-tracker do; so /usr/share/kernel-package
>  contain the information that goes into ./debian; but if there is a user
>  specified overlay, then files present in the overlay are used instead
>  (files not in the overlay dir still come from the default location).

It might be nice to have a changelog.d/ directory in the source with
sniplets for the debian/changelog. All files would be cated together
and used as the text for the current changelog entry.

This would have two use cases:

1) Patch packages can drop a file in there (when the user applies the
   patch) saying what got applied.

2) Users can add their own files there detailing what they changed.
   E.g. '  * added CONFIG_SCSI_DISK=y'

As I write this I notice that (2) doesn't quite work. For my manual
entries I would like to specify a version. E.g. in 2.6.26-1 I added
CONFIG_SCSI_DISK=y, in 2.6.26-2 I added CONFIG_SCSI_CDROM=y and in
2.6.26-3 I removed it again.

But maybe that goes too far. Just being able to add to the current
entry would be a good start already.

MfG
Goswin


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

Re: Is the FHS dead ?

[Goswin von Brederlow]

Giacomo Catenazzi  writes:

> Standards should be most frozen as possible. I don't find a lot of
> think that need to be added.

What about cross compile and multiarch paths?

The old lib32/lib64 dirs currently mentioned in the FHS are just not
covering enough cases and are misleading (like amd64 uses /lib for
64bit libraries as that is the native bit-ness).

MfG
Goswin


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

Re: Security Issue of .desktop files

[Harald Braumann]

On Tue, 24 Feb 2009 23:36:38 +
Matthew Johnson  wrote:

> On Tue Feb 24 23:44, Yves-Alexis Perez wrote:
> > On mar, 2009-02-24 at 17:33 -0500, Michael S. Gilbert wrote:
> > > here is
> > > a .desktop file that looks like it is iceweasel, but really it
> > > downloads an essentially random file, but I could have made it do
> > > pretty much anything.
> > 
> > Yes, tests may need to be narrowed. That should be part of the spec,
> > though.
> 
> Speaking as someone with a PhD in computer security (and my PhD was in
> this area) I can tell you that trying to use heuristics in order to
> determine if something is 'bad' does not, and it's fairly widely
> recognised cannot, work.

Not only widely recognised, it's proven. People with or without a PhD
might look up the halting problem.

> I firmly agree with Michael that the only good solution is to require
> explicit marking or .desktop files in some fashion.

Isn't downloading something, putting it on the desktop and clicking on
it a strong enough indication of the user's will to execute whatever it
is? If he does all this without blinking once, he surely wouldn't have
any concerns about setting the x bit, if that gets him what he wants,
i.e. to execute the file.

As long as most people think, that embedded scripts, programmes
opening all sorts of crap automatically and .dektop files are
really a great idea, trouble won't be amiss, no matter how many warning
pop-ups, checks or blocks you put in front. I fear the day, when I can
download soft links and disguise shell scripts as pictures.

Cheers,
harry



signature.asc
Description: PGP signature

Re: Proposed release goal: fix debian/rules build-arch

[Goswin von Brederlow]

Raphael Hertzog  writes:

> On Mon, 16 Feb 2009, Kari Pahula wrote:
>> Currently, Debian Policy doesn't match with the current practice in
>> section 7.7.
>> 
>> > The Build-Depends-Indep and Build-Conflicts-Indep fields must be
>> > satisfied when any of the following targets is invoked: build,
>> > build-indep, binary and binary-indep.
>> 
>> I know that people like to say that Policy should reflect reality, not
>> have wishful thinking (like in #178809).  It's been tried before but
>> I'd like to try again to get a transition done to make reality into
>> what 7.7 says it is.
>
> I don't know if you are aware, but there's lots of discussion already
> about this in various dpkg bug reports and in particular this one:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=229357
>
> This bug is on my radar and I certainly plan to fix it in the squeeze
> timeline but before we can clearly fix it, we need to come to a reasonable
> agreement about what constitutes the official interface to build Debian
> packages and how it should look like. We currently have an unfortunate
> divergence between dpkg-buildpackage and the policy that needs to be
> solved before we can tackle this problem seriously.

Wether dpkg-buildpackage calls build or the user call debian/rules
build manually makes no difference to the discussion. Policy says the
build targets needs B-D-I installed while current practice is that
build must work without B-D-I installed.

Think of it this way: The question is not about the interface for the
user to build package but about the interface of the source to allow
building. Wether dpkg-buildpackage invokes the build target or the
user makes no difference to the source.

>> Now, option 1 (cold turkey):
>> 
>> Make build-arch to be a mandatory target in debian/rules files in the
>> next policy version (3.9.0, already?).  Any existing "build" targets
>> work, by necessity, correctly without having B-D-I installed, and a
>> debian/rules file could be fixed by adding one line:
>> build-arch: build
>> 
>> Buildds would still call "debian/rules build" on anything that had a
>
> Note: buildd use dpkg-buildpackage so the change needs to be done in
> dpkg-buildpackage.

Possibly as the last step. All packages could be build with a patched
dpkg-buildpackage, bugs could be filed, patches send, packages fixed
before anything has to be done to the official dpkg-buildpackage.

Although I favour breaking sources by changing the buildds as fast as
possible. If a maintainer bumps their standards version but fails to
follow it then let the source FTBFS.

>> Option 2 (features field):
>> 
>> Add a field called "Build-Features:" to debian/control and have it
>> contain a space separated list of tokens.  Define "build-arch" as a
>> recognized value.  Put that in .dsc.  As with things like this, we'd
>> potentially get stuck with it forever, but it'd be the least invasive
>> thing to do and still get buildds to use build-arch.  There'd be no
>> transition, other than getting sbuild patched.
>> 
>> We could also change build-arch into a "should" feature and warn
>> anyone who didn't support build-arch and switch over to having it as a
>> "must" once everyone did it.  It'd be easy to check for that, with
>> this.
>
> My current plan is to implement a Build-Options field but the expected use
> case for such a field are a bit too broad and it leads us to the
> discussion about how much "build customization" we should support and how
> that customization must be handled (and how we should mix choices of
> packagers, choices of user that rebuild the package, choices of the
> (derivative) distributions). Note the usage of standards-version to
> auto-enable some options is still possible even if we implement
> Build-Options.

I think Build-Options should only be for options. And the build-arch
target is not ment to be optional. Only for the transition there could
be a window of optionality. After that the target should just be a
MUST. Adding the target is trivialst and there is really no reason to
complicate the build tools by having it optional in the long run.

> The first and main customization that users and derivatives distributions
> want is related to compiler options so that they can do hardened builds or
> optimized builds without having to hand-edit each and every package.

And how is a per package Build-Options field supposed to do that? That
is clearly a per package choice and not a distribution choise. For
distribution choices the VENDOR approach from emdebian is more in line.

MfG
Goswin


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

Re: Proposal to improve package configuration upgrades

[Harald Braumann]

On Wed, 25 Feb 2009 09:28:52 +0100
Dominique Dumont  wrote:

> Of course, there's no miracle. For the merge to work automatically and
> the result to be valid, the semantic of the configuration file must be
> known by Config::Model. This is done by describing the structure and
> constraints of the configuration file in a model (hence the
> Config::Model name). 
> 
> What do you think about this ?

I don't really know Config::Model. But the main problem I have with the
current system is, that I only see diffs between the currently
installed version and the new package version. 

No what I really would like to see is the diff between the last version
I've merged and the new package version. So changes can easily be seen
(changes in defaults, new/removed parameters or just white-space
changes?) and merging would work without a conflict in most cases.
Similar to like SCMs work.

Config::Model could be useful in addition, but would it support such a
work-flow?

Cheers,
harry


signature.asc
Description: PGP signature

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Harald Braumann  writes:

> I don't really know Config::Model. But the main problem I have with the
> current system is, that I only see diffs between the currently
> installed version and the new package version. 

With ucf, you see a diff between current file (i.e. installed version
with your modifications) and the new package version. 

> No what I really would like to see is the diff between the last version
> I've merged and the new package version. 

I fail to see the differences (no pun intented) between "the last
version I've merged" and the current file ...

> So changes can easily be seen (changes in defaults, new/removed
> parameters or just white-space changes?) and merging would work
> without a conflict in most cases. 

With Config::Model:
- you would not see white space or any other formatting difference
- your customized values would be merged into the new package file
  (more accurately, loaded in Config::Model configuration tree using
  the new package *model*). Thus you would see the delta between your
  new file and the new default value. See this example of a screenshot
  [1] where the config values different from "default" are shown with
  a green arrow
- yes, merging would work mostly without conflict 

> Similar to like SCMs work.

The main difference between a SCM and Config::Model is that a SCM
works purely at text level without knowledge of the semantic of the
file under control. OTOH, Config::Model uses the semantic knowledge
provided by the model to perform the upgrade.

> Config::Model could be useful in addition, but would it support such a
> work-flow?

Provided I've understood correctly your work-flow, I'd say mostly yes...

All the best

[1] http://freshmeat.net/screenshots/69123/74589/

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: Proposal to improve package configuration upgrades

[Stefano Zacchiroli]

On Wed, Feb 25, 2009 at 05:15:52PM +0100, Harald Braumann wrote:
> No what I really would like to see is the diff between the last version
> I've merged and the new package version. So changes can easily be seen
> (changes in defaults, new/removed parameters or just white-space
> changes?) and merging would work without a conflict in most cases.
> Similar to like SCMs work.

Actually, this is something I've been pondering about for a
while. Having /etc under some VCS (as many of us, I presume, already
have by the means of etckeeper and similar tools), diff file merging
can be seriously improved.

The point is that we of course do not want neither to add the
dependency on some VCS into dpkg, nor to have dpkg making the choice
of which VCS.

So, it looks like that what we need is a pluggable mechanism into
dpkg, which dpkg will invoke when configuration file change conflicts
are encountered. A usual /etc/*.d/ place where to stick some script
with a well-defined API or something like that ...

Would something like that be thinkable of or am I totally on crack?

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: Proposal to improve package configuration upgrades

[Manoj Srivastava]

On Wed, Feb 25 2009, Dominique Dumont wrote:


> So I was thinking that this is a typical case where the upgrade could
> be smoothly handled by Config::Model. 

> Of course, there's no miracle. For the merge to work automatically and
> the result to be valid, the semantic of the configuration file must be
> known by Config::Model. This is done by describing the structure and
> constraints of the configuration file in a model (hence the
> Config::Model name). 

Do we have an idea of how many configuration files can be
 described in terms of such a model? (I generally tend to code
 configuration files in  a scripting language if the code is written in a
 scripting language).

While I suspect a large number of our configuration files are
 simple, I fear that a significan chunk of them are fairly complex; and
 possibly not amenable to being described in terms of a non-trivial
 model. 

manoj
-- 
Drop the vase and it will become a Ming of the past. The Adventurer
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Forthcoming changes in kernel-package

[Manoj Srivastava]

On Wed, Feb 25 2009, Goswin von Brederlow wrote:

> Manoj Srivastava  writes:
>
>> On Wed, Feb 18 2009, Theodore Tso wrote:
>>
>>> On Mon, Feb 09, 2009 at 12:14:49AM -0600, Manoj Srivastava wrote:
 Hi,
 
 This is a heads up for a major change in kernel-package, the
  tool to create user packaged kernel images and headers; which will
  make the make-kpkg script far less error prone, and far more
  deterministic.
 
a. Every invocation of kernel-package will remove ./debian directory,
   and regenerate the changelog and control files. This will get rid
   of any remaining issues with the ./debian directory getting out of
   sync with the kernel sources; and will allow people to make small
   tweaks to the kernel sources and have  make-kpkg reflect those
   changes.
>>>
>>> Is there going to be a way for people to replace the changelog with
>>> one that contains useful information in that case?  I've been doing
>>> this by doing a make-kpkg configure and then editing the
>>> debian/changelog file afterwards...>
>>
>> I have a plan for something like this, though currently there is
>>  no code. I was thinking of doing an "overlay" for ./debian, kind of
>>  like what ikiwiki and request-tracker do; so /usr/share/kernel-package
>>  contain the information that goes into ./debian; but if there is a user
>>  specified overlay, then files present in the overlay are used instead
>>  (files not in the overlay dir still come from the default location).
>
> It might be nice to have a changelog.d/ directory in the source with
> sniplets for the debian/changelog. All files would be cated together
> and used as the text for the current changelog entry.
>
> This would have two use cases:
>
> 1) Patch packages can drop a file in there (when the user applies the
>patch) saying what got applied.
>
> 2) Users can add their own files there detailing what they changed.
>E.g. '  * added CONFIG_SCSI_DISK=y'
>
> As I write this I notice that (2) doesn't quite work. For my manual
> entries I would like to specify a version. E.g. in 2.6.26-1 I added
> CONFIG_SCSI_DISK=y, in 2.6.26-2 I added CONFIG_SCSI_CDROM=y and in
> 2.6.26-3 I removed it again.
>
> But maybe that goes too far. Just being able to add to the current
> entry would be a good start already.

Both these options are far more complex than anything I had
 planned on doing; since while they are laudable goals, the effort
 required seems to be kind of high based on the return -- espescially
 now that the official kernels are not built with kernel-package; the
 audience of kernel-package created images is lower.

However, I'll be happy to incorporate any patches people submit
 to get this feature into kernel-package.

manoj
-- 
People think love is an emotion.  Love is good sense. Ken Kesey
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Stefano Zacchiroli  writes:
> Actually, this is something I've been pondering about for a
> while. Having /etc under some VCS (as many of us, I presume, already
> have by the means of etckeeper and similar tools), diff file merging
> can be seriously improved.

I tend to disagree.

>From a user point of view, you will get the same diff output whether a
SCM performs the diff or ucf performs the diff.

So your proposal will probably not help my mother-in-law to upgrade
the packages on her system ;-)

For seasoned sys admin, storing /etc/ files under a SCM will give a
much better roll-back capability if a config is screwed up by a manual
merge.

All the best

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: DebConf10 to take place in New York City, USA

[Vincent Bernat]

OoO Pendant  le temps de midi  du mercredi 25 février  2009, vers 12:45,
martin f krafft  disait :

> In eleven years of DebConf history, this will be the first time
> that the Debian developer conference takes place in the United
> States of America, which had been avoided in previous years due to
> visa and other immigration issues. The NYC team had addressed those
> issues from the very start and submitted a very convincing bid.

Out of curiosity, how those issues will be handled?
-- 
Localise input and output in subroutines.
- The Elements of Programming Style (Kernighan & Plauger)


pgp6Q5VnhTSHG.pgp
Description: PGP signature

Re: Proposal to improve package configuration upgrades

[Dominique Dumont]

Manoj Srivastava  writes:

>  Do we have an idea of how many configuration files can be
>  described in terms of such a model? 

I do not know how many. I'd say most of the files that do not use
variables. For instance exim config is out. I do not know for Apache
config files. 

So far, I've created models for OpenSsh [1] (quite easy) and Xorg [2]
(more challenging and the model is still not complete)

You will be able to try yourself OpenSsh editor as soon as
libconfig-model-openssh-perl is accepted by ftp-masters.

>  (I generally tend to code configuration files in a scripting
>  language if the code is written in a scripting language).

Uh ?

> While I suspect a large number of our configuration files are
>  simple, I fear that a significan chunk of them are fairly complex; and
>  possibly not amenable to being described in terms of a non-trivial
>  model. 

Agreed. We may need to use hybrid solution for the most complex
configuration files. Something like exim-like template + Config::Model
for the template variables.

All the best

[1] 
http://cpansearch.perl.org/src/DDUMONT/Config-Model-OpenSsh-1.203/lib/Config/Model/models/
[2] 
http://cpansearch.perl.org/src/DDUMONT/Config-Model-Xorg-0.513/lib/Config/Model/models/

-- 
Dominique Dumont 
"Delivering successful solutions requires giving people what they
need, not what they want." Kurt Bittner

irc:
  domidumont at irc.freenode.net
  ddumont at irc.debian.org


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

Re: Proposal to improve package configuration upgrades

[Manoj Srivastava]

On Wed, Feb 25 2009, Dominique Dumont wrote:

> Harald Braumann  writes:
>
>> I don't really know Config::Model. But the main problem I have with the
>> current system is, that I only see diffs between the currently
>> installed version and the new package version. 
>
> With ucf, you see a diff between current file (i.e. installed version
> with your modifications) and the new package version. 
>
>> No what I really would like to see is the diff between the last version
>> I've merged and the new package version. 
>
> I fail to see the differences (no pun intented) between "the last
> version I've merged" and the current file ...

Well. If the maintainer so desires, ucf does have this to say:
,[  Manual page ucf(1) ]
| --three-way
|This turns on the option, during installation, for the user to
|be offered a chance to see a merge of the changes between old
|maintainer version and the new maintainer version into the
|local copy of the configuration file. If the user likes what
|they see, they can ask to have these changes merged in. This
|allows one to get new upstream changes merged in even while
|retaining local modifications to the configuration file.  This
|is accomplished by taking the configuration file and stashing
|it in a cache area during registration, and using diff3 during
|the install (the stashed file name is a munged version of the
|full path of the configuration file to avoid name space
|clashes).  Note This option appeared in Version 0.8 of ucf,
|which was the first version released into unstable and
|ultimately Sarge.  The version of ucf in woody does not contain
|this option.
`


Seems like this is what is desired; however, the reason this is
 not on by default is that some configuration files can be huge, and ucf
 did not want to stash away _all_ the configuration files handled by it
 into /var.  The exectation was that most developers with smallish
 configuration files would use --three-way, but that expectation was
 unfounded.

manoj
-- 
In the stairway of life, you'd best take the elevator.
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: DebConf10 to take place in New York City, USA

[Cyril Brulebois]

Vincent Bernat  (25/02/2009):
> Out of curiosity, how those issues will be handled?

Obvi: Covert channels.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: DebConf10 to take place in New York City, USA

[Jimmy Kaplowitz]

(Please CC me on responses - I'm not subscribed to debian-devel currently.)

On Wed, Feb 25, 2009 at 06:55:22PM +0100, Vincent Bernat wrote:
> OoO Pendant  le temps de midi  du mercredi 25 février  2009, vers 12:45,
> martin f krafft  disait :
> 
> > In eleven years of DebConf history, this will be the first time
> > that the Debian developer conference takes place in the United
> > States of America, which had been avoided in previous years due to
> > visa and other immigration issues. The NYC team had addressed those
> > issues from the very start and submitted a very convincing bid.
> 
> Out of curiosity, how those issues will be handled?

Martin may have left the wrong impression. We don't have the issues fully
solved, and of course can no more make guarantees that there won't be visa or
border hassles than the Mexico local team was able to for DebConf6 (the first
year where visas became an issue). What he meant was that we've started
discussing, researching, and explaining the issues; building connections with
people who can help us navigate the bureaucracy and figure out the real truth;
and planning ways to reduce the hassles and ease the paperwork of getting any
necessary visa and then entering the US.

We have some information from during the bid process here:
http://wiki.debconf.org/wiki/DebConf10/NewYork/VisaAndBorderIssues

The Boston bid, which also would have been in the US, has a few additional 
thoughts on their bid page:
http://wiki.debconf.org/wiki/DebConf10/Boston#Visa.2FImmigration.2FLocale_Issues

Further, we're definitely going to be giving people invitation letters and
other advice to make sure they present themselves in the best (accurate) light
they can to the visa or border officials, as well as separate exaggeration from
fact with regard to border search and other privacy concerns so that people can
make rational decisions based on reality instead of sensationalism. More
details will be provided at the DebConf10 presentation in Caceres at DebConf9,
if not sooner.

- Jimmy Kaplowitz
ji...@debian.org


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

Re: DebConf10 to take place in New York City, USA

[Patrick Ouellette]

With respect to visa issues, early application is always a good ideal.
I work for a US government agency that hosts international guests for
training three to four times a year.  We usually don't know who is going
to show up until we actually see the people arrive on the first day of
training.  This is usually due to trying to rush the visa process.

If someone *thinks* they want to attend DebConf10, I suggest they commit
to attending and apply for a visa sooner rather than later.  It just makes
things easier.  This advice applies anytime a visa is needed to visit any
country, not just the USA.

Pat

-- 

Patrick Ouellette p...@flying-gecko.net
ne4po (at) arrl (dot) net Amateur Radio: NE4PO 
"Crank the amp to 11, this needs more cowbell - and a llama wouldn't hurt 
either"
"Your arguments are an odd mix of overly optimistic on one side and overly 
pessimistic on the other"


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

Re: DebConf10 to take place in New York City, USA

[Victor H De la Luz]

On Wed, Feb 25, 2009 at 5:08 PM, Patrick Ouellette  wrote:
>
> With respect to visa issues, early application is always a good ideal.
> I work for a US government agency that hosts international guests for
> training three to four times a year.  We usually don't know who is going
> to show up until we actually see the people arrive on the first day of
> training.  This is usually due to trying to rush the visa process.
>
> If someone *thinks* they want to attend DebConf10, I suggest they commit
> to attending and apply for a visa sooner rather than later.  It just makes
> things easier.  This advice applies anytime a visa is needed to visit any
> country, not just the USA.
>
> Pat
>
> --
>
> Patrick Ouellette                 p...@flying-gecko.net
> ne4po (at) arrl (dot) net         Amateur Radio: NE4PO
> "Crank the amp to 11, this needs more cowbell - and a llama wouldn't hurt 
> either"
> "Your arguments are an odd mix of overly optimistic on one side and overly
> pessimistic on the other"
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
>
>

And if you are rejected, then always exists the mexican "coyotes" to
cross the border (is a joke but is real)...

-- 
ItZtLi


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

Re: Proposal to improve package configuration upgrades

[Manoj Srivastava]

On Wed, Feb 25 2009, Dominique Dumont wrote:

> Manoj Srivastava  writes:
>
>>  (I generally tend to code configuration files in a scripting
>>  language if the code is written in a scripting language).
>
> Uh ?

/etc/kernel-pkg.conf, for example, is in Perl. You may define
 functions, variables, closures (given enough make-kpkg-fu) and have it
 all work.

>> While I suspect a large number of our configuration files are
>>  simple, I fear that a significan chunk of them are fairly complex; and
>>  possibly not amenable to being described in terms of a non-trivial
>>  model. 
>
> Agreed. We may need to use hybrid solution for the most complex
> configuration files. Something like exim-like template + Config::Model
> for the template variables.

I dare you to try one for sendmail.cf. (and yes,  often don't
 use the new fangled m4 stuff)

manoj
-- 
"No one can forbid us the future." Inscription on the base of Paris's
monument to Leon Gambetta
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: DebConf10 to take place in New York City, USA

[AtomCell]

hi all,
if you need a visa to the USA, just ask the NY team to send you an
invitation (if possible from an association).
the invitation should be addressed to your company (so ask your company to
support you).
ask also the NY team to send a copy of this invitation to your local US
embassy.
kind regards
hatem


On Wed, Feb 25, 2009 at 9:29 PM, Victor H De la Luz wrote:

> On Wed, Feb 25, 2009 at 5:08 PM, Patrick Ouellette 
> wrote:
> >
> > With respect to visa issues, early application is always a good ideal.
> > I work for a US government agency that hosts international guests for
> > training three to four times a year.  We usually don't know who is going
> > to show up until we actually see the people arrive on the first day of
> > training.  This is usually due to trying to rush the visa process.
> >
> > If someone *thinks* they want to attend DebConf10, I suggest they commit
> > to attending and apply for a visa sooner rather than later.  It just
> makes
> > things easier.  This advice applies anytime a visa is needed to visit any
> > country, not just the USA.
> >
> > Pat
> >
> > --
> >
> > Patrick Ouellette p...@flying-gecko.net
> > ne4po (at) arrl (dot) net Amateur Radio: NE4PO
> > "Crank the amp to 11, this needs more cowbell - and a llama wouldn't hurt
> either"
> > "Your arguments are an odd mix of overly optimistic on one side and
> overly
> > pessimistic on the other"
> >
> >
> > --
> > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> >
> >
>
> And if you are rejected, then always exists the mexican "coyotes" to
> cross the border (is a joke but is real)...
>
> --
> ItZtLi
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
>
>

Accelerated video cards and non-free firmware

[Daniel Dickinson]

Hi,

I'm looking at getting a video card, and I want to know what video card
that has 3D acceleration to get.  Normally I'd ask on -users but as the
subject says I want to know what video cards will still have
acceleration when the non-free firmware is removed from the kernel,
which is supposed to happen for squeeze.

I had heard that the ATI cards, which would normally be my first
choice, have non-free firmware in the driver, which may be removed.  Is
this true, and if so what accelerated cards will have have acceleration
once non-free firmware is removed.

I can delay purchase (easily), if the answer to this is not yet known.

Thanks,

Daniel

P.S. I *am* subscribed to the list but would appreciated CC's anyway.

-- 
And that's my crabbing done for the day.  Got it out of the way early, 
now I have the rest of the afternoon to sniff fragrant tea-roses or 
strangle cute bunnies or something.   -- Michael Devore
GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C  http://gnupg.org


signature.asc
Description: PGP signature

Re: Accelerated video cards and non-free firmware

[William Pitcock]

On Wed, 2009-02-25 at 16:28 -0500, Daniel Dickinson wrote:
> Hi,
> 
> I'm looking at getting a video card, and I want to know what video card
> that has 3D acceleration to get.  Normally I'd ask on -users but as the
> subject says I want to know what video cards will still have
> acceleration when the non-free firmware is removed from the kernel,
> which is supposed to happen for squeeze.
> 
> I had heard that the ATI cards, which would normally be my first
> choice, have non-free firmware in the driver, which may be removed.  Is
> this true, and if so what accelerated cards will have have acceleration
> once non-free firmware is removed.
> 
> I can delay purchase (easily), if the answer to this is not yet known.

The kernel team has separated out the radeon firmware as part of the
firmware-nonfree package in non-free. So, if you run with non-free
enabled and install the firmware-nonfree package, radeon cards will
continue to behave as expected.

William


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

Bug#517141: ITP: pysieved -- Python-based Managesieve server

[Christoph Haas]

Package: wnpp
Severity: wishlist
Owner: Christoph Haas 

* Package name: pysieved
  Version : 1.0
  Upstream Author : Neale Pickett 
* URL : http://woozle.org/~neale/src/pysieved/
* License : GPL
  Programming Lang: Python
  Description : Python-based Managesieve server

This is a GPL managesieve server. It uses a plug-in architecture to
support different authentication, homedir lookup, and storage back-ends.

-- System Information:
Debian Release: 5.0
  APT prefers unstable
  APT policy: (900, 'unstable')
Architecture: i386 (i686)



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

Re: Should 32-bit apps work with a 64-bit kernel?

[Roger Leigh]

On Wed, Feb 25, 2009 at 04:16:53PM +0100, Goswin von Brederlow wrote:

> Maybe we need a mass bug filing for programs not using 64bit file
> offsets.

I think that would be appropriate.  At this point, I can't see a
valid reason for any package to not have LFS enabled.

> Anyone up for hacking libc to always fail on the 32bit wrappers for
> seek, stat, ...?

Well, breaking old code might be considered bad.  This would break
*all* binaries using the old 32-bit ABI.

Personally, I would prefer the glibc headers to just set the LFS
macros to the 64 bit versions by default, so that rather than
taking extra steps to enable LFS, LFS would be the default and you
would then need to take extra steps to disable it.

i.e. just default _FILE_OFFSET_BITS to 64 rather than 32.

If someone really, really, wanted 32 bit file offsets, they could
just set it back to 32 again.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: handling group membership in and outside d-i

[Roger Leigh]

On Tue, Feb 24, 2009 at 02:11:36PM +, Jon Dowland wrote:

> Finally can anyone with a deeper insight of the issues
> explain whether or not the frustrating "existing logins
> don't inherit new groups" behaviour is fixable, or is that
> deeply rooted in UNIX tradition?

The limitation is due to the way in which the groups a *process*
(not user) belongs to.  When you log in, login/sshd/xdm/schroot
or whatever process is controlling the process will call
initgroups(3) to read the group database for the user in question,
which internally calls setgroups(2) to add all of the GIDs in
question to the process.  It will then call setgid(2) and setuid(2)
to drop privileges and then typically exec the login shell/command/
session as appropriate.

Setting the group list with setgroups(2) requires the CAP_SETGID
capability (i.e. root in almost all cases).  Because root
privileges are dropped, the group list is fixed and subsequently
inherited by all child processes.  This is why you need to log
out and back in again, because it's only when you log in you
can add the new group to the group list of the parent of your
login session.

> (I note that it seems
> HAL makes an on-invocation group check for suspend so
> adding a user to the powerdev group and attempting a
> suspend from a pre-logged in session works)

HAL is just querying the group database directly.  Any process can of
course do this.  But it's asking a different question, namely:
what groups is this user a member of in the group database.  All of
the system calls checking group membership are checking the process'
group list, not the group database.  This is because internally the
group list is just a list of integer GIDs, so it's fast and does not
require any database lookups (which are all done in userspace by
libnss*).


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: xcdroast does no longer work with wodim: Who to blame?

[Ben Hutchings]

On Wed, 2009-02-25 at 09:28 +0100, Joerg Schilling wrote:
> >xcdroast is looking for cdrecord, which does no longer exist in Debian 
> >Sid (apparently). And wodim does no longer provide a symlink as cdrecord 
> >or something (apparently).
> 
> >So: xcdroast does no longer work. Who is to blame (Bug entry): xcdroats 
> >or wodim?
> 
> You need to blame the people who are responsible for removing cdrecord
> and who started to include a fork (wodim) that cannot be legally distributed.

You're the one who distributes a legally dubious mixture of code covered
by GPLv2 and CDDL.

> Just add cdrecord from:
> 
> ftp://ftp.berlios.de/pub/cdrecord/alpha/
> 
> and you get a legal and working system.

If by "working" you mean "complaining about every way that Linux differs
from Schilix".  How is Schilix going, by the way?  Do you have a second
user yet?

Ben.



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

Re: Should 32-bit apps work with a 64-bit kernel?

[Steve Langasek]

On Wed, Feb 25, 2009 at 10:52:30PM +, Roger Leigh wrote:

> Personally, I would prefer the glibc headers to just set the LFS
> macros to the 64 bit versions by default, so that rather than
> taking extra steps to enable LFS, LFS would be the default and you
> would then need to take extra steps to disable it.

> i.e. just default _FILE_OFFSET_BITS to 64 rather than 32.

> If someone really, really, wanted 32 bit file offsets, they could
> just set it back to 32 again.

There are libraries in existence that (unfortunately) expose libc types that
are sensitive to _FILE_OFFSET_BITS as part of their ABIs.  Making a change
like this without first identifying and handling those libraries would cause
a mess.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


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

Bug#517165: ITP: phyml -- Phylogenetic estimation using Maximum Likelihood

[Charles Plessy]

Package: wnpp
Severity: wishlist
Owner: Charles Plessy 

Hello everybody,

I intend to package Phyml, as it is necessary for upgrading SeaView to version
4.0.  As usual, the source of the PDF manual was omitted from the Upstream
tarball. I am working on this issue.

Have a nice day,

-- Charles

Source: phyml
Section: science
Priority: optional
Maintainer: Debian-Med Packaging Team 

DM-Upload-Allowed: yes
Uploaders: Charles Plessy 
Build-Depends: debhelper (>= 7), automake, autoconf
Standards-Version: 3.8.0
Homepage: http://www.atgc-montpellier.fr/phyml

Package: phyml
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Phylogenetic estimation using Maximum Likelihood
 PhyML is a software that estimates maximum likelihood phylogenies from
 alignments of nucleotide or amino acid sequences. It provides a wide range of
 options that were designed to facilitate standard phylogenetic analyses. The
 main strengths of PhyML lies in the large number of substitution models coupled
 to various options to search the space of phylogenetic tree topologies, going
 from very fast and efficient methods to slower but generally more accurate
 approaches. It also implements two methods to evaluate branch supports in a
 sound statistical framework (the non-parametric bootstrap and the approximate
 likelihood ratio test).
 .
 PhyML was designed to process moderate to large data sets. In theory,
 alignments with up to 4,000 sequences 2,000,000 character-long can analyzed. In
 practice however, the amount of memory required to process a data set is
 proportional of the product of the number of sequences by their length. Hence,
 a large number of sequences can only be processed provided that they are short.
 Also, PhyML can handle long sequences provided that they are not numerous. With
 most standard personal computers, the “comfort zone” for PhyML generally lies
 around 3 to 500 sequences less than 2,000 character long.


Upstream-Name: PhyML
Upstream-Maintainer:
 Stephane Guindon 
 Department of Statistics. University of Auckland. New Zealand
 Universite Montpellier II - CNRS UMR 5506. LIRMM. Montpellier France.
 .
 Olivier Gascuel 
 Universite Montpellier II - CNRS UMR 5506. LIRMM. Montpellier France.
 .
 Jean-Francois Dufayard 
 Universite Montpellier II - CNRS UMR 5506. LIRMM. Montpellier France.
Upstream-Source: http://phyml.googlecode.com/files/phyml_3December2008.tar.gz

Files: *
Copyright: Stephane Guindon 
   Olivier Gascuel 
   Jean-Francois Dufayard 
   Wim Hodrijk 
   Franck Lethiec 
Licence: GPL-2+



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

Re: handling group membership in and outside d-i

[Peter Palfrader]

On Wed, 25 Feb 2009, Roger Leigh wrote:

> HAL is just querying the group database directly.  Any process can of
> course do this.  But it's asking a different question, namely:
> what groups is this user a member of in the group database.

This is of course broken.  It breaks granting console users access to
the netdev or powerdev groups through pam_groups, which is really really
annoying when you get your users from say ldap.

-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


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

FORM MISS JOY EMMA.

[MissJoy Emma]

Hello,

How are you? i hope all is well with you, i hope you may not know me, and
idon't know who you are, My Name is Miss Joy Emma., i am just broswing
now i just saw your Email it seams like some thing touches me all over my body,
i started having some feelings in me which i have
never experience in me before, so i became interested in you, l will also like
to know you the more,and l want you to send an email, so l can give you my
picture for you to know whom l am.

I believe we can move from here! i have good things to disclose to you ,but
after knowing each other more better.
I am waiting for your mail to my email address above.

(Remember the distance or colour does not matter but love trust,honesty
,understanding matters alot in life)
Miss Joy Emma.

-
Find the home of your dreams with eircom net property
Sign up for email alerts now http://www.eircom.net/propertyalerts



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