Doug Goldstein wrote:

Howdy all,

Further questions regarding use.desc have come up with regard to this
GLEP. My proposed solution would be a potential amendment to the GLEP to
state that


<flag name='png' />



Comments, Suggestions, Input are all welcome.


If you're going for proper XML, then it should look like this:

<flag name="png"/>

XML doesn't put a space between the attribute and the closing slash --
XHTML does. Common mistake. Also, use " for attributes, rather than '.

Josh Saddler <nightmorph@gentoo.org> said:
> If you're going for proper XML, then it should look like this:
>
> <flag name="png"/>
>
> XML doesn't put a space between the attribute and the closing slash --
> XHTML does. Common mistake. Also, use " for attributes, rather than '.

Well, if we want to nitpick, adding a space, tab, or newline is
perfectly valid, as is using ' to quote the attribute.

http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-EmptyElemTag
http://www.w3.org/TR/2006/REC-xml11-20060816/#NT-AttValue

--
Mark Loeser
email - halcy0n AT gentoo DOT org
email - mark AT halcy0n DOT com
web - http://www.halcy0n.com

Santiago M. Mola wrote:

On Wed, Aug 13, 2008 at 7:11 PM, Doug Goldstein <cardoe@gentoo.org> wrote:


Howdy all,

Further questions regarding use.desc have come up with regard to this GLEP.
My proposed solution would be a potential amendment to the GLEP to state
that

<flag name='png' />

Would be allowed. This syntax is not actually disallowed or allowed by the
current GLEP, but mentioning it would allow a metadata.xml contain all the
USE flags that appear in IUSE, even the global ones. By using the above
syntax, it would simply state that there is no additional descriptions or
details but to just use the use.desc description.

Further more, it would allow us in the future to make that mandatory and
repoman would only have to check metadata.xml for your USE flag.

Comments, Suggestions, Input are all welcome.




What is the benefit?

Regards,

There is none really. Allow all use flags to exist in metadata.xml. It's
really more of a clarification to the GLEP if this is allowed.

Josh Saddler wrote:
> XML doesn't put a space between the attribute and the closing slash --
> XHTML does. Common mistake. Also, use " for attributes, rather than '.

Nope, both is perfectly legal in XML (and illegal per the GDP coding
style, which certainly doesn't apply to metadata.xml) .

Cheers,
-jkt

Hi,

just submitted this bug. Am I missing something and is
this somehow "on purpose"?


Cheers,
Dirk


-------- Original-Nachricht --------
Betreff: Etch's and Lenny's mktemp seriously broken
Datum: Fri, 15 Aug 2008 10:46:09 +0200
Von: Dirk Wetter <spam@drwetter.org>
An: submit@bugs.debian.org


Package: mktemp
Version: 1.5-2
Severity: grave
Tags: security

There's a problem with the randomness of mktemp. The
string includes a number which includes somewhat
the current process ID (based on the current PID). Worse:
Subsequent calls just seem to increase the number
by one:

me@etch:~|0% cat /etc/debian_version
4.0
me@etch:~|0% ps
PID TTY TIME CMD
32342 pts/2 00:00:00 zsh
32366 pts/2 00:00:00 ps
me@etch:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/-zsh.32342.32367
me@etch:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/-zsh.32342.32368
me@etch:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/-zsh.32342.32369
me@etch:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/-zsh.32342.32370
me@etch:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/-zsh.32342.32371
me@etch:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/-zsh.32342.32372
me@etch:~|0%


If you specify more "X" you will get letters included
-- the amount seems to depend on the length of the PPID --
but as far as the numbers are concerned, it shows
the same behaviour.

This is the way it should be (Opensuse):

me@os11:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/zsh.6802.WawJF
me@os11:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/zsh.6802.53xOG
me@os11:~|0% mktemp /tmp/$0.$$.XXXXX
/tmp/zsh.6802.HCmhP
me@os11:~|0% mktemp /tmp/$0.$$.XXXXX



I suggest you use

a) a mixture of letters and numbers for mktemp (more letters, since
1 out of 26 has higher degree of randomness than 1 out of 10).
b) don't include a fixed ratio or position of letters/numbers
c) neither base the numbers or also letters on PIDs or any other
predictable values. Use /dev/(u)random or similar.


This also applies to Debian Lenny.


Cheers,
Dirk






--
Dirk Wetter @ Dr. Wetter IT Consulting http://drwetter.org
Beratung IT-Sicherheit + Open Source
Key fingerprint = 2AD6 BE0F 9863 C82D 21B3 64E5 C967 34D8 11B7 C62F

-
Found core file older than 7 days: /usr/share/man/man5/core.5.gz




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hi Dirk,

On 2008-08-15 10:51 +0200, Dirk Wetter wrote:

> just submitted this bug. Am I missing something and is
> this somehow "on purpose"?

Well, I don't think this is a serious problem, since mktemp will create
a different file if the one with the pid already exists. The
predictability of the file name is not nice, but it is only a security
problem if you create the file in a world-writable directory that does
not have the sticky bit set. And in such directories, you're subject to
all kinds of race conditions anyway.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wed, 13 Aug 2008 16:13:26 -0400
Doug Goldstein <cardoe@gentoo.org> wrote:

> > What is the benefit?

> There is none really. Allow all use flags to exist in metadata.xml.
> It's really more of a clarification to the GLEP if this is allowed.

I personally think that this would facilitate a lot of duplication that
would ultimately amount to bitrot. Of course having, say, repoman
suggest cleanups would be one solution to the problem of bitrot, but
then I still fail to see the advantage over having both an IUSE per
ebuild as well as maintaining <gentoo-x86/profiles/use.desc>.

In my opinion the GLEP needs clarification on this matter. It should
forbid the use of these empty flag tags, and the DTD should reflect
that[1].


Kind regards,
JeR


[1] Come to think of it, in the recent metadata.xml / no-herd debate,
wasn't having an empty herd tag ever suggested? <herd />

On 2008-08-15 12:13 +0200, Sven Joachim wrote:

> Well, I don't think this is a serious problem, since mktemp will create
> a different file if the one with the pid already exists. The
> predictability of the file name is not nice, but it is only a security
> problem if you create the file in a world-writable directory that does
> not have the sticky bit set. And in such directories, you're subject to
> all kinds of race conditions anyway.

However, Nico Golde informed me that mktemp has a `-u' switch which will
unlink the file before mktemp exits. If you use that, the easy-to-guess
filename becomes a severe problem.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Wednesday 13 August 2008 16:26, Frank McCormick wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Nigel Henry wrote:
> | On Tuesday 12 August 2008 22:57, Frank McCormick wrote:
> |> -----BEGIN PGP SIGNED MESSAGE-----
> |> Hash: SHA1
> |>
> |>>> Sometime over the last few days I lost all sound on my system. Its
> |>>> an intel board - audio apps tell me they can't open the sound device,
> |>>> but when the system boots I hear a pop in the speakers as the drivers
> |>>> are loaded.
> |>>
> |>> cat /proc/asound/cards
> |>
> |> 0 [ICH5 ]: ICH4 - Intel ICH5
> |> Intel ICH5 with AD1985 at irq 17
> |>
> |>> In a terminal/Konsole, what does typing alsamixer as user show? Perhaps
> |>> some
> |>> update or other has muted the sound, and you now need to unmute it.
> |>> Just a thought.
> |>
> |> Nope. Nothing is muted.
> |
> | Hi Frank. I should have realised that all the above output would be
>
> ok, when a
>
> | couple of posts back, you said that aplay was working ok.
> |
> | Did you run aplay as user, or root?
>
> ~ As a user. I am still in audio group.
>
> ~ I have since discovered SOME of the problem is caused by
> audacious...which not only doesn't play..but sits quietly sucking up
> 100% cpu. I have filed a bug.
>
>
> Cheers
>
> Frank

Not using Sid, and wondering if pulseaudio may have been installed as a new
package to your Sid install as part of the updates, I changed
my /etc/apt/sources.list in Lenny to point to unstable, ran apt-get update,
apt-get dist-upgrade (without doing the upgrade), but saw no mention of
pulseaudio being installed as a new package.

Of course, if you had already installed pulseaudio on your Sid install, it is
possible that there may have been an update to it, which may have caused your
sound to "hit the fan" . Saying that though, perhaps with pulseaudio
installed, even aplay would not have worked (not sure on that).

I don't have pulseaudio installed on my Lenny install, and from experiencing
it on a Fedora 8 install, where my sound no longer worked, I quickly disabled
it, and have no intention of using it on Lenny, or anything else for that
matter.

Have you tried other audio apps apart from audacious since the sound problems?
I use Mhwaveedit for playing sound files, and it's available from the Debian
repo's. I'm not sure what the default is for audio out, but if you try it,
look in Edit/preferences/sound, and driver options.

If by some obscure chance you do have pulseaudio installed, you can disable it
by removing the package, alsa-plugins-pulseaudio, and if you're using KDE, as
I am, this will also remove the package kde-settings-pulseaudio.

Just a couple of thoughts Frank, as it's horrible when you use sounds a lot,
then suddenly they are no more.

All the best, and have a nice weekend.

Nigel.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On Fri,15.Aug.08, 16:05:13, Sven Joachim wrote:
> On 2008-08-15 12:13 +0200, Sven Joachim wrote:
>
> > Well, I don't think this is a serious problem, since mktemp will create
> > a different file if the one with the pid already exists. The
> > predictability of the file name is not nice, but it is only a security
> > problem if you create the file in a world-writable directory that does
> > not have the sticky bit set. And in such directories, you're subject to
> > all kinds of race conditions anyway.
>
> However, Nico Golde informed me that mktemp has a `-u' switch which will
> unlink the file before mktemp exits. If you use that, the easy-to-guess
> filename becomes a severe problem.

I must be dense, could you please elaborate on how this can be a
problem?

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