Re: Explications needed...

[Mike Hommey]

On Fri, Dec 29, 2006 at 07:58:34AM +0100, Sven Luther <[EMAIL PROTECTED]> wrote:
> Don't you find it a bit hypocrit to have x86 uploads go directly to the
> archive, and not allowing even a single day delay which would allow to stop
> unclean DD-build-boxes breakage and a clean state, and on the other day let
> the other arches depend on the good will of the buildd maintainer, who is
> usually a single person, who doesn't communicate much, and who sometimes is
> not able to sign and thus upload the packages for a couple of days (sometimes
> more even, but i guess this is the exception).

It's even better than this. The DD could upload on any arch and let
buildds do the job for the others. The arch could even be arm.

Mike


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

tmpnam usage warning

[Colin Tuckley]

I'm doing some work on a Basic Interpreter and will be packaging it for Debian.

The interpreter allows the user to execute shell commands, this is
implemented using the "system" call.

To capture the output from the command " > " is concatenated onto
the end of the user supplied command. The  is generated by a call
to "tmpnam".

This causes a warning "the use of `tmpnam' is dangerous, better use `mkstemp'".

I'd like to fix this, but how? tmpnam generates a name for a file which is
guaranteed *not* to exist, which is ideal in this situation since the output
from the command run by system is redirected to it and the file can then be
opened once the command has finished.

"mkstemp" however gives me a handle to a guaranteed uniquely named file
which is already open and which gets deleted when it's closed.

What is the best solution to this problem?

regards,

Colin

-- 
Colin Tuckley  |  [EMAIL PROTECTED]  |  PGP/GnuPG Key Id
+44(0)1903 236872  |  +44(0)7799 143369  | 0x1B3045CE

A door is what a cat is perpetually on the wrong side of. - adapted from
Ogden Nash


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

Re: Explications needed...

[Josselin Mouette]

Le jeudi 28 décembre 2006 à 16:45 -0800, Steve Langasek a écrit :
> So first of all, neither the debian-arm list, nor the #debian-arm channel,
> nor his blog are a communication medium that's guaranteed to reach the arm
> buildd maintainer *or* the buildd local admins.  For the former, you want
> [EMAIL PROTECTED]; for the latter, there is no list of contacts other
> than the buildd maintainer, since these may change semi-frequently and most
> buildd changes need to be coordinated with the buildd maintainer anyway.

An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not
doing his job as buildd maintainer. You can't pretend to be the one
handling builds for the whole archive while not following discussions
around problems specific to this architecture. Would you trust a release
manager who wouldn't be reading debian-release?

> If he only uploads packages that haven't been built by the autobuilders, or
> failed to build on the autobuilders, we still have the problem that there is
> no single party who can account for the configuration of all the buildds
> that were used for uploading packages, because there has been no
> coordination -- so building these packages on rogue autobuilders is a poor
> predictor of whether the autobuilders will be able to build them again later
> when a security update is needed.  Indeed, in the case of Aurelien's
> buildds, we have the additional variable of using emulated arm systems -- I
> don't know what ARM instruction set qemu emulates, and I don't know who else
> among the ARM porters knows, maybe it's been discussed and maybe it hasn't,
> but it's definitely another variable that contributes to these buildds being
> a poor predictor for the official autobuilders.

Please, let's be consistent. How is it any different to the sourceful
upload case? In fact, I trust Aurélien's buildd much more than my own
sourceful uploads; last month I have broken an amd64 package by not
building it within the right chroot, while this cannot happen with his
buildd using the same software setup as the official buildd network.

> Uploading packages like this is an expedient fix that does nothing to help,
> and possibly quite a bit to hinder, long-term support for etch.  We want to
> fix autobuilder problems, not cover them up.

Then let's fix them, now. For example, by making Aurélien an arm buildd
maintainer. Unless you want etch to be delayed for 6 months because of
missing buildd infrastructure, but things like that could never happen,
could they?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


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

ОРГАНИАЗЦИЯ КОНЦЕРТОВ

[Natalia Velasquez]

  ОРГАНИЗАЦИЯ ПРАЗДНИКОВ
  Организация шоу-программ с участием артистов
Подбор места праздника
Звуковое и световое обеспечение
  Создание сценария
  Фото и видео съемка
  Стриптиз (женский и мужской)

  И многое другое
  ЗВОНИТЕ СЕЙЧАС!
  (495)792 77 31

Re: tmpnam usage warning

[Steinar H. Gunderson]

On Fri, Dec 29, 2006 at 10:17:55AM +, Colin Tuckley wrote:
> The interpreter allows the user to execute shell commands, this is
> implemented using the "system" call.
>
> [...]
>
> What is the best solution to this problem?

Why can't you just set up a pipe, fork, connect stdout of the child to one
end of the pipe, and exec the program?

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


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

Re: Explications needed...

[MJ Ray]

Josselin Mouette <[EMAIL PROTECTED]> wrote:
> An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not
> doing his job as buildd maintainer.

Please show where reading everything on [EMAIL PROTECTED] is
given as a requirement for buildd maintainership.

> You can't pretend to be the one
> handling builds for the whole archive while not following discussions
> around problems specific to this architecture.

Similarly, people can't pretend that mailing debian-$arch is a
substitute for emailing [EMAIL PROTECTED] (which is in the
buildd section of the devel-ref).

In message http://lists.debian.org/debian-project/2006/12/msg00161.html
and the parent of
http://lists.debian.org/debian-project/2006/12/msg00155.html
Aurelien Jarno comments about emailing [EMAIL PROTECTED], so what
has this [EMAIL PROTECTED] vs [EMAIL PROTECTED] to do with anything?

> Would you trust a release
> manager who wouldn't be reading debian-release?

I'd trust one who didn't read eveything on debian-release.


I'm uncertain about who did what on the whole RogueOrNot buildd, but
much of that email seems to be unhelpful.  This looks like an old
problem: the project doesn't recover gracefully if people in its
organizational structure become unresponsive.  Any bright ideas on how
to fix that?

Regards,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: tmpnam usage warning

[Colin Tuckley]

Steinar H. Gunderson wrote:

> Why can't you just set up a pipe, fork, connect stdout of the child to one
> end of the pipe, and exec the program?

Thanks, reading about 'pipe' led me to 'popen' which pretty much
automatically does what you suggest.

regards,

Colin

-- 
Colin Tuckley  |  [EMAIL PROTECTED]  |  PGP/GnuPG Key Id
+44(0)1903 236872  |  +44(0)7799 143369  | 0x1B3045CE

A door is what a cat is perpetually on the wrong side of. - adapted from
Ogden Nash


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

Re: Explications needed...

[Julien BLACHE]

Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote:

> It seems common sense! Debian has a serious problem if you have to
> write everything down.
>
> "A buildd maintainer must be able to type Unix commands on a
> keyboard."

"And the said keyboard must be connected one way or another to the
said buildd, which must be powered up and booted"

While we're at it ... unfortunately common sense isn't exactly common
anymore these days.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: Explications needed...

[Stephane Bortzmeyer]

On Fri, Dec 29, 2006 at 11:36:45AM +,
 MJ Ray <[EMAIL PROTECTED]> wrote 
 a message of 43 lines which said:

> > An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not
> > doing his job as buildd maintainer.
> 
> Please show where reading everything on [EMAIL PROTECTED] is
> given as a requirement for buildd maintainership.

It seems common sense! Debian has a serious problem if you have to
write everything down.

"A buildd maintainer must be able to type Unix commands on a
keyboard."


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

Bug#404932: ITP: xserver-xorg-input-evtouch -- Evtouch is a Touchscreen-Driver for X.

[Mattia Dongili]

Package: wnpp
Severity: wishlist
Owner: Mattia Dongili <[EMAIL PROTECTED]>

* Package name: xserver-xorg-input-evtouch
  Version : 0.8.1
  Upstream Author : Kenan Esau <[EMAIL PROTECTED]>
* URL : http://stz-softwaretechnik.com/~ke/touchscreen/evtouch.html
* License : BSD style
  Programming Lang: C
  Description : Evtouch is a Touchscreen-Driver for X.

This XFree/Xorg driver provides support for touchscreens input devices.
The driver is actually an evdev-driver which supports events for moving
in absolute coordinates, relative coordinates and mouse-buttons.

The source package is xf86-input-evtouch.

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (990, 'testing'), (300, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.20-rc2-mm1-1
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1)
-- 
mattia
:wq!


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

Re: Explications needed...

[Pierre Habouzit]

On Thu, Dec 28, 2006 at 04:45:32PM -0800, Steve Langasek wrote:
> On Thu, Dec 21, 2006 at 11:39:13AM +0100, Aurelien Jarno wrote:
> > All started with this email:
> > http://lists.debian.org/debian-arm/2006/08/msg00151.html
> 
> > ARM was *in danger*, a lot of stuff (java, xulrunner, mono, ...) were
> > not working correctly. People worked hard to fix that, but it was very
> > difficult to get packages depending on fixed stuff to get requeued. Also
> > a lot of "arch-specific compile errors" were actually due to build
> > daemon problems.
> 
> Yes, let's be clear here: ARM was in danger because of a large number of
> packages that were *not buildable*, not just because they weren't built. 
> The call for help was in identifying the reasons for the build failures so
> that the underlying problems could be fixed, *not* for hand-building
> packages and ignoring the implications for security support.

  I feel it's deeper than that:

  now that aurélien completely stopped to upload non built packages at
all (a thing he did on a regular basis before, and just automated with
his "rogue" autobuilder) just look at [1], whereas every single arch is
keeping up quietly, arm and sparc seem to go to the deepness of hell. I
don't know who are the sparc buildd admins, but for sure, the arm port
do not seem to be that well.


  [1] http://buildd.debian.org/stats/graph2-week-big.png
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpQfh48olDgF.pgp
Description: PGP signature

Re: Explications needed...

[MJ Ray]

Stephane Bortzmeyer <[EMAIL PROTECTED]> wrote:
>  MJ Ray <[EMAIL PROTECTED]> wrote 
> > Please show where reading everything on [EMAIL PROTECTED] is
> > given as a requirement for buildd maintainership.
>
> It seems common sense!

Huh?  It seems common sense that most subscribers ignore at least some
list emails, particularly on unguided lists like debian ones.  This
has been common for years.  See these links from 1999 and 1998:
http://cmc.dsv.su.se/select/coping-with-too-much-email/#filtering
http://cmc.dsv.su.se/select/information-filtering.html

> Debian has a serious problem if you have to
> write everything down.
>
> "A buildd maintainer must be able to type Unix commands on a
> keyboard."

I agree.  It seems silly if we must write "buildd maintainers do not
have to read all emails to debian-$arch".

So, back to the more general problem: how should the project handle
bits of the organization going silent?

Regards,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Explications needed...

[Kurt Roeckx]

On Fri, Dec 29, 2006 at 11:20:30AM +0100, Josselin Mouette wrote:
> An arm buildd maintainer not reading [EMAIL PROTECTED] is simply not
> doing his job as buildd maintainer. You can't pretend to be the one
> handling builds for the whole archive while not following discussions
> around problems specific to this architecture.

I think you're confusing the buildd admin with the porters.  I expect
porters to read the [EMAIL PROTECTED] list, I don't expect
the same from the buildd admin.

The buildd admin's job is getting packages built, while the porter's is
to deal with architecture specific issues.

The buildd admins aren't always also porters for that arch.  But I
think it would be a good thing that (some) porters also see all the
buildd logs.  That way they know alot faster about problems the port
might have.


Kurt


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

Bell's theorem refuted. More information at ...

[Ilija Barukcic]

Jever, 29.12.2006.

Bell's theorem is refuted!

If you need more information, please download for free: 

http://www.barukcic-causality.homepage.t-online.de/Causation/Causation_2006_Volume_2.pdf
 .

Happy new year.

Ilija


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

Re: Explications needed...

[Russ Allbery]

Mike Hommey <[EMAIL PROTECTED]> writes:
> Sven Luther <[EMAIL PROTECTED]> wrote:

>> Don't you find it a bit hypocrit to have x86 uploads go directly to the
>> archive, and not allowing even a single day delay which would allow to
>> stop unclean DD-build-boxes breakage and a clean state, and on the
>> other day let the other arches depend on the good will of the buildd
>> maintainer, who is usually a single person, who doesn't communicate
>> much, and who sometimes is not able to sign and thus upload the
>> packages for a couple of days (sometimes more even, but i guess this is
>> the exception).

> It's even better than this. The DD could upload on any arch and let
> buildds do the job for the others. The arch could even be arm.

Indeed, I've started occasionally uploading some of my packages as amd64
instead of x86 precisely so that they'll autobuild on x86 and I can notice
any problems that for some reason my local pbuilder environment didn't
pick up.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Bug#374997: ITP: utf8-migration-tool -- tool to migrate a Debian system to UTF-8

[Vincent Bernat]

OoO  En cette  fin de  matinée radieuse  du lundi  26 juin  2006, vers
11:19, Martin-Éric Racine <[EMAIL PROTECTED]> disait:

> That is a leftover from Tollef's original code in wizard.py, where the
> UI colors are hard-coded, rather than inherited via the GTK theme.

> I can see the lines where this is taking place, but I'm not familiar
> enough with GTK coding to know how to fix it.

IMO, the best way would be  to remove colors. The application is still
good  looking without  them and  this work  even with  white  on black
theme. Just suppress all lines containing "color" in wizard.py.

Here is a patch :

--- wizard.py~	2006-06-26 01:17:20.0 +0200
+++ wizard.py	2006-12-29 19:49:20.0 +0100
@@ -160,10 +160,6 @@
 pass
 
 class Wizard(gobject.GObject):
-sidebar_color = gtk.gdk.color_parse('#cc')
-main_color = gtk.gdk.color_parse('#ff')
-sidebar_active_color = gtk.gdk.color_parse('#99')
-
 __gsignals__ = {
 'finished' : (gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE,
   ())
@@ -175,8 +171,6 @@
 for widget in self.wtree.get_widget_prefix(''):
 setattr(self, widget.get_name(), widget)
 self.wtree.signal_autoconnect(self)
-self.eventbox_top.modify_bg(gtk.STATE_NORMAL, self.sidebar_color)
-self.eventbox_main.modify_bg(gtk.STATE_NORMAL, self.main_color)
 self._use_main = True
 self.steps = []
 self.stack = Stack()
@@ -399,7 +393,6 @@
 else:
 parent = self.eventbox_sidebar
 
-parent.modify_bg(gtk.STATE_NORMAL, self.sidebar_color)
 self.vbox_sidebar = gtk.VBox()
 self.vbox_sidebar.set_border_width(5)
 self.vbox_sidebar.set_size_request(200, -1)
@@ -417,8 +410,6 @@
 
 text = escape(name)
 button = gtk.Button('')
-button.modify_bg(gtk.STATE_PRELIGHT, self.sidebar_active_color)
-button.modify_bg(gtk.STATE_ACTIVE, self.sidebar_active_color)
 
 label = button.get_children()[0]
 label.set_padding(padding, 0)
@@ -446,10 +437,10 @@
 button.set_sensitive(False)
 
 if not active and not step.visited:
-markup = '%s' % name
+markup = '%s' % name
 button.set_sensitive(False)
 else:
-markup = '%s' % (name)
+markup = '%s' % (name)
 button.set_property('can_focus', False)
 
 label.set_markup(markup)

-- 
printk(KERN_WARNING "Warning: defective CD-ROM (volume sequence
number). Enabling \"cruft\" mount option.\n");
2.2.16 /usr/src/linux/fs/isofs/inode.c

Re: Explications needed...

[Clint Adams]

> I think you're confusing the buildd admin with the porters.  I expect

Maybe that's because the buildd admins used to be the porters, and then,
for some reason I do not understand, this mysteriously stopped being
true.


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

Re: tmpnam usage warning

[Joey Hess]

Colin Tuckley wrote:
> tmpnam generates a name for a file which is guaranteed *not* to exist

No, tmpnam generates a name for a file that did not exist at some point
in time, but that *will* exist in the worst possible state (eg, a
symlink to something important) when an attacker is targeting your program.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Bell's theorem refuted. More information at ...

[John H. Robinson, IV]

Ilija Barukcic wrote:
> 
> Bell's theorem is refuted!

I submit this as the oddest spam on a Debian list this year.

-- 
John H. Robinson, IV  [EMAIL PROTECTED]
 http  
WARNING: I cannot be held responsible for the above, sbih.org ( )(:[
as apparently my cats have learned how to type.  spiders.html  


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

Re: tmpnam usage warning

[Colin Tuckley]

Joey Hess wrote:

> No, tmpnam generates a name for a file that did not exist at some point
> in time, but that *will* exist in the worst possible state (eg, a
> symlink to something important) when an attacker is targeting your program.

Which is why I'm trying to find a way to get rid of the calls to it in the
program I'm packaging.

regards,

Colin

-- 
Colin Tuckley  |  [EMAIL PROTECTED]  |  PGP/GnuPG Key Id
+44(0)1903 236872  |  +44(0)7799 143369  | 0x1B3045CE

"Heisenberg may have slept here"


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

Bug#404978: ITP: gktools -- GUI utilities for managing Kerberos V tickets

[Cedric Delfosse]

Package: wnpp
Severity: wishlist
Owner: Cedric Delfosse <[EMAIL PROTECTED]>

* Package name: gktools
  Version : 0.10.2
  Upstream Author : Nils O. Selåsdal 
* URL : http://asgaard.homelinux.org/code/gktools/
* License : GPL
  Programming Lang: C
  Description : GUI utilities for managing Kerberos V tickets

 Contains two GNOME tools for managing Kerberos V tickets:
  - gkinit: obtains Kerberos ticket-granting tickets (similar to kinit),
  - gktickets: Lists and monitors the tickets obtained for the user.
 
-- System Information:
Debian Release: 4.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-3-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)

Re: Bug#374997: ITP: utf8-migration-tool -- tool to migrate a Debian system to UTF-8

[Martin-Éric Racine]

pe, 2006-12-29 kello 19:50 +0100, Vincent Bernat kirjoitti:
> OoO  En cette  fin de  matinée radieuse  du lundi  26 juin  2006, vers
> 11:19, Martin-Éric Racine <[EMAIL PROTECTED]> disait:
> 
> > That is a leftover from Tollef's original code in wizard.py, where the
> > UI colors are hard-coded, rather than inherited via the GTK theme.
> 
> > I can see the lines where this is taking place, but I'm not familiar
> > enough with GTK coding to know how to fix it.
> 
> IMO, the best way would be  to remove colors. The application is still
> good  looking without  them and  this work  even with  white  on black
> theme. Just suppress all lines containing "color" in wizard.py.
> 
> Here is a patch :

Thanks for the patch! I have merged it and updated the source package. 
It's waiting for someone to review it and sponsor it, at the same URL.

-- 
Martin-Éric Racine
http://q-funk.iki.fi


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

Bug#404985: ITP: libauthen-simple-http-perl -- Simple HTTP authentication

[Xavier Oswald]

Package: wnpp
Severity: wishlist
Owner: Xavier Oswald <[EMAIL PROTECTED]>


* Package name: libauthen-simple-http-perl
  Version : 0.2
  Upstream Author : Christian Hansen <[EMAIL PROTECTED]>
* URL : 
http://search.cpan.org/CPAN/authors/id/C/CH/CHANSEN/Authen-Simple-HTTP-0.2.tar.gz
* License : GPL
  Programming Lang: Perl
  Description : Simple HTTP authentication

This package allow to use HTTP authentication methods.
 
It uses the libauthen-simple-perl framework. 

-- System Information:
Debian Release: 3.1
Architecture: powerpc (ppc)
Kernel: Linux 2.6.8-powerpc
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)


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