Re: Summary: Moving /tmp to tmpfs makes it useless

[Josselin Mouette]

Le dimanche 10 juin 2012 à 01:51 +0300, Serge a écrit : 
> Some people asked for a thread summary. So here it is.

> "/tmp on tmpfs is good" quotes
> ==
> No real quotes here. 

So much for a thread summary.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1339399239.4245.171.camel@pi0307572

Re: gnome is completely f^Mmessed up

[Timo Juhani Lindfors]

Luke Cycon  writes:
> I have the added issue that GNOME seems to (somehow) manage to spawn in
> excess of 100 Xserver when I try to log in.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650183


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/84zk8a9o22@sauna.l.org

Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 binNMU broke multi-arch installability

[Ian Jackson]

Guillem Jover writes ("Re: [xml/sgml-pkgs] Bug#676686: libxslt1.1: libxslt1.1 
binNMUbroke multi-arch installability"):
> As I mentioned in the long ref-counting thread, I strongly disagree this
> is a correct solution, it just seems like a hack to me. Instead I
> think we should consider changelog (and copyright as long as it's in
> machine parseable format) as dpkg metadata (something dpkg misses
> compared to rpm or other package managers for example) and as such they
> should go into the .deb control member, which would end up in the dpkg
> database w/o any kind of file conflict, and very minor packaging effort
> as for most that would be handled by helpers.

I think this is the wrong design.  The changelog is primarily used by
humans, not software, and burying it in the dpkg database is not
helpful.  I think the solution with the binNMU changelogs is
straightforward and should be implemented.

>  * changelog extractors (like apt-listchanges) would not need (eventually)
>to extract the whole .deb data member to get the changelog, it
>would just need to extract the control member, and get a fixed
>filename. They would stop needing to hardcode possible paths to
>the files too. This still leaves the NEWS.Debian file but then
>maybe that should also be considered metadata...

This path leads, eventually, to all structured data currently stored
in the filesystem being subsumed by dpkg.  This is not healthy for
dpkg and not healthy for the rest of the project.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20437.51932.971859.384...@chiark.greenend.org.uk

Re: Planned changes to Debian Maintainer uploads

[Ian Jackson]

Ansgar Burchardt writes ("Planned changes to Debian Maintainer uploads"):
> (Please send followup messages to -project.)
> 
> The ftp team wants to change how allowing Debian Maintainers to upload
> packages works.  The current approach with the DM-Upload-Allowed field
> has a few issues we would like to address:

Your proposal simultaneously changes two things:

>  - It applies to all DMs listed as Maintainer/Uploaders. It is not
>possible to grant upload permission to only a specific DM.

This does involve changing the structure of the metadata.

And I find it difficult to see what it would mean to list a DM as a
Maintainer or an Uploader if they weren't supposed to be able to
upload the package.

>  - It is tied to the source package so can only be changed with a
>sourceful upload.

This is slightly annoying but given that maintainership changes
involve an upload too, it hardly seems fatal.  Has this been a problem
in practice ?

>  - It allows DMs to grant permissions to other DMs.

It is far from clear that forbidding this is the right thing to do.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20437.57572.743896.174...@chiark.greenend.org.uk

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Aneurin Price]

On 8 June 2012 12:04, Bjørn Mork  wrote:
> Any file system will run out of space given the broken applications
> mentioned in this thread.

It is not productive to redefine applications as 'broken' simply
because they do not conform to an arbitrary set of requirements that
you have just added, especially when you haven't even given any
indication of what you consider 'non-broken' behaviour.

The use of /tmp (or TMPDIR if set) to store temporary files is its
*purpose*. If suddenly that use is considered 'broken' behaviour, then
who is to say what other standard behaviour will be declared 'broken'
tomorrow?

I could declare that from now on I'm going to use FAT32 for my /tmp,
and all applications which expect a case-sensitive filesystem are
broken, but it would be similarly absurd.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAHb+SPBD-t34i_z6o=mg0sk9j2qurga1kzvjtodes73w5u4...@mail.gmail.com

Re: Lets (eventually) find a good solution for /tmp

[Aneurin Price]

On 10 June 2012 19:31, Thomas Goirand  wrote:
> On 06/11/2012 12:06 AM, Don Armstrong wrote:
>> swap file on / [...] is
>> really the direction that we should be going
> NO !
>
> Does this need to be explained? :/
>

Not quite sure what you're objecting to. If you are against the use of
swap files rather than swap partitions then yes, it does need to be
explained, because as far as I am aware a swap file is the better
choice in virtually all situations (and is what I've been using
exclusively since Linux 2.6 removed the downsides).

If in fact there are any remaining downsides I'm unaware of, it would
be good to see them documented.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAHb+SPC=jww-faxu_uc9xsotiy3p69wudznfwemrog0y983...@mail.gmail.com

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Josselin Mouette]

Le lundi 11 juin 2012 à 14:53 +0100, Aneurin Price a écrit : 
> On 8 June 2012 12:04, Bjørn Mork  wrote:
> > Any file system will run out of space given the broken applications
> > mentioned in this thread.
> 
> It is not productive to redefine applications as 'broken' simply
> because they do not conform to an arbitrary set of requirements that
> you have just added, especially when you haven't even given any
> indication of what you consider 'non-broken' behaviour.

Right.

So your applications are not broken because they all have access to
infinite storage?

Your life must be so fantastic.

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1339423495.4245.209.camel@pi0307572

Re: Lets (eventually) find a good solution for /tmp

[Simon McVittie]

On 11/06/12 15:01, Aneurin Price wrote:
> as far as I am aware a swap file is the better
> choice in virtually all situations

Assuming
 is
still current:

If you want to use hibernation (suspend-to-disk), you need roughly[0] as
much partion-based swap as you have RAM, unless you're using the setup
on that wiki page (using uswsusp, which is not installed by default;
have allocated a contiguous swap file; have made sure to use a
filesystem which will not move that file; done some dangerous[1] manual
configuration for uswsusp).

By default, GNOME's gnome-power-manager will just suspend
(suspend-to-RAM) under normal conditions; but if your laptop battery
gets critically low, it will automatically hibernate, because that's the
only way it can preserve what you were working on across total power
failure (i.e. not enough battery to keep your RAM alive). I think this
is a sensible approach.

S

[0] I believe the hibernation image is compressed, and doesn't include
disk cache, so you only need as much swap as you have "real data" in RAM

[1] "dangerous" as in "if you got the numbers wrong, you will trash
arbitrary parts of your filesystem next time you hibernate", as far as I
can see


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd5fef0.9080...@debian.org

Re: [xml/sgml-pkgs] Processed: severity of 676686 is important

[Aron Xu]

severity 676686 serious
thanks

Please don't lower it to make it migrate, I've already explained the
reasons, and let me repeat:

1. There aren't so many user-visible changes in this version, but the
most important one is moving patches to quilt maintained.
2. I'll make sure to upload new version or downgrade the severity
before 15th, so it won't bother release team for unblocking.

On Mon, Jun 11, 2012 at 6:45 PM, Debian Bug Tracking System
 wrote:
> Processing commands for cont...@bugs.debian.org:
>
>> severity 676686 important
> Bug #676686 [libxslt1.1] libxslt1.1: libxslt1.1 binNMU broke multi-arch 
> installability
> Severity set to 'important' from 'serious'
>> thanks
> Stopping processing here.
>
> Please contact me if you need assistance.
> --
> 676686: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676686
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
> ___
> debian-xml-sgml-pkgs mailing list
> debian-xml-sgml-p...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-xml-sgml-pkgs



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5Snye1=GN60OkrUe=TsTnohpHuk_zw=y7falmuggz...@mail.gmail.com

Re: Lets (eventually) find a good solution for /tmp

[George Danchev]

On Monday 11 June 2012 16:01:10 Aneurin Price wrote:
> On 10 June 2012 19:31, Thomas Goirand  wrote:
> > On 06/11/2012 12:06 AM, Don Armstrong wrote:
> >> swap file on / [...] is
> >> really the direction that we should be going
> > 
> > NO !
> > 
> > Does this need to be explained? :/

Hi,

> Not quite sure what you're objecting to. If you are against the use of
> swap files rather than swap partitions then yes, it does need to be
> explained, because as far as I am aware a swap file is the better
> choice in virtually all situations (and is what I've been using
> exclusively since Linux 2.6 removed the downsides).

data point: a swap file would not work with btrfs [1].

[1]https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_swap_files.3F

-- 
pub 4096R/0E4BD0AB 


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201206111630.53595.danc...@spnet.net

Re: Lets (eventually) find a good solution for /tmp

[Aneurin Price]

On 11 June 2012 15:21, Simon McVittie  wrote:
> On 11/06/12 15:01, Aneurin Price wrote:
>> as far as I am aware a swap file is the better
>> choice in virtually all situations
>
> Assuming
>  is
> still current:
>
> If you want to use hibernation (suspend-to-disk), you need roughly[0] as
> much partion-based swap as you have RAM, unless you're using the setup
> on that wiki page (using uswsusp, which is not installed by default;
> have allocated a contiguous swap file; have made sure to use a
> filesystem which will not move that file; done some dangerous[1] manual
> configuration for uswsusp).
>


Thanks. that's useful information. It's not relevant to me personally
which is why I was unaware of it, but certainly that would count as a
good reason not to use a file by default (at least until that
limitation is overcome).


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAHb+SPDNnZkSHcuOm6w2de=NuBt_jrSUFEisRaR+_0MMcQ=w...@mail.gmail.com

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Joey Hess]

Wouter Verhelst wrote:
> Also, the symlink attack thing isn't just something I made up;
> tmpreaper's REAME.Debian actually warns about that.

It's not particularly hard to securely delete /tmp in single user mode,
ie at boot. Just don't follow symlinks. Tmpreaper's potential for
symlink attacks is entirely due to it being run in multiuser mode, which
provides the potential for users to race it. 

Thankfully, tmpreaper is not included in the base system, although I
would still prefer it not be included in Debian at all, because IMHO
it's a security hole waiting to happen, as well as a Debian-specific 
fork that has now missed out on 14 years (!!!) of upstream development
and, presumably, security improvements. http://bugs.debian.org/71251

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Stephan Seitz]

On Sun, Jun 10, 2012 at 12:20:32PM +0200, Wouter Verhelst wrote:

When /tmp is in a tmpfs, it's easy to connect the dots if it's empty on
the next boot, and even easy to understand that restoring there (and
then rebooting) isn't going to be very helpful.


I don’t think the standard user will realize the difference between disk 
/tmp cleaned at reboot and a RAM disk.



Also, the symlink attack thing isn't just something I made up;
tmpreaper's REAME.Debian actually warns about that.


True, but tmpreaper is not needed for systems with frequent reboots. /tmp 
on disk is cleaned according to the setting of TMPTIME. You need 
tmpreaper to clean /tmp on systems which rarely reboot. And then you have 
the same problem with tmpfs.


Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Salvo Tomaselli]

> I don’t think the standard user will realize the difference between disk
> /tmp cleaned at reboot and a RAM disk.

He will realize the difference between a program that works and a program that 
informs him of insufficient disk space (if lucky, or just behaving odd 
otherwise).
If he is smart he will use the information to figure out what the problem is 
and solve it, otherwise he might just think that it's very odd that it's 1TB 
disk is already full.

-- 
Salvo Tomaselli


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201206111828.39894.tipos...@tiscali.it

Re: Lets (eventually) find a good solution for /tmp

[Don Armstrong]

On Mon, 11 Jun 2012, Thomas Goirand wrote:
> On 06/11/2012 12:06 AM, Don Armstrong wrote:
> > swap file on / [...] is
> > really the direction that we should be going
> NO !

Some imprecise language on my part has apparently lead to some
misunderstanding of what I am suggesting.

I don't mean a swap file that gets used as swap. I meant file(s) which
are on / (or some other large filesystem if / is not large) which are
used to handle /tmp growing beyond the bounds of the memory assigned
to it. These file(s) should be orthogonal to the current memory
management system. [I know that using a swap file can currently do
this to some extent, but it has other problems.]


Don Armstrong

-- 
Maybe I did steal your heart
and I am such a perfect criminal
that you never noticed
 -- a softer world #481
http://www.asofterworld.com/index.php?id=481

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


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120611171326.gp32...@rzlab.ucr.edu

Is Debian affected by the recent MySQL sql/password.c flow?

[Thomas Goirand]

Hi,

Since it has been made public, I believe it's ok to discuss it in
-devel. I came across this:
http://seclists.org/oss-sec/2012/q2/493

Is the Squeeze version affected? And SID? By reading it, especially the
end about GCC, it's unclear to me if we need an urgent patch:

"To my knowledge gcc builtin memcmp is safe, BSD libc memcmp is safe.
Linux glibc sse-optimized memcmp is not safe, but gcc usually uses the
inlined builtin version."

In which case are we?

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd62e80.20...@goirand.fr

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 1:44 AM, Thomas Goirand  wrote:
> Hi,
>
> Since it has been made public, I believe it's ok to discuss it in
> -devel. I came across this:
> http://seclists.org/oss-sec/2012/q2/493
>
> Is the Squeeze version affected? And SID? By reading it, especially the
> end about GCC, it's unclear to me if we need an urgent patch:
>
> "To my knowledge gcc builtin memcmp is safe, BSD libc memcmp is safe.
> Linux glibc sse-optimized memcmp is not safe, but gcc usually uses the
> inlined builtin version."
>
> In which case are we?
>

IMHO I suggest to talk with Security Team before disclosing
information that might be sensitive in the mean time on a Debian
development mailing list.


-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w4mob-swjzygcwbw-qlbhhjf+umos+38uq839bmra2...@mail.gmail.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Lech Karol Pawłaszek]

On Tue, 2012-06-12 at 01:44 +0800, Thomas Goirand wrote:
> Hi,
> 
> Since it has been made public, I believe it's ok to discuss it in
> -devel. I came across this:
> http://seclists.org/oss-sec/2012/q2/493
> 
> Is the Squeeze version affected? And SID? By reading it, especially the
> end about GCC, it's unclear to me if we need an urgent patch:

According to this:
https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql

Debian is not affected.

Kind regards,

-- 
Lech Karol Pawłaszek
lech.pawlas...@blstream.com
+48 600 060 758


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1339437600.2658.3.camel@macbook

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Thomas Goirand]

On 06/12/2012 01:52 AM, Aron Xu wrote:
> IMHO I suggest to talk with Security Team before disclosing
> information that might be sensitive in the mean time on a Debian
> development mailing list.
>   
Could you explain to me what exactly I'm disclosing?
The news is already on slashdot and so on, and I think
it'd be better to know, as hackers will.

I made 10 000 connection attempts with a random pass
to one of my Squeeze server, and couldn't get in, so unless
I'm really unlucky (there's one chance out of 256), then
Debian is not vulnerable. I just wanted to be sure of it.

Cheers,

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd634d8.7050...@debian.org

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Thomas Goirand]

On 06/12/2012 02:00 AM, Lech Karol Pawłaszek wrote:
> According to this:
> https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql
>
> Debian is not affected.
>
> Kind regards,
>   
Cool, thanks!

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd634ff.2000...@debian.org

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 2:11 AM, Thomas Goirand  wrote:
> On 06/12/2012 01:52 AM, Aron Xu wrote:
>> IMHO I suggest to talk with Security Team before disclosing
>> information that might be sensitive in the mean time on a Debian
>> development mailing list.
>>
> Could you explain to me what exactly I'm disclosing?
> The news is already on slashdot and so on, and I think
> it'd be better to know, as hackers will.
>

I'm not saying you are disclosing anything, but you are asking if
someone knows it's in what status publicly in a Debian development
mailing list. Then this may lead to some disclosing and even mislead
some other people. Yes there are many people doing tests just like
you, and they are reporting their results in many ways they prefer.
But as you are a DD you'd better not ignore our Security Team when
starting discussion publicly about a security incident your are not
sure whether it's relevant to Debian. People at Security Team are not
only responsible for fixing things when it breaks out, but also make
sure sensitive information is being disclosed in a correct form at a
correct time. In the end, I believe talking with them beforehand is
always a right way to do, no matter if Debian is affected by this
particular issue.




-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w6smb3shwjwmeo_-vuruvzrviigonbsxf3pgnxpkoq...@mail.gmail.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Jonas Smedegaard]

On 12-06-12 at 02:11am, Thomas Goirand wrote:
> On 06/12/2012 01:52 AM, Aron Xu wrote:
> > IMHO I suggest to talk with Security Team before disclosing 
> > information that might be sensitive in the mean time on a Debian 
> > development mailing list.
> >   
> Could you explain to me what exactly I'm disclosing?

s/disclosing/promoting/


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Yves-Alexis Perez]

On mar., 2012-06-12 at 02:23 +0800, Aron Xu wrote:
> On Tue, Jun 12, 2012 at 2:11 AM, Thomas Goirand  wrote:
> > On 06/12/2012 01:52 AM, Aron Xu wrote:
> >> IMHO I suggest to talk with Security Team before disclosing
> >> information that might be sensitive in the mean time on a Debian
> >> development mailing list.
> >>
> > Could you explain to me what exactly I'm disclosing?
> > The news is already on slashdot and so on, and I think
> > it'd be better to know, as hackers will.
> >
> 
> I'm not saying you are disclosing anything, but you are asking if
> someone knows it's in what status publicly in a Debian development
> mailing list. Then this may lead to some disclosing and even mislead
> some other people. Yes there are many people doing tests just like
> you, and they are reporting their results in many ways they prefer.
> But as you are a DD you'd better not ignore our Security Team when
> starting discussion publicly about a security incident your are not
> sure whether it's relevant to Debian. People at Security Team are not
> only responsible for fixing things when it breaks out, but also make
> sure sensitive information is being disclosed in a correct form at a
> correct time. In the end, I believe talking with them beforehand is
> always a right way to do, no matter if Debian is affected by this
> particular issue.
> 
> 
> 
To be honest, I think -devel is a bad place for this just because it's
more or less full of useless, hundred mails long threads, so for example
I barely can follow it (and consider removing my subscription). So it'd
be better on some less noisy, security related, debian list like
debian-secur...@lists.debian.org.

Regards,
-- 
Yves-Alexis


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

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Clint Adams]

On Tue, Jun 12, 2012 at 02:23:47AM +0800, Aron Xu wrote:
> sure whether it's relevant to Debian. People at Security Team are not
> only responsible for fixing things when it breaks out, but also make
> sure sensitive information is being disclosed in a correct form at a
> correct time. In the end, I believe talking with them beforehand is
> always a right way to do, no matter if Debian is affected by this
> particular issue.

Coordinated disclosure is irresponsible, and we shouldn't do it.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120611183902.ga3...@scru.org

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Thomas Goirand]

On 06/12/2012 02:23 AM, Aron Xu wrote:
> I'm not saying you are disclosing anything, but you are asking if
> someone knows it's in what status publicly in a Debian development
> mailing list. Then this may lead to some disclosing and even mislead
> some other people. Yes there are many people doing tests just like
> you, and they are reporting their results in many ways they prefer.
> But as you are a DD you'd better not ignore our Security Team when
> starting discussion publicly about a security incident your are not
> sure whether it's relevant to Debian. People at Security Team are not
> only responsible for fixing things when it breaks out, but also make
> sure sensitive information is being disclosed in a correct form at a
> correct time. In the end, I believe talking with them beforehand is
> always a right way to do, no matter if Debian is affected by this
> particular issue.
>   

The first time I wrote it, it wasn't clear enough. Maybe writing with
CAPS-ON will help your understanding! :)

IT HAS ALREADY BEEN MADE PUBLIC (for example: on slashdot) !!!

Do you get it now? :)

With such security "glitch", how much do you expect from keeping
such a discussion secret, with the security team? I'm telling you,
you'd achieve absolutely nothing. Everyone will know so fast that
it doesn't mater at all. And it's better that everyone in Debian knows
about what's going on, so we have at least a little be of opportunity
to fix what can be before disasters.

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd63b81.2080...@debian.org

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Thijs Kinkhorst]

On Mon, June 11, 2012 20:11, Thomas Goirand wrote:
> On 06/12/2012 01:52 AM, Aron Xu wrote:
>> IMHO I suggest to talk with Security Team before disclosing
>> information that might be sensitive in the mean time on a Debian
>> development mailing list.
>>
> Could you explain to me what exactly I'm disclosing?
> The news is already on slashdot and so on, and I think
> it'd be better to know, as hackers will.

As usual, the appropriate discussion venue for specific public security
issues is a bug against the package tagged security, in this case 677018.
Vulnerability information for the various current distributions can also
be found in the Security Tracker. I don't think there is a need to move
these fora to debian-devel.


Thanks.
Thijs


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/a53561f605ea17ad9be101d9a2e9c8f2.squir...@wm.kinkhorst.nl

Re: DUCK -the Debian Url Checker

[Axel Beckert]

Hi Simon,

Simon Kainz wrote:
> as I had some problems in the past finding upstream sources and
> homepages, I hacked up some scripts to monitor and display the results
> of the Upstream Homepage entries in the package control files.
> 
> Please take a look at http://debian.tugraz.at/duck/

Very cool! And I like that name! :-)

> Currently the job runs once a day and the results are displayed. Maybe
> this is of some use for some maintainers and/or developers.

Indeed!

> One can also search for specific maintainers.

Could you also treat uploaders like maintainers (or similar, i.e. add
some [U] flag if someone is just an Uploader as seen elsewhere in
Debian)? That would help people who are also active in teams but don't
help to maintain all packages in the team.

Another thing I noticed:
http://debian.tugraz.at/duck/?maintainer=pkg-wml-maintain...@lists.alioth.debian.org
-- if I click on the link the ftp directory shows up perfectly in my
browser. Any idea why it's regarded as broken?

Michal already suggested to check also debian/copyright. I would also
love to see to have Vcs-*, at least Vcs-Browser checked. Actually
today I noticed a package where the Vcs repo location moved and is no
more uptodate (mssh FWIW).

Anyway, already now this is a great service!

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120611190848.gb16...@sym.noone.org

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Jonas Smedegaard]

On 12-06-12 at 02:40am, Thomas Goirand wrote:
> On 06/12/2012 02:23 AM, Aron Xu wrote:
> > I'm not saying you are disclosing anything, but you are asking if 
> > someone knows it's in what status publicly in a Debian development 
> > mailing list. Then this may lead to some disclosing and even mislead 
> > some other people. Yes there are many people doing tests just like 
> > you, and they are reporting their results in many ways they prefer. 
> > But as you are a DD you'd better not ignore our Security Team when 
> > starting discussion publicly about a security incident your are not 
> > sure whether it's relevant to Debian. People at Security Team are 
> > not only responsible for fixing things when it breaks out, but also 
> > make sure sensitive information is being disclosed in a correct form 
> > at a correct time. In the end, I believe talking with them 
> > beforehand is always a right way to do, no matter if Debian is 
> > affected by this particular issue.
> >   
> 
> The first time I wrote it, it wasn't clear enough. Maybe writing with 
> CAPS-ON will help your understanding! :)
> 
> IT HAS ALREADY BEEN MADE PUBLIC (for example: on slashdot) !!!

What you asked, and the answer to that question, was not already public.

...or you wouldn't have asked, I hope. ;-)


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Thomas Goirand]

On 06/12/2012 03:17 AM, Jonas Smedegaard wrote:
> What you asked, and the answer to that question, was not already public.
>
> ...or you wouldn't have asked, I hope. ;-)
>
>
>  - Jonas
>   
Actually, it was, and I was expecting to be able to find it, but didn't,
which is why I asked! :)

Thomas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd64649.9070...@debian.org

Migration path for 'Multi-Arch:allowed' packages

[Michael Gilbert]

Hi,

We've been getting a few bug reports from users attempting to install
multiarch wine who have yet to manually enable multiarch itself.
Obviously that is a failure on their part, and is easily correctable.
However, I wonder if we can't make such migrations a bit more
straightforward?

In particular, I filed a bug against dpkg requesting that it produce
more informative error messages in these cases [0], but I wonder if a
part of the solution shouldn't be more automated or at least presented
at a higher level through apt/aptitude, etc?

Also, limitations in the existing testing migration tools are making
wine not considered for wheezy, since those tools don't check whether
dependencies for 'Multi-Arch: allowed' packages are satisfied by
packages on other architectures.

Best wishes,
Mike

[0] http://bugs.debian.org/676822
[1] http://packages.qa.debian.org/w/wine.html


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mp3emp7idyp1dskpx3i4uytum-th42g3ufwwa5bjej...@mail.gmail.com

Re: Migration path for 'Multi-Arch:allowed' packages

[Adam D. Barratt]

On Mon, 2012-06-11 at 15:40 -0400, Michael Gilbert wrote:
> Also, limitations in the existing testing migration tools are making
> wine not considered for wheezy, since those tools don't check whether
> dependencies for 'Multi-Arch: allowed' packages are satisfied by
> packages on other architectures.

What exactly would you expect britney to do here?  Assume that if the
dependencies are satisfiable on /any/ other architecture then
everything's fine?

I guess one could hard-code assumptions in to the (hypothetical) code
like "accept i386 packages for amd64 m-a: allowed", but I'm not sure
that's the right solution.  In any case, the eve of freeze doesn't seem
like a great time to be making non-trivial changes to britney's concept
of installability checking.  YMMV, E&OE.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1339445002.22084.14.ca...@jacala.jungle.funky-badger.org

Re: Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Peter Pöschl]

Seems you overlooked this:

> Debian Unstable 64-bit 5.5.23-2


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201206112253.50532.pp2ml.deb0...@nest-ai.de

Packages up for adoption

[Luca Falavigna]

Hi,

due to lack of time, I intend to give a couple of packages up for adoption:
* remmina (#676894)
* libvncserver (#676895)

The latter is a (build-)dependency of the first, so you may want to
have a look at both if you are interested in maintaining them.

Cheers,
Luca


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cadk7b0pxajselgeh1fgjqvest5k7pnswo4xpy_w+ur2ngtb...@mail.gmail.com

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Bjørn Mork]

Aneurin Price  writes:

> (Note that we are talking about applications which fail gracefully
> when confronted with ENOSPC, 

Are we? What's the problem then?

> but which are likely to do so more often when the size of /tmp is
> restricted.)

Yes, but the tmpfs correlation is weak.  There is absolutely no
guarantee that there will be more space available on the root file
system than a default tmpfs.



Bjørn


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d355pl0v@nemi.mork.no

Re: Planned changes to Debian Maintainer uploads

[Joey Hess]

Ian Jackson wrote:
> >  - It allows DMs to grant permissions to other DMs.
> 
> It is far from clear that forbidding this is the right thing to do.

As far as I know, we did this intentionally. When a DM is the maintainer
of a package, they should be able to move it to team maintenance without
needing to find some DD who cares about the package, who may not exist.

I've never heard of this being abused.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Jonas Smedegaard]

On 12-06-12 at 03:26am, Thomas Goirand wrote:
> On 06/12/2012 03:17 AM, Jonas Smedegaard wrote:
> > What you asked, and the answer to that question, was not already public.
> >
> > ...or you wouldn't have asked, I hope. ;-)
> >
> >
> >  - Jonas
> >   
> Actually, it was, and I was expecting to be able to find it, but didn't,
> which is why I asked! :)

So because it turned out that the information indeed was public, you 
find it ok to ask in public if it is public.


Wauw.  I give up.


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: Digital signature

Re: Idea: mount /tmp to tmpfs depending on free space and RAM

[Aneurin Price]

On 11 June 2012 22:59, Bjørn Mork  wrote:
> Aneurin Price  writes:
>
>> (Note that we are talking about applications which fail gracefully
>> when confronted with ENOSPC,
>
> Are we? What's the problem then?
>

Honestly, I have no idea. It's clear that some people think storing
'large' temporary files in /tmp is 'broken', for unspecified values of
'large', but I don't understand why and nobody seems interesting in
explaining the reasoning when they can just declare it axiomatic. My
best reasoning is that the application shouldn't fail at all in this
case, but should find some way of working despite running out of
storage space. Obviously that would be great, but I can't really
imagine all that many cases where it's likely to be possible (or
really *any* cases where it's likely to be worth going to the extra
trouble).

It does annoy me quite a lot that people are calling applications
broken without even *attempting* to define what they might deign to
call *not* broken.

>> but which are likely to do so more often when the size of /tmp is
>> restricted.)
>
> Yes, but the tmpfs correlation is weak.  There is absolutely no
> guarantee that there will be more space available on the root file
> system than a default tmpfs.

In anything resembling a 'normal' system (ie. the kind where one might
be using the defaults) I would say that the tmpfs correlation is so
strong as to be very nearly 1:1, and this seems like the crux of the
matter; that is after all the reason that these applications are
failing when /tmp is switched to tmpfs.

It is almost a complete certainty that on any given system there will
be more space available on the root filesystem than a default tmpfs,
unless that system has requirements so specific that the choice of
defaults is moot. Sure there's no *guarantee*, but it is exceptionally
likely; if you do seriously believe otherwise (ie. you're not just
pointing out that it *might* not be the case), I'd say that's
sufficiently extraordinary a claim as to require extraordinary
evidence.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cahb+spbfe0zcryetorxbnu0mfdfoncmme_qcykhznyjj73v...@mail.gmail.com

wwwoffle

[Enrico Weigelt]

Hi folks,


I've seen wwwoffle was dropped from Debian and Ubuntu.
As I really need it, I'm willing to step in as maintainer.

I'm currently in process of importing the available releases into
an git repo and adding the latest patches.

I've never really contributed to Debian yet, so please let me
know what should be done here.


thx
-- 
--
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weig...@metux.de
 mobile: +49 151 27565287  icq:   210169427 skype: nekrad666
--
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
--


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120612011246.ga25...@mailgate.onlinehome-server.info

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 2:40 AM, Thomas Goirand  wrote:
> On 06/12/2012 02:23 AM, Aron Xu wrote:
>> I'm not saying you are disclosing anything, but you are asking if
>> someone knows it's in what status publicly in a Debian development
>> mailing list. Then this may lead to some disclosing and even mislead
>> some other people. Yes there are many people doing tests just like
>> you, and they are reporting their results in many ways they prefer.
>> But as you are a DD you'd better not ignore our Security Team when
>> starting discussion publicly about a security incident your are not
>> sure whether it's relevant to Debian. People at Security Team are not
>> only responsible for fixing things when it breaks out, but also make
>> sure sensitive information is being disclosed in a correct form at a
>> correct time. In the end, I believe talking with them beforehand is
>> always a right way to do, no matter if Debian is affected by this
>> particular issue.
>>
>
> The first time I wrote it, it wasn't clear enough. Maybe writing with
> CAPS-ON will help your understanding! :)
>
> IT HAS ALREADY BEEN MADE PUBLIC (for example: on slashdot) !!!
>
> Do you get it now? :)
>

It's YOU that didn't get my point, :)

> With such security "glitch", how much do you expect from keeping
> such a discussion secret, with the security team? I'm telling you,
> you'd achieve absolutely nothing. Everyone will know so fast that
> it doesn't mater at all. And it's better that everyone in Debian knows
> about what's going on, so we have at least a little be of opportunity
> to fix what can be before disasters.
>

I'm not expecting to hide anything, but it's harmful to announce the
world by a discussion in debian-devel that we are affected with no
solution provided, at the time related people (means the maintainers
and Security Team, not including the user - like you) haven't said a
word about it.

If you are trying to informing people to act, then debian-devel is not
a good place, because you can't expect all Debian users are following
our mailing lists, it's YOU want to be sure for something, then
confirm with mysql's maintainer and/or Security Team will give you a
certain answer. debian-devel is not a place for collecting random
trying discoveries for security related issues anyway.



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w7wdcxsinarakgyjmcunbsdachultnyroj4_0b1k4z...@mail.gmail.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Aron Xu]

On Tue, Jun 12, 2012 at 2:39 AM, Clint Adams  wrote:
> On Tue, Jun 12, 2012 at 02:23:47AM +0800, Aron Xu wrote:
>> sure whether it's relevant to Debian. People at Security Team are not
>> only responsible for fixing things when it breaks out, but also make
>> sure sensitive information is being disclosed in a correct form at a
>> correct time. In the end, I believe talking with them beforehand is
>> always a right way to do, no matter if Debian is affected by this
>> particular issue.
>
> Coordinated disclosure is irresponsible, and we shouldn't do it.
>

Then it's better to start the discussion at debian-security@l.d.o or
at least start a new thread, :) Currently our Security Team is tend to
coordinate disclosures, I think (but I'm not a team member, of
course).



-- 
Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAMr=8w5royoyascd1wppvjma3mwk10jquopn5dkxggse2y0...@mail.gmail.com

Bug#677174: RFA: python-minimock -- simple library for Python mock objects

[Ben Finney]

Package: wnpp
Severity: normal

I have not been an active user of ‘python-minimock’ for a while, and no
longer want to maintain the package. If someone else want to take over
maintaining this package, I would be happy to help the transition.

It has packaging files under VCS, and a recent release of the latest
upstream version (1.2.7) in Debian.

-- 
 \   “As far as the laws of mathematics refer to reality, they are |
  `\not certain, and as far as they are certain, they do not refer |
_o__)  to reality.” —Albert Einstein, 1983 |
Ben Finney 



--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bokp5k63@benfinney.id.au

Re: wwwoffle

[Paul Wise]

On Tue, Jun 12, 2012 at 9:12 AM, Enrico Weigelt wrote:

> I've seen wwwoffle was dropped from Debian and Ubuntu.
> As I really need it, I'm willing to step in as maintainer.
>
> I'm currently in process of importing the available releases into
> an git repo and adding the latest patches.
>
> I've never really contributed to Debian yet, so please let me
> know what should be done here.

Please read through some of these pages:

http://www.debian.org/doc/manuals/maint-guide/
http://mentors.debian.net/intro-maintainers

Most of the steps are the same as introducing a new package. So you
need to file an ITP bug, do the package update, upload to mentors.d.n
and then look for a sponsor.

SInce you are reintroducing the package:

You should take the latest Debian packaging from the Debian wayback
machine instead of from any older version:

http://snapshot.debian.org/package/wwwoffle/

You should also unarchive and reopen all the bugs that were closed in
a version ending in +rm. If there are any such bugs that got fixed
upstream, you should close those via debian/changelog as usual:

http://bugs.debian.org/cgi-bin/pkgreport.cgi?archive=both;dist=unstable;package=wwwoffle
http://www.debian.org/Bugs/server-control
http://packages.qa.debian.org/w/wwwoffle.html

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAKTje6GzQfcG0KSsqkqmb_vb9TE=hnafefgkgvek5nvpop4...@mail.gmail.com

Re: DUCK -the Debian Url Checker

[Simon Kainz]

On 06/11/12 21:08, Axel Beckert wrote:
> Hi Simon,
Hi Axel,
> 
> Simon Kainz wrote:
>> as I had some problems in the past finding upstream sources and
>> homepages, I hacked up some scripts to monitor and display the results
>> of the Upstream Homepage entries in the package control files.
>>
>> Please take a look at http://debian.tugraz.at/duck/
> 
> Very cool! And I like that name! :-)
> 
>> Currently the job runs once a day and the results are displayed. Maybe
>> this is of some use for some maintainers and/or developers.
> 
> Indeed!
> 
>> One can also search for specific maintainers.
> 
> Could you also treat uploaders like maintainers (or similar, i.e. add
> some [U] flag if someone is just an Uploader as seen elsewhere in
> Debian)? That would help people who are also active in teams but don't
> help to maintain all packages in the team.
> 

ok, I'll think about that - good idea.

> Another thing I noticed:
> http://debian.tugraz.at/duck/?maintainer=pkg-wml-maintain...@lists.alioth.debian.org
> -- if I click on the link the ftp directory shows up perfectly in my
> browser. Any idea why it's regarded as broken?

Umm, yes - that is a false positive: FTP return 226/227, which tells me
the file transfer was successful (
http://en.wikipedia.org/wiki/List_of_FTP_server_return_codes ). I
treated codes >200 as "warning", so it showed up in the list - sorry,
I'll fix this.

> 
> Michal already suggested to check also debian/copyright. I would also
> love to see to have Vcs-*, at least Vcs-Browser checked. Actually
> today I noticed a package where the Vcs repo location moved and is no
> more uptodate (mssh FWIW).

Code for VCS-* is already there ( in fact, I started with this some
weeks ago). I definitly will incorporate VCs-* check results in the
list. Also I'm working on code for links found in Description: fields.


> 
> Anyway, already now this is a great service!
> 

Thanks !
>   Regards, Axel

Cheers, Simon


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd6d415.30...@familiekainz.at

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Christian PERRIER]

Quoting Thomas Goirand (z...@debian.org):

> The first time I wrote it, it wasn't clear enough. Maybe writing with
> CAPS-ON will help your understanding! :)
> 
> IT HAS ALREADY BEEN MADE PUBLIC (for example: on slashdot) !!!


The debian-security mailing list is a public list.

My stance about security issues (and, by looking at samba's changelog,
you can see that I dealt with many, now...):

- when public, discuss them with the security team through the
debian-security mailing list

- when not yet public, discuss them with t...@security.debian.org

In both cases, our security team is very helpful and reactive.




signature.asc
Description: Digital signature

Re: Handling of changelogs and bin-nmus

[Raphael Hertzog]

Hi,

On Sun, 10 Jun 2012, Andreas Barth wrote:
> Asking to be sure: For sbuild, that means instead of changing the file
> debian/changelog before starting the build, a new file
> debian/changelog.binary-rebuild (or however it is named) is created
> and from there on all works "by itself"?

That's the idea, yes.

> Do we have other tools than dpkg that parse the changelog to find out
> the package version? How far are we away from getting that
> implemented once we decide we want that?

Why other than dpkg? In any case, we have dpkg-parsechangelog. And I guess
you probably refer to sbuild where you want to grab the version number.
It could use the Dpkg::Changelog modules from libdpkg-perl. It already
uses those modules for various purposes.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120611045351.gb13...@rivendell.home.ouaza.com

Re: Is Debian affected by the recent MySQL sql/password.c flow?

[Thomas Goirand]

On 06/12/2012 10:25 AM, Aron Xu wrote:
> I'm not expecting to hide anything, but it's harmful to announce the
> world by a discussion in debian-devel that we are affected with no
> solution provided, at the time related people (means the maintainers
> and Security Team, not including the user - like you) haven't said a
> word about it.
>   
If Debian was affected (which it seems it is not), you wouldn't be able
to keep that secret for more than few minutes. You can be 100% sure
that a bunch of hackers would already be playing with your MySQL
server. And this, even before you hear about this.

If  such a disaster happens, then it's better to know asap, so critical
servers can be patched asap too (even before Debian releases or
announces anything). The harm would be to believe not posting in
debian-devel is changing anything.

I agree I should have posted in debian-security@l.d.o though.

Thomas

p.s: Anyway, it seems we're safe this time, even in SID! :)


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4fd6e6ba.8060...@debian.org

Bug#677182: ITP: libguac-client-rdp -- RDP client plugin for Guacamole

[Mike Jumper]

Package: wnpp
Severity: wishlist
Owner: Mike Jumper 


* Package name: libguac-client-rdp
  Version : 0.6.0
  Upstream Author : Mike Jumper 
* URL : http://guac-dev.org/
* License : MPL-1.1 or GPL-2.0 or LGPL-2.1
  Programming Lang: C
  Description : RDP client plugin for Guacamole

 A plugin for the Guacamole proxy daemon (guacd) that provides
 support for the RDP protocol (Windows Remote Desktop).



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20120612065419.11769.9547.report...@test1.guac-dev.org