Re: Some bits of experience gained from handling upgrade-reports.

[Stephen Birch]

Bill

Just out of curiosity, when testing the upgrade procedure how do you
select the mix of packages installed prior to the upgrade?

Steve


Bill Allombert([EMAIL PROTECTED])@2005-06-09 22:53:
> Hello Debian developers,
> 
> [Please store this mail in a safe place and read it when you have
> recovered from the release party.]
> 
> During the few weeks before sarge release, I have tried to reproduce the
> upgrade problems reported to upgrade-reports [1]. I reached the following
> conclusions:
> 
> 1) Circular dependencies are cause of lot of breakage. Worse, the
> problem that plague the woody to sarge upgrade are not circular
> dependency in sarge but in woody. It means that if we want a nice etch
> to etch+1 transition, we need to try to get rid of them now.
> Usually it can be achieved by spliting packages to isolate the
> dependency.
> 
> 2) apt and aptitude reliance on C++ make them quite painful to upgrade
> before doing the dist-upgrade due to C++ ABI changes. This issue is
> likely to be the same during the sarge to etch upgrade, so we should not
> rely on the user installing the latest apt or aptitude version before 
> upgrading.
> 
> 3) There are far too many packages that mess with conffiles causing
> useless dpkg conffiles handling. We should strive to do better in etch.
> Never move a conffile in a maintainer script without checking the md5sum
> against the stable version of the conffile. If it match, remove it
> instead instead of moving it. It is the same if you use ucf instead.
> 
> 4) Upgrade-test need to be done continuously because there is not enough
> time during the freeze to fix all the problems. Another conclusion is
> that this need to be done automatically. This could be done roughly
> the same way as a buildd work, but would generate a 'upgrade
> certificate' instead of a package. Such test will also find the 
> packages that cannot be installed due to maintainers scripts breakage.
> 
> Unfortunately I do not have access to suitable hardware anymore to do
> such upgrade test, so help with this project would be more than
> welcome. Some kind of virtualisation technology like user-mode-linux
> might be required (that is what I was using).
> 
> As a conclusion, I am not very happy with the state of woody to sarge
> upgrade. I expect around 30% of users will suffer serious breakage that 
> could have been avoided. This statistic assume smart users. We should do
> better for etch.
> 
> Acknowledgement:
> I would like to thanks Frans Pop and Steve Langasek for bearing with me
> while I was inflating the release notes changes and the RC bugs count and
> for generally be helpful at trying to solve upgrade issue.
> 
> I would also like to thanks people that took the trouble to send
> upgrade-reports.
> 



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

Re: C++ ABI change -- freezing unstable for new C++ library packages

[Steve Langasek]

On Thu, Jun 09, 2005 at 09:04:20PM -0500, Adam Majer wrote:
> Santiago Vila wrote:

> >On Thu, 9 Jun 2005, Adam Majer wrote:

> >>Also, the testing seems to be now unfrozen except for base. Does the
> >>base freeze have anything to do with the new C++ ABI?

> >No, it's more a leftover of the freeze process. I asked Steve today
> >about this. He says base packages will be unfrozen again in a few days.

> Ok, thanks! I just wander why weren't all packages unfrozen at once.
> Something to do with too much new stuff entering Etch at once?

We're leaning towards possibly keeping udeb-generating packages frozen
during etch still because they require manual intervention for syncing udebs
into testing; this means separating the source packages that create udebs
(which as a class were frozen later) from the rest of the base packages.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: http://www.golden-gryphon.com/software/security/selinux.xhtml

[Manoj Srivastava]

On Fri, 10 Jun 2005 00:20:31 +0100, Luke Kenneth Casson Leighton <[EMAIL 
PROTECTED]> said: 

> On Thu, Jun 09, 2005 at 11:42:00PM +0100, antoine wrote:
>> On Thu, 2005-06-09 at 20:20 +0100, Luke Kenneth Casson Leighton wrote:
>> > manoj, hi,
>> > 
>> > i am delighted to see the above web page re: selinux.
>> Err?

>  never seen it before :)

>> > 
>> > i notice you mention that there is an effort underway to make a
>> > uml-selinux.
>> > 
>> > perhaps i should mention that it is utterly trivial to set up a
>> > xen system with a guest domain running pretty much any kind of
>> > kernel - including selinux enabled ones.

>> We have been running selinux guest kernels in uml for years, that
>> was

>  _great_.

>  hm - the above page gives the impression that it hasn't been:

> "There also has been an interest in creating an
> 
> SELinux UML, since it allows for rapid testing of policies,
> and packages, and to observe the reaction of the machine to
> threats and other stimuli. However, it has been tedious,
> traditionally, to create a UML that can be run in enforcing
> mode. A recipe for doing so has been created..."

--^^

  Recipe \Rec"i*pe\ (r[e^]s"[i^]*p[-e]), n.; pl. {Recipes}
 (r[e^]s"[i^]*p[=e]z). [L., imperative of recipere to take
 back, take in, receive. See {Receive}.]

 4. a method or procedure for accomplishing a goal by defined
steps; -- implying a high probability of achieving the
goal; as, a recipe for success. Also used in a negative
sense, as, a recipe for disaster.

>> not the issue here,

>> or are you just doing xen advocacy?

>  i was under the impression, from the above, that somehow debian
>  cannot run selinux/uml.

If it were not possible to do so, a recipe could also not have
 been created.


>  hm.  sorry about that - the above URL gives an impression other
>  than that.

Onnly if you
  a) do not understand the meaning of the word recipe, and
  b) do not follow the link down to
 http://www.golden-gryphon.com/software/security/selinux-uml.xhtml


manoj
-- 
Calling you stupid is an insult to stupid people! Wanda, "A Fish
Called Wanda"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: libselinux1 - required

[Manoj Srivastava]

On Wed, 8 Jun 2005 23:08:08 +1200, Nigel Jones <[EMAIL PROTECTED]> said: 

> On 08/06/05, Petter Reinholdtsen <[EMAIL PROTECTED]> wrote:
>> [Nigel Jones]
>> > if "coreutils" is made absolutely dependant on libselinux1, then
>> > the user gets no choice...
>> 
>> One think is depending on the library, another is actually using
>> selinux.  Your objection to use selinux might have some merit, but
>> your objection to have a package depend on libselinux1 does not.
>> In
> I guess it's distrust of thee who make it (please don't start a
> flame war, it's personal opinion, you must accept that, i know it
> gets looked at by many eyes, but i still don't like the idea.  No
> matter how hard you look, it's easy enough to slip a backdoor or
> something in, and in the kernel, well thats not good).  - I don't
> have distrust for common programs that may have had a Government
> developer or two work on it, but when the majority is made by a Govt
> department, thats when I loose the trust.

You may have already lost, then, since NSA code is now in the
 kernel itself, and LSM is compiled in as well.

> Hmmm, I can see your point, BUT, if a user is not going to use
> selinux at all, then what is the use of downloading extra
> dependencies that you don't need.  I thought that a feature of APT
> was that it makes you only download the libraries that you need/use.

Since the idea is to make even dpkg link with libselinux, this
 may be moot.

> Anyway, just my two cents.  Personally, I'm going to continue to
> build my own kernels, just be an annoyance to have to build my own
> coreutils etc to make sure code that I don't need isn't there.

dpkg, coreutils, ssh, cron, logrotate, pam, sysvinit. 

> (Because really, it is a bit hard on the Dial Up users (not really
> complaining, just saying that downloading stuff that your never
> going to use is a bit of a pain)).

The binaries you use are linked with that library, so it is
 not as if you can get by without libselinux1. It is not large, but to
 get areound that 196k you'll have to compile a boat load of
 packages -- and download far more in terms of source code.

I am not sure you are really making any sense here.

manoj
-- 
Working with Julie Andrews is like getting hit over the head with a
valentine. Christopher Plummer
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


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

Re: namespace conflict != package Conflict?

[Adam Majer]

Sebastian Kuzminsky wrote:

>Hi folks, I have a noob question for you.  I maintain the Cogito package
>(my first), and it wants to install an executable as /usr/bin/git.  The
>GNU Interactive Tools package (git) also wants to install an executable
>as /usr/bin/git.  To avoid this conflict I made cogito Conflict with git.
>
>  
>
Of course this is *seriously* wrong. Why are you preventing people from
using git and cogito together?

>I have been told by Jurij Smakov that this is "seriously wrong", and
>I'm asking for help here.  What's the proper way to handle this situation?
>
>The cogito /usr/bin/git is a tiny little helper script hardly worth its
>inode, but it's in the upstream package and I dont want to remove it or
>rename it.
>  
>
rename /usr/bin/git to /usr/bin/cogito-git or whatever. It is not that hard.

- Adam


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

Re: namespace conflict != package Conflict?

[Ben Finney]

On 09-Jun-2005, Sebastian Kuzminsky wrote:
> The cogito /usr/bin/git is a tiny little helper script hardly worth
> its inode, but it's in the upstream package and I dont want to
> remove it or rename it.

Care to expand on why you don't wish to rename or remove the
conflicting Cogito file? It may help those trying to form a solution.

-- 
 \  "I busted a mirror and got seven years bad luck, but my lawyer |
  `\ thinks he can get me five."  -- Steven Wright |
_o__)  |
Ben Finney <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

Re: Keysigning without physically meeting ... thoughts?

[Gunnar Wolf]

Ron Johnson dijo [Wed, Jun 01, 2005 at 05:48:46AM -0500]:
> > A while ago, in an IRC discussion, it was revealed that a notary in the
> > US doesn't mean as much as it does in Europe.
> > 
> > AIUI, in the US, a notary is just some extra title a lot of secretaries
> > have, so that they can make some documents more official.
> 
> That's wrong.  You take a non-trivial test, and be background checked.
> 
> The secretaries you are referring to are 99.9% of the time in law
> offices and title-transfer companies.

Well, the main point behind this still stands: In the US, notaries are
quite common and cheap. In Mexico, they serve +- the same role as
there (gathered from your other replies in this thread and from what I
know), but I don't think a single notary in this city would certify
that I am the guy that appears in my government-issued ID without
charging me some US$200 first, at the very least. Most people in this
country don't make more than US$400 a month, so notaries are an
unaffordable luxury.

...And that for simple transactions. My father bought his house a
couple of years ago. IIRC, the notary's fee for the transaction was
closer to US$1500. 

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5623-0154
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: hijacking libhtml-mason-perl

[Joshua Kwan]

Hi Eric,

Eric Dorland wrote:
> I'm pretty interested in this package as well, and I'm willing to
> sponsor you.

I'm currently interning together with Charles, and it will probably be a
fair bit more convenient for me to sponsor him instead. Thanks for
offering, though.

-- 
Joshua Kwan


signature.asc
Description: OpenPGP digital signature

Re: Debian 3.1r0 CD/DVD image problem

[Kenneth Stailey]

--- Anonymous <[EMAIL PROTECTED]> wrote:

> >> Can't the remainder of the third DVD be filled up with multimedia
> >> propoganda files or other fluff?

> > Or 3vil planz for world domination?

> If all elve fails fill it up with pr0n. ;)

We have to uphold the maxim: Data Expands To Fill All Existing Storage!


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

Re: http://www.golden-gryphon.com/software/security/selinux.xhtml

[antoine]

>  i was under the impression, from the above, that somehow
>  debian cannot run selinux/uml.
I haven't tried selinux on my debian uml instances.

>  i was therefore recommending an alternative that is, by
>  comparison, just... okay: xen takes a source code download,
>  two kernel compiles, create a guest-machine-config, and
>  a guest-machine-install (unless like me you're prepared to
>  copy the drive images of an existing machine and hack it into
>  submission from there :) and you're done, up, running.
> 
>  by contrast: i once installed uml...
Example with Gentoo-SELinux:
* make a Gentoo SELinux filesystem (loopback mounted + chroot)
 and add /dev/ubd devices (uml block devices) adjust fstab and inittab
* build a kernel (make ARCH=um vmlinux)
* run it:
 ./vmlinux mem=512 ubd0=./root_fs root=/dev/ubda selinux=1 enforcing=0
* selinux relabel
(optional: reboot guest in enforcing mode, add skas to host, etc)

It cannot be easier than this, can it?

>  in theory, it can be done (and i haven't been mad enough to switch on
>  selinux in the xen master domain yet...)
It is the most critical system to secure: One ring to rule them all...

>  management of xen (communication between domains) is done
>  via a python-based HTTP web server (twisted python) running on a high
>  port number.
I'm not here to have a go at xen/python (or start a holy war) but I
prefer the way uml is managed: like a normal process, which means you
can apply normal tools to control it (ie: selinux if you want to). Any
linux system can run uml instances without a single reboot (albeit
without skas). On the other hand, uml is linux only, xen virtualises the
whole system and has some nice features (live migration particularly)

> the above URL gives an impression other than that.
When it comes to performance benchmarks (that's part of my job) it is
very difficult to compare accurately unless you know all the products
very well. If you are referring to this benchmark:
http://www.cl.cam.ac.uk/Research/SRG/netos/xen/performance.html
* It uses kernel 2.4.22 which is *very* old.
* I/O is the main difference but it does not mention what method was
used for the filesystems backing store. There are many tricks that can
drastically improve performance if you know what you are doing (even for
VMWare). Xen generally uses raw disks whereas uml generally uses files
as disk images, this overhead alone will create a huge difference in
performance. I believe Xen can probably achieve better I/O performance
than uml, but not by the margins shown above.
* It was authored by people working on Xen, I am not trying to discredit
the results in any way, just pointing out that they clearly knew Xen
better than the others...

Now, don't get me started on database performance...

Cheers
Antoine


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

Re: C++ ABI change -- freezing unstable for new C++ library packages

[Adam Majer]

Santiago Vila wrote:

>On Thu, 9 Jun 2005, Adam Majer wrote:
>
>  
>
>>Also, the testing seems to be now unfrozen except for base. Does the
>>base freeze have anything to do with the new C++ ABI?
>>
>>
>
>No, it's more a leftover of the freeze process. I asked Steve today
>about this. He says base packages will be unfrozen again in a few days.
>  
>

Ok, thanks! I just wander why weren't all packages unfrozen at once.
Something to do with too much new stuff entering Etch at once?

- Adam


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

Re: kernel security bug #307900

[Adam Majer]

Olaf van der Spek wrote:

> > woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
> condition.
>
> Will this be fixed for Woody?
> I thought the plan was to provide security support for Woody for
> another year?


AFAIK, there is no security support for Woody kernels for some time now.
Use kernel.org and compile your kernels for security sensitive machines.

- Adam



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

Re: C++ ABI change for etch -- freeze unstable for all C++ libs with changed or new sonames

[Adam Majer]

Bill Allombert wrote:

>On Sun, Jun 05, 2005 at 01:25:28PM +0200, Matthias Klose wrote:
>  
>
>>The time frame of the C++ ABI changed is not yet fixed.  We will
>>certainly need some time to get the toolchain in shape to start the
>>transition.  In the meantime you can check the new compilers in
>>unstable (g++-3.4) and in experimental (g++-4.0), the new binutils in
>>experimental (2.16), and the new glibc in experimental (2.3.5).
>>
>>
>
>What is proposed as the default C compiler for etch ? gcc-3.4 or
>gcc-4.0 ?
>  
>

By the time Etch rolls out it could be 2007 (at least early part
thereof) so it will most likely be gcc-4.x. Remember that Woody had gcc
2.95 and Sarge is with gcc 3.3.5.

- Adam


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

namespace conflict != package Conflict?

[Sebastian Kuzminsky]

Hi folks, I have a noob question for you.  I maintain the Cogito package
(my first), and it wants to install an executable as /usr/bin/git.  The
GNU Interactive Tools package (git) also wants to install an executable
as /usr/bin/git.  To avoid this conflict I made cogito Conflict with git.

I have been told by Jurij Smakov that this is "seriously wrong", and
I'm asking for help here.  What's the proper way to handle this situation?

The cogito /usr/bin/git is a tiny little helper script hardly worth its
inode, but it's in the upstream package and I dont want to remove it or
rename it.


-- 
Sebastian Kuzminsky


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

Re: http://www.golden-gryphon.com/software/security/selinux.xhtml

[Luke Kenneth Casson Leighton]

On Thu, Jun 09, 2005 at 11:42:00PM +0100, antoine wrote:
> On Thu, 2005-06-09 at 20:20 +0100, Luke Kenneth Casson Leighton wrote:
> > manoj, hi,
> > 
> > i am delighted to see the above web page re: selinux.
> Err?

 never seen it before :)

> > 
> > i notice you mention that there is an effort underway to make
> > a uml-selinux.
> > 
> > perhaps i should mention that it is utterly trivial to set up
> > a xen system with a guest domain running pretty much any kind
> > of kernel - including selinux enabled ones.

> We have been running selinux guest kernels in uml for years, that was

 _great_.
 
 hm - the above page gives the impression that it hasn't been:

  "There also has been an interest in creating an
  
  SELinux UML, since it allows for rapid testing of
  policies, and packages, and to observe the reaction of
  the machine to threats and other stimuli. However,
  it has been tedious, traditionally, to create a
  UML that can be run in enforcing mode. A recipe for
  doing so has been created..."

> not the issue here, 

> or are you just doing xen advocacy?

 i was under the impression, from the above, that somehow
 debian cannot run selinux/uml.

 i was therefore recommending an alternative that is, by
 comparison, just... okay: xen takes a source code download,
 two kernel compiles, create a guest-machine-config, and
 a guest-machine-install (unless like me you're prepared to
 copy the drive images of an existing machine and hack it into
 submission from there :) and you're done, up, running.

 by contrast: i once installed uml...

> The question was about ensuring proper containment of the UML kernel
> process *from outside*, with regards to the way uml handles tmpfs (which
> it uses as a ram backing store with execute attributes).
> 
> > people who are not happy about using or waiting for uml-selinux
> > might want to consider either temporarily or permanently
> > utilising xen instead.
> Running uml-selinux guests is not a problem, and xen is not necessarily
> the right approach for everything: the system virtualisation does not
> happen at the same os level. Can you control your xen instance from
> within a selinux controlled system? 

 you're talking about running xen in the domain master, yes?

 known as domain "0".

 in theory, it can be done (and i haven't been mad enough to switch on
 selinux in the xen master domain yet...)

 management of xen (communication between domains) is done
 via a python-based HTTP web server (twisted python) running on a high
 port number.

 want fine-grained control?  ... erk.




> (note: I am not talking about
> running selinux from within a xen instance)
 
 known as a guest domain (i.e not numbered domain 0)

> > l.
> > 
> > p.s. xen's a lot damn quicker, too.  quick enough so that you can
> > seriously consider just doing apt-get update, blah blah.
> uml on x86 with the skas3 patch is very fast.
> We've been running debian guests (inc apt-get) just fine for years.

 hm.  sorry about that - the above URL gives an impression other than
 that.

 l.

--
http://lkcl.net";>http://lkcl.net
--


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

inconsistent newlines while configuring packages?

[Justin Pryzby]

After doing a recent dist-upgrade, I see:


$ fg
sudo apt-get dist-upgrade

Setting up libgphoto2-2 (2.1.5-6) ...

Setting up libgphoto2-port0 (2.1.5-6) ...

Setting up libxv-dev (4.3.0.dfsg.1-13) ...
Setting up libxi-dev (4.3.0.dfsg.1-13) ...
Setting up g++-3.3 (3.3.5-13) ...
Setting up g++-3.4 (3.4.3-13) ...
Setting up gcj-3.3 (3.3.5-13) ...

Setting up libgtk2.0-0 (2.6.4-3) ...

Setting up gkrellm (2.2.5-1.3) ...

Why do some packages [re]configuration cause a newline to be
outputted, and others do not?  Is it related to the existence of a
postinst script?, and, Is it intentional?

Please Cc: me, not subscribed.
TIA,
Justin


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

Re: freetype package

[Arne Götje (高盛華)]

On Thursday 09 June 2005 21:42, Will Newton wrote:
> This package hasn't had a maintainer upload in 12 months. It is
> currently at version 2.1.7 whilst upstream is in the process of
> releasing 2.1.10. These new releases include some quite critical
> bugfixes and visual improvements.
>
> Is this package being actively maintained? I volunteer to help out
> with packaging, but I think freetype requires at least one maintainer
> who is familiar with CJK fonts (i.e. not me).

Well, I am familiar with CJK fonts, but not with freetype. So I don't 
know if I can be of any help. And I'm not an official DD.
Further more I'm also quite busy with my own packages 
(ttf-arphic-{uming|ukai}), which btw. are CJK fonts. :)

Cheers
Arne
-- 
Arne Götje (高盛華) <[EMAIL PROTECTED]> 
(Spam catcher.  Address might change in future!)
PGP/GnuPG key: 1024D/685D1E8C
Fingerprint: 2056 F6B7 DEA8 B478 311F  1C34 6E9F D06E 685D 1E8C
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.



pgpFLfyLE4LQf.pgp
Description: PGP signature

Re: http://www.golden-gryphon.com/software/security/selinux.xhtml

[antoine]

On Thu, 2005-06-09 at 20:20 +0100, Luke Kenneth Casson Leighton wrote:
> manoj, hi,
> 
> i am delighted to see the above web page re: selinux.
Err?
> 
> i notice you mention that there is an effort underway to make
> a uml-selinux.
> 
> perhaps i should mention that it is utterly trivial to set up
> a xen system with a guest domain running pretty much any kind
> of kernel - including selinux enabled ones.
We have been running selinux guest kernels in uml for years, that was
not the issue here, or are you just doing xen advocacy?
The question was about ensuring proper containment of the UML kernel
process *from outside*, with regards to the way uml handles tmpfs (which
it uses as a ram backing store with execute attributes).

> people who are not happy about using or waiting for uml-selinux
> might want to consider either temporarily or permanently
> utilising xen instead.
Running uml-selinux guests is not a problem, and xen is not necessarily
the right approach for everything: the system virtualisation does not
happen at the same os level. Can you control your xen instance from
within a selinux controlled system? (note: I am not talking about
running selinux from within a xen instance)

> l.
> 
> p.s. xen's a lot damn quicker, too.  quick enough so that you can
> seriously consider just doing apt-get update, blah blah.
uml on x86 with the skas3 patch is very fast.
We've been running debian guests (inc apt-get) just fine for years.

Antoine


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

Re: And now for something completely different... etch!

[Joey Hess]

Andreas Gredler wrote:
> Is there a way to handle this? Could a kernel be patched to read data
> from multiple floppy disks? I know that this question sounds a little
> bit stupid, but floppies still seem to be the most reliable way to boot.

[EMAIL PROTECTED]:/boot>ls -l vmlinuz-2.6.11-1-386
-rw-r--r--  1 root root 1170465 May 20 04:54 vmlinuz-2.6.11-1-386

Since d-i currently puts the initrd that reads the second floppy (or
other USB media) on the boot floppy with the kernel, we either have to
shoehorn that initrd, which is currently 644k, onto the same floppy,
reducing its size by 414k somehow. 

uclibc is one possibility, but 409-some kilobytes of that 644k are used
for kernel modules and other stuff that uclibc wouldn't effect (much);
only 235k is used for libc currently, and I fear those numbers don't add
up to uclibc making it small enough, unless uclibc occupys only 5k of
the compressed disk. Maybe other changes, like using initramfs for that
image, a little kernel hacking to remove a few modules that are barely
used (like ide-core which is on there for only 1 symbol on 2.4; didn't
check 2.6), and so on might just make it work.

Or we could make make some compromise, such as using the kernel initrd
loader to load the initrd from a second floppy, which might cause
problems for USB floppy installs (does the kernel initrd loader support
usb floppies?) and would break the floppy+usb stick install path. It
would also add yet another floppy to the install, probably.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Planet Debian and Akregator

[Raphaël Pinson]

Le Jeudi 9 Juin 2005 07:13, Marc Haber a écrit :
> Hi,
>
> as we all know, Planet Debian generates RSS feeds that Akregator
> doesn't grok, and both packages point at the other one for being at
> fault.

"As we all know" ?
I read Planet Debian on Akregator using the RSS and it works great ... What's 
wrong with it?

>
> Does Debian have something like an "xmltidy" program which can convert
> the Planet Debian RSS feeds into something that Akregator can actually
> read?
>
> Greetings
> Marc

-- 

Raphaël Pinson - [EMAIL PROTECTED]
http://raphink.multiply.com
http://www.ichthux.org - Christian Linux Distribution


pgppMjIC94KcZ.pgp
Description: PGP signature

Re: C++ ABI change -- freezing unstable for new C++ library packages

[Santiago Vila]

On Thu, 9 Jun 2005, Adam Majer wrote:

> Also, the testing seems to be now unfrozen except for base. Does the
> base freeze have anything to do with the new C++ ABI?

No, it's more a leftover of the freeze process. I asked Steve today
about this. He says base packages will be unfrozen again in a few days.


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

Re: Planet Debian and Akregator

[Adeodato Simó]

* Marc Haber [Thu, 09 Jun 2005 07:13:45 +0200]:
> Hi,

  Hi, (cc'ing Mako, the current Planet Debian maintainer)

> as we all know, Planet Debian generates RSS feeds that Akregator
> doesn't grok, and both packages point at the other one for being at
> fault.

> Does Debian have something like an "xmltidy" program which can convert
> the Planet Debian RSS feeds into something that Akregator can actually
> read?

  on IRC today, liw discussed this a bit with Keybuk (former Planet
  Debian maintainer), and this could be read there:

17:32  if you want the & escaped, you do 
   rather than 
17:33  the example rss templates don't escape it, iirc; but
   the example atom template does

  Mako, this is a problem that regularly affects all akregator users,
  could we use the above fix, perhaps after investigating a bit if it
  would have unwanted side effects?

  Thanks,

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Ara que ets la meva dona, te la fotré fins a la melsa, bacona!
-- Borja Álvaro a Miranda Boronat en «Chulas y famosas»


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

Re: And now for something completely different... etch!

[Andreas Gredler]

On Thu, Jun 09, 2005 at 02:24:12PM -0400, Joey Hess wrote:
> Adrian von Bidder wrote:
> > Dropping 2.4 can easily be done on relatively short notice prior to etch 
> > release, so no need to worry about now.
> 
> Relatively short notice of several months, even ignoring problems we
> currently can't solve such as 2.6 not fitting on floppies for the
> installer, at least.

Is there a way to handle this? Could a kernel be patched to read data
from multiple floppy disks? I know that this question sounds a little
bit stupid, but floppies still seem to be the most reliable way to boot.

greets Jimmy

-- 
 Andreas "Jimmy" Gredler 
   ,'"`. http://www.g-tec.co.at/ | [EMAIL PROTECTED]
  (  grml.org -» Linux for texttool-users and sysadmins
   `._,  http://www.grml.org/| [EMAIL PROTECTED]


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

Re: hijacking libhtml-mason-perl

[Julian Mehnle]

Charles Fry wrote:
> [...] I have already packaged the new upstream release of
> libhtml-mason-perl. 

Could you make the prepared package available for download in advance?  
That would be great!

Julian.


pgpUAPiI9FbmW.pgp
Description: PGP signature

Re: Re: kernel security bug #307900

[Olaf van der Spek]

> woody's kernels are vulnerable to CAN-2004-1235, a uselib() race
condition.

Will this be fixed for Woody?
I thought the plan was to provide security support for Woody for another 
year?

--
Olaf van der Spek
http://xccu.sf.net/


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

Re: And now for something completely different... etch!

[Giuseppe Sacco]

Il giorno gio, 09-06-2005 alle 19:06 +0200, Frans Pop ha scritto:
> On Thursday 09 June 2005 18:45, Marco d'Itri wrote:
> > On Jun 09, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> > > Dropping 2.4 can easily be done on relatively short notice prior to
> > > etch release, so no need to worry about now.
> >
> > It would be too late, because at that time we would have wasted a
> > couple of years trying to support them.
> > This kind of decision should be taken early in the development cycle.
> 
> Making the decision early would also help d-i development as we could then 
> start cleaning e.g. keyboard selection (and console-data).
> Being able to rely on sysfs being present would also simplify hardware 
> detection in some cases.

Right, this would really simplify d-i development. My personal opinion
is that 2.6.8 isn't enought mature to be used on server installation
with multidisk, lvm and XFS.
But, when Etch will be released, we will probably have 2.6.25 or such
available. I think, in this case, 2.6 could really be offered as a
complete replacement for 2.4.

Giuseppe


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

http://www.golden-gryphon.com/software/security/selinux.xhtml

[Luke Kenneth Casson Leighton]

manoj, hi,

i am delighted to see the above web page re: selinux.

i notice you mention that there is an effort underway to make
a uml-selinux.

perhaps i should mention that it is utterly trivial to set up
a xen system with a guest domain running pretty much any kind
of kernel - including selinux enabled ones.

people who are not happy about using or waiting for uml-selinux
might want to consider either temporarily or permanently
utilising xen instead.

l.

p.s. xen's a lot damn quicker, too.  quick enough so that you can
seriously consider just doing apt-get update, blah blah.

-- 
--
http://lkcl.net";>http://lkcl.net
--


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

heeeeeaaaave! debian releases: the solution to windows viruses!

[Luke Kenneth Casson Leighton]

uhhn... is it just me, or has the world's internet traffic just taken
a major performance degradation over the past few days?

roll up roll up, get yorr anti-virus sofwarz here - right from a debian
mirror.  all you have to do is get the debian developers to do _another_
major release.  noo more problems with in'ur'ne' traffic, cos there
won't be any _left_ for viruses.

... but seriously: if anyone knows mr bram cohen personally,
or if there's anyone willing to be a victim, could someone
_please_ write a bittorrent server (and associated client
including a filesystem driver) and install it on the debian
mirrors so that the entire debian file/directory structure
can be shared/downloaded just like they can with rsync?

plase?

l.

-- 
--
http://lkcl.net";>http://lkcl.net
--


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

Re: libselinux1 - required

[Luke Kenneth Casson Leighton]

On Wed, Jun 08, 2005 at 10:44:30PM +1200, Nigel Jones wrote:
> It's been implied that people will be basicly *forced* to use selinux,

 wrong.  completely wrong.

 in the debian kernel builds (as arranged i believe by
 manoj), the default option for the selinux kernel module is
 "selinux=0".

 that means it's switched off.

 libselinux1 has a function which will detect this.
 
 all patches in all programs and all utilities and all services
 utilise this function, and disable all and any functionality
 related to and pertaining to selinux.

 at no time and on any account and under no circumstances will selinux
 cause any loss of functionality, loss of speed or any other perceived
 or actual "detrimental" effects or side-effects when the kernel option
 "selinux=0" is set.

 if this isn't clear and explicit enough, do let me know and
 i'll be happy to come round with a big stick with nails in
 it to help make the point more clearly.

 cheers,

 l.


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

Re: C++ ABI change -- freezing unstable for new C++ library packages

[Adam Majer]

Matthias Klose wrote:

> We will send an update with a detailed schedule, when the toolchain is
> ready for the change.


I'm sorry but I'm a little bit confused. Is unstable frozen *now*? If
yes, is the toolchain being updated now?

I'm assuming the change mostly involve moving gcc-defaults to point at
3.4 or 4.0 which I think is possible for all arch at this time [1].
gcc-3.4 is on all arches that I can see.

A much better announcement would be to include some rough estimate on
how long are we going to be waiting for the new toolchain. Is it hours?
days? week? years?

Also, the testing seems to be now unfrozen except for base. Does the
base freeze have anything to do with the new C++ ABI?

Thanks,
- Adam

[1] - http://packages.debian.org/unstable/devel/gcc-3.4


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

Re: And now for something completely different... etch!

[Otavio Salvador]

> "humberto" == Humberto Massa Guimarães <[EMAIL PROTECTED]> writes:

humberto> * John Hasler ::
>> Wouter Verhelst writes: > In practice, many third-party
>> applications will make assumptions > about the availability and
>> configuration of runlevels...
>> 
>> Seems to me that the most likely such assumption is that the
>> runlevels are Red Hat-like.

humberto> IOW, the most likely assumption is that the runlevels
humberto> follow the LSB

I agree with you.

-- 
O T A V I OS A L V A D O R
-
 E-mail: [EMAIL PROTECTED]  UIN: 5906116
 GNU/Linux User: 239058 GPG ID: 49A5F855
 Home Page: http://www.freedom.ind.br/otavio
-
"Microsoft gives you Windows ... Linux gives
 you the whole house."

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 09, Joey Hess <[EMAIL PROTECTED]> wrote:

> I agree, and it seems they have the maintainers interested in
> maintaining 2.4.
The main issue is not maintaining kernel images, but supporting them
in other packages.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Bug#312605: [SPAM?]: Bug#312605 acknowledged by developer (Re: Bug#312605: percent sign in debian package names)

[Holger Klawitter]

Hi Adam,

> Of course not.  Don't escape the filename when placing it into Packages.gz.
> Use the unescaped form.

As a low bandwidth user I was ending up "apt-get update"ing one host at a high 
bandwidth place and creating a mirror from the resulting apt-archive for 
further local distribution. I wrongfully assumed the files in apt-archive to 
be unescaped. Now that I know it's easy to solve. ;-)

Thanks for your time!

Mit freundlichem Gruß / With kind regards
Holger Klawitter
--
[EMAIL PROTECTED]


pgpP8zYswnkT6.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Steve Langasek]

On Thu, Jun 09, 2005 at 02:24:12PM -0400, Joey Hess wrote:
> Adrian von Bidder wrote:
> > Dropping 2.4 can easily be done on relatively short notice prior to etch 
> > release, so no need to worry about now.

> Relatively short notice of several months, even ignoring problems we
> currently can't solve such as 2.6 not fitting on floppies for the
> installer, at least.

> > Also, I feel that the decision to ship 2.4 or not can be left up to the 
> > kernel team - if they have the manpower, fine, if not, dropping 2.4 
> > certainly is an option.

> I agree, and it seems they have the maintainers interested in
> maintaining 2.4.

Hmm, if we're referring to the Debian kernel team, I'm not so sure of that.
My impression is that the people currently maintaining the 2.4 tree for
Debian regard it as a necessary evil...

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Is Ubuntu a debian derivative or is it a fork?

[David Nusinow]

On Thu, Jun 09, 2005 at 09:45:42AM -0700, Matt Zimmerman wrote:
> > What I've decided to do with X.Org is a compromise. I'm using the Ubuntu
> > packages as a base, but I've spent the last month doing as careful an
> > audit of them as I can, comparing them to the XFree86 packaging, and
> > reverting what changes I don't agree with, keeping the ones that I like,
> > etc.
> 
> Did you discuss these plans with any Ubuntu developers?  How much have you
> changed relative to the Ubuntu packages?

Yes, all of this has gone on at debian-x, and Daniel has been enormously
helpful with the process, even if he isn't happy about the fact that I'm
auditing things. Most of the Ubuntu changes, for example the reworking of
the xserver debconf configuration scripts, I kept almost completely
(merging in whatever fixes went in to the xfree86 tree after the Ubuntu
branch). The remainder of the changes are either re-branding to Debian or
merges from the latest xfree86 packaging tree.

> From what I can tell from the changelog, Daniel merged a batch of
> changes from Debian XFree86 SVN into the Ubuntu packages in 6.8.2-16, but I
> don't know what portion of your changes this represents.

Yes he did, and I took those in to account in what I've been doing.

> Ubuntu isn't likely to spend time on another monolithic release, given that
> we're in the process of going modular right now.  If your eventual goal is
> to use the modular tree as well, why wouldn't you do it immediately, given
> the opportunity to use Ubuntu's work as a base?

Because the modular tree does not really exist yet. The work is ongoing and
there are a few modular trees which are unofficial, but the real one is yet
to be finished and the server portion is barely begun (as far as the public
CVS tree goes). Daniel has such a tree on his hard drive, but it's not in
the X.Org CVS, and as such I don't really want to work on packaging it
until I feel comfortable that the rest of the X.Org developers will accept
the work. I also don't feel comfortable with actually doing the
modularization with upstream at this point (due to my own skill level), so
I can either wait for upstream to progress or work towards providing the
best possible option for the 6.9 (monolithic) tree, should we need it.

> Again, I'd be interested to hear details of what you needed to change
> relative to the Ubuntu packages in order to achieve a result which you found
> suitable.

In all honesty, they're minimal. I began the task with full confidence in
Daniel and Fabio's work, and that confidence has been more than justified
in my eyes.

> > I plan to use the patch system Branden and I will develop for the
> > monolithic tree in the modular tree, and if the Ubuntu developers decide
> > that this isn't the best option then they can go their own route, unless
> > they can demonstrate that an alternate system is preferrable.
> 
> We would of course evaluate this decision based on technical merit, but my
> knee-jerk reaction would be "why write yet another patch system"?

The transition to a modular tree will require a new patch system anyway, so
the question is which one to use? The current packages use dbs, which is
sub-optimal. Branden has a well-founded desire for a patch system that has
dependencies, and quilt seems to fit the bill. For me, quilt also has the
most intuitive interface, and it has been proven for use in the kernel
(it's Andrew Morton's patch management scripts). There was a good use-case
writeup posted to debian-x (see the patch management discussion for a link)
which helped sway Branden's opinion as well. If anyone wants to contribute
to the discussion, they're free to do so. Daniel hasn't said on-list as to
what patch management system he's planning to use (I'd imagine it's a lower
priority than the other work he's doing), so I'm hoping he'll look in to
quilt and find it suitable as well.

> > Despite this, Debian will remain independant, at least with respect to
> > X.Org, in the future. I share Daniel's ambition to have up to date X
> > packages in Debian, and I plan to work to make this a reality so that we
> > don't have these kinds of discussions in the future. 
> 
> I'm not sure what the issue is here regarding independence.  Do you consider
> merging the work from Ubuntu into your tree to have created a dependency on
> Ubuntu?  It sounds more like healthy cross-pollination to me.

That's exactly what I mean, it's healthy. We're not sitting around, blindly
putting whatever packages Ubuntu releases in to Debian, we're taking an
active role in their creation and maintainance. Hopefully our packages will
converge to the point where the only difference is branding.

> Case studies of particular collaborations (kernel, X.org, much of d-i) seem
> to reveal a great deal of success, but outside of those collaborations,
> there is still an unfortunate amount of distrust and suspicion of Ubuntu
> within the Debian community.  I hope that as more Debian developers have the
> opportu

Bug#312700: ITP: kchmviewer -- chm viewer for KDE

[Tommaso Moroni]

Package: wnpp
Severity: wishlist
Owner: Tommaso Moroni <[EMAIL PROTECTED]>

* Package name: kchmviewer
  Version : 0.9
  Upstream Author : Georgy Yunaev <[EMAIL PROTECTED]>
* URL : http://kchmviewer.sourceforge.net
* License : GPL
  Description : chm viewer for KDE

KchmViewer is a chm (MS HTML help file format) viewer, written in C++. 
Unlike most existing CHM viewers for Unix, it uses 
Trolltech Qt widget library, and does not depend on KDE or Gnome. 
However, it may be compiled with full KDE support, 
including KDE widgets and KIO/KHTML.

The main advantage of KchmViewer is non-English language support. 
KchmViewer in most cases correctly detects help file encoding, 
correctly shows tables of context of Russian, Korean, Chinese and 
Japanese help files, and correctly searches in non-English help files 
(search for MBCS languages - ja/ko/ch is still in progress).


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

Re: Vancouver prpopsal (was Re: Canonical and Debian)

[Christian Perrier]

Quoting John Goerzen ([EMAIL PROTECTED]):

> I am glad to have discussions take place at Debconf.  In-person meetings
> are a great way to brainstorm and reach some consensus.  But I am wary
> about decisions being reached there, or in IRC, or wherever only a
> minority of Debian developers can participate.


Probably not, of course, because as you said not everyone can
attend. But, actually, live discussions usually make things progress
way faster than mail fl^W discussions or IRC meetings. And compromises
are very much easier to reach, of course.

Then these discussions/proposals have of course to be re-discussed
more widely in the community, to give those who cannot attend a chance
to give their advice.

All this is of course completely trivial, by the way..:-)



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

Re: And now for something completely different... etch!

[=?iso-8859-1?Q?Humberto_Massa_Guimar=E3es?=]

* John Hasler ::

> Wouter Verhelst writes:
> > In practice, many third-party applications will make assumptions
> > about the availability and configuration of runlevels...
> 
> Seems to me that the most likely such assumption is that the
> runlevels are Red Hat-like.

IOW, the most likely assumption is that the runlevels follow the LSB

--
[]s,
Massa


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

Re: And now for something completely different... etch!

[Joey Hess]

Adrian von Bidder wrote:
> Dropping 2.4 can easily be done on relatively short notice prior to etch 
> release, so no need to worry about now.

Relatively short notice of several months, even ignoring problems we
currently can't solve such as 2.6 not fitting on floppies for the
installer, at least.

> Also, I feel that the decision to ship 2.4 or not can be left up to the 
> kernel team - if they have the manpower, fine, if not, dropping 2.4 
> certainly is an option.

I agree, and it seems they have the maintainers interested in
maintaining 2.4.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[John Hasler]

Wouter Verhelst writes:
> In practice, many third-party applications will make assumptions about
> the availability and configuration of runlevels...

Seems to me that the most likely such assumption is that the runlevels are
Red Hat-like.
-- 
John Hasler


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Matt Zimmerman]

On Thu, Jun 09, 2005 at 10:36:25AM -0400, David Nusinow wrote:

> I'm sorry, this turned out to be very long-winded, but since many people
> are interested in what's going on with X.Org, I may as well explain to a
> larger audience than debian-x what's in store.

Thanks for bringing concrete information to the discussion.

> What I've decided to do with X.Org is a compromise. I'm using the Ubuntu
> packages as a base, but I've spent the last month doing as careful an
> audit of them as I can, comparing them to the XFree86 packaging, and
> reverting what changes I don't agree with, keeping the ones that I like,
> etc.

Did you discuss these plans with any Ubuntu developers?  How much have you
changed relative to the Ubuntu packages?

>From what I can tell from the changelog, Daniel merged a batch of
changes from Debian XFree86 SVN into the Ubuntu packages in 6.8.2-16, but I
don't know what portion of your changes this represents.

> Furthermore, Branden has had plans to shift the packaging to a different
> patch system, and we plan to move ahead with that as soon as we have X.Org
> packages in the archive. We'll be branching off the trunk which is derived
> from the modified Ubuntu packaging, so while we're using the Ubuntu
> packages as a base (which were the Debian packages originally anyway)
> we're going to make some radical changes to the system. This packaging can
> potentially be used for the X.Org 6.9 release, which will be the last
> monolithic version to be releaseed during the transition to a modular
> tree.  We may never release 6.9 packages in Debian, but this will provide
> us with a good foundation for it if we do.  This work will be done
> independantly of Ubuntu (as no one from Ubuntu seems interested in
> helping) so we'll go it alone.

Ubuntu isn't likely to spend time on another monolithic release, given that
we're in the process of going modular right now.  If your eventual goal is
to use the modular tree as well, why wouldn't you do it immediately, given
the opportunity to use Ubuntu's work as a base?

> As the upstream X.Org tree gets modularized, we're going to begin to work
> on packaging that instead. My personal preference is to use the modular
> tree (which will be entirely equivalent to the 6.9 release otherwise,
> except called 7.0) but if it's not ready for us, we can stick with 6.9, so
> as to get the latest drivers to our users.  Members of both the XSF,
> including myself and Josh Triplett (who's already begun this work) and
> Ubuntu developers (Daniel Stone) will be working on this together. My goal
> is to have as close a tree for both Ubuntu and Debian as possible,
> preferrably the same tree, but again we'll have to see what happens.

Again, I'd be interested to hear details of what you needed to change
relative to the Ubuntu packages in order to achieve a result which you found
suitable.

> I plan to use the patch system Branden and I will develop for the
> monolithic tree in the modular tree, and if the Ubuntu developers decide
> that this isn't the best option then they can go their own route, unless
> they can demonstrate that an alternate system is preferrable.

We would of course evaluate this decision based on technical merit, but my
knee-jerk reaction would be "why write yet another patch system"?

> So the reality of the situation is that it seems as though we can
> cooperate and remain independant. I'm personally very grateful the Daniel,
> Fabio, and anyone else who worked on X.Org packaging for Ubuntu, since
> it's given me a boost in getting it in to the archive (almost there!) and
> I look forward to collaborating more with them in the future.

I'm glad to hear it.

> Despite this, Debian will remain independant, at least with respect to
> X.Org, in the future. I share Daniel's ambition to have up to date X
> packages in Debian, and I plan to work to make this a reality so that we
> don't have these kinds of discussions in the future. 

I'm not sure what the issue is here regarding independence.  Do you consider
merging the work from Ubuntu into your tree to have created a dependency on
Ubuntu?  It sounds more like healthy cross-pollination to me.

> I'd be surprised if there wasn't a more thorny relationship between Debian
> and Ubuntu than in X packaging

Case studies of particular collaborations (kernel, X.org, much of d-i) seem
to reveal a great deal of success, but outside of those collaborations,
there is still an unfortunate amount of distrust and suspicion of Ubuntu
within the Debian community.  I hope that as more Debian developers have the
opportunity to interact with Ubuntu developers, this will fade in time.

> , but if we can make it work then I urge everyone else to try and do the
> same. The fighting will only harm us all.

Agreed.

-- 
 - mdz


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

Bug#312605: marked as done (percent sign in debian package names)

[Debian Bug Tracking System]

Your message dated Thu, 9 Jun 2005 12:21:41 -0500 (CDT)
with message-id <[EMAIL PROTECTED]>
and subject line Bug#312605: percent sign in debian package names
has caused the attached Bug report to be marked as done.

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

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--
Received: (at submit) by bugs.debian.org; 9 Jun 2005 06:22:06 +
>From [EMAIL PROTECTED] Wed Jun 08 23:22:06 2005
Return-path: <[EMAIL PROTECTED]>
Received: from moutng.kundenserver.de [212.227.126.188] 
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DgGQY-lF-00; Wed, 08 Jun 2005 23:22:06 -0700
Received: from dialin-145-254-179-097.arcor-ip.net [145.254.179.97] 
(helo=puck.klawitter.local)
by mrelayeu.kundenserver.de with ESMTP (Nemesis),
id 0ML21M-1DgGQS1D22-0007fo; Thu, 09 Jun 2005 08:22:00 +0200
From: Holger Klawitter <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: percent sign in debian package names
Date: Wed, 8 Jun 2005 22:54:25 +0200
User-Agent: KMail/1.7.2
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <[EMAIL PROTECTED]>
X-Provags-ID: kundenserver.de [EMAIL PROTECTED] 
login:c3f09bf0911098d231c83d2978ee4594
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-4.5 required=4.0 tests=BAYES_44,DATE_IN_PAST_06_12,
HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level: 

Package: apt
Package: general package management
Version: up to 0.5.28.5

Hi there,

I tried to put a collection of debian packages on a tomcat webserver along=
=20
with a Packages.gz for easy retrieval via apt-get. However the retrieval do=
es=20
not work whenever a percent sign is part of the filename (and the follwing=
=20
two characters indicate a valid hex number) as tomcat interprets the escape=
=20
sequence and retrieves the wrong file name.
 http://oberon/apt/./g++_4%3a3.3.5-3_i386.deb
becomes:
 http://oberon/apt/./g++_4:3.3.5-3_i386.deb

According to rfc1630 percent signs are reserved for quoting and hence=20
forbidden as (literal) part of a URI. So tomcat is doing nothing wrong.

Most other webservers do the percent expansion only in the query part of a =
URL=20
so this problem does not occur there. Tweaking apt-get to send properly=20
quoted URLs would break on other servers. Not desirable :-)

So I'd suggest to avoid the percent sign as part of a package file name.

=2D-=20
Mit freundlichem Gru=C3=9F / With kind regards
Holger Klawitter
=2D-
[EMAIL PROTECTED]

---
Received: (at 312605-done) by bugs.debian.org; 9 Jun 2005 17:21:43 +
>From [EMAIL PROTECTED] Thu Jun 09 10:21:43 2005
Return-path: <[EMAIL PROTECTED]>
Received: from newmail.brainfood.com [146.82.138.14] (Debian-exim)
by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
id 1DgQit-0007GC-00; Thu, 09 Jun 2005 10:21:43 -0700
Received: from brown.brainfood.com ([146.82.138.61] 
helo=gradall.private.brainfood.com)
by newmail.brainfood.com with esmtp 
(TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24)
(Exim 4.31)
id 1DgQiO-0003vs-2A; Thu, 09 Jun 2005 12:21:12 -0500
Date: Thu, 9 Jun 2005 12:21:41 -0500 (CDT)
From: Adam Heath <[EMAIL PROTECTED]>
X-X-Sender: [EMAIL PROTECTED]
To: Holger Klawitter <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Re: Bug#312605: percent sign in debian package names
In-Reply-To: <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER,
VALID_BTS_CONTROL autolearn=no version=2.60-bugs.debian.org_2005_01_02
X-Spam-Level: 
X-CrossAssassin-Score: 2

reassign 312605 general
thanks

On Wed, 8 Jun 2005, Holger Klawitter wrote:

> Package: apt
> Package: general package management
> Version: up to 0.5.28.5
>
> Hi there,
>
> I tried to put a collection of debian packages on a tomcat webserver along
> with a Packages.gz for easy retrieval via apt-get. However the retrieval does
> not work whenever a percent sign is part of the filename (and the follwing
> two characters indicate a valid hex number) as tomcat interprets the escape
> sequence and retrieves the wrong file

Processed: Re: Bug#312605: percent sign in debian package names

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 312605 general
Bug#312605: percent sign in debian package names
Bug reassigned from package `apt' to `general'.

> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: And now for something completely different... etch!

[Darren Salt]

I demand that Rich Walker may or may not have written...

> Matthew Palmer <[EMAIL PROTECTED]> writes:
>> How common was that problem you were trying to solve, again?

> Presumably, you never used an S3 video card.

> (Locks up on leaving X in many card/X permutations).

IME (one S3 ViRGE), that's VESA driver territory. (No lockup problems, though
- at least, not that I recall...)

-- 
| Darren Salt   | linux (or ds) at | nr. Ashington,
| sarge,| youmustbejoking  | Northumberland
| RISC OS   | demon co uk  | Toon Army
|   Let's keep the pound sterling

He is no lawyer who cannot take two sides.


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

Re: freetype package

[Oleksandr Moskalenko]

* Will Newton <[EMAIL PROTECTED]> [2005-06-09 14:42:26 +0100]:

> 
> This package hasn't had a maintainer upload in 12 months. It is currently at 
> version 2.1.7 whilst upstream is in the process of releasing 2.1.10. These 
> new releases include some quite critical bugfixes and visual improvements.
> 
> Is this package being actively maintained? I volunteer to help out with 
> packaging, but I think freetype requires at least one maintainer who is 
> familiar with CJK fonts (i.e. not me).

Will,

This is a good news. Thank you for taking action. My upstream has recently
declared freetype < 1.9 obsolete and dangerous to use with their software, so
I was about to start looking into why we are still at 1.7. If I can help you
with packaging a more recent version I would be happy to do so. Unfortunately
I am not familiar with the CJK fonts, so can't help you there.

Please feel free to contact me privately if you'd like me to do something to
help you.

Best wishes,

Alex.


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

Re: Bug#311997: ITP: gaim-latex -- gaim plugin wich translate LaTeX code into image in conversation

[Anthony DeRobertis]

Nicolas Schoonbroodt wrote:

> chdir("/tmp")
> system("latex -interaction=nonstopmode " FILE_TEX)
> system("dvips -o" FILE_PS " -E " FILE_DVI)
> system("convert " FILE_PS " " FILE_PNG)
> 
> and finaly a I do a
> system("rm -rf /tmp/GaimTeX.*") somewhere

This is still a security problem, this time from local users: A standard
symlink attack.


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

Re: And now for something completely different... etch!

[Frans Pop]

On Thursday 09 June 2005 18:45, Marco d'Itri wrote:
> On Jun 09, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> > Dropping 2.4 can easily be done on relatively short notice prior to
> > etch release, so no need to worry about now.
>
> It would be too late, because at that time we would have wasted a
> couple of years trying to support them.
> This kind of decision should be taken early in the development cycle.

Making the decision early would also help d-i development as we could then 
start cleaning e.g. keyboard selection (and console-data).
Being able to rely on sysfs being present would also simplify hardware 
detection in some cases.


pgp0SKYarfXri.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Adrian von Bidder]

On Tuesday 07 June 2005 23.32, Roger Leigh wrote:
> Frans Pop <[EMAIL PROTECTED]> writes:
> > On Tuesday 07 June 2005 23:02, Roger Leigh wrote:
> >> Existing installs are already configured with debconf.  Their
> >> /etc/locale.gen will not be touched.
> >>
> >> If you do dpkg-reconfigure locales, then users could have the locale
> >> switch to UTF-8 if they so choose.
> >
> > AFAIK locales are automatically regenerated when the locales package is
> > upgraded, so this _would_ effect every existing install directly on
> > upgrade to the new release.
>
> locale-gen is run, but /etc/locale.gen is not necessarily altered.  If
> you don't change it, it will regenerate the same locales you already
> have.

But 'the same locale I already have' would probably mean 'the locale with 
the name of the locale I previously had' which has now suddenly changed its 
behaviour.

No easy way out - either you force people to adapt locale.gen, or you don't 
change locale names.

cheers
-- vbi

-- 
"L'uomo" - diceva S... - "e' un animale ben sciocco, almeno a giudicare
da me stesso".
-- Nicolas de Chamfort, "Caratteri e aneddoti"


pgp2EjmpgyML8.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 09, Adrian von Bidder <[EMAIL PROTECTED]> wrote:

> Dropping 2.4 can easily be done on relatively short notice prior to etch 
> release, so no need to worry about now.
It would be too late, because at that time we would have wasted a couple
of years trying to support them.
This kind of decision should be taken early in the development cycle.

> Also, I feel that the decision to ship 2.4 or not can be left up to the 
> kernel team - if they have the manpower, fine, if not, dropping 2.4 
> certainly is an option.
So you would not mind if e.g. alsa-base or hotplug started to depend on
udev, which depends on 2.6 kernels? This is the kind of situation I'm
discussing.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: launchd and lookupd

[muzzle]

I really feel that Debian is all about freedom of choice. launchd is a
great tool and you should be able to use it if you want to, so
including it in Debian is a Good Idea, IMHO of course. You should not
decide for _other_ people what will suit their needs.
BTW someone could create a very interesting desktop distibution using
these tools
Bye,

Michele


In reply to:
martin f krafft wrote:

>Apple has just released launchd, a init/cron/watchdog/etc.
>replacement. Has anyone looked at it? It seems like a bit of work to
>  
>
It is not a good idea to replace multiple system utilities with one.
Right now I can install a different cron or inetd or atd, or I can
remove them. I don't think launchd is a viable alternative to all these
programs since it tries to do too much.

There are positives for apple for doing this, but I don't think they
translate to an open distribution like Debian.

- Adam









-- 
"Aspetto un'emozione sempre piu' indefinibile" (CCCP Fedeli alla linea)

Bug#312698: ITP: urlgrabber -- advanced URL grabbing package for python

[Norbert Tretkowski]

Package: wnpp
Severity: wishlist
Owner: Norbert Tretkowski <[EMAIL PROTECTED]>

* Package name: urlgrabber
  Version : 2.9.6
  Upstream Author : Michael D. Stenner and Ryan Tomayko
* URL : http://linux.duke.edu/projects/urlgrabber/
* License : LGPL
  Description : advanced URL grabbing package for python

Python package that drastically simplifies the fetching of files. It is
designed to be used in programs that need common (but not necessarily simple)
url-fetching features. It is extremely simple to drop into an existing program
and provides a clean interface to protocol-independant file-access. Best of
all, urlgrabber takes care of all those pesky file-fetching details, and lets
you focus on whatever it is that your program is written to do!

It came into existence as the part of yum that downloads rpms and header
files, but it quickly became clear that this is a general problem that many
applications must deal with.


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

Re: And now for something completely different... etch!

[Adrian von Bidder]

On Tuesday 07 June 2005 19.51, Marco d'Itri wrote:
> On Jun 07, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> > > In my wishlist there is NO support of 2.4 kernels
> >
> > Hmm.  I've never verified this myself, however until recently it was
> > often claimed that 2.6 is still quite a bit worse than 2.4 for some
> > workloads -
>
> This does not make it true.

No it doesn't.  But it indicates that there are still people who prefer 2.4 
to 2.6.

Dropping 2.4 can easily be done on relatively short notice prior to etch 
release, so no need to worry about now.

Also, I feel that the decision to ship 2.4 or not can be left up to the 
kernel team - if they have the manpower, fine, if not, dropping 2.4 
certainly is an option.

cheers
-- vbi

-- 
Available for key signing in Zürich and Basel, Switzerland
(what's this? Look at http://fortytwo.ch/gpg/intro)


pgpiK9LtGpwnr.pgp
Description: PGP signature

Re: And now for something completely different... etch!

[Steve Greenland]

On 07-Jun-05, 12:51 (CDT), Marco d'Itri <[EMAIL PROTECTED]> wrote: 
> On Jun 07, Adrian von Bidder <[EMAIL PROTECTED]> wrote:
> 
> > > In my wishlist there is NO support of 2.4 kernels
> > Hmm.  I've never verified this myself, however until recently it was often 
> > claimed that 2.6 is still quite a bit worse than 2.4 for some workloads - 
> This does not make it true.

Nor does your assertion that "2.4 is obsolete" make it true. There are
obviously enough people still running 2.4 to justify Marcelo's continued
maintenance effort. 

I suspect that the problem is that you're confusing "obsolete" with
"not current". "Obsolete" caries the connotation of "useless except for
entertainment/hobbiest purposes". For example, steam engine cars are
obsolete. The 1999 Toyota Camry is not.

Now, it may be that there is no need to ship 2.4 kernels in etch. There
are strong reasons to minimize the number of different kernels we need
to support, and if all of the targeted architectures are well supported
by 2.6, well and good. But simply claiming that "2.4 is obsolete" is not
a useful contribution to that decision.


Steve

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net


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

Processed: Re: Bug#312605: percent sign in debian package names

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> reassign 312605 control
Bug#312605: percent sign in debian package names
Warning: Unknown package 'package'
Warning: Unknown package 'management'
Warning: Unknown package 'control'
Bug reassigned from package `general package management' to `control'.

> --
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: And now for something completely different... etch!

[Wouter Verhelst]

On Thu, Jun 09, 2005 at 01:18:39PM +0200, Josselin Mouette wrote:
> Le jeudi 09 juin 2005 à 10:53 +0200, Wouter Verhelst a écrit :
> > Now, that is why we have runlevel 1. But in most cases, wasting
> > runlevels to things that could just as easily be fixed by ending the
> > attempts to start is silly.
> 
> How would these runlevels be "wasted"? We're only talking about the
> default configuration, not about something a system administrator
> couldn't change.

In theory.

In practice, many third-party applications will make assumptions about
the availability and configuration of runlevels, and will break horribly
if anything is different from what they expect; this has happened on
those RedHat systems that I've tried this on.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: problems with public keys

[Nico Golde]

Hello Adam,

* Adam D. Barratt <[EMAIL PROTECTED]> [2005-06-09 15:47]:
> "Nico Golde" <[EMAIL PROTECTED]> wrote, Wednesday, June 08, 2005 9:52 AM
> 
> > My qa page http://qa.debian.org/[EMAIL PROTECTED]
> > looks like this:
> > General information for Id: [EMAIL PROTECTED] (click to
> > collapse)
> > GPG key id not found! (key id was not found neither in the
> > Debian keyring nor on a public keyserver)
> 
> developer.php is currently configured not to check against any external
> keyservers.
> 
> See #307461 and http://lists.debian.org/debian-qa/2005/05/msg2.html

[...] 
Thanks!
Regards Nico
-- 
Nico Golde - [EMAIL PROTECTED] | GPG: 1024D/73647CFF
http://www.ngolde.de | http://www.muttng.org | http://grml.org 
VIM has two modes - the one in which it beeps 
and the one in which it doesn't -- encrypted mail preferred


pgpSRBpD0BaGe.pgp
Description: PGP signature

Re: Is Ubuntu a debian derivative or is it a fork?

[David Nusinow]

On Thu, Jun 09, 2005 at 01:07:11AM -0700, Matt Zimmerman wrote:
> On Thu, Jun 09, 2005 at 03:12:02AM -0400, Joey Hess wrote:
> I didn't say "always", but so far we have done this with every package
> modified by Ubuntu.  However, the situation with X.org seems quite different
> to me, given your explanation that the packages were created independently.

> What it assumes is merely that Ubuntu's X.org packages would be suitable for
> Debian, and that the right people at Debian were aware of their existence at
> the time.

I'm sorry, this turned out to be very long-winded, but since many people
are interested in what's going on with X.Org, I may as well explain to a
larger audience than debian-x what's in store.

What I've decided to do with X.Org is a compromise. I'm using the Ubuntu
packages as a base, but I've spent the last month doing as careful an audit
of them as I can, comparing them to the XFree86 packaging, and reverting
what changes I don't agree with, keeping the ones that I like, etc.

Furthermore, Branden has had plans to shift the packaging to a different
patch system, and we plan to move ahead with that as soon as we have X.Org
packages in the archive. We'll be branching off the trunk which is derived
from the modified Ubuntu packaging, so while we're using the Ubuntu
packages as a base (which were the Debian packages originally anyway) we're
going to make some radical changes to the system. This packaging can
potentially be used for the X.Org 6.9 release, which will be the last
monolithic version to be releaseed during the transition to a modular tree.
We may never release 6.9 packages in Debian, but this will provide us with
a good foundation for it if we do. This work will be done independantly of
Ubuntu (as no one from Ubuntu seems interested in helping) so we'll go it
alone.

As the upstream X.Org tree gets modularized, we're going to begin to work
on packaging that instead. My personal preference is to use the modular
tree (which will be entirely equivalent to the 6.9 release otherwise,
except called 7.0) but if it's not ready for us, we can stick with 6.9, so
as to get the latest drivers to our users.  Members of both the XSF,
including myself and Josh Triplett (who's already begun this work) and
Ubuntu developers (Daniel Stone) will be working on this together. My goal
is to have as close a tree for both Ubuntu and Debian as possible,
preferrably the same tree, but again we'll have to see what happens. I plan
to use the patch system Branden and I will develop for the monolithic tree
in the modular tree, and if the Ubuntu developers decide that this isn't
the best option then they can go their own route, unless they can
demonstrate that an alternate system is preferrable.

So the reality of the situation is that it seems as though we can cooperate
and remain independant. I'm personally very grateful the Daniel, Fabio, and
anyone else who worked on X.Org packaging for Ubuntu, since it's given me a
boost in getting it in to the archive (almost there!) and I look forward to
collaborating more with them in the future. Despite this, Debian will
remain independant, at least with respect to X.Org, in the future. I share
Daniel's ambition to have up to date X packages in Debian, and I plan to
work to make this a reality so that we don't have these kinds of
discussions in the future. 

I'd be surprised if there wasn't a more thorny relationship between Debian
and Ubuntu than in X packaging, but if we can make it work then I urge
everyone else to try and do the same. The fighting will only harm us all.

 - David Nusinow


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

Re: hijacking libhtml-mason-perl

[Florian Weimer]

* Charles Fry:

> I discussed the matter with Joshua Kwan, who recommended that I send
> this email, asking whether or not it would be acceptable for me to
> hijack the abandoned libhtml-mason-perl package.

Don't forget to coordinate uploads with the request-tracker folks, for
whom libhtml-mason-perl is a very central dependency.


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

Re: Debian AMD64 Sarge released

[Rafael Rodríguez]

Any approximate time for that event? :)

Rafael Rodríguez

El Jueves, 9 de Junio de 2005 13:29, Joerg Jaspert escribió:
>  We
> will continue to track these two releases until AMD64 is in Debian

Re: Is Ubuntu a debian derivative or is it a fork?

[Joey Hess]

Matt Zimmerman wrote:
> I didn't say "always", but so far we have done this with every package
> modified by Ubuntu.  However, the situation with X.org seems quite different
> to me, given your explanation that the packages were created independently.

My x.org example is somewhat theoretical, FWIW.

> As I explained in the message to which you replied, it depends on the
> details of the situation, and both outcomes are possible.  If the new
> packages were to meet Ubuntu's needs as-is, or with little modification,
> then the benefits of sharing the code would likely outweigh the cost of
> making the switch.  If they don't, then this might not be the case.

There certianly seems to be the potential here for Ubuntu to leapfrog
Debian and then for Debian to catch up and go off in a non-Ubuntu
compatible direction, and for Ubuntu to decide it's not worthwhile for
it to reconverge. At that point, as I said, we have a fork, in all the
bad senses of the word. I suppose we will just have to wait and see.


FWIW, I'd still appreciate an answer to the following question from
someone involved in Ubuntu:

| Let's assume that starting tomorrow, every patch that is applied to
| Ubuntu, that is not Ubuntu-specific, and not something too trivial to
| worry about (such as the python or c++ transitions), is accompnied by a
| handwritten email to the Debian BTS containing the patch and an
| explanation. Writing such an email would surely only take a few minutes;
| how many new such patches do you really create each day? How could this
| not be feasable? Wouldn't this tend to highlight cases where Ubuntu is
| making many useful changes to Debian and tend to get the Ubuntu people
| direct commit access to those packages?

People involved in Ubuntu seem to have been going out of their way to do
this for packages I maintain in the past few days, which I appreciate,
even if it's a cooincidence, but I still don't understand why it cannot
be done in general.

-- 
see shy jo


signature.asc
Description: Digital signature

Bug#312660: ITP: shish -- the diet shell

[Michael Prokop]

Package: wnpp
Severity: wishlist
Owner: Michael Prokop <[EMAIL PROTECTED]>


* Package name: shish
  Version : 0.7-pre3
  Upstream Author : Roman Senn <[EMAIL PROTECTED]>
* URL : http://www.blah.ch/shish/
* License : GPL
  Description : the diet shell

shish is a shell language interpreter and an interactive command
line interpreter.

This shell aims at being very small and doing its tasks in
efficient ways (and not through 100 abstraction layers), which
is mainly done by using the dietlibc and libowfat libraries.

shish will be a POSIX compatible shell language interpreter
according to the IEEE P1003.2 Draft 11.2 by its 1.0 release.


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

Re: Planet Debian and Akregator

[Marc Haber]

On Thu, 9 Jun 2005 12:54:06 +0200, [EMAIL PROTECTED] (Marco d'Itri) wrote:
>On Jun 09, Marc Haber <[EMAIL PROTECTED]> wrote:
>
>> as we all know, Planet Debian generates RSS feeds that Akregator
>> doesn't grok, and both packages point at the other one for being at
>> fault.
>Yes. The (former?) Planet Debian maintainer believes that aggregators
>should deal with malformed XML streams and is not willing to reject
>malformed entries instead of blindly copying them in the output.
>Most aggregators maintainers tend to disagree...

I am aware of that situation. Is there a workaround that doesn't
require cooperation of either side?

Greetings
Marc

-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: And now for something completely different... etch!

[John Hasler]

Frank Lenaerts writes:
> The proposal however, indicates that a runlevel would be dedicated to
> X. In my setup, this would mean that my application server would have to
> run in this dedicated X runlevel because xdm happens to be started there.

The proposal would do nothing to prevent you from continuing to customize
your runlevels.  We are mererly proposing to change the default, not to
impose anything on you.
-- 
John Hasler


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

Re: Vancouver prpopsal (was Re: Canonical and Debian)

[John Goerzen]

On Thu, Jun 09, 2005 at 07:05:17AM +0200, Christian Perrier wrote:
> By reading the Debconf5 participant list, I bet that much of these
> will lead to heavy discussions at Debconf and you will have a lot of
> opportunities to debate them. Just remind that one just cannot be as
> rude in real life as you are by mail...so just be prepared for polite
> and peaceful discussions, possibly around some beverage...:-)

I am glad to have discussions take place at Debconf.  In-person meetings
are a great way to brainstorm and reach some consensus.  But I am wary
about decisions being reached there, or in IRC, or wherever only a
minority of Debian developers can participate.

-- John


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

Bug#312662 submitter address changed (setting proper submitter)

[Debian Bug Tracking System]

The submitter address recorded for your Bug report
#312662: irssi: per-network recoding support would be nice
has been changed.

The new submitter address for this report is
Adeodato Simó <[EMAIL PROTECTED]>.

This change was made by
Adeodato Simó <[EMAIL PROTECTED]>.
If it was incorrect, please contact them directly.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


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

Re: freetype package

[Jeroen van Wolffelaar]

On Thu, Jun 09, 2005 at 02:42:26PM +0100, Will Newton wrote:
> 
> This package hasn't had a maintainer upload in 12 months. It is currently at 
> version 2.1.7 whilst upstream is in the process of releasing 2.1.10. These 
> new releases include some quite critical bugfixes and visual improvements.
> 
> Is this package being actively maintained? I volunteer to help out with 
> packaging, but I think freetype requires at least one maintainer who is 
> familiar with CJK fonts (i.e. not me).

Please feel invited to help with the packaging, and when you upload, if
you wish you can put your name in the Maintainer: field -- and seek
someone who's more familiar with CJK fonts to help you. Anthony Fok
unfortunately seems too busy to help actively, and has expressed his
consent with interested people taking over one of his packages.

--Jeroen

-- 
Jeroen van Wolffelaar
[EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl


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

freetype package

[Will Newton]

This package hasn't had a maintainer upload in 12 months. It is currently at 
version 2.1.7 whilst upstream is in the process of releasing 2.1.10. These 
new releases include some quite critical bugfixes and visual improvements.

Is this package being actively maintained? I volunteer to help out with 
packaging, but I think freetype requires at least one maintainer who is 
familiar with CJK fonts (i.e. not me).


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

Re: And now for something completely different... etch!

[Josselin Mouette]

Le jeudi 09 juin 2005 à 13:21 +0200, Marco d'Itri a écrit :
> On Jun 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:
> 
> > > Wrong. The problem is packages which need to interact with text files,
> > > mail and usenet messages generated by broken software, and for which
> > > assuming UTF-8 would be totally wrong.
> > Please come up with real-life examples. Most mail software in Debian, as
> > well as a good share of our text editors, can deal with several
> > character sets.
> I did. The problem is not if they can deal with LANG=it_IT.UTF-8, but
> how they deal with unlabeled Latin 1 text streams when LANG=it_IT.UTF-8.

At least evolution and all mozilla derivatives can set a default
character set for unlabeled text streams.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: irssi: per-network recoding support would be nice

[Marco d'Itri]

On Jun 09, Adeodato Simó <[EMAIL PROTECTED]> wrote:

>   I'd like too see recoding suport per IRC network, since I believe it's
>   a common use case scenario. Last time I checked (0.8.10-rc5), only
>   per-channel recoding was supported.
You need the charsetwars script.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Josselin Mouette]

Le jeudi 09 juin 2005 à 10:53 +0200, Wouter Verhelst a écrit :
> > At the time, I would have appreciated the
> > opportunity to bootup in a runlevel that wouldn't try to start up the X
> > environment until I had fixed the issue.
> 
> Now, that is why we have runlevel 1. But in most cases, wasting
> runlevels to things that could just as easily be fixed by ending the
> attempts to start is silly.

How would these runlevels be "wasted"? We're only talking about the
default configuration, not about something a system administrator
couldn't change.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: libselinux1 - required

[Josselin Mouette]

Le jeudi 09 juin 2005 à 17:43 +1200, Nigel Jones a écrit :
> > Did you know that all Debian kernels now have SELinux compiled in?
> Yeah, thankfully, I build my own kernels...

It seems that for many people, building your own kernel is still
considered as a proof of virility. Great.

> > Well, you can keep your box security free for as long as you want.
> Yeah, as my computer is personal, I don't normally let anyone else use
> it, these tools don't provide anything for me.

This answers is a proof that you don't have any clue as to how security
works.

> Personally, I agree with Thijs, if coreutils does not need
> "libselinux1" to run (and other packages for that matter), they should
> just be "recommends" or "suggests".

So that you could save 196 kilobytes, we'd have to clutter the whole
archive with packages compiled with or without SELinux support ? No,
thanks. That's not how things work in Debian. If you really want to save
these 196 kilobytes (YES! 196 kilobytes! that's horrible!), you should
use Gentoo.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

irssi: per-network recoding support would be nice

[Adeodato Simó]

Package: irssi
Severity: wishlist

* David Pashley [Thu, 09 Jun 2005 09:54:13 +0100]:
> On Jun 09, 2005 at 09:09, Tollef Fog Heen praised the llamas by saying:
> > * Christian Perrier 

> > | > Again, do not mess with cultures you do not understand.

> > | Do you have real examples?

> > IRC.  An example is the current irssi in Debian which doesn't do
> > recoding between different locales.  (And that is needed, since IRC
> > doesn't have a charset concept and there are still loads and loads of
> > users out there with clients which interpret everything as Latin1.)

> One of the new features of irssi 0.8.10 (when it gets released) is
> recoding support built in.

  I'd like too see recoding suport per IRC network, since I believe it's
  a common use case scenario. Last time I checked (0.8.10-rc5), only
  per-channel recoding was supported.

  Thanks.

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
Russian roulette in bash: ((RANDOM%6)) || rm -rf ~


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

Re: CDBS and /usr/share/doc links

[Adeodato Simó]

* Andreas Tille [Thu, 09 Jun 2005 12:00:20 +0200]:

> Or is there even a hook for doing exactly what I want: Link to the doc 
> directory
> of a dependant package?
  
  I use this in amarok:

common-binary-post-install-arch::
for p in $(filter-out amarok,$(DEB_ALL_PACKAGES)); do \
  rm -rf debian/$$p/usr/share/doc/$$p; \
  ln -sf amarok debian/$$p/usr/share/doc/$$p; \
done

-- 
Adeodato Simó
EM: asp16 [ykwim] alu.ua.es | PK: DA6AE621
 
The total accumulated knowledge of all the men that ever walked the Earth
on the topic of women can fit in the period at the end of this sentence.


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

Re: CDBS and /usr/share/doc links

[Josselin Mouette]

Le jeudi 09 juin 2005 à 12:00 +0200, Andreas Tille a écrit :
> Intended layout:
> 
> $ ls -l `pwd`/debian/tipptrainer-data-*/usr/share/doc
> /home/tillea/debian-maintain/packages/tipptrainer/tipptrainer-0.6.0/debian/tipptrainer-data-de/usr/share/doc:
> lrwxr-xr-x  1 tillea admin 11 2005-06-09 10:55 tipptrainer-data-de -> 
> tipptrainer
> 
> /home/tillea/debian-maintain/packages/tipptrainer/tipptrainer-0.6.0/debian/tipptrainer-data-en/usr/share/doc:
> lrwxr-xr-x  1 tillea admin 11 2005-06-09 10:55 tipptrainer-data-en -> 
> tipptrainer

I'm doing this with cdbs in libpng3, just have a look at this package.
Basically I'm using dh_link to create the links, and I deactivated
dh_installchangelogs and dh_installdocs for the packages that want the
symbolic link.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: And now for something completely different... etch!

[Humberto Massa Guimarães]

Matt wrote:
> On Thu, Jun 09, 2005 at 01:13:16AM +0200, Javier Fernández-Sanguino Peña 
> wrote:
> > to find their own (sometimes flawed) solution to a very common problem. 
>
> Years using Linux: 10.
Idem here
>
> Times I've absolutely needed an X-less boot when an XDM was installed: 0.
Mine: 30 or more.
>
> How common was that problem you were trying to solve, again?
It depends on how great is the hardware you have access to. In Brasil, we have 
a lot of crappy SiS mb-integrated video, and stuff like it, that would easily 
freeze the machine if X configuration is not *milimetrically* well-adjusted.
--
HTH, Massa

Re: CDBS and /usr/share/doc links

[Andreas Tille]

On Thu, 9 Jun 2005, Josselin Mouette wrote:


I'm doing this with cdbs in libpng3, just have a look at this package.
Basically I'm using dh_link to create the links, and I deactivated
dh_installchangelogs and dh_installdocs for the packages that want the
symbolic link.


DEB_INSTALL_DOCS_foo := --no-act
DEB_INSTALL_CHANGELOGS_foo := --no-act

is the solution.  I just used my debian/*.links files from former packaging
again ...

Thanks for the hint

 Andreas.

--
http://fam-tille.de


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

Re: Planet Debian and Akregator

[Pierre HABOUZIT]

On Thu, Jun 09, 2005 at 12:54:06PM +0200, Marco d'Itri wrote:
> On Jun 09, Marc Haber <[EMAIL PROTECTED]> wrote:
> 
> > as we all know, Planet Debian generates RSS feeds that Akregator
> > doesn't grok, and both packages point at the other one for being at
> > fault.
> Yes. The (former?) Planet Debian maintainer believes that aggregators
> should deal with malformed XML streams and is not willing to reject
> malformed entries instead of blindly copying them in the output.
> Most aggregators maintainers tend to disagree...

  it's even worse : planet debian en-malform xml.
  create a blog entry with title "foo & bar" ...  you'll see, your &
will be translated as & in the rss feed of your blog entry, and as &
in planet...
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

Re: Why apt-get is not a proper software search engine (was Re: And now for something completely different... etch!)

[George Danchev]

On Tuesday 07 June 2005 23:44, Javier Fernández-Sanguino Peña wrote:

> Debtags might not cut it either, but might be an improvement over a free
> keyword search which ends up turing the wron packages just because they
> have the word used in the query. A good search function could:
>
> - use keywords/tags (using boolean logic or even regular expressions)
> - use package sections and priorities to adjust results (few users look
> directly for 'libs' or 'oldlibs')
> - use package dependancies to ponder if this is an end-user package or
> something pulled in by other packages (users typically look for end-user
> programs)
> - use popcon to priorise results (users typically look for programs many
> others use)
> - i18n/l10n search, through translation of package descriptions (so that
> searching in != english is possible)

You may try ara [1].  It can perform sophisticated queries on 
the /var/lib/dpkg/available database. You can use atomic expressions which can 
be of the forms pattern, /regexp/, quoted_string, fieldspec operator1 string, 
or fieldspec operator2 regexp. It is possible to use any field of the package 
database as a search criterion and any boolean combination thereof . You can 
perform really simple and really complex queries interactively and within its 
own shell-like environment (history supported) with configurable output 
format. Since the whole database may or may not be loaded into memory it can 
trade memory usage for speed and reverse, also it has option to try to 
compact the heap. It even has its own lightweight httpd, which is still 
experimental and not activated in 1.0.9 release, but you can try it at 
http://ara.zapto.org. It has many options, its own config, and can call 
external progs to grok things as user defined them (apt-get update/install in 
a xterm, a2ps... ). It's written in ocaml, well documented and it it in sarge 
for a long time ;-) [2].

Here are some self-explaned syntax examples:
A simple one:
[ara shell here]& depends:(kde or gnome or x11 or qt) & section:graphics

Regular expressions:
More complex regular expressions need to be enclosed between slashes /.  The 
syntax is sed-ish, the second slash can be followed by i for 
case-insensitivity and w for word-boundary enforcing.  (Remark: digits count 
as word boundaries).  The regular expression syntax is that of Ocaml's Str 
module, which is more or less standard.  Example :

[ara shell here]& /[tpn]etris/iw & depends:/libqt.*/w
[results] cuyo gnome-games kfouleggs ksirtet ksmiletris

Variables:
It is possible to put the result of a query into a named variable and use that 
variable afterwards.  This is accomplished by including an assignment in the 
query, such as :

[ara shell here]& $gui := depends:(gtk | qt | kde | gnome | xlibs)
[results] 
After execution a variable named GUI will appear in the variable list.  It may 
then be referred as $gui.

A 'guess what' non-interactive, nice formating example ;-)
(from the man page)
bash$ ara -old -fields Package:8,Size,Description:100 \
 -table 'Section=games and not (Depends:(gtk|sdl|kde|opengl|gnome|qt)
 or /shoot\|kill\|destroy\|blast\|race\|bomb/iw
 or /multi\(-\|\)player\|strategy\|conquest\|3\(-\|\)d/iw)
 and Depends:(xlibs or vga)
 and Size <= 100'

> an improvement over the 1st thing (keyword search) would be the use of
> "intelligent" text analysis tools (bayesian analysis, N-grams, TFIDF and
> the like). For an example implementation of this take a look at
> remembrance-agent (which uses the 'bag of words' library: bow)

Such analysis and popcon results are not supported.

[1] Packages are: ara, xara, ara-byte, xara-gtk-byte.
note: this's a complete rewrite of ara package found in oldstable woody, 
featuring CLI and GTK2 bytecode and native versions for most arches (native is 
faster of course). Thanks to upstream author and debian-ocaml-maint@ hackers 
(author is subscribed there) for helping me to package and sponsor that 
beast.
[2] perhaps it is not perfect, but works.

-- 
pub 4096R/0E4BD0AB 2003-03-18 
fingerprint1AE7 7C66 0A26 5BFF DF22 5D55 1C57 0C89 0E4B D0AB 


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

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 08, Roger Leigh <[EMAIL PROTECTED]> wrote:

> >> > Wrong. The problem is packages which need to interact with text files,
> >> > mail and usenet messages generated by broken software, and for which
> >> > assuming UTF-8 would be totally wrong.
> >> This is completely orthogonal to making UTF-8 the default locale
> >> codeset.
> > No, it's not because most applications do not allow setting a different
> > "default charset".
> 
> Please could you re-read what I wrote?  What you are saying does not
> follow from that.
> 
> By default locale charset, I'm referring to the defaults in the
> locales package, which are used to generate /etc/locale.gen.  If you
I'm not. I'm referring to the charset which is used by applications to
interpret unlabeled text streams.

> GNU/Linux has been slowly moving to UCS since the late '90s.  We are
> now well past the point where it's mostly usable and ready for proper
> use.  Debian is well behind the times here.
UTF-8 support is good. A default may be good for some locales and wrong
for others.

> As something to ponder: with all current gcc's in Debian, UTF-8 and
> UCS-4 are used as the internal narrow and wide string literal encoding
> in all binaries, independent of the C source encoding.  See
I can't see why this would be relevant. I'm not arguing about the merits
of Unicode.

> > Unsurprisingly, looks you live in a country where anything else than
> > US-ASCII was rarely used in the past.
> ISO-8859-1 actually.  But this is not really topical.
It is, it explains why you do not understand the issue.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Planet Debian and Akregator

[Marco d'Itri]

On Jun 09, Marc Haber <[EMAIL PROTECTED]> wrote:

> as we all know, Planet Debian generates RSS feeds that Akregator
> doesn't grok, and both packages point at the other one for being at
> fault.
Yes. The (former?) Planet Debian maintainer believes that aggregators
should deal with malformed XML streams and is not willing to reject
malformed entries instead of blindly copying them in the output.
Most aggregators maintainers tend to disagree...

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Marco d'Itri]

On Jun 09, Josselin Mouette <[EMAIL PROTECTED]> wrote:

> > Wrong. The problem is packages which need to interact with text files,
> > mail and usenet messages generated by broken software, and for which
> > assuming UTF-8 would be totally wrong.
> Please come up with real-life examples. Most mail software in Debian, as
> well as a good share of our text editors, can deal with several
> character sets.
I did. The problem is not if they can deal with LANG=it_IT.UTF-8, but
how they deal with unlabeled Latin 1 text streams when LANG=it_IT.UTF-8.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Simon Huggins]

On Wed, Jun 08, 2005 at 06:22:15PM +0100, Andrew Suffield wrote:
> On Wed, Jun 08, 2005 at 02:18:28PM +0100, Simon Huggins wrote:
> > I think having a target date, even a target month for release, would
> > help everyone and reduce the posts to -release lately where people
> > have finally crawled out of the woodwork to say please let such and
> > such a package in.
> This one is "release managers should make real, practical, believable
> plans and communicate them to the developers, and then stick to them".
> Which, I will note, is not on that wiki page. Also it already seems to
> have been happening for sarge, now that Anthony Towns has been
> replaced, so I don't think it really qualifies as a proposal.

Well ok, I see this as part of http://wiki.debian.net/?FixedReleaseDate

Though I'd rather trade this off to say "we'll release in 18 months
time" and then slip a month if we have to than have an absolutely fixed
date.

Simon.

-- 
oOoOo  If at first you don't succeed, you'll get lots of advice.   oOoOo
 oOoOooOoOo
  oOoOo  oOoOo
  htag.pl 0.0.22 ::: http://www.earth.li/~huggie/


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[Enrico Zini]

On Thu, Jun 09, 2005 at 11:41:09AM +0200, Wouter Verhelst wrote:
> On Wed, Jun 08, 2005 at 10:13:00AM +0200, Marco d'Itri wrote:
> > On Jun 07, Roger Leigh <[EMAIL PROTECTED]> wrote:
> > > - - The locale codeset should be UTF-8 for all new installs by default.
> > FFS! When will people learn to not mess with other cultures they know
> > nothing about?
> > Feel free to advocate a different default charset for *your* locale, but
> > do not pretend to know what's better for other locales.
> What is the problem with UTF-8 in the Italian locale?

I've been it_IT.UTF-8 for quite a while with no problems.  And I also
get to be able to write the name of my girlfriend, which Latin1 cannot
encode, together with accented Italian words, which BIG5 cannot encode.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>


signature.asc
Description: Digital signature

CDBS and /usr/share/doc links

[Andreas Tille]

Hi,

I wanted to switch to CDBS which makes the packaging awesome easy.  One
final problem was left for me when I tried to use implement the following
multi binary package:

Extract from control:

Package: tipptrainer
Architecture: any
Depends: tipptrainer-data, ...
...
Package: tipptrainer-data-de
Architecture: all
Depends: tipptrainer (=${Source-Version})
...
Package: tipptrainer-data-en
Architecture: all
Depends: tipptrainer (=${Source-Version})


Intended layout:

$ ls -l `pwd`/debian/tipptrainer-data-*/usr/share/doc
/home/tillea/debian-maintain/packages/tipptrainer/tipptrainer-0.6.0/debian/tipptrainer-data-de/usr/share/doc:
lrwxr-xr-x  1 tillea admin 11 2005-06-09 10:55 tipptrainer-data-de -> 
tipptrainer

/home/tillea/debian-maintain/packages/tipptrainer/tipptrainer-0.6.0/debian/tipptrainer-data-en/usr/share/doc:
lrwxr-xr-x  1 tillea admin 11 2005-06-09 10:55 tipptrainer-data-en -> 
tipptrainer


My try in debian/rules to accomplish this:

pkg=tipptrainer
pkg-de=$(pkg)-data-de
pkg-en=$(pkg)-data-en

binary/$(pkg-de)::
rm -rf `pwd`/debian/$(pkg-de)/usr/share/doc/$(pkg-de)
ln -s $(pkg) `pwd`/debian/$(pkg-de)/usr/share/doc/$(pkg-de)
binary/$(pkg-en)::
rm -rf `pwd`/debian/$(pkg-en)/usr/share/doc/$(pkg-en)
ln -s $(pkg) `pwd`/debian/$(pkg-en)/usr/share/doc/$(pkg-en)


The result is that the build log (sorry for German locale, but the problem seems
to be clear):

dh_installdocs -ptipptrainer-data-de ./README ./NEWS ./TODO ./BUGS ./AUTHORS
...
dh_installdocs -ptipptrainer-data-en ./README ./NEWS ./TODO ./BUGS ./AUTHORS
...
dh_builddeb -ptipptrainer-data-de
dpkg-deb: baue Paket »tipptrainer-data-de« in 
»../tipptrainer-data-de_0.6.0-3_all.deb«.
rm -rf `pwd`/debian/tipptrainer-data-de/usr/share/doc/tipptrainer-data-de
ln -s tipptrainer 
`pwd`/debian/tipptrainer-data-de/usr/share/doc/tipptrainer-data-de
dh_shlibdeps -ptipptrainer-data-en
dh_gencontrol -ptipptrainer-data-en
dh_md5sums -ptipptrainer-data-en
dh_builddeb -ptipptrainer-data-en
dpkg-deb: baue Paket »tipptrainer-data-en« in 
»../tipptrainer-data-en_0.6.0-3_all.deb«.
rm -rf `pwd`/debian/tipptrainer-data-en/usr/share/doc/tipptrainer-data-en
ln -s tipptrainer 
`pwd`/debian/tipptrainer-data-en/usr/share/doc/tipptrainer-data-en


So the links are implemented right *after* the package is builded instead of
*before*.  I tried to get a clue from

https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS

where this is stated this way, but I tried "install/foo::" first which does
not help either, because this is executed before dh_installdocs which fails
obviousely because there is no directory to copy the docs to.  So the
question is:

   Is there any hook which I can insert inbetween dh_installdocs and 
dh_builddeb ?

Or is there even a hook for doing exactly what I want: Link to the doc directory
of a dependant package?

Kind regards

 Andreas.

--
http://fam-tille.de

Re: Planet Debian and Akregator

[Lars Wirzenius]

to, 2005-06-09 kello 11:40 +0200, Pierre HABOUZIT kirjoitti:
>   AFAIK, it is a debianplanet bug since the source feeds it uses *are*
> correctly escaped.

I haven't bothered to investigate it often when the ampersand problem
occurs, but on the couple of occasions I have, it has been a case of the
ampersand being escaped only once, not twice.

In RSS, or at least the versions of RSS I have read about (RSS being a
mess of conflicting badly defined drafts of standards at best), there
are two levels of encoding: the RSS level and the HTML level. First you
create the HTML content, and at this point, you have to write "&" if
you want an ampersand. Then you escape the HTML so that you can embed it
into the RSS without having the HTML tags be interpreted by the RSS
processors. At this point, the original "&" had been encoded as "&"
and that now becomes becomes "&".

"&" (what user sees) -> "&" (HTML code) -> "&" (HTML
embedded in RSS).

This is easily all very confusing, of course, and therefore easy to make
mistakes in. I may well have made mistakes in my explanation: it's been
a couple of years since I wrote my RSS generating code.


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Matt Zimmerman]

On Thu, Jun 09, 2005 at 03:12:02AM -0400, Joey Hess wrote:

> Matt Zimmerman wrote:
> > Without any clarification on your part, my interpretation remains unchanged.
> > Ubuntu routinely imports all of the new code in the Debian archive, sorts
> > out any necessary merging, and incorporates the changes.  You are arguing
> > for something similar to happen in the opposite direction.
> 
> I clarified it in my next paragraph. I don't understand how you can say
> here that Ubuntu always merges with Debian and then claim below that it
> would depend on a case by case basis.

I didn't say "always", but so far we have done this with every package
modified by Ubuntu.  However, the situation with X.org seems quite different
to me, given your explanation that the packages were created independently.

> > Surely it would be misdirected effort to reimplement work which has
> > already been done in Ubuntu, and so I assume the Debian packaging would
> > at least be based on Ubuntu's packaging
> 
> This seems to assume that Ubuntu always makes the best decisions for
> Debian.

What it assumes is merely that Ubuntu's X.org packages would be suitable for
Debian, and that the right people at Debian were aware of their existence at
the time.

> Perhaps we instead decide to use work done by Progeny instead.  Perhaps we
> even decide to *gasp* do it ourselves.
> 
> My original question remains -- would you possibly massively rework your
> package to stay based on Debian's, or leave it forked?

As I explained in the message to which you replied, it depends on the
details of the situation, and both outcomes are possible.  If the new
packages were to meet Ubuntu's needs as-is, or with little modification,
then the benefits of sharing the code would likely outweigh the cost of
making the switch.  If they don't, then this might not be the case.

The tone of your messages in this thread seems thoroughly hostile.  This is
not an attitude that I have come to expect from you, and there's no need for
it here.  I'm not here to argue, but to to help clarify what Ubuntu is doing
and why.  I'm only interested in continuing this thread of conversation if
your intent is genuinely to understand, and not to promote conflict.

-- 
 - mdz


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

Re: And now for something completely different... etch!

[Wouter Verhelst]

On Wed, Jun 08, 2005 at 10:13:00AM +0200, Marco d'Itri wrote:
> On Jun 07, Roger Leigh <[EMAIL PROTECTED]> wrote:
> 
> > - - The locale codeset should be UTF-8 for all new installs by default.
> FFS! When will people learn to not mess with other cultures they know
> nothing about?
> Feel free to advocate a different default charset for *your* locale, but
> do not pretend to know what's better for other locales.

What is the problem with UTF-8 in the Italian locale?

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: Planet Debian and Akregator

[Pierre HABOUZIT]

On Thu, Jun 09, 2005 at 07:13:45AM +0200, Marc Haber wrote:
> Hi,
> 
> as we all know, Planet Debian generates RSS feeds that Akregator
> doesn't grok, and both packages point at the other one for being at
> fault.
> 
> Does Debian have something like an "xmltidy" program which can convert
> the Planet Debian RSS feeds into something that Akregator can actually
> read?
> 
> Greetings
> Marc

  try to ask planet develppers to fix it.  the problem with planet (at
least the debian one) is that when it meets & it puts an & in the
feed it creates, instead of &

  AFAIK, it is a debianplanet bug since the source feeds it uses *are*
correctly escaped.

  BTW, a feed is XML, not html, and it's not really akregator's fault
not beeing tolerant.  If you are not convinced, when akregator has a
problem on debian planet, open the feed with konqueror or firefox,
you'll see that the xml is not valid.
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


signature.asc
Description: Digital signature

Re: Planet Debian and Akregator

[Frans Pop]

On Thursday 09 June 2005 09:59, Isaac Clerencia wrote:
> I've read about this before, but I read Debian Panet with akregator
> without any problem. ??

I use akregator too (1.0 beta 10) and every once in a while you get an 
icon indicating a feed cannot be read. Most of the time this will be 
fixed pretty soon.
From an explanation a while back I understood the main (?) cause is 
ampersands ("&") in headers, but I'm not sure.

One thing that is quite bad about akregator is that if a feed can not be 
read correctly, it will retry very often (something like once a minute or 
even more frequently). This has already gotten me banned temporarily 
from /. once (they only allow one refresh per 30 minutes).


pgpUVcMeNecbi.pgp
Description: PGP signature

Re: Canonical and Debian

[Wouter Verhelst]

On Wed, Jun 08, 2005 at 08:55:17AM -0700, Steve Langasek wrote:
> On Wed, Jun 08, 2005 at 01:10:43PM +0200, Wouter Verhelst wrote:
> > The primary question, I think, is whether one can be 100% sure whether a
> > bug that results in an FTBFS on only one out of eleven platforms will
> > not have any effect whatsoever on another platform.
[...]
> Portability bugs are bugs, and generally worth fixing, but we really ought
> to be giving higher priority to bugs that are known to have real effects on
> users, don't you think?
> 
> > Usually, the answer to that one is "no, you can't be sure". FTBFS bugs
> > that occur on only one platform are rare, very rare; most build failures
> > are mistakes in packaging (which usually have effect on all
> > architectures, rather than just one) or things such as incorrect
> > assumptions regarding char signedness or word length, that have effect
> > on all big endian or 64-bit platforms. Of course, these usually result
> > in runtime errors rather than compile time ones.
> 
> And various of those bugs, when they are *known* to imply runtime brokenness
> on release architectures, should be regarded as release-critical; but that's
> not really generalizable to "all porting bugs".

We are really saying the same thing here. I'm saying "you shouldn't
generalize; portability bugs can be RC even if they don't have an impact
on more popular platforms", while you are saying "you shouldn't
generalize; portability bugs can be not RC if they don't have an impact
on more popular platforms".

While my emphasis is different, it really is the same message ;-)

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


signature.asc
Description: Digital signature

Re: And now for something completely different... etch!

[David Pashley]

On Jun 09, 2005 at 09:09, Tollef Fog Heen praised the llamas by saying:
> * Christian Perrier 
> 
> | > Again, do not mess with cultures you do not understand.
> | 
> | Do you have real examples?
> 
> IRC.  An example is the current irssi in Debian which doesn't do
> recoding between different locales.  (And that is needed, since IRC
> doesn't have a charset concept and there are still loads and loads of
> users out there with clients which interpret everything as Latin1.)
> 
One of the new features of irssi 0.8.10 (when it gets released) is
recoding support built in.

-- 
David Pashley
[EMAIL PROTECTED]
Nihil curo de ista tua stulta superstitione.


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

Re: And now for something completely different... etch!

[Wouter Verhelst]

On Wed, Jun 08, 2005 at 07:58:32PM +0200, Javier Fernández-Sanguino Peña wrote:
> On Wed, Jun 08, 2005 at 03:34:26PM +0200, Wouter Verhelst wrote:
> > 
> > Nobody. However, you're assuming that xdm et al will keep trying to
> > start an X server, even if it fails. Luckily, the respective initscripts
> > are far more clever than that.
> 
> I've had a laptop that froze because of X starting up and using the wrong
> driver to access the card (some of the embedded graphic cards in laptops
> are really crappy). The only way to fix this was to startup with a rescue
> CD and preventing xdm from running with an 'exit 0' in its initd script (or
> by removing its links). At the time, I would have appreciated the
> opportunity to bootup in a runlevel that wouldn't try to start up the X
> environment until I had fixed the issue.

Now, that is why we have runlevel 1. But in most cases, wasting
runlevels to things that could just as easily be fixed by ending the
attempts to start is silly.

-- 
The amount of time between slipping on the peel and landing on the
pavement is precisely one bananosecond


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

Re: And now for something completely different... etch!

[Frank Lenaerts]

on Thu, Jun 09, 2005 at 02:30:26AM +0200, Wesley J. Landaker wrote about Re: 
And now for something completely different... etch!:
> I don't often customize runlevels very much, but usually the first thing
> I 
> do when I install a Debian system is remove all the xdm's from 2 and 3
> and 
> add them to 5. I switch between those all the time on systems that are 

The first thing I do after installing xdm is often (not on single
workstations) disabling the startup of the X server because the machine
running xdm is a central application server i.e. client workstations start X
with -query / ... to get a login on the application server. 

I don't want an X server running on the application server so I change xdm's
default configuration. I want to start an X server on the client, so I
create a startup script to start the X server in a non conventional way.

Currently, the runlevel indicates which things are started and these things
can be anything. I consider it a nice and flexible abstraction.

The proposal however, indicates that a runlevel would be dedicated to X. In
my setup, this would mean that my application server would have to run in
this dedicated X runlevel because xdm happens to be started there. However,
this machine doesn't run X at all ... It doesn't seem to feel right i.e. the
abstraction is polluted with implementation issues.

> mostly lights servers but sometimes need to become desktops on the fly
> when 
> an extra warm body shows up.
>
> -- 
> Wesley J. Landaker <[EMAIL PROTECTED]>
> OpenPGP FP: 4135 2A3B 4726 ACC5 9094  0097 F0A9 8A4C 4CD6 E3D2

-- 
[EMAIL PROTECTED]

"Those who do not understand Unix are condemned to reinvent it, poorly."
-- Henry Spencer 


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

Re: Vancouver prpopsal (was Re: Canonical and Debian)

[Christian Perrier]

> No, actually, at the time it was released it was presented as a fait
> accompli. After it received a wide expression of distaste and disgust,

That is your point of view and the way you read it. This is not the
way I read it, so it's likely to be a matter of interpretation.

> There has, to date, been no 'starting point for discussion' provided
> by the Vancouver cabal.


Whether or not there was such intent, it indeed ended up in being a
"starting point of discussion" as much discussion happened and
constructive proposals were already made. Some of them being already
considered by the so-called Kabbalists.


By reading the Debconf5 participant list, I bet that much of these
will lead to heavy discussions at Debconf and you will have a lot of
opportunities to debate them. Just remind that one just cannot be as
rude in real life as you are by mail...so just be prepared for polite
and peaceful discussions, possibly around some beverage...:-)



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

Re: And now for something completely different... etch!

[Miros/law Baran]

9.06.2005 pisze Tollef Fog Heen ([EMAIL PROTECTED]):

> | > Again, do not mess with cultures you do not understand.

> | Do you have real examples?

> IRC.  An example is the current irssi in Debian which doesn't do
> recoding between different locales.  (And that is needed, since IRC
> doesn't have a charset concept and there are still loads and loads of
> users out there with clients which interpret everything as Latin1.)

s/Latin1/any 8-bit encoding from the iso-8859-* range/

Jubal

-- 
[ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ]
[ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] 

Say the secret word and the duck is yours.


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

Re: And now for something completely different... etch!

[Tollef Fog Heen]

* Christian Perrier 

| > Again, do not mess with cultures you do not understand.
| 
| Do you have real examples?

IRC.  An example is the current irssi in Debian which doesn't do
recoding between different locales.  (And that is needed, since IRC
doesn't have a charset concept and there are still loads and loads of
users out there with clients which interpret everything as Latin1.)

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  


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

Re: Planet Debian and Akregator

[Isaac Clerencia]

On Thursday, 9 June 2005 07:13, Marc Haber wrote:
> Hi,
>
> as we all know, Planet Debian generates RSS feeds that Akregator
> doesn't grok, and both packages point at the other one for being at
> fault.
>
> Does Debian have something like an "xmltidy" program which can convert
> the Planet Debian RSS feeds into something that Akregator can actually
I've read about this before, but I read Debian Panet with akregator without 
any problem. ??

Best regards

-- 
Isaac Clerencia at Warp Networks, http://www.warp.es
Work: <[EMAIL PROTECTED]>   | Debian: <[EMAIL PROTECTED]>


pgpVaMM9Rhr7M.pgp
Description: PGP signature

Bug#312605: percent sign in debian package names

[Holger Klawitter]

Package: apt
Package: general package management
Version: up to 0.5.28.5

Hi there,

I tried to put a collection of debian packages on a tomcat webserver along 
with a Packages.gz for easy retrieval via apt-get. However the retrieval does 
not work whenever a percent sign is part of the filename (and the follwing 
two characters indicate a valid hex number) as tomcat interprets the escape 
sequence and retrieves the wrong file name.
 http://oberon/apt/./g++_4%3a3.3.5-3_i386.deb
becomes:
 http://oberon/apt/./g++_4:3.3.5-3_i386.deb

According to rfc1630 percent signs are reserved for quoting and hence 
forbidden as (literal) part of a URI. So tomcat is doing nothing wrong.

Most other webservers do the percent expansion only in the query part of a URL 
so this problem does not occur there. Tweaking apt-get to send properly 
quoted URLs would break on other servers. Not desirable :-)

So I'd suggest to avoid the percent sign as part of a package file name.

-- 
Mit freundlichem Gruß / With kind regards
Holger Klawitter
--
[EMAIL PROTECTED]

LinuxTag conference: 2 free tickets available

[Christian Hammers]

Hello

I have two free tickets for the LinuxTag in Karlsruhe / Germany this year, so if
anybody wants to attend and has not yet got one, contact me.

bye,

-christian-


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

Re: Is Ubuntu a debian derivative or is it a fork?

[Joey Hess]

Matt Zimmerman wrote:
> > This is a falacy, for example, I would never use any of these (IMHO
> > useless at best and often damaging[1]) patch management systems (I know of
> > two much better ones: subversion and arch), but this does not mean that I
> > do not feed (and, as necessary, re-feed for new upstream releases)
> > individual patches to all my upstreams for every non-debian-specific
> > change that I make to my packages. I have no reason to think that I'm
> > alone in this.
> 
> I didn't claim that you were alone in this, but the fact is that there are
> plentiful examples of packages in Debian where this is not the case: we've
> discussed the situation on this very mailing list in the past.

I don't understand why you're talking about packages here. Feeding
patches upstream is not a package-level problem, it is a
maintainer-level problem. Where it doesn't happen a maintainer is not
doing his job according to Debian's established best practices. It's a
pity that Ubuntu doesn't seem to have similar guidelines for feeding
patches usefully upstream to Debian.

> > > Ubuntu re-converges with Debian very regularly.  I think what you meant to
> > > say is that you want Debian to re-converge with Ubuntu.
> > 
> > Not really.
> 
> Without any clarification on your part, my interpretation remains unchanged.
> Ubuntu routinely imports all of the new code in the Debian archive, sorts
> out any necessary merging, and incorporates the changes.  You are arguing
> for something similar to happen in the opposite direction.

I clarified it in my next paragraph. I don't understand how you can say
here that Ubuntu always merges with Debian and then claim below that it
would depend on a case by case basis.

> > > Regarding your specific example, I know of no reason why Debian couldn't 
> > > use
> > > Ubuntu's X.org packages when Debian is ready to make the transition, but 
> > > in
> > > the end that will be the XSF's decision, not Ubuntu's.
> > 
> > Let's assume that they don't (since they're not, exactly, TTBOMK). Now
> > does Ubuntu re-converge its X.org packaging with Debian's new
> > packaging, or do you stay forked?
> 
> That question obviously depends on the details of the differences in
> packaging, which I don't have at the moment.  We'll do what makes most sense
> for Ubuntu based on how the situation plays out.
> 
> Surely it would be misdirected effort to reimplement work which has already
> been done in Ubuntu, and so I assume the Debian packaging would at
> least be based on Ubuntu's packaging

This seems to assume that Ubuntu always makes the best decisions for
Debian. Perhaps we instead decide to use work done by Progeny instead.
Perhaps we even decide to *gasp* do it ourselves.

My original question remains -- would you possibly massively rework your
package to stay based on Debian's, or leave it forked?

-- 
see shy jo


signature.asc
Description: Digital signature