Re: bits from the release team
On Thu, May 04, 2006 at 08:07:45PM -0400, Joey Hess wrote: > Goswin von Brederlow wrote: >> Having the key in the debian-keyring package was a nice idea but >> ultimatly useless. Sarge users can't fetch the new etch keyring >> package because the signature doesn't match and the signature >> doesn't match because the sarge keyring doesn't have the key. Fun >> fun fun. > FWIW, I consider this issue solved by the debian-archive-keyring, > only issue I know if is that upgrades have to manually upgrade it > before upgrading apt. Why can't we have a master key that signs the yearly keys? After all, we have a long-term unique X.509 master key, so what's the difference with OpenPGP? -- Lionel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Easy way to incorporate Ubuntu improvements back into Debian?
Hi, Ubuntu benefits alot from Debian. They have custom development tools for streamlining the process of taking Debian packages and making them into Ubuntu packages. I'm curious: does the reverse of this exist for the convenience of Debian Developers somehow? For example (just a thought): how about a Debian Developer receiving an email every time Ubuntu has added something (possibly juicy) to a Debian package (that the DD maintains) upon Ubuntu adding it? In this way, the juicy bits that Ubuntu adds could possibly get back to into Debian quicker. What processes, infrastructure and tools are in place to streamline Debian integrating improvements Ubuntu makes? The reason I ask is that there are several huge usability improvements that Ubuntu has over Debian that I would love to see in Debian. What are the chances of Debian catching up to the quantum leap in usability that Ubuntu has added in Etch? Has Ubuntu been consistent in sending all these goodies back upstream to Debian (or farther)? It seems to me that Ubuntu is getting alot more out of their friendship with Debian, than Debian gets out of Ubuntu. Anyone have comments on this? Please correct me if I'm wrong, and examples would be great. Does Debian get lots of benefits from Ubuntu (in the software) that I'm unaware of? Don't get me wrong, I deeply dig Ubuntu and Debian. I would just like to get a pulse for who is benefiting more (and by how much) out of the relationship, and hear some technical examples of processes and instances of these benefits (especially in the direction of Ubuntu to Debian). Cheers, -- Dustin Harriman http://annexia.ca My Blog's RSS feed: https://annexia.ca/news/RSS -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Policy version
Hi, On Thu, 04 May 2006, Joe Smith wrote: > It seems to me that it is unreasonable for the PTS to be updated before the > policy package actually hits the mirrors. > There is a period of time after a package leaves incomming but before the > mirrors are updated when the package is difficult to > obtain. Frankly, I updated it a bit soon, right, but that was only because 3.7.2 revert the cgi-lib stuff and the PTS will let people notice that there's a newer version and that they must take care... And do we really need to complain of something that is broken for a few hours and that's will resolve itself alone in a few hours? /me wishes people wouldn't complain when we're actually fast Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: the BTS gains a remote bug tracking feature for free !
Le Ven 5 Mai 2006 05:49, Anthony DeRobertis a écrit :
> On Wed, May 03, 2006 at 01:21:41PM +0200, Pierre Habouzit wrote:
> > * the forward canonization is vital for things like tracking
> > bugzilla's "merges" (it in fact rewrites a
> > $(uri)/show_bug.cgi?old_nnn into the $(uri)/show_bug.cgi?new_nnn)
>
> Out of curiosity, how does it handle un-merges in Bugzilla?
it does not. In fact I even didn't knew it was possible, even if when I
think about it, it's obvious it should ;)
I could obviously use usertags to tell "That bug was merged from NNN to
MMM, and at each cron see if the NNN bug is unmerged, and go back
there".
Could you please point me to an UNMERGED bug to see what it looks like ?
(an URL to the {status=closed ; resolution=merged} bug that was reopen,
as well as the bug in was merged "into").
I promise I'll put that on the TODO list if it looks feasible, even if
I've most urgent features to work on. I consider this is seldom enough
to ignore it quite safely for the moment.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpDMbcPJvgE2.pgp
Description: PGP signature
Re: Compiling packages for the standard distribution with -Os instead of -O2
On Thu, May 04, 2006 at 11:54:44PM -0400, Anthony DeRobertis wrote: > If gcc generally generates faster code with -Os than -O2, then isn't > that a gcc bug, in that the optimizations enabled by -O2 are incorrectly > picked? The problem is, "faster" is not a well-defined term. Faster when? I can well imagine that -O2 code is faster (maybe a LOT faster) as long as all of your code fits inside the CPU cache. Cache misses nowadays are very expensive, so if you have a large cache footprint (do words like GNOME, KDE, Mozilla ring a bell?), using -Os may improve the overall performance even when all the code pieces are slower when you benchmark them individually. I think someone should come up with exact numbers (performance regressions vs. actual size reduction) before a decision can be made. My personal opinion is that there is no single choice that is good for the whole project; I expect performance-critical things like compression or stream-processing software (like OpenSSL or web servers) to benefit from -O2, while desktop environments (GNOME, KDE) may benefit from -Os. Also worth considering that the kernel still marks the usage of -Os as experimental because of known gcc breakages in the past. Using -Os on a large scale may well discover new and interesting compiler bugs. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: System users and valid shells...
Richard A Nelson <[EMAIL PROTECTED]> writes: > On Wed, 3 May 2006, Colin Watson wrote: > > > The rest of the system accounts are happily running with /bin/false > There is now /bin/nologin which is more secure Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emacs out for lunch?
Steve Langasek <[EMAIL PROTECTED]> wrote: > On Thu, May 04, 2006 at 06:08:46PM +0200, Frank Küster wrote: >> Yes, http://bugs.debian.org/365597 >> >> Although the bug is still marked open, it's at least "fixed enough" now >> that the package builds again. > > No it isn't. I've successfully built emacs21 on sid (i386) with (I think) xaw3dg-dev_1.5+E-12, in other words the version which lacked all xlibs dependencies. I was surprised, but I guess emacs21 has all xlibs needed by xaw3dg-dev already as direct build-deps. And the latest buildd attempt was on sparc, and it is "maybe-successful": http://buildd.debian.org/fetch.php?&pkg=emacs21&ver=21.4a-3.1&arch=sparc&stamp=1146691993&file=log&as=raw It used xaw3dg-dev_1.5+E-14. Regards, Frank -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
Re: Emacs out for lunch?
On Fri, May 05, 2006 at 10:13:58AM +0200, Frank Küster wrote: > Steve Langasek <[EMAIL PROTECTED]> wrote: > > On Thu, May 04, 2006 at 06:08:46PM +0200, Frank Küster wrote: > >> Yes, http://bugs.debian.org/365597 > >> Although the bug is still marked open, it's at least "fixed enough" now > >> that the package builds again. > > No it isn't. > I've successfully built emacs21 on sid (i386) with (I think) > xaw3dg-dev_1.5+E-12, in other words the version which lacked all xlibs > dependencies. I was surprised, but I guess emacs21 has all xlibs needed > by xaw3dg-dev already as direct build-deps. Or you're building in an unclean chroot. The *only* X dev package emacs21 build-depends on is xaw3dg-dev; so if emacs21 built for you even with the broken version of xaw3dg-dev, that should tell you something about your build environment. > And the latest buildd attempt was on sparc, and it is > "maybe-successful": An accident of the build environment -- it looks like mrpurply had libxaw-dev already installed in the chroot. Every other buildd has failed to build emacs21 using xaw3dg-dev; furthermore, the failure has been analyzed and the bug against emacs21 reopened... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Easy way to incorporate Ubuntu improvements back into Debian?
On Fri, May 05, 2006 at 12:09:01AM -0700, Dustin Harriman wrote: > Ubuntu benefits alot from Debian. They have custom development tools > for streamlining the process of taking Debian packages and making them > into Ubuntu packages. > > I'm curious: does the reverse of this exist for the convenience of > Debian Developers somehow? For example (just a thought): how about a > Debian Developer receiving an email every time Ubuntu has added > something (possibly juicy) to a Debian package (that the DD maintains) > upon Ubuntu adding it? In this way, the juicy bits that Ubuntu adds > could possibly get back to into Debian quicker. > > What processes, infrastructure and tools are in place to streamline > Debian integrating improvements Ubuntu makes? See the Utnubu project (on Alioth). Having automatic mail notifications and the like was discussed, but many DDs did not want anything to do with it, so the idea was quickly dropped. > The reason I ask is that there are several huge usability improvements > that Ubuntu has over Debian that I would love to see in Debian. What > are the chances of Debian catching up to the quantum leap in usability > that Ubuntu has added in Etch? Has Ubuntu been consistent in sending > all these goodies back upstream to Debian (or farther)? > > It seems to me that Ubuntu is getting alot more out of their friendship > with Debian, than Debian gets out of Ubuntu. Anyone have comments on > this? Please correct me if I'm wrong, and examples would be great. > Does Debian get lots of benefits from Ubuntu (in the software) that I'm > unaware of? ... GNOME, Xorg, et al. signature.asc Description: Digital signature
Re: Easy way to incorporate Ubuntu improvements back into Debian?
On Friday 05 May 2006 11:24, Daniel Stone wrote: > > It seems to me that Ubuntu is getting alot more out of their friendship > > with Debian, than Debian gets out of Ubuntu. Anyone have comments on > > this? Please correct me if I'm wrong, and examples would be great. > > Does Debian get lots of benefits from Ubuntu (in the software) that I'm > > unaware of? > > ... GNOME, Xorg, et al. Hi all! I just wanted to ask if there is any plans to package Xgl in debian soon? I have tryed building current package found in ubuntu but it failed... Compiz was building ok BTW... Romain
Re: Compiling packages for the standard distribution with -Os instead of -O2
Anthony DeRobertis wrote: > On Wed, May 03, 2006 at 11:02:57AM -0300, Henrique de Moraes Holschuh wrote: > > > For Etch and Sid, it is probably a good idea to use -Os instead of -O2 at > > least on the bigger arches (ia32, ia64, amd64, etc), as we can probably > > trust gcc not to screw up. > > If gcc generally generates faster code with -Os than -O2, then isn't > that a gcc bug, It doesn't do so generally. >in that the optimizations enabled by -O2 are incorrectly picked? The compiler can only make some broad assumptions about the CPU's memory/cache system, and none about the size of the working set. If the working set with -O2 spills out of the cache but doesn't with -Os then you get a performance improvement from -Os, for the next CPU with bigger caches it can swing back. > [Also, are there that man AMD64 machines with limited memory? Or IA64?] Swap is now mostly irrelevant for performance discussions, if you hit swap you won't have performance anyway. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emacs out for lunch?
Steve Langasek <[EMAIL PROTECTED]> wrote: >> I've successfully built emacs21 on sid (i386) with (I think) >> xaw3dg-dev_1.5+E-12, in other words the version which lacked all xlibs >> dependencies. I was surprised, but I guess emacs21 has all xlibs needed >> by xaw3dg-dev already as direct build-deps. > > Or you're building in an unclean chroot. Yes, must have been. >> And the latest buildd attempt was on sparc, and it is >> "maybe-successful": > > An accident of the build environment -- it looks like mrpurply had > libxaw-dev already installed in the chroot. No, I checked that before trying here: It had not. But it obviously had other dev packages installed. Regards, Fran -- Frank Küster Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich Debian Developer (teTeX)
I can't submit a comment to bug #364751 (part 2)
From: [EMAIL PROTECTED] (Mail Delivery System) To: [EMAIL PROTECTED] Subject: Undelivered Mail Returned to Sender Date: Fri, 5 May 2006 01:42:09 -0300 (BRT) This is the Postfix program at host smtp2.oi.com.br. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program <[EMAIL PROTECTED]>: host bugs.debian.org[140.211.166.43] said: 550 Administrative prohibition (in reply to end of DATA command) <[EMAIL PROTECTED]>: host master.debian.org[146.82.138.7] said: 550 Administrative prohibition (in reply to end of DATA command) From: Savio Ramos <[EMAIL PROTECTED]> To: #364751 <[EMAIL PROTECTED]>, [EMAIL PROTECTED] <[EMAIL PROTECTED]> Subject: Try to use gdb Date: Fri, 5 May 2006 01:41:28 -0300 X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.17; i486-pc-linux-gnu) $ gdb sylpheed-claws-gtk2 GNU gdb 6.4-debian Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i486-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1". (gdb) set width 70 (gdb) break sylpheed_ sylpheed_do_idle sylpheed_done sylpheed_get_startup_dir sylpheed_get_version sylpheed_gtk_idle sylpheed_init sylpheed_marshal_VOID__INT_POINTER sylpheed_register_idle_function (gdb) bt No stack. (gdb) run Starting program: /usr/bin/sylpheed-claws-gtk2 (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1496082048 (LWP 9102)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:9102): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:9102): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm: a
I can't submit a comment do bug #364751 (part 1)
From: [EMAIL PROTECTED] (Mail Delivery System) To: [EMAIL PROTECTED] Subject: Undelivered Mail Returned to Sender Date: Fri, 5 May 2006 01:42:11 -0300 (BRT) This is the Postfix program at host smtp2.oi.com.br. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to If you do so, please include this problem report. You can delete your own text from the attached returned message. The Postfix program <[EMAIL PROTECTED]>: host master.debian.org[146.82.138.7] said: 550 Administrative prohibition (in reply to end of DATA command) <[EMAIL PROTECTED]>: host bugs.debian.org[140.211.166.43] said: 550 Administrative prohibition (in reply to end of DATA command) From: Savio Ramos <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>, #364751 <[EMAIL PROTECTED]> Subject: Output of command "sylpheed-claws-gtk2 --debug" Date: Fri, 5 May 2006 01:41:57 -0300 X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.17; i486-pc-linux-gnu) $ sylpheed-claws-gtk2 --debug sylpheed.c:99:Starting sylpheed version 02010100 prefs.c:283:Found [Plugins_Common] current dir: /home/savio/.sylpheed-claws current dir: /home/savio folder.c:112:registering folder class mh folder.c:112:registering folder class imap folder.c:112:registering folder class news prefs_gtk.c:68:Reading configuration... prefs_gtk.c:96:Found [Common] prefs_gtk.c:120:Finished reading configuration. prefs_themes.c:365:Creating preferences for themes... stock_pixmap.c:450:dir /usr/share/sylpheed-claws-gtk2/themes not found, skipping theme scanprefs_actions.c:342:Reading actions configurations... prefs_display_header.c:402:Reading configuration for displaying headers... addressbook.c:3449:Reading address index... addressbook.c:3481:done. mainwindow.c:1013:Creating main window... toolbar.c:585:read Toolbar Configuration from toolbar_main.xml folderview.c:542:Creating folder view... folderview.c:417:creating tree... hooks.c:70:registed new hook for 'folder_update' as id 1 hooks.c:70:registed new hook for 'folder_item_update' as id 1 summaryview.c:531:Creating summary view... hooks.c:70:registed new hook for 'msginfo_update' as id 1 messageview.c:339:Creating message view... headerview.c:82:Creating header view... noticeview.c:77:Creating notice view... mimeview.c:195:Creating MIME view... noticeview.c:77:Creating notice view... textview.c:270:Creating text view... hooks.c:70:registed new hook for 'msginfo_update' as id 2 logwindow.c:82:Creating log window... hooks.c:70:registed new hook for 'log_append_text' as id 1 mainwindow.c:1208:done. mainwindow.c:2276:Setting widgets... mainwindow.c:1677:Changing window separation type from 1 to 1 mainwindow.c:2525:done. mainwindow.c:1790:called after messageview has been deallocated! mainwindow.c:1790:called after messageview has been deallocated! (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap != NULL' failed (sylpheed-claws-gtk2:21948): Gdk-CRITICAL **: gdk_pixmap_colormap_create_from_xpm_d: assertion `drawable != NULL || colormap != NULL' failed (sylpheed-claws-gtk2:21948): Sylpheed-Claws-CRITICAL **: stock_pixmap_gdk: assertion `pix_d->pixmap
Re: I can't submit a comment to bug #364751 (part 2)
On 5/5/06, Savio Ramos <[EMAIL PROTECTED]> wrote: From: [EMAIL PROTECTED] (Mail Delivery System) To: [EMAIL PROTECTED] Subject: Undelivered Mail Returned to Sender Date: Fri, 5 May 2006 01:42:09 -0300 (BRT) This is the Postfix program at host smtp2.oi.com.br. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. Is this something to do with the fact that the email is way too long?
Re: Easy way to incorporate Ubuntu improvements back into Debian?
On Fri, May 05, 2006 at 11:27:50AM +0200, Romain Beauxis wrote: > On Friday 05 May 2006 11:24, Daniel Stone wrote: > > > It seems to me that Ubuntu is getting alot more out of their friendship > > > with Debian, than Debian gets out of Ubuntu. Anyone have comments on > > > this? Please correct me if I'm wrong, and examples would be great. > > > Does Debian get lots of benefits from Ubuntu (in the software) that I'm > > > unaware of? > > > > ... GNOME, Xorg, et al. > > Hi all! > > I just wanted to ask if there is any plans to package Xgl in debian soon? I > have tryed building current package found in ubuntu but it failed... > Compiz was building ok BTW... > As you can see in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=362779 you need a patched mesa to make it works. If you want to try a working xgl (with patched mesa) you can point your apt to: deb http://www.prato.linux.it/~mnencia/debian xgl/ deb-src http://www.prato.linux.it/~mnencia/debian xgl/ Here you can find the foolwing source packages: xserver-xgl Stolen from Ubuntu compiz Stolen from Ubuntu control-center Stolen from gnome-team svn Version 2.14 is needed by compiz. mesaPatched to support Xgl Best Regards -- - |Marco Nenciarini| Debian/GNU Linux Developer - Plug Member | | [EMAIL PROTECTED] | http://www.prato.linux.it/~mnencia | - Key fingerprint = FED9 69C7 9E67 21F5 7D95 5270 6864 730D F095 E5E4 signature.asc Description: Digital signature
Re: Easy way to incorporate Ubuntu improvements back into Debian?
On Fri, 05 May 2006, Daniel Stone wrote: > > What processes, infrastructure and tools are in place to streamline > > Debian integrating improvements Ubuntu makes? > > See the Utnubu project (on Alioth). Having automatic mail notifications > and the like was discussed, but many DDs did not want anything to do > with it, so the idea was quickly dropped. The PTS will receive notifications once Gustavo Franco enables his script. There's a new "derivatives" keyword for that. I will announce that when it becomes effective. > > It seems to me that Ubuntu is getting alot more out of their friendship > > with Debian, than Debian gets out of Ubuntu. Anyone have comments on > > this? Please correct me if I'm wrong, and examples would be great. > > Does Debian get lots of benefits from Ubuntu (in the software) that I'm > > unaware of? > > ... GNOME, Xorg, et al. We do benefit but we could benefit way more. In several occasions when I discovered an interesting bug fix in Ubuntu I informed the Debian maintainer. (example: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=351621) Some people like Ian Jackson work for Ubuntu and always send their patches back to Debian: he has done so for at least dpkg and firefox on several occasions. Colin Watson is working directly on debian-installer as part of his Ubuntu work as well. I wish more Ubuntu developers would act like Ian and Colin. Ubuntu also introduced some packages to provide better support for laptop (like acpi-support) and those packages are not always submitted back. I recently asked Matthew Garrett to upload it to Debian also so that our laptop task could install it... In short: in many cases we need to pull out ourselves what we want, you can't rely on Ubuntu developers to send all enhancements to us directly. That's sad, but that's not a reason to not make the effort to look into Ubuntu and see what we can grab. And that's precisely the purpose of Utnubu... but this project needs fresh blood. There's a dormant mailing list and that's all right now. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Sascha Einloft ist nicht im Büro | Sascha Einloft is not in the office.
Ich werde ab 29.04.2006 nicht im Büro sein. Ich kehre zurück am 08.05.2006. Bitte wenden Sie sich während meiner Abwesenheit an meine Kollegen von der IT-Abteilung unter der Telefonnummer: +49 (8272) 86-555. Please contact my colleagues from the IT department - extension -555 - during my vacation. Ihr Mail wird nicht automatisch weitergeleitet! Your mail will not automatically be forwarded! Viele Grüße, Kind regards, Sascha Einloft System- & Networkadministrator CREATON AG Dillinger Str. 60 86637 Wertingen Phone: +49 (8272) 86 404 Fax: +49 (8272) 86 207404 http://www.creaton.de http://www.dachundfassade.de http://www.etexgroup.com
Re: bits from the release team
* Lionel Elie Mamane: > Why can't we have a master key that signs the yearly keys? After all, > we have a long-term unique X.509 master key, so what's the difference > with OpenPGP? End users are typically not exposed to the X.509 keys, which makes things a lot easier. By the way, if you've got a master key, you need to plan for key rollover, too. Why not apply that procedure directly to the keys used to sign the release files? A yearly key change just results in unnecessary administrative overhead for our users, without providing any real benefit to them. A key compromise still needs manual intervention. At the very least, if we have to keep that yearly key change for political reasons, please schedule it in a way that it doesn't happen in January. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bits from the release team
Le Ven 5 Mai 2006 18:41, Florian Weimer a écrit : > * Lionel Elie Mamane: > > Why can't we have a master key that signs the yearly keys? After > > all, we have a long-term unique X.509 master key, so what's the > > difference with OpenPGP? > > End users are typically not exposed to the X.509 keys, which makes > things a lot easier. > > By the way, if you've got a master key, you need to plan for key > rollover, too. Why not apply that procedure directly to the keys > used to sign the release files? A yearly key change just results in > unnecessary administrative overhead for our users, without providing > any real benefit to them. A key compromise still needs manual > intervention. > > At the very least, if we have to keep that yearly key change for > political reasons, please schedule it in a way that it doesn't happen > in January. Proposal 1: a possible way would be to have two valid keys at any time. like one new key per year (or 6 month like you want) with a validity of 2 years (resp. one year). that would obviously mean two signatures per package (but I don't think that's that much work) and would require the user to update their "keyring package" only once every year (or 6 month), which looks like a quite reasonnable trade-off. Even stable updates can use that scheme, since it's released more than once a year. Proposal 2: the package that holds the public signature key has to contain every single emited key, and be signed with any anterior one. Meaning that the upgrade for any user would be smooth. I don't think that having a kludge in dpkg that forces the upgrade of that package ASAP would be hard or dangerous to implement, so that even a non aware user could just "apt-get update" without having read the release notes. This is simpler, but less secure than the Proposal 1. Proposal ...: there is a lot of such ideas IMHO, one just has to think 10 minutes to imagine a couple of ones. IMHO, changing the key every year at any date is not problematic at all, because there is plenty of solution to do smooth replacement of the key. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDFt8hoaFpj.pgp Description: PGP signature
Re: Debian Policy version
"Raphael Hertzog" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] It seems to me that it is unreasonable for the PTS to be updated before the policy package actually hits the mirrors. There is a period of time after a package leaves incomming but before the mirrors are updated when the package is difficult to obtain. Frankly, I updated it a bit soon, right, but that was only because 3.7.2 revert the cgi-lib stuff and the PTS will let people notice that there's a newer version and that they must take care... And do we really need to complain of something that is broken for a few hours and that's will resolve itself alone in a few hours? /me wishes people wouldn't complain when we're actually fast I was not complaining. I was suggesting that the actions that were taken be avoided in general. It realy is not a big deal, and you are right that complaining about excessive speed is nearly absurd considering the last release cycle. Especially considering the context, what was done is reasonable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Emacs out for lunch?
On Fri, May 05, 2006 at 12:39:27PM +0200, Frank Küster wrote: > >> And the latest buildd attempt was on sparc, and it is > >> "maybe-successful": > > An accident of the build environment -- it looks like mrpurply had > > libxaw-dev already installed in the chroot. > No, I checked that before trying here: It had not. No, you did not. Unless you're a buildd admin, you have no access to see what other packages are installed on the buildd, you only see the ones pulled in as build-depends. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#366160: ITP: qgit -- git GUI viewer built on Qt
Package: wnpp Severity: wishlist Owner: Wartan Hachaturow <[EMAIL PROTECTED]> * Package name: qgit Version : 1.2 Upstream Author : Marco Costalba <[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/qgit * License : GPL Programming Lang: C++ Description : QGit is a git GUI viewer built on Qt. With qgit you will be able to browse revisions history, view patch content and changed files, graphically following different development branches. Features: * View revisions, diffs, files history, files annotation, archive tree. * Commit changes visually cherry picking modified files. * Apply or format patch series from selected commits, drag and drop commits between two instances of qgit. * qgit implements a GUI for the most common StGIT commands like push/pop and apply/format patches. You can also create new patches or refresh current top one using the same semantics of git commit, i.e. cherry picking single modified files. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) -- Regards, Vartan. "Be different: conform." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Easy way to incorporate Ubuntu improvements back into Debian?
On Fri, May 05, 2006 at 11:27:50AM +0200, Romain Beauxis wrote: > On Friday 05 May 2006 11:24, Daniel Stone wrote: > > > It seems to me that Ubuntu is getting alot more out of their friendship > > > with Debian, than Debian gets out of Ubuntu. ??Anyone have comments on > > > this? ??Please correct me if I'm wrong, and examples would be great. > > > Does Debian get lots of benefits from Ubuntu (in the software) that I'm > > > unaware of? > > > > ... GNOME, Xorg, et al. > > Hi all! > > I just wanted to ask if there is any plans to package Xgl in debian soon? I > have tryed building current package found in ubuntu but it failed... > Compiz was building ok BTW... See http://lists.debian.org/debian-x/2006/04/msg02216.html for the current problem list. If anyone wants to help make Xgl in Debian a reality, I'd love the help, but right now it's not looking very likely any time soon. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366188: ITP: python-pastewebkit -- port/reimplementation of Webware WebKit in WSGI and Paste
Package: wnpp Severity: wishlist Owner: Piotr Ozarowski <[EMAIL PROTECTED]> * Package name: python-pastewebkit Version : 0.9 Upstream Author : Ian Bicking <[EMAIL PROTECTED]> * URL : http://pythonpaste.org/ * License : MIT Programming Lang: Python Description : port/reimplementation of Webware WebKit in WSGI and Paste This is a reimplementation of the Webware WebKit servlet API. This implementation uses WSGI internally very heavily, and builds upon the framework-neutral tools and services in Paste -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.12-grsec Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366189: ITP: python-routes -- Routing Recognition and Generation Tools
Package: wnpp Severity: wishlist Owner: Piotr Ozarowski <[EMAIL PROTECTED]> * Package name: python-routes Version : 1.3.2 Upstream Author : Ben Bangert <[EMAIL PROTECTED]> * URL : http://routes.groovie.org/ * License : BSD Programming Lang: Python Description : Routing Recognition and Generation Tools A Routing package for Python that matches URL's to dicts and vice versa -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.12-grsec Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
resetting forwarded addresses (Re: Processed: [bts-link] source package gcc-3.4)
Please STOP resetting the forwarded address and revert the changes you already did. We do loose information in the upstream BTS: it becomes more tedious to track the reverse direction (upstream -> Debian), unless you add information to the upstream bug report as well. I.e. you have to search now _every_ duplicate report to find the one which was reported in Debian. That's insane when a report has a large number of duplicates. I don't mind adding information to the BTS, but removing information from it is just insane. Thanks, Matthias Debian Bug Tracking System writes: > Processing commands for [EMAIL PROTECTED]: > > > # > > # bts-link upstream status pull for source package gcc-3.4 > > # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html > > # > > user [EMAIL PROTECTED] > Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]). > > # remote status report for #217360 > > # * http://gcc.gnu.org/PR1027 > > # * remote status changed: (?) -> RESOLVED > > # * remote resolution changed: (?) -> RESOLVED > > forwarded 217360 http://gcc.gnu.org/PR1027 > Bug#217360: [PR12867, fixed in 3.5] incorrect warning message (void format, > should be void* format) > Forwarded-to-address changed from http://gcc.gnu.org/PR12867 to > http://gcc.gnu.org/PR1027. > (By the way, this Bug is currently marked as done.) > > > usertags 217360 + status-RESOLVED resolution-FIXED > There were no usertags set. > Usertags are now: resolution-FIXED status-RESOLVED. > > # remote status report for #238432 > > # * http://gcc.gnu.org/PR11801 > > # * remote status changed: (?) -> RESOLVED > > # * remote resolution changed: (?) -> RESOLVED > > forwarded 238432 http://gcc.gnu.org/PR11801 > Bug#238432: [fixed in 4.0] gcj fails to wait for its child processes on exec() > Forwarded-to-address changed from http://gcc.gnu.org/PR14709 to > http://gcc.gnu.org/PR11801. > (By the way, this Bug is currently marked as done.) > > > usertags 238432 + status-RESOLVED resolution-FIXED > There were no usertags set. > Usertags are now: resolution-FIXED status-RESOLVED. > > # remote status report for #254659 > > # * http://gcc.gnu.org/PR16052 > > # * remote status changed: (?) -> RESOLVED > > # * remote resolution changed: (?) -> RESOLVED > > forwarded 254659 http://gcc.gnu.org/PR16052 > Bug#254659: [fixed in 4.0] [PR 16066] i386 loop strength reduction bug > Forwarded-to-address changed from http://gcc.gnu.org/PR16066 to > http://gcc.gnu.org/PR16052. > (By the way, this Bug is currently marked as done.) > > > usertags 254659 + status-RESOLVED resolution-FIXED > There were no usertags set. > Usertags are now: resolution-FIXED status-RESOLVED. > > # remote status report for #285692 > > # * http://gcc.gnu.org/PR18384 > > # * remote status changed: (?) -> RESOLVED > > # * remote resolution changed: (?) -> RESOLVED > > forwarded 285692 http://gcc.gnu.org/PR18384 > Bug#285692: [fixed in 3.4/4.0] [PR 19006] [3.3 / 3.4 / 4.0 regression] ICE in > tree_low_cst, at tree.c:3255 > Forwarded-to-address changed from http://gcc.gnu.org/PR19006 to > http://gcc.gnu.org/PR18384. > (By the way, this Bug is currently marked as done.) > > > usertags 285692 + status-RESOLVED resolution-FIXED > There were no usertags set. > Usertags are now: resolution-FIXED status-RESOLVED. > > # remote status report for #286715 > > # * http://gcc.gnu.org/PR9157 > > # * remote status changed: (?) -> RESOLVED > > # * remote resolution changed: (?) -> RESOLVED > > forwarded 286715 http://gcc.gnu.org/PR9157 > Bug#286715: [fixed in 4.0] [PR 19711] gcj segfaults instead of reporting the > ambiguous expression > Forwarded-to-address changed from http://gcc.gnu.org/PR19711 to > http://gcc.gnu.org/PR9157. > (By the way, this Bug is currently marked as done.) > > > usertags 286715 + status-RESOLVED resolution-FIXED > There were no usertags set. > Usertags are now: resolution-FIXED status-RESOLVED. > > # remote status report for #293466 > > # * http://gcc.gnu.org/PR22309 > > # * remote status changed: (?) -> RESOLVED > > # * remote resolution changed: (?) -> RESOLVED > > forwarded 293466 http://gcc.gnu.org/PR22309 > Bug#293466: [PR 19265] [fixed in 4.0] g++-3.4: mt_allocator + threads + > dlclose = crash > Forwarded-to-address changed from http://gcc.gnu.org/PR19265 to > http://gcc.gnu.org/PR22309. > (By the way, this Bug is currently marked as done.) > > > usertags 293466 + status-RESOLVED resolution-FIXED > There were no usertags set. > Usertags are now: resolution-FIXED status-RESOLVED. > > # remote status report for #307993 > > # * http://gcc.gnu.org/PR16676 > > # * remote status changed: (?) -> RESOLVED > > # * remote resolution changed: (?) -> RESOLVED > > # * upstream said bug is wontfix > > forwarded 307993 http://gcc.gnu.org/PR16676 > Bug#307993: CE in gen_subprogram_die at dwarf2out.c:10913 building glibc > 2.3.5 with nptl > Forwarded-to-address changed from http://gcc.gnu.org/PR21457 to > http://gcc.gnu.org/PR16676. > (By the way, this Bu
Bug#366194: ITP: mcast-tools -- IPv6 multicast routing daemons and applications
Package: wnpp Severity: wishlist Owner: Jeremie Corbier <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: mcast-tools Version : 20060216 Upstream Author : SUZUKI Shinsuke <[EMAIL PROTECTED]> * URL : http://mcast-tools.sourceforge.net/ * License : BSD Programming Lang: C Description : IPv6 multicast routing daemons and applications This package will provide these applications: pim6sd IPv6 PIM-SM routing protocol pim6dd IPv6 PIM-DM routing protocol mfc static IPv6 multicast routing command mcastread MLDv1/v2 listener mcastsend IPv6 UDP multicast packet sender pmsft MLDv2 MSF-API tester - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.5 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEW++SFq2EwGQTI7ERAicrAJ4rP+vOf+SMBwcL6atlTBE62Cg1YgCfRp2A EtNNNMURK6619AnPNHIpd2A= =hCD6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366199: ITP: supertuxkart -- a kart racing game
Package: wnpp Severity: wishlist Owner: "Gonéri Le Bouder" <[EMAIL PROTECTED]> * Package name: supertuxkart Version : 0.0.0.1 Upstream Author : Coz, Craig Keogh, Pascal Giard, Caleb Sawtell, Ingo Ruhnke, James Gregory, Matt Thomas, Matze Braun, paul carley, Ricardo Cruz, Oliver Jeeves, Jacob Persson, Willian Padovani Germano, Oliver Baker, Steve Baker * URL : http://supertuxkart.berlios.de * License : GPL Programming Lang: C++ Description : a kart racing game SuperTuxKart is an enhanced version of TuxKart, a kart racing game, originaly done by Steve Baker, featuring Tux and a bunch of his friends. SuperTuxKart is the work of the GotM run for TuxKart at happypenguin.org. Due to some disagreements that happened in that time this fork of TuxKart was done. SuperTuxKart features include: new characters new tracks a completly new userinterface some smaller graphical improvemnts (skidmarks, smoke, animated wheels, etc.) whole bunch of new bugs, in its current state its not really playable -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: sparc (sparc64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-sparc64-smp Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
