From rc040203 at freenet.de Wed Feb 1 14:41:16 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Wed, 01 Feb 2006 15:41:16 +0100 Subject: Perl modules that may be updated In-Reply-To: <43DFB47B.9020306@di.uminho.pt> References: <43DFB47B.9020306@di.uminho.pt> Message-ID: <1138804876.5149.107.camel@mccallum.corsepiu.local> On Tue, 2006-01-31 at 19:03 +0000, Jos? Pedro Oliveira wrote: > The list below represents a possible list of perl modules [1] that > *could* be updated by their maintainers. I say could because some of > the modules may require additional reqs not yet available, may need > perl core modules that will only be available in perl 5.8.8, etc. Class-Autouse seems to be of them ... > * Class-Autouse-1.21 (Class-Autouse-1.24.tar.gz) Class-Autouse-1.24 doesn't build because the version of List::Util being shipped with perl-core is too old (1.17 would be required). Ralf From dwalsh at redhat.com Fri Feb 3 18:26:29 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 03 Feb 2006 13:26:29 -0500 Subject: Why don't we turn on NetworkManager by default? Message-ID: <43E3A055.4040803@redhat.com> I was surprised and confused when my wireless card did not work on a rawhide install. I later found out that NetworkManager was not running. I would have thought that would be on by default. Dan From katzj at redhat.com Fri Feb 3 18:34:17 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 13:34:17 -0500 Subject: Why don't we turn on NetworkManager by default? In-Reply-To: <43E3A055.4040803@redhat.com> References: <43E3A055.4040803@redhat.com> Message-ID: <1138991657.2652.15.camel@bree.local.net> On Fri, 2006-02-03 at 13:26 -0500, Daniel J Walsh wrote: > I was surprised and confused when my wireless card did not work on a > rawhide install. I later found out that NetworkManager was not > running. I would have thought that would be on by default. Because to enable it by default means it needs to work for all of the (at least basic) cases that we set up by default. And then all of the corresponding changes to installation UI so that you're not confused by what's set up. Jeremy From dwalsh at redhat.com Fri Feb 3 19:26:11 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 03 Feb 2006 14:26:11 -0500 Subject: Why don't we turn on NetworkManager by default? In-Reply-To: <1138991657.2652.15.camel@bree.local.net> References: <43E3A055.4040803@redhat.com> <1138991657.2652.15.camel@bree.local.net> Message-ID: <43E3AE53.3050503@redhat.com> Jeremy Katz wrote: > On Fri, 2006-02-03 at 13:26 -0500, Daniel J Walsh wrote: > >> I was surprised and confused when my wireless card did not work on a >> rawhide install. I later found out that NetworkManager was not >> running. I would have thought that would be on by default. >> > > Because to enable it by default means it needs to work for all of the > (at least basic) cases that we set up by default. And then all of the > corresponding changes to installation UI so that you're not confused by > what's set up. > > Jeremy > > Well that sucks. This needs to get fixed for FC6. > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From katzj at redhat.com Fri Feb 3 22:39:47 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 03 Feb 2006 17:39:47 -0500 Subject: Fedora Core 5 Test 3 Slip Message-ID: <1139006387.2652.29.camel@bree.local.net> Although I hate to do it, it looks like we're going to have to slip Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc stack that requires a rebuild of the entire distribution. Given that, there is no way that we'll be able to make a freeze date of Monday. So, test3 will now freeze on Monday, 13 February with a release date of Monday, 20 February. We'll adjust the final schedule sometime next week based on the progress of the rebuilding efforts. Thanks, Jeremy From arjan at fenrus.demon.nl Sun Feb 5 16:59:56 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 05 Feb 2006 17:59:56 +0100 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <200602041157.17339.prigault@oricom.ca> References: <200602041157.17339.prigault@oricom.ca> Message-ID: <1139158796.3131.44.camel@laptopd505.fenrus.org> > I am also very concerned about the delay in the release of GCC-4.1 (no release > candidate yet), expecting FC5-final to include a compiler that has a wide > level of exposure to testing. Having GCC-4.1-cvs-xxx would make users > uncomfortable, and without bringing back the old RedHat ghost of gcc-2.96, I > remind you that FC4 was released with a compiler blacklisted by the KDE > project, which incidentally was one of the reasons for me and my institution > to skip FC4 altogether and stay with FC3 until FC5 is released. That doesn't show a lot of knowledge on your institutions part though ;( KDE blacklisted that gcc for ONE bug, a bug fixed in the RH rpms already. From alan at redhat.com Mon Feb 6 15:37:30 2006 From: alan at redhat.com (Alan Cox) Date: Mon, 6 Feb 2006 10:37:30 -0500 Subject: Fedora Core 5 Test 3 Slip In-Reply-To: <200602041157.17339.prigault@oricom.ca> References: <200602041157.17339.prigault@oricom.ca> Message-ID: <20060206153730.GA24791@devserv.devel.redhat.com> On Sat, Feb 04, 2006 at 11:57:16AM -0500, Philippe Rigault wrote: > relevance of March 15 as the release date for FC5-final, which I see a the > worst possible choice in March, given the following release dates: > March 15 GNOME-2.14, koffice-1.5 > March 17 KDE-3.5.2 > > These would make Fecora Core 5 labeled as both "obsolete" and "unstable" if it It would need to be a large delay because moving to major new versions means invalidating a lot of the testing work in T1/T2. If sliding test2 a bit to fit these would have worked then maybe there would be a practical way to do it, but test3 > final is about polishing critical final bugs. Alan -- "He's been overclocked. All that beer you see him drinking ? - Coolant." - Adam Thornton From jkeating at redhat.com Tue Feb 7 19:24:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 07 Feb 2006 11:24:31 -0800 Subject: Massive rebuild in progress Message-ID: <1139340272.3579.23.camel@ender> After a late night of staging, I have 900~ packages queued up to rebuild for the gcc4.1 snapshot and glibc changes. These will be submitted to our build system throughout the day as low priority jobs. Some will be finished for tonight's rawhide push, but not all of them. There are still some packages that should be rebuilt that are not in my list, but those package maintainer's have expressed desire to bump their packages themselves. Over the next couple days I'll be checking package timestamps and keeping an eye on what else needs to build. Please bear with the churn and the very lengthy rawhide reports. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From twaugh at redhat.com Thu Feb 9 18:30:02 2006 From: twaugh at redhat.com (Tim Waugh) Date: Thu, 9 Feb 2006 18:30:02 +0000 Subject: New printer administration tool design for comments Message-ID: <20060209183002.GA16000@redhat.com> A NEW PRINTER ADMINISTRATION TOOL ================================= Draft 2, Feb 9th 2006 Tim Waugh 1. PROBLEMS -------- 1.1. Alchemist --------- There are various reasons for redesigning the current system-config-printer configuration tool. A brief summary is: * the XML file format it uses is inflexible * the configuration options are limited to those common to both spoolers we were shipping at the time the XML format was decided * it is VERY SLOW: you can't *modify* configuration, only write out entirely new configurations (i.e. trigger the back-end) * again, due to the XML format chosen, we are tied to the foomatic database in such as way that we absolutely require foomatic to know about the printer before we can configure it. Even if you have the manufacturer's PPD file, there is very little you can do to get your printer working. * changes made using the CUPS configuration interface (http://localhost:631/), or any other method external to system-config-printer, are not reflected in the XML file and so cannot be modified and often get overwritten. 1.2. Stateless Linux --------------- An extra consideration to take into account when re-designing the administration tool is Stateless Linux. The requirement from that project is that users may specify their own (private) queues for submitting jobs to. For example, a particular user may want to print to an SMB printer, with certain default settings such as which input tray to use. With Stateless Linux, this queue definition will be tied to the user's home directory so that they can log in on any stateless workstation and be able to print to their queue. 2. SOLUTIONS --------- 2.1. Stateless Linux --------------- A Stateless Linux configuration has /etc read-only. This causes a problem with local printers: automatic detection of a local printer needs to add a queue. This runtime configuration means that the CUPS configuration files, currently stored in /etc/cups, should be moved to /var/run. Since /var/run does not preserve data over a reboot, this should only be done for stateless configurations. One possible trigger for this special stateless behaviour would be for CUPS to detect that /etc is read-only -- or else, it could be a configuration option. 2.1.2. (intentionally left blank) 2.1.3. Per-user queues in system CUPS daemon ------------------------------------- At session start, for each per-user queue defined by the user, the CUPS daemon is notified that a per-user queue needs to be created (if it does not already exist). This could be done using D-BUS. Firstly, the CUPS daemon is told to remove all per-user queues for this user IF they are not processing jobs. Then, for each per-user queue the CUPS daemon is given the PPD file from the user's home directory, and the URI for the printer, as well as the queue name. Given this information, the CUPS daemon will then: * copy the PPD into its ppd directory * set up a queue if it does not already exist This new queue will NOT be advertised in IPP "browse" broadcasts. Jobs may only be submitted to this queue by the owning user at the local machine, i.e.: cupsd.conf: ----------- | Allow from localhost | | AuthClass Basic | ---------------------- printers.conf: ------ | AllowUser the_user | -------------------- In addition to the current "certificates" method of avoiding the need to type in a password when submitting jobs, we could patch CUPS to use D-BUS for the same purpose. REMAINING QUESTIONS: Should steps be taken to avoid accidentally forming round-robin classes with other per-user or remote queues of the same name as the user-defined queue? One suggestion is to use 'user-$uid-$queue' as the real name, but present it to the user as '$queue'. 2.2. Better configuration method --------------------------- It will solve many of the configuration issues mentioned in 1.1 if a new printer administration tool would configure CUPS directly rather than maintaining a separate configuration file. There are two main ways of doing this: * using the command-line tools such as lpadmin and lpoptions * using IPP to communicate with the CUPS daemon directly Using IPP directly will offer more flexibility. Some of the more subtle changes we will need to make may not be possible using command-line tools alone. Additionally, using IPP for configuration allows the possibility of configuring remote CUPS instances using the graphical tool, and this will be important for print servers that do not have a full graphical interface installed. Additionally, the user interface must provide a method for the administrator to enable and disable queues. Some queues can get disabled as a result of an error detected by the backend, and there is currently no means of re-enabling the queue using the existing graphical interface. 2.3. IPP authentication ------------------ There are two options: * The admin tool runs with user privileges. An authentication dialog box will appear when configuring the CUPS daemon using IPP. Some mechanism similar to consolehelper needs to be devised in order to avoid the need to keep asking for passwords. (This is my preferred alternative.) -or- * The admin tool uses consolehelper as before, but can run in unprivileged mode in order to configure only per-user queues. 2.4. Modifying PPD options --------------------- The new printer administration tool will be responsible for providing a graphical interface for changing default queue options. These are options such as duplexing, page size, and print quality. All of these options are stored in the PPD file representing the queue, and this is modified by the CUPS daemon when it receives the IPP request to do so. The GTK+ print dialog will also allow these settings to be over-ridden on a per-job basis. The user interface will be largely the same, and there is opportunity for code-sharing here. Some aspects of PPD option representation (such as grouping and constraints) require careful implementation in the user interface, and so it would be better not to duplicate this work. REMAINING QUESTIONS: Perhaps the administration tool needn't provide a method for changing default options at all? After all, the applications will be remembering their job settings between prints. 2.5. Page size as a special case --------------------------- When adding a new queue for an automatically detected printer, an appropriate default page size should be chosen based on the system locale. CUPS will already do this for us when a new queue is created, so there is no action to be taken. 2.6. Persistent settings ------------------- Unplugging a USB printer and re-attaching it must retain the settings it had prior to unplugging. This needs to be handled by HAL. One easy method is to avoid automatically removing queues at all. Instead, the queue could be disabled (i.e. cupsdisable) when the device is unplugged, and enabled when inserted. For this to be feasible, it must be possible to identify a newly-inserted printer as being the same one that had been unplugged previously. Many USB printers provide a serial number in their IEEE 1284 Device ID string which can be used for this purpose. If there is no serial number available, the manufacturer and model strings could be used to identify the correct queue to act upon. The proposal that persistent settings be handled by simply disabling/enabling queues rather than removing queues altogether means that persistent settings can be managed entirely by HAL. 2.7. Automatic detection ------------------- A local printer will be automatically detected by HAL and an appropriate queue created for it. 2.7.2. Remote discovery ---------------- For remote printers, the common types are: SMB, JetDirect, and IPP/CUPS. IPP/CUPS instances can broadcast browse packets to facilitate automatic detection for clients. We already make use of this. For JetDirect printers there is no way of automatically finding them other than probing each address on the subnet. For SMB printers there may very well be a means of actively discovering remote queues automatically, perhaps by querying the domain server and then each named SMB host in turn. However, I think authentication details (such as username/password) need to be configured when you create a queue, rather than when a job is submitted -- the information is placed into the URI for the queue. I am not aware of a passive discovery method for SMB. It has been suggested that UPnP could be used for remote discovery of some newer network printers. 2.7.1. Method for creating a queue --------------------------- The vast majority of printers provide IEEE 1284 Device ID strings to identify themselves. These strings provide: manufacturer name, model name, description, and command sets understood by the device. For example: MFG:EPSON;CMD:ESCPL2,BDC,D4;MDL:Stylus Photo 830U;CLS:PRINTER;DES:EPSON Stylus Photo 830U; or: MFG:Hewlett-Packard;CMD:PJL,MLC,PCL,PCLXL,POSTSCRIPT;MDL:HP LaserJet 1200;CLS:PRINTER;DES:Hewlett-Packard LaserJet 1200;MEM:8MB The foomatic RPM package provides a database of printers and printer drivers. It stores IEEE 1284 Device ID strings for a large number of printers. It also stores information about which drivers may be used with a given device, and which of those is recommended. When a local printer is detected, its IEEE 1284 Device ID string should be retrieved. For parallel port printers, /proc/sys/dev/parport/*/autoprobe provides this; for USB printers, /sys/devices/*/*/usb*/*/*/ieee1284_id provides it in newer kernels (>= 2.6.15-1.1826.2.6.FC5). The foomatic database should then be consulted to look up a printer model based on the manufacturer and model IEEE 1284 Device ID fields. (NB: printconf currently uses some tricks to match printer models for those whose IEEE 1284 Device IDs are not known to foomatic). If no printer is found, the command set field should be examined. If "POSTSCRIPT" is found, the generic PostScript driver can be used. If "PCLXL" is found, the generic PCL 6/PCL XL driver can be used. If "PCL" is found, the generic PCL 3 driver can be used. Otherwise, a manufacturer's PPD is required from the user. If the printer was found, and there is a manufacturer-provided PPD available for the recommended driver for it (a PPD is specific to a printer model and driver combination), the queue is set up automatically and needs no user intervention. If there was no manufacturer-provided PPD (including the case where the printer was not found in the database), the user should be asked to see if they have a manufacturer-provided PPD file. On creating the queue, the page size needs to be adjusted appropriately for the locale. 2.7.2. Code sharing ------------ IEEE 1284 Device ID strings may also be provided by remote printers that are SNMP-capable. There are some subtleties in creating a new queue, such as altering the page size. As a result, the mechanism for creating a queue outlined in 2.7.1 needs to be used for: a) automatically detected printers b) adding printers using the admin tool c) adding per-user remote queues 2.8. Admin tool for creating system queues and per-user queues --------------------------------------------------------- If it makes sense from a user interface perspective, it would be useful to combine the facility for creating and editing per-user queues into the admin tool, since a lot of the same functionality is needed. Additionally, in order to keep the queue creation logic in one place, it might very well make sense for HAL to hand off the IEEE 1284 information from a detected local printer to the admin tool rather than trying to configure a queue on its own. (NB: This bit needs someone with some user interface sense:) Perhaps the interface could have two tabs, one for "System print queues" and another for "My print queues". Browsed queues would not be shown. For each tab, the queues could be listed exactly as they are in the GTK+ print dialog (including number of jobs in queue, and the location). Queue sharing will be allowed for "System queues" (as currently) but not for "My queues". Editing a queue will allow the same things to be edited as currently: which driver to use; driver options; queue options such as banner pages. This combined printer administration tool would be launched by the GTK+ print dialog's "Add printer" button. 2.9. Error handling -------------- The foomatic we are shipping for Fedora Core 5 provides a special CUPS backend: beh (backend error handler). It allows the administrator to modify the behaviour of the backends when errors are encountered: whether to try again, how many times to do that, and so on. It would be useful to be able to offer this in a user interface. The per-user queues would mean that an unprivileged user would even be able to modify error handling for their own jobs. 2.10. Ink levels and maintenance functions ------------------------------------ Although there is no unified way of doing so yet, a future enhancement to the administration tool would be to allow the administrator to check ink levels and perform functions like aligning/changing cartridges, for printers that have such a facility. 2.11. Beyond scope ------------ There are other things that need fixing with printing, such as status feedback to find out if the ink has hit the paper. These are beyond the scope of the administration tool. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Thu Feb 9 19:31:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 09 Feb 2006 20:31:34 +0100 Subject: New printer administration tool design for comments In-Reply-To: <20060209183002.GA16000@redhat.com> References: <20060209183002.GA16000@redhat.com> Message-ID: <1139513494.19338.31.camel@rousalka.dyndns.org> Le jeudi 09 f?vrier 2006 ? 18:30 +0000, Tim Waugh a ?crit : > 2.4. Modifying PPD options > --------------------- > ... > REMAINING QUESTIONS: > > Perhaps the administration tool needn't provide a method for > changing default options at all? After all, the applications will > be remembering their job settings between prints. ROTFL. 1. No they won't, at least not all of them and not consistently 2. Some settings are job-specific and should *not* be remembered 3. Some apps won't be able to change settings so you'll need to to it at the print queue level > 2.5. Page size as a special case > --------------------------- > > When adding a new queue for an automatically detected printer, an > appropriate default page size should be chosen based on the system > locale. > > CUPS will already do this for us when a new queue is created, so there > is no action to be taken. Unless the RH/Fedora tools have been fouling-up cups, it has always been defaulting to Letter in my experience (note : you need an A4 printer which does not transparently scale Letter to A4 to notice this. The printing apps are systematically lying about what they actually send under Linux). > 2.6. Persistent settings > ------------------- > > Unplugging a USB printer and re-attaching it must retain the settings > it had prior to unplugging. This needs to be handled by HAL. ... > The proposal that persistent settings be handled by simply > disabling/enabling queues rather than removing queues altogether means > that persistent settings can be managed entirely by HAL. 2.6.1 Inheritance of settings for one printer model Also, when a new queue is setup for a printer model which the user already used before, it should inherit the settings of the most recently used queue of the same model Printer model is either autodetected or declared by the user (typical use case : bigcorp site where all the floors use the same printers, and where dying printers are replaced by the same model from the corp stocks) 2.6.2 Memory of configuration strategies I'd also be nice if generic settings (use best quality available or fastest printing, PS or PCL, duplex or not) could be remembered by the tool and applied to new queues 2.12 Queue routing 2.12.1 Printer groups The user must be able to create aliases for groups of printers, and print to the group in apps (with the job sent to the first printer in the group which is available and ready) For roaming users which have access to several networked printers (some of which may be on another physical site) the choice of the preferred printer in the one group may be based on user location (dhcp hints, hostname, whatever) 2.12.2 Rescue jobs When jobs are stuck in the queue of a printer which is no longer responding or stuck somewhere, and if other queues with compatible characteristics (same PS level and paper...) are available or created later, the print jobs should be routed (automatically or after prompting the user) to these new queues Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From laroche at redhat.com Thu Feb 9 19:39:48 2006 From: laroche at redhat.com (Florian La Roche) Date: Thu, 9 Feb 2006 20:39:48 +0100 Subject: New printer administration tool design for comments In-Reply-To: <1139513494.19338.31.camel@rousalka.dyndns.org> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> Message-ID: <20060209193948.GA4447@dudweiler.stuttgart.redhat.com> > > CUPS will already do this for us when a new queue is created, so there > > is no action to be taken. > > Unless the RH/Fedora tools have been fouling-up cups, it has always been > defaulting to Letter in my experience (note : you need an A4 printer > which does not transparently scale Letter to A4 to notice this. The > printing apps are systematically lying about what they actually send > under Linux). I keep the root and default config to en_US and only change per user account to German (like for my kids;-). To change the printing setup to A4, I am setting LANG before calling system-config-printer: LANG=de_DE.UTF-8 system-config-printer-tui --Xadd-local \ --device=/dev/usb/lp0 --make="HP" --model="PSC 2110" \ --as-default --name=printer Great document and discussion about s-c-printer, Tim! regards, Florian La Roche From nicolas.mailhot at laposte.net Thu Feb 9 19:57:57 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 09 Feb 2006 20:57:57 +0100 Subject: New printer administration tool design for comments In-Reply-To: <20060209193948.GA4447@dudweiler.stuttgart.redhat.com> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060209193948.GA4447@dudweiler.stuttgart.redhat.com> Message-ID: <1139515078.19338.35.camel@rousalka.dyndns.org> Le jeudi 09 f?vrier 2006 ? 20:39 +0100, Florian La Roche a ?crit : > > > CUPS will already do this for us when a new queue is created, so there > > > is no action to be taken. > > > > Unless the RH/Fedora tools have been fouling-up cups, it has always been > > defaulting to Letter in my experience (note : you need an A4 printer > > which does not transparently scale Letter to A4 to notice this. The > > printing apps are systematically lying about what they actually send > > under Linux). > > I keep the root and default config to en_US and only change per user > account to German (like for my kids;-). To change the printing setup > to A4, I am setting LANG before calling system-config-printer: > LANG=de_DE.UTF-8 system-config-printer-tui --Xadd-local \ > --device=/dev/usb/lp0 --make="HP" --model="PSC 2110" \ > --as-default --name=printer Sure, but that basically means you can not use hotplug usb printer queue creation > Great document and discussion about s-c-printer, Tim! +++10 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From blizzard at redhat.com Fri Feb 10 01:33:15 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 09 Feb 2006 20:33:15 -0500 Subject: New printer administration tool design for comments In-Reply-To: <20060209183002.GA16000@redhat.com> References: <20060209183002.GA16000@redhat.com> Message-ID: <43EBED5B.90008@redhat.com> Tim Waugh wrote: > cupsd.conf: ----------- > | Allow from localhost | > | AuthClass Basic | > ---------------------- > > printers.conf: ------ > | AllowUser the_user | > -------------------- > > In addition to the current "certificates" method of > avoiding the need to type in a password when submitting jobs, we could > patch CUPS to use D-BUS for the same purpose. This is exactly what d-bus was designed to do. Go for it. (If we ever get our cert story together, it would be great to support that as a method as well.) --Chris From arjan at fenrus.demon.nl Fri Feb 10 02:48:02 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 10 Feb 2006 03:48:02 +0100 Subject: New printer administration tool design for comments In-Reply-To: <20060209183002.GA16000@redhat.com> References: <20060209183002.GA16000@redhat.com> Message-ID: <1139539682.3069.7.camel@laptopd505.fenrus.org> On Thu, 2006-02-09 at 18:30 +0000, Tim Waugh wrote: > A NEW PRINTER ADMINISTRATION TOOL > ================================= what I'd like to see is a mechanism similar to automatic http proxy discovery; eg allow for a "site configuration", which you pull down automatic (say if dhcp points you at it) if you are in a certain building at work, but not when you are at home (because then you want to pull down another printer list from your local firewall box ;) these site printers are obviously sort of similar, but in addition to, personal printers. Maybe there is some overlap; I could have a preferred printer, or settings for printer, which are in a site config. Would be nice that those are remembered local and reactivated when I get back to that site... From blizzard at redhat.com Fri Feb 10 04:24:16 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 09 Feb 2006 23:24:16 -0500 Subject: New printer administration tool design for comments In-Reply-To: <1139539682.3069.7.camel@laptopd505.fenrus.org> References: <20060209183002.GA16000@redhat.com> <1139539682.3069.7.camel@laptopd505.fenrus.org> Message-ID: <43EC1570.3080107@redhat.com> Arjan van de Ven wrote: > On Thu, 2006-02-09 at 18:30 +0000, Tim Waugh wrote: >> A NEW PRINTER ADMINISTRATION TOOL >> ================================= > > > what I'd like to see is a mechanism similar to automatic http proxy > discovery; eg allow for a "site configuration", which you pull down > automatic (say if dhcp points you at it) if you are in a certain > building at work, but not when you are at home (because then you want to > pull down another printer list from your local firewall box ;) > Yeah, getting off topic, this would be nice to have. But maybe not in our short printing time frame. [ I've always wanted to have a dhcp hint to find a local public directory server that exposes all these services. ] --Chris From twaugh at redhat.com Fri Feb 10 11:05:28 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 11:05:28 +0000 Subject: Page size (was Re: New printer administration tool design for comments) In-Reply-To: <1139513494.19338.31.camel@rousalka.dyndns.org> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> Message-ID: <20060210110528.GC16000@redhat.com> On Thu, Feb 09, 2006 at 08:31:34PM +0100, Nicolas Mailhot wrote: > > REMAINING QUESTIONS: > > > > Perhaps the administration tool needn't provide a method for > > changing default options at all? After all, the applications will > > be remembering their job settings between prints. > > ROTFL. > 1. No they won't, at least not all of them and not consistently > 2. Some settings are job-specific and should *not* be remembered > 3. Some apps won't be able to change settings so you'll need to to it at > the print queue level Fair points. > > 2.5. Page size as a special case > > --------------------------- > > > > When adding a new queue for an automatically detected printer, an > > appropriate default page size should be chosen based on the system > > locale. > > > > CUPS will already do this for us when a new queue is created, so there > > is no action to be taken. > > Unless the RH/Fedora tools have been fouling-up cups, it has always been > defaulting to Letter in my experience What I mean by 'CUPS will already do this for us' is this: [root at cyberelk ~]# zgrep DefaultPageSize /usr/share/cups/model/deskjet.ppd.gz *DefaultPageSize: Letter [root at cyberelk ~]# /usr/sbin/lpadmin -x test lpadmin: delete-printer failed: client-error-not-found [root at cyberelk ~]# /usr/sbin/lpadmin -p test -m deskjet.ppd.gz [root at cyberelk ~]# zgrep DefaultPageSize /etc/cups/ppd/test.ppd *DefaultPageSize: A4 [root at cyberelk ~]# grep LANG /etc/sysconfig/i18n LANG="en_GB.UTF-8" [root at cyberelk ~]# rpm -q cups cups-1.1.23-15.4 CUPS knows to adjust the "PageSize" PPD option based on your locale when a queue is added using the IPP interface. (I'll reply to the other points in a separate message.) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Fri Feb 10 11:45:49 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 11:45:49 +0000 Subject: Persistent settings (was Re: New printer administration tool design for comments) In-Reply-To: <1139513494.19338.31.camel@rousalka.dyndns.org> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> Message-ID: <20060210114549.GD16000@redhat.com> On Thu, Feb 09, 2006 at 08:31:34PM +0100, Nicolas Mailhot wrote: > 2.6.1 Inheritance of settings for one printer model > > Also, when a new queue is setup for a printer model which the user > already used before, it should inherit the settings of the most recently > used queue of the same model > > Printer model is either autodetected or declared by the user > > (typical use case : bigcorp site where all the floors use the same > printers, and where dying printers are replaced by the same model from > the corp stocks) This sounds like a really good idea. I think there are two cases: a. all floors use the same printer model This really becomes the idea that Arjan suggested, which was (I think) that there is a site policy on which printer models should have which settings. Arjan, is that what you meant? b. dying printers are replaced by same model This doesn't really seem to be any different to 'unplug printer; re-insert it', already covered in 2.6. > 2.6.2 Memory of configuration strategies > > I'd also be nice if generic settings (use best quality available or > fastest printing, PS or PCL, duplex or not) could be remembered by the > tool and applied to new queues I don't think this can really be done in general. Different PPDs can have widely differing options. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Fri Feb 10 12:13:03 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 12:13:03 +0000 Subject: Classes (was Re: New printer administration tool design for comments) In-Reply-To: <1139513494.19338.31.camel@rousalka.dyndns.org> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> Message-ID: <20060210121303.GE16000@redhat.com> On Thu, Feb 09, 2006 at 08:31:34PM +0100, Nicolas Mailhot wrote: > 2.12 Queue routing > > 2.12.1 Printer groups > > The user must be able to create aliases for groups of printers, and > print to the group in apps (with the job sent to the first printer in > the group which is available and ready) > > For roaming users which have access to several networked printers (some > of which may be on another physical site) the choice of the preferred > printer in the one group may be based on user location (dhcp hints, > hostname, whatever) In CUPS terminology these are "classes". Yes, the administration tool could configure classes (it can be done using IPP). I would rather avoid having user-defined classes, though -- system classes should be sufficient. Perhaps that would be something to look at after the initial implementation is done. In other words, it's something we can make sure is possible to implement in the future without having to change anything fundamental. > 2.12.2 Rescue jobs > > When jobs are stuck in the queue of a printer which is no longer > responding or stuck somewhere, and if other queues with compatible > characteristics (same PS level and paper...) are available or created > later, the print jobs should be routed (automatically or after prompting > the user) to these new queues I don't think that CUPS is capable of this. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Feb 10 12:14:48 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 10 Feb 2006 13:14:48 +0100 (CET) Subject: Page size (was Re: New printer administration tool design for comments) In-Reply-To: <20060210110528.GC16000@redhat.com> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210110528.GC16000@redhat.com> Message-ID: <38299.192.54.193.25.1139573688.squirrel@rousalka.dyndns.org> Le Ven 10 f?vrier 2006 12:05, Tim Waugh a ?crit : >> > 2.5. Page size as a special case >> > --------------------------- >> > >> > When adding a new queue for an automatically detected printer, an >> > appropriate default page size should be chosen based on the system >> > locale. >> > >> > CUPS will already do this for us when a new queue is created, so there >> > is no action to be taken. >> >> Unless the RH/Fedora tools have been fouling-up cups, it has always been >> defaulting to Letter in my experience > > What I mean by 'CUPS will already do this for us' is this: > > [root at cyberelk ~]# zgrep DefaultPageSize > /usr/share/cups/model/deskjet.ppd.gz > *DefaultPageSize: Letter > [root at cyberelk ~]# /usr/sbin/lpadmin -x test > lpadmin: delete-printer failed: client-error-not-found > [root at cyberelk ~]# /usr/sbin/lpadmin -p test -m deskjet.ppd.gz > [root at cyberelk ~]# zgrep DefaultPageSize /etc/cups/ppd/test.ppd > *DefaultPageSize: A4 > [root at cyberelk ~]# grep LANG /etc/sysconfig/i18n > LANG="en_GB.UTF-8" > [root at cyberelk ~]# rpm -q cups > cups-1.1.23-15.4 > > CUPS knows to adjust the "PageSize" PPD option based on your locale > when a queue is added using the IPP interface. > > (I'll reply to the other points in a separate message.) Ok, but here you are triggering queue creation manually from the shell with (I suppose) every locale-related environment variables set correctly. Will it be the case for hotplug-triggered creations ? (it seems not to be the case today) BTW some vendor PPDs only include a subset of the formats a printer can process (the manual tray can typically eat whatever strange enveloppe format you feed it), so I wouldn't trust them blindly. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Feb 10 12:21:20 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 10 Feb 2006 13:21:20 +0100 (CET) Subject: Persistent settings (was Re: New printer administration tool design for comments) In-Reply-To: <20060210114549.GD16000@redhat.com> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210114549.GD16000@redhat.com> Message-ID: <51310.192.54.193.25.1139574080.squirrel@rousalka.dyndns.org> Le Ven 10 f?vrier 2006 12:45, Tim Waugh a ?crit : > On Thu, Feb 09, 2006 at 08:31:34PM +0100, Nicolas Mailhot wrote: > >> 2.6.1 Inheritance of settings for one printer model >> >> Also, when a new queue is setup for a printer model which the user >> already used before, it should inherit the settings of the most recently >> used queue of the same model >> >> Printer model is either autodetected or declared by the user >> >> (typical use case : bigcorp site where all the floors use the same >> printers, and where dying printers are replaced by the same model from >> the corp stocks) > > This sounds like a really good idea. I think there are two cases: > > a. all floors use the same printer model > > This really becomes the idea that Arjan suggested, which was (I think) > that there is a site policy on which printer models should have which > settings. > > Arjan, is that what you meant? > > b. dying printers are replaced by same model > > This doesn't really seem to be any different to 'unplug printer; > re-insert it', already covered in 2.6. No, because in the USB case they'll have a different serial number, so HAL will declare a new device. Also it should be possible for the user to have different settings for two printers of the same model (ie by default copy settings of most recently used for new queue creation, but allow the user to change them later on a printer-per-printer basis). Sometimes two printers will declare the same model but one will have one or more addons installed (trays, memory, duplex unit, stappler, whatever) >> 2.6.2 Memory of configuration strategies >> >> I'd also be nice if generic settings (use best quality available or >> fastest printing, PS or PCL, duplex or not) could be remembered by the >> tool and applied to new queues > > I don't think this can really be done in general. Different PPDs > can have widely differing options. That's tricky. they all have different options, but the options all have similar meanings (they're all printers after all) Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Feb 10 12:30:12 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 10 Feb 2006 13:30:12 +0100 (CET) Subject: Classes (was Re: New printer administration tool design for comments) In-Reply-To: <20060210121303.GE16000@redhat.com> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210121303.GE16000@redhat.com> Message-ID: <6252.192.54.193.25.1139574612.squirrel@rousalka.dyndns.org> Le Ven 10 f?vrier 2006 13:13, Tim Waugh a ?crit : > On Thu, Feb 09, 2006 at 08:31:34PM +0100, Nicolas Mailhot wrote: > >> 2.12 Queue routing >> >> 2.12.1 Printer groups >> >> The user must be able to create aliases for groups of printers, and >> print to the group in apps (with the job sent to the first printer in >> the group which is available and ready) >> >> For roaming users which have access to several networked printers (some >> of which may be on another physical site) the choice of the preferred >> printer in the one group may be based on user location (dhcp hints, >> hostname, whatever) > > In CUPS terminology these are "classes". Yes, the administration tool > could configure classes (it can be done using IPP). I would rather > avoid having user-defined classes, though -- system classes should be > sufficient. A typical user will want a "dumb fast black and white printer" class. If you allow for network user-specific printers (smb...) the printers a particular user may have at his disposal to constitute classes will be very different from the ones known at system-level. For laptop users system printers will be corp printers, but user printers will be corp printers + home printers, or even home printers + corp printers + local printers (you really do not want a laptop user to drop in system mode just because he's working on another site) >> 2.12.2 Rescue jobs >> >> When jobs are stuck in the queue of a printer which is no longer >> responding or stuck somewhere, and if other queues with compatible >> characteristics (same PS level and paper...) are available or created >> later, the print jobs should be routed (automatically or after prompting >> the user) to these new queues > > I don't think that CUPS is capable of this. CUPs routing capabilities suck compared to LPRng:(. It might work with a little prodding of the printer admin tool (not sure) Regards, -- Nicolas Mailhot From twaugh at redhat.com Fri Feb 10 12:38:16 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 12:38:16 +0000 Subject: New printer administration tool design for comments In-Reply-To: <1139539682.3069.7.camel@laptopd505.fenrus.org> References: <20060209183002.GA16000@redhat.com> <1139539682.3069.7.camel@laptopd505.fenrus.org> Message-ID: <20060210123816.GF16000@redhat.com> On Fri, Feb 10, 2006 at 03:48:02AM +0100, Arjan van de Ven wrote: > what I'd like to see is a mechanism similar to automatic http proxy > discovery; eg allow for a "site configuration", which you pull down > automatic (say if dhcp points you at it) if you are in a certain > building at work, but not when you are at home (because then you want to > pull down another printer list from your local firewall box ;) I can see two things you might mean: a. site policy tells clients about printers in the print room b. site policy tells clients what settings to use for any local printers that get attached, on a model by model basis (e.g. for HP printer with duplexer, use long-edge duplexing) I think that a. should be taken care of by CUPS browsing (2.7.2 Remote Discovery). I chose interpretation b. when replying to Nicolas Mailhot in "Persistent Settings (was ...)". I don't know if that's what you meant, or if it's a good idea, or how to implement it if it is. :-) Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Fri Feb 10 12:46:08 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 12:46:08 +0000 Subject: Page size (was Re: New printer administration tool design for comments) In-Reply-To: <38299.192.54.193.25.1139573688.squirrel@rousalka.dyndns.org> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210110528.GC16000@redhat.com> <38299.192.54.193.25.1139573688.squirrel@rousalka.dyndns.org> Message-ID: <20060210124608.GG16000@redhat.com> On Fri, Feb 10, 2006 at 01:14:48PM +0100, Nicolas Mailhot wrote: > Ok, but here you are triggering queue creation manually from the shell > with (I suppose) every locale-related environment variables set correctly. > Will it be the case for hotplug-triggered creations ? (it seems not to be > the case today) Today we are using system-config-printer to do this stuff, and while it ought to get it right, in some cases apparently it doesn't. Just using CUPS on its own: [root at gene ~]# export LC_ALL=en_US.UTF-8 [root at gene ~]# unset LANG [root at gene ~]# grep LANG /etc/sysconfig/i18n LANG="en_GB.UTF-8" [root at gene ~]# locale LC_PAPER 279 216 UTF-8 (i.e. Letter) [root at gene ~]# lpadmin -x test lpadmin: delete-printer failed: client-error-not-found [root at gene ~]# zgrep DefaultPageSize /usr/share/cups/model/deskjet.ppd.gz *DefaultPageSize: Letter [root at gene ~]# lpadmin -p test -m deskjet.ppd.gz [root at gene ~]# grep DefaultPageSize /etc/cups/ppd/test.ppd *DefaultPageSize: A4 The CUPS daemon uses the system locale (i.e. the locale it was started in). FWIW, CUPS uses some fairly simplistic rules: if (!DefaultLanguage || !strcasecmp(DefaultLanguage, "C") || !strcasecmp(DefaultLanguage, "POSIX") || !strcasecmp(DefaultLanguage, "en") || !strncasecmp(DefaultLanguage, "en_US", 5) || !strncasecmp(DefaultLanguage, "en_CA", 5) || !strncasecmp(DefaultLanguage, "fr_CA", 5)) I'm sure it could be persuaded to use the equivalent of 'locale LC_PAPER' first, and if that doesn't work fall back to the above method. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Fri Feb 10 12:52:17 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 12:52:17 +0000 Subject: Classes (was Re: New printer administration tool design for comments) In-Reply-To: <6252.192.54.193.25.1139574612.squirrel@rousalka.dyndns.org> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210121303.GE16000@redhat.com> <6252.192.54.193.25.1139574612.squirrel@rousalka.dyndns.org> Message-ID: <20060210125217.GH16000@redhat.com> On Fri, Feb 10, 2006 at 01:30:12PM +0100, Nicolas Mailhot wrote: > A typical user will want a "dumb fast black and white printer" class. If > you allow for network user-specific printers (smb...) the printers a > particular user may have at his disposal to constitute classes will be > very different from the ones known at system-level. I do think there is a real danger of over-designing in this area. Let's try not to make things any more complicated than they need be. Per-user queues are in the design because Stateless Linux requires them. If it weren't for Stateless Linux, I wouldn't be talking about them at all. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From nicolas.mailhot at laposte.net Fri Feb 10 13:05:53 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 10 Feb 2006 14:05:53 +0100 (CET) Subject: New printer administration tool design for comments In-Reply-To: <20060210123816.GF16000@redhat.com> References: <20060209183002.GA16000@redhat.com> <1139539682.3069.7.camel@laptopd505.fenrus.org> <20060210123816.GF16000@redhat.com> Message-ID: <23581.192.54.193.25.1139576753.squirrel@rousalka.dyndns.org> Le Ven 10 f?vrier 2006 13:38, Tim Waugh a ?crit : > On Fri, Feb 10, 2006 at 03:48:02AM +0100, Arjan van de Ven wrote: > >> what I'd like to see is a mechanism similar to automatic http proxy >> discovery; eg allow for a "site configuration", which you pull down >> automatic (say if dhcp points you at it) if you are in a certain >> building at work, but not when you are at home (because then you want to >> pull down another printer list from your local firewall box ;) > > I can see two things you might mean: > > a. site policy tells clients about printers in the print room > > b. site policy tells clients what settings to use for any local > printers that get attached, on a model by model basis (e.g. for HP > printer with duplexer, use long-edge duplexing) > > I think that a. should be taken care of by CUPS browsing (2.7.2 Remote > Discovery). Not entirely. Cups browsing tries to "discover" printers. In this mode you find public printers, which tells you nothing about whether printing on them or not is a good idea (network locality for printers do not translate in physical locality and even less in printing policy user classes). An awful lot of printers are not centrally managed or are too dumb to do fine-grained access checks. Also some printers are not remotely discoverable The dhcp server OTOH can regognize individual systems (mac address), select the appropriate printing policy, and suggest it to the system. Sure you could also put printers on a separate network with a smart print server gateway enforcing all sorts of controls. But that's not usually the case. (my personnal opinion is relying on CUPS browsing is broken by design, because 1. most network printers do not advertise themselves 2. you definitely do *not* want every single computer in a network to aggressively scan it to find new ressources 3. you've found a printer at an IP. So what? You still need to actually locate/access it to find your printouts) > I chose interpretation b. when replying to Nicolas Mailhot in > "Persistent Settings (was ...)". I don't know if that's what you > meant, or if it's a good idea, or how to implement it if it is. :-) b. is useful too, but I don't think it was Arjan's point. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Feb 10 13:16:47 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 10 Feb 2006 14:16:47 +0100 (CET) Subject: Classes (was Re: New printer administration tool design for comments) In-Reply-To: <20060210125217.GH16000@redhat.com> References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210121303.GE16000@redhat.com> <6252.192.54.193.25.1139574612.squirrel@rousalka.dyndns.org> <20060210125217.GH16000@redhat.com> Message-ID: <47786.192.54.193.25.1139577407.squirrel@rousalka.dyndns.org> Le Ven 10 f?vrier 2006 13:52, Tim Waugh a ?crit : > On Fri, Feb 10, 2006 at 01:30:12PM +0100, Nicolas Mailhot wrote: > >> A typical user will want a "dumb fast black and white printer" class. If >> you allow for network user-specific printers (smb...) the printers a >> particular user may have at his disposal to constitute classes will be >> very different from the ones known at system-level. > > I do think there is a real danger of over-designing in this area. > Let's try not to make things any more complicated than they need be. > Per-user queues are in the design because Stateless Linux requires > them. If it weren't for Stateless Linux, I wouldn't be talking about > them at all. Stateless Linux is just an extreme case of roaming user. Most of the stateless linux enhancements are also very useful for roaming laptop users. In the Stateless Linux care changing system state is useless because it's not saved. In the Roaming Laptop User case you could possibly change system state except : 1. He'll plug in networks controlled by different entities. You need to isolate the printing policies of each of those entities, and none of them is abilited to do the synthesis of all the policies. The roaming user will have to do it alone 2. you really do *not* want to give him admin rights and ability to do changes at the system level. Synthesis (priorization of queues, alias asignments) must be done at the user level Regards, -- Nicolas Mailhot From tibbs at math.uh.edu Fri Feb 10 14:59:47 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 10 Feb 2006 08:59:47 -0600 Subject: Classes In-Reply-To: <20060210121303.GE16000@redhat.com> (Tim Waugh's message of "Fri, 10 Feb 2006 12:13:03 +0000") References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210121303.GE16000@redhat.com> Message-ID: >>>>> "TW" == Tim Waugh writes: [Rescue jobs] TW> I don't think that CUPS is capable of this. Does CUPS have to do this? I believe CUPS allows a user to move a job from one queue to another. A user-level print manager could note that a job has yet to print (or that a queue has failed to advance), notify the user of the fact and give them the opportunity to shift the job to another queue. - J< From twaugh at redhat.com Fri Feb 10 15:20:05 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 15:20:05 +0000 Subject: Classes In-Reply-To: References: <20060209183002.GA16000@redhat.com> <1139513494.19338.31.camel@rousalka.dyndns.org> <20060210121303.GE16000@redhat.com> Message-ID: <20060210152005.GI16000@redhat.com> On Fri, Feb 10, 2006 at 08:59:47AM -0600, Jason L Tibbitts III wrote: > >>>>> "TW" == Tim Waugh writes: > > [Rescue jobs] > TW> I don't think that CUPS is capable of this. > > Does CUPS have to do this? I believe CUPS allows a user to move a job > from one queue to another. A user-level print manager could note that > a job has yet to print (or that a queue has failed to advance), notify > the user of the fact and give them the opportunity to shift the job to > another queue. Well, anyway, it's something for the application that manages print jobs (I think eggcups does this now?), not the administration tool. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From orion at cora.nwra.com Fri Feb 10 16:39:51 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 10 Feb 2006 09:39:51 -0700 Subject: New printer administration tool design for comments In-Reply-To: <20060209183002.GA16000@redhat.com> References: <20060209183002.GA16000@redhat.com> Message-ID: <43ECC1D7.6030408@cora.nwra.com> Tim Waugh wrote: > A NEW PRINTER ADMINISTRATION TOOL > ================================= > > 2.4. Modifying PPD options > --------------------- > > The new printer administration tool will be responsible for providing > a graphical interface for changing default queue options. These are > options such as duplexing, page size, and print quality. All of these > options are stored in the PPD file representing the queue, and this is > modified by the CUPS daemon when it receives the IPP request to do so. > Maybe too early for specific feature requests, but here goes: Certain newer printers can print PDF natively. To do so requires the following added to the PPD: *cupsFilter: "application/pdf 0 -" I'm still not sure how useful this is (brand new printer for us), but should be configurable from the admin interface. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From twaugh at redhat.com Fri Feb 10 17:36:02 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 17:36:02 +0000 Subject: New printer administration tool design for comments In-Reply-To: <43ECC1D7.6030408@cora.nwra.com> References: <20060209183002.GA16000@redhat.com> <43ECC1D7.6030408@cora.nwra.com> Message-ID: <20060210173602.GK16000@redhat.com> On Fri, Feb 10, 2006 at 09:39:51AM -0700, Orion Poplawski wrote: > Maybe too early for specific feature requests, but here goes: > > Certain newer printers can print PDF natively. To do so requires the > following added to the PPD: > > *cupsFilter: "application/pdf 0 -" > > I'm still not sure how useful this is (brand new printer for us), but > should be configurable from the admin interface. I think the first step is making it really easy to use a given PPD to set up a queue. Right now that's harder than it should be. It would be good to concentrate on re-implementing the functionality we already have in such a way that it is no longer tied to alchemist, and then we can look at new features. For the specific case of native PDF handling, there are rumblings among printing developers about switching from PS to PDF for jobs in the future anyway, so perhaps it's best to see what happens with that. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From twaugh at redhat.com Fri Feb 10 17:57:45 2006 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 10 Feb 2006 17:57:45 +0000 Subject: New printer administration tool design for comments In-Reply-To: <20060209183002.GA16000@redhat.com> References: <20060209183002.GA16000@redhat.com> Message-ID: <20060210175745.GM16000@redhat.com> I've sent a newer draft of this to fedora-devel-list. Thanks for your feedback so far! Thanks, Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jkeating at redhat.com Fri Feb 10 19:04:28 2006 From: jkeating at redhat.com (Jesse Keating) Date: Fri, 10 Feb 2006 11:04:28 -0800 Subject: Massive rebuild in progress In-Reply-To: <1139340272.3579.23.camel@ender> References: <1139340272.3579.23.camel@ender> Message-ID: <1139598268.2892.45.camel@ender> On Tue, 2006-02-07 at 11:24 -0800, Jesse Keating wrote: > After a late night of staging, I have 900~ packages queued up to rebuild > for the gcc4.1 snapshot and glibc changes. These will be submitted to > our build system throughout the day as low priority jobs. Some will be > finished for tonight's rawhide push, but not all of them. There are > still some packages that should be rebuilt that are not in my list, but > those package maintainer's have expressed desire to bump their packages > themselves. Over the next couple days I'll be checking package > timestamps and keeping an eye on what else needs to build. Please bear > with the churn and the very lengthy rawhide reports. A late breaking bug was found that affects ppc32/64 systems, and so I have to rebuild every package that is built on these arches over the weekend. Please wait on rebuilding Extras until this is done. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From arjan at fenrus.demon.nl Sun Feb 12 12:21:23 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 12 Feb 2006 13:21:23 +0100 Subject: New printer administration tool design for comments In-Reply-To: <20060210123816.GF16000@redhat.com> References: <20060209183002.GA16000@redhat.com> <1139539682.3069.7.camel@laptopd505.fenrus.org> <20060210123816.GF16000@redhat.com> Message-ID: <1139746883.20703.3.camel@laptopd505.fenrus.org> On Fri, 2006-02-10 at 12:38 +0000, Tim Waugh wrote: > On Fri, Feb 10, 2006 at 03:48:02AM +0100, Arjan van de Ven wrote: > > > what I'd like to see is a mechanism similar to automatic http proxy > > discovery; eg allow for a "site configuration", which you pull down > > automatic (say if dhcp points you at it) if you are in a certain > > building at work, but not when you are at home (because then you want to > > pull down another printer list from your local firewall box ;) > > I can see two things you might mean: > > a. site policy tells clients about printers in the print room I meant this one > I think that a. should be taken care of by CUPS browsing (2.7.2 Remote > Discovery). I doubt it; discovery is nice for small networks but for bigger companies... not so, same for printers which don't by nature do discoverable things; it also can take a long time and a lot of network traffic. Some places turn discovery off on a sysadmin level (eg they filter it on the router) as a result. While.. it wouldn't be hard to get the settings from a server, especially when it's easy to do for both the admins and the user. From arjan at fenrus.demon.nl Sun Feb 12 13:21:05 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 12 Feb 2006 14:21:05 +0100 Subject: New printer administration tool design for comments In-Reply-To: <43EC1570.3080107@redhat.com> References: <20060209183002.GA16000@redhat.com> <1139539682.3069.7.camel@laptopd505.fenrus.org> <43EC1570.3080107@redhat.com> Message-ID: <1139750465.20703.9.camel@laptopd505.fenrus.org> On Thu, 2006-02-09 at 23:24 -0500, Christopher Blizzard wrote: > Arjan van de Ven wrote: > > On Thu, 2006-02-09 at 18:30 +0000, Tim Waugh wrote: > >> A NEW PRINTER ADMINISTRATION TOOL > >> ================================= > > > > > > what I'd like to see is a mechanism similar to automatic http proxy > > discovery; eg allow for a "site configuration", which you pull down > > automatic (say if dhcp points you at it) if you are in a certain > > building at work, but not when you are at home (because then you want to > > pull down another printer list from your local firewall box ;) > > > > Yeah, getting off topic, this would be nice to have. But maybe not in > our short printing time frame. > > [ I've always wanted to have a dhcp hint to find a local public > directory server that exposes all these services. ] it could be dhcp.. it could be network manager where you set a printer settings thing per location profile. But bigger companies will really need this, browsing sucks for them. From nicolas.mailhot at laposte.net Sun Feb 12 13:44:57 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Feb 2006 14:44:57 +0100 Subject: New printer administration tool design for comments In-Reply-To: <1139750465.20703.9.camel@laptopd505.fenrus.org> References: <20060209183002.GA16000@redhat.com> <1139539682.3069.7.camel@laptopd505.fenrus.org> <43EC1570.3080107@redhat.com> <1139750465.20703.9.camel@laptopd505.fenrus.org> Message-ID: <1139751897.27179.6.camel@rousalka.dyndns.org> Le dimanche 12 f?vrier 2006 ? 14:21 +0100, Arjan van de Ven a ?crit : > On Thu, 2006-02-09 at 23:24 -0500, Christopher Blizzard wrote: > > Arjan van de Ven wrote: > > > On Thu, 2006-02-09 at 18:30 +0000, Tim Waugh wrote: > > >> A NEW PRINTER ADMINISTRATION TOOL > > >> ================================= > > > > > > > > > what I'd like to see is a mechanism similar to automatic http proxy > > > discovery; eg allow for a "site configuration", which you pull down > > > automatic (say if dhcp points you at it) if you are in a certain > > > building at work, but not when you are at home (because then you want to > > > pull down another printer list from your local firewall box ;) > > > > > > > Yeah, getting off topic, this would be nice to have. But maybe not in > > our short printing time frame. > > > > [ I've always wanted to have a dhcp hint to find a local public > > directory server that exposes all these services. ] > > it could be dhcp.. it could be network manager where you set a printer > settings thing per location profile. But bigger companies will really > need this, browsing sucks for them. Especially since a dhcp hint is already documented in dhcp man pages, except it's for lpr systems and useless in the brave new ipp world Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From caillon at redhat.com Mon Feb 13 08:19:28 2006 From: caillon at redhat.com (Christopher Aillon) Date: Mon, 13 Feb 2006 03:19:28 -0500 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> Message-ID: <43F04110.3050002@redhat.com> Just a note that all the dependencies of gstreamer08 are gone from Core, and we will be removing gstreamer08 soon from Core. There is a package or two in extras that depends on it still, so this is a heads up that either it needs to be imported into Extras, or packages should be updated to use gstreamer 0.10. Thanks From gauret at free.fr Mon Feb 13 09:24:57 2006 From: gauret at free.fr (Aurelien Bompard) Date: Mon, 13 Feb 2006 10:24:57 +0100 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <43F04110.3050002@redhat.com> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> Message-ID: <200602131024.58482.gauret@free.fr> Le Lundi 13 F?vrier 2006 09:19, Christopher Aillon a ?crit : > Just a note that all the dependencies of gstreamer08 are gone from Core, > and we will be removing gstreamer08 soon from Core. There is a package > or two in extras that depends on it still, so this is a heads up that > either it needs to be imported into Extras, or packages should be > updated to use gstreamer 0.10. Amarok is one of those packages still depending on gstreamer 0.8. Version 1.4beta1 was out two days ago, and in the changelog there is : * Initial port of GStreamer engine to GStreamer 0.10. So I think amarok 1.4 final will use gstreamer 0.10 (I'm double-checking that with the devs). Amarok 1.4 will be out before FC5, so this package does not need gstreamer 0.8 imported into Extras. Aur?lien -- http://aurelien.bompard.org ~~~~ Jabber : abompard at jabber.fr L'exp?rience est quelquechose que l'on acquiert juste apr?s en avoir eu besoin. From bdpepple at ameritech.net Mon Feb 13 14:25:02 2006 From: bdpepple at ameritech.net (Brian Pepple) Date: Mon, 13 Feb 2006 09:25:02 -0500 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <43F04110.3050002@redhat.com> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> Message-ID: <1139840702.5721.4.camel@shuttle.273piedmont.org> On Mon, 2006-02-13 at 03:19 -0500, Christopher Aillon wrote: > Just a note that all the dependencies of gstreamer08 are gone from Core, > and we will be removing gstreamer08 soon from Core. There is a package > or two in extras that depends on it still, so this is a heads up that > either it needs to be imported into Extras, or packages should be > updated to use gstreamer 0.10. > Looks like gnomebaker is about the only package that still uses gstreamer08 (now that Amarok is just about finished ported). If no one has already imported gstreamer08 into Extras, I'd be willing to take over the package. /B -- Brian Pepple gpg --keyserver pgp.mit.edu --recv-keys 810CC15E BD5E 6F9E 8688 E668 8F5B CBDE 326A E936 810C C15E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Mon Feb 13 15:45:08 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 13 Feb 2006 10:45:08 -0500 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <1139840702.5721.4.camel@shuttle.273piedmont.org> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> <1139840702.5721.4.camel@shuttle.273piedmont.org> Message-ID: <604aa7910602130745t7a62667dg61d113f3630b18d@mail.gmail.com> On 2/13/06, Brian Pepple wrote: > Looks like gnomebaker is about the only package that still uses > gstreamer08 (now that Amarok is just about finished ported). If no one > has already imported gstreamer08 into Extras, I'd be willing to take > over the package. istanbul still uses gstreamer08 via the python-gstreamer08 packages in Extras. (There is a build problem with python-gstreamer08 currently which is keeping istanbul from building) Last I heard from upstreamer, istanbul doesn't work with .10. -jef From fedora at leemhuis.info Mon Feb 13 17:22:42 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Feb 2006 18:22:42 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras Message-ID: <1139851362.2904.79.camel@localhost.localdomain> Replies to fedora-extras-list please, tia! Hi Fedora Maintainers! The last rawhide mass-rebuild is mostly done now so it's time for us to also rebuild **all packages** in the Fedora Extras development tree before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is branched/released. Why a rebuild of all packages? There are several reasons, the most important: - use the security features the new gcc 4.1 provides - make sure everything still builds with gcc 4.1, modular xorg and all the other things that have changed since FC4 How does it work? Very simple: If you have a package in Fedora Extras checkout a fresh version from cvs, increase "Release" by one and add a changelog-entry with and explanation like "Rebuild for Fedora Extras 5". Then run the usual "make tag build". While at it make sure that the upgrade path from FE4 to FE5 works -- e.g. the epoch:version-release of a package in the devel-tree/FE5 needs to be higher than in FE4 (hint: use fedora-rpmvercmp from fedora-rpmdevtools if you want to test which epoch:version-release is higher). Are there any specific things that need attention? The most important: - Please don't flood the buildsys with to many rebuild requests. E.g. before you run make build take a look at the buildsys web interface at http://buildsys.fedoraproject.org/build-status/ If there are many jobs listed already (let's say more then round about 40 packages) then please wait with the rebuild request some hours or a day. Why that? We have no priorities in the buildsys atm, but need a chance to get urgent updates for FC-4 and/or FC-3 build in case a security problem arises in an extras package. - Don't request rebuilds for FC-4 or FC-3 just to keep the spec files in sync in all branches. This would mean a extra burden for the buildsys and for the users (they would have to download new packages where nothing changed) Do all packages need a rebuild? Yes. Most noarch packages probably would work fine without a rebuild and won't have a benefit from the new gcc security features. But we know that some noarch package are broken due to changes in rawhide -- we'd like to catch and fix those. And we want to make sure that a package still has a active maintainer while at it. If you want to be nice please submit the noach rebuild request only after February the 18th or when less then 10 packages are in the buildsys build queue. Should the build-requests happen in dep-order? They should in an ideal world -- but we chose to ignore it (core ignores the order, too, and it works fine). If you know that build-order is important to your package please take care of it manually. You don't like it? Then work on a better solution for the FE6 rebuild ;-) What about orphaned packages? They should be removed by now. If you need one of them to build your package you probably have to adopt them (we might have one or two such cases) What shall I do if a rebuild failed? Fix it. If you need help ask on fedora-extras-list and/or on #fedora-extras. It might be a good idea to use some tagging in the subject when posting to the list, e.g.: [gcc] - for problems specific to gcc [xorg] - for problems related to modular xorg [x86-64] - for problems specific to x86_64 [ppc] - for problems specific to pcc [python] - for problems related to python [perl] - for problems related to perl [gtk/gnome] - for problems related to GTK/GNOME [qt/kde] - for problems related to Qt/KDE *Note*: If you can't fix it until February the 24th please file a bug in bugzilla.redhat.com for the problem. In the field "Bug XYZ Block" please add "FE5Target" -- this way it blocks the tracker bug 162161. This bureaucracy is needed to allow other people to track the status of the packages not yet rebuild. What happens with packages where no one stepped up to rebuild them? Ehhh, we didn't talk about that to much yet. Maybe we'll file bugs after the rebuild flood goes back and ask the package-maintainer to rebuild his or her package(s). Or we simply rebuild them and ignore the maintainer -- but in that case we can't be sure that the maintainer is still active in Fedora Extras. What happens with the old packages build before February the 13th 2006? They'll probably be removed from the repo before FE5 goes live. That's all. Thanks for you attention. CU thl /me hopes that he hasn't forgotten anything important -- Thorsten Leemhuis From fedora at leemhuis.info Mon Feb 13 18:15:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Mon, 13 Feb 2006 19:15:32 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139851362.2904.79.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> Message-ID: <1139854532.2904.83.camel@localhost.localdomain> Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > Are there any specific things that need attention? > > The most important: > - Please don't flood the buildsys with to many rebuild requests. E.g. > before you run make build take a look at the buildsys web interface at > http://buildsys.fedoraproject.org/build-status/ > If there are many jobs listed already (let's say more then round about > 40 packages) then please wait with the rebuild request some hours or a > day. Why that? We have no priorities in the buildsys atm, but need a > chance to get urgent updates for FC-4 and/or FC-3 build in case a > security problem arises in an extras package. That was a stupid idea -- the web interface does not list all packages that are in the waiting state. So use something like the following to get the number of packages that are waiting in the buildsys already: $ plague-client list status waiting | grep -e '^$' | wc -l 38 -- Thorsten Leemhuis From nicolas.mailhot at laposte.net Mon Feb 13 22:16:06 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 13 Feb 2006 23:16:06 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139854532.2904.83.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1139854532.2904.83.camel@localhost.localdomain> Message-ID: <1139868966.7241.0.camel@rousalka.dyndns.org> buildsys is already dead : Package foo enqueued. (However, no Job ID was provided in the time required) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dcbw at redhat.com Tue Feb 14 07:33:18 2006 From: dcbw at redhat.com (Dan Williams) Date: Tue, 14 Feb 2006 02:33:18 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139868966.7241.0.camel@rousalka.dyndns.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1139854532.2904.83.camel@localhost.localdomain> <1139868966.7241.0.camel@rousalka.dyndns.org> Message-ID: <1139902398.3523.12.camel@localhost.localdomain> On Mon, 2006-02-13 at 23:16 +0100, Nicolas Mailhot wrote: > buildsys is already dead : > > Package foo enqueued. (However, no Job ID was provided in the time > required) Been kicked, packages that made it into the db are restarted. Dan From nicolas.mailhot at laposte.net Tue Feb 14 09:43:55 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 14 Feb 2006 10:43:55 +0100 (CET) Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139902398.3523.12.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1139854532.2904.83.camel@localhost.localdomain> <1139868966.7241.0.camel@rousalka.dyndns.org> <1139902398.3523.12.camel@localhost.localdomain> Message-ID: <14648.192.54.193.25.1139910235.squirrel@rousalka.dyndns.org> Le Mar 14 f?vrier 2006 08:33, Dan Williams a ?crit : > On Mon, 2006-02-13 at 23:16 +0100, Nicolas Mailhot wrote: >> buildsys is already dead : >> >> Package foo enqueued. (However, no Job ID was provided in the time >> required) > > Been kicked, packages that made it into the db are restarted. Thanks a lot (that's one reason BTW why IMHO it would better if the mass rebuild was controled by someone able to kick the system at need *and* limit the number of in-flight packages to something the buildsys can handle) Regards, -- Nicolas Mailhot From thomas at apestaart.org Tue Feb 14 19:19:36 2006 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Tue, 14 Feb 2006 20:19:36 +0100 Subject: gstreamer08 is dead; long live gstreamer In-Reply-To: <43F04110.3050002@redhat.com> References: <200602130747.k1D7lXGQ018834@porkchop.devel.redhat.com> <43F04110.3050002@redhat.com> Message-ID: <1139944776.4109.22.camel@otto> On Mon, 2006-02-13 at 03:19 -0500, Christopher Aillon wrote: > Just a note that all the dependencies of gstreamer08 are gone from Core, > and we will be removing gstreamer08 soon from Core. There is a package > or two in extras that depends on it still, so this is a heads up that > either it needs to be imported into Extras, or packages should be > updated to use gstreamer 0.10. Excellent news ! So, do people want a gstreamer08 in Extras ? If so, I of course wouldn't mind maintaining it. Let me know, Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> You take it in stride but still You fall as you're walking Big sky above me a river inside me and I'm Doubled up in love <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From shahms at shahms.com Wed Feb 15 15:58:01 2006 From: shahms at shahms.com (Shahms King) Date: Wed, 15 Feb 2006 07:58:01 -0800 Subject: Kick the Build System Please Message-ID: <43F34F89.10102@shahms.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could someone kick the build system? I'm getting "Connection Refused" errors (and the status page says the same). - -- Shahms E. King Multnomah ESD Public Key: http://shahms.mesd.k12.or.us/~sking/shahms.asc Fingerprint: 1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFD80+J/qs2NkWy11sRAmwVAJwKEyBC6UGbbtFuK+2MtYYpwEFRUQCeNJ8Q eOKwEaVjnepQe2ttld30Z/k= =J3q6 -----END PGP SIGNATURE----- From kaboom at oobleck.net Wed Feb 15 15:13:41 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 15 Feb 2006 10:13:41 -0500 (EST) Subject: build system needs a kick? Message-ID: Looks like the build system is down [kaboom at urd ~]$ plague-client list_builders Error connecting to build server: '(111, 'Connection refused')' [kaboom at urd ~]$ later, chris From skvidal at linux.duke.edu Wed Feb 15 16:16:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 15 Feb 2006 11:16:36 -0500 Subject: build system needs a kick? In-Reply-To: References: Message-ID: <1140020196.13764.17.camel@cutter> On Wed, 2006-02-15 at 10:13 -0500, Chris Ricker wrote: > Looks like the build system is down > > [kaboom at urd ~]$ plague-client list_builders > Error connecting to build server: '(111, 'Connection refused')' > [kaboom at urd ~]$ > kicked. -sv From kaboom at oobleck.net Wed Feb 15 16:38:52 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 15 Feb 2006 11:38:52 -0500 (EST) Subject: build system needs a kick? In-Reply-To: <1140020196.13764.17.camel@cutter> References: <1140020196.13764.17.camel@cutter> Message-ID: On Wed, 15 Feb 2006, seth vidal wrote: > On Wed, 2006-02-15 at 10:13 -0500, Chris Ricker wrote: > > Looks like the build system is down > > > > [kaboom at urd ~]$ plague-client list_builders > > Error connecting to build server: '(111, 'Connection refused')' > > [kaboom at urd ~]$ > > > > kicked. Thanks! It tried to build a couple of mine (jobs 4433 and 4432), wasn't able to due to the same errors everyone's reporting (incomplete headers on packages from mirror) and now it's down again.... later, chris From kaboom at oobleck.net Wed Feb 15 16:53:15 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 15 Feb 2006 11:53:15 -0500 (EST) Subject: FC-4 CVS problem? Message-ID: If I try to check out the entire FC-4 tree, I get this [kaboom at fc5test fedora-extras-cvs]$ cvs co FC-4 For more information on using the Fedora CVS repositories, please visit http://fedoraproject.org/wiki/UsingCvs U bazaar/bazaar.spec U galculator/galculator-1.2.5-gobject-unref.patch U galculator/galculator.spec cvs [checkout aborted]: there is no repository /cvs/extras/rpms/GiNaC/FC-4 [kaboom at fc5test fedora-extras-cvs]$ Looks like maybe GiNaC got renamed to ginac but wasn't cleaned up completely in FC-4? later, chris From dcbw at redhat.com Wed Feb 15 16:52:11 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 15 Feb 2006 11:52:11 -0500 Subject: build system needs a kick? In-Reply-To: References: <1140020196.13764.17.camel@cutter> Message-ID: <1140022331.4231.4.camel@localhost.localdomain> On Wed, 2006-02-15 at 11:38 -0500, Chris Ricker wrote: > On Wed, 15 Feb 2006, seth vidal wrote: > > > On Wed, 2006-02-15 at 10:13 -0500, Chris Ricker wrote: > > > Looks like the build system is down > > > > > > [kaboom at urd ~]$ plague-client list_builders > > > Error connecting to build server: '(111, 'Connection refused')' > > > [kaboom at urd ~]$ > > > > > > > kicked. > > Thanks! > > It tried to build a couple of mine (jobs 4433 and 4432), wasn't able to > due to the same errors everyone's reporting (incomplete headers on > packages from mirror) and now it's down again.... Sorry, was fixing some SSL issues this morning. Should be back up and better than ever now :) I'm not sure of the status of rawhide though. Dan From dcbw at redhat.com Wed Feb 15 16:52:30 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 15 Feb 2006 11:52:30 -0500 Subject: Kick the Build System Please In-Reply-To: <43F34F89.10102@shahms.com> References: <43F34F89.10102@shahms.com> Message-ID: <1140022351.4231.6.camel@localhost.localdomain> On Wed, 2006-02-15 at 07:58 -0800, Shahms King wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Could someone kick the build system? I'm getting "Connection Refused" > errors (and the status page says the same). Was doing some SSL fixes. Should be all good now. Dan From bugs.michael at gmx.net Fri Feb 17 00:39:37 2006 From: bugs.michael at gmx.net (Michael Schwendt) Date: Fri, 17 Feb 2006 01:39:37 +0100 Subject: FC-4 CVS problem? In-Reply-To: References: Message-ID: <20060217013937.3aa31b0a.bugs.michael@gmx.net> On Wed, 15 Feb 2006 11:53:15 -0500 (EST), Chris Ricker wrote: > If I try to check out the entire FC-4 tree, I get this > > [kaboom at fc5test fedora-extras-cvs]$ cvs co FC-4 > For more information on using the Fedora CVS repositories, please visit > http://fedoraproject.org/wiki/UsingCvs > U bazaar/bazaar.spec > U galculator/galculator-1.2.5-gobject-unref.patch > U galculator/galculator.spec > cvs [checkout aborted]: there is no repository /cvs/extras/rpms/GiNaC/FC-4 > [kaboom at fc5test fedora-extras-cvs]$ > > Looks like maybe GiNaC got renamed to ginac but wasn't cleaned up > completely in FC-4? Looked liked incomplete removal of CVS modules. Several others were broken, too, and had been on the FC4Status Wiki page before. Fixed. From fedora at leemhuis.info Fri Feb 17 19:51:32 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 17 Feb 2006 20:51:32 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1139851362.2904.79.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> Message-ID: <1140205892.2904.30.camel@localhost.localdomain> This time also: Replies to fedora-extras-list please, tia! Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > Hi Fedora Maintainers! > > The last rawhide mass-rebuild is mostly done now so it's time for us to > also rebuild **all packages** in the Fedora Extras development tree > before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is > branched/released. Guys, please keep the buildsys busy. There are a lot of packages that are still not rebuild afaics. I wrote a small script "buildcheck" (attached) that can check what packages are not yet rebuild. The script is far from perfect but it works quite well afaics. Maybe it has some bugs -- I'm sure you guys will find some and tell me about it. How does it work? Rough version: It checks the buildtime of all srpms in extras/development and prints the name and the email of all those that were rebuild before the official mass-rebuild was announced. The script found the following packages in extras/development for which no entry in the owners.list could be found: fftw3, umfpack, perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, dia, libdsk, libspectrum, lib765 The following 565 arch specific packages still need a rebuild according to the script. There might be some false positives in the list like for example "icu" -- that was moved to core, but still is in the repo and found by the script. Simply ignore those false positives. aaron.bennett at olin.edu ifplugd ad+rh-bugzilla at uni-x.org pam_abl adrian at lisas.de cvsup adrian at lisas.de jhead adrian at lisas.de kover adrian at lisas.de libcdio adrian at lisas.de most adrian at lisas.de nexuiz adrian at lisas.de ninja adrian at lisas.de sopwith adrian at lisas.de source-highlight adrian at lisas.de tin adrian at lisas.de uudeview adrian at lisas.de vnstat adrian at lisas.de xdesktopwaves adrian at lisas.de xlockmore adrian at lisas.de xmlindent a.kurtz at hardsun.net libdaemon andreas at bawue.net barcode andreas at bawue.net commoncpp2 andreas at bawue.net ddrescue andreas at bawue.net mod_suphp andreas at bawue.net perl-Crypt-Blowfish andreas at bawue.net scmxx andreas.bierfert at lowlatency.de fbdesk andreas.bierfert at lowlatency.de fluxbox andreas.bierfert at lowlatency.de lcms andreas.bierfert at lowlatency.de orange andreas.bierfert at lowlatency.de synce andreas.bierfert at lowlatency.de synce-gnomevfs andreas.bierfert at lowlatency.de synce-software-manager andreas.bierfert at lowlatency.de synce-trayicon andreas.bierfert at lowlatency.de wine anvil at livna.org aalib anvil at livna.org bin2iso anvil at livna.org id3lib anvil at livna.org imlib2 anvil at livna.org irssi anvil at livna.org libcddb anvil at livna.org libebml anvil at livna.org libmatroska anvil at livna.org libsamplerate anvil at livna.org libsndfile anvil at livna.org libtar anvil at livna.org lzo aportal at univ-montp2.fr gpsim aportal at univ-montp2.fr gputils aportal at univ-montp2.fr gtk+extra aportal at univ-montp2.fr utrac bdpepple at ameritech.net gnomebaker bdpepple at ameritech.net tagtool bojan at rexursive.com libapreq2 bressers at redhat.com nmh bugs.michael at gmx.net abicheck bugs.michael at gmx.net aide bugs.michael at gmx.net bchunk bugs.michael at gmx.net chkrootkit bugs.michael at gmx.net mhash bugs.michael at gmx.net xmms-sid caillon at redhat.com epiphany-extensions ch.nolte at fh-wolfenbuettel.de kbibtex chris at chrisgrau.com frotz chris at chrisgrau.com ifm chris at chrisgrau.com perl-Time-Piece chrisw at redhat.com git-core colin at fedoraproject.org adns colin at fedoraproject.org gaim-guifications colin at fedoraproject.org MagicPoint colin at fedoraproject.org python-adns danken at cs.technion.ac.il bidiv danken at cs.technion.ac.il hspell danken at cs.technion.ac.il taarich davidhart at tqmcube.com leafnode davidz at redhat.com NetworkManager-vpnc denis at poolshark.org galeon denis at poolshark.org gconfmm26 denis at poolshark.org glibmm24 denis at poolshark.org gnome-vfsmm26 denis at poolshark.org gtkmm24 denis at poolshark.org inkscape denis at poolshark.org libglademm24 denis at poolshark.org libgnomecanvasmm26 denis at poolshark.org libgnomemm26 denis at poolshark.org libgnomeuimm26 denis at poolshark.org libsigc++ denis at poolshark.org libsigc++20 dennis at ausil.us krecipes dgregor at redhat.com perl-Class-MethodMaker dwmw2 at infradead.org ctrlproxy dwmw2 at redhat.com exim dwmw2 at redhat.com hfsplusutils endur at bennewitz.com streamtuner enrico.scholz at informatik.tu-chemnitz.de cfs enrico.scholz at informatik.tu-chemnitz.de clamav enrico.scholz at informatik.tu-chemnitz.de dhcp-forwarder enrico.scholz at informatik.tu-chemnitz.de dietlibc enrico.scholz at informatik.tu-chemnitz.de gif2png enrico.scholz at informatik.tu-chemnitz.de hunt enrico.scholz at informatik.tu-chemnitz.de ip-sentinel enrico.scholz at informatik.tu-chemnitz.de libtasn1 enrico.scholz at informatik.tu-chemnitz.de milter-greylist enrico.scholz at informatik.tu-chemnitz.de mimetic enrico.scholz at informatik.tu-chemnitz.de opencdk enrico.scholz at informatik.tu-chemnitz.de util-vserver enrico.scholz at informatik.tu-chemnitz.de xca enrico.scholz at informatik.tu-chemnitz.de xmlrpc-c extras-orphan at fedoraproject.org abe extras-orphan at fedoraproject.org anjuta extras-orphan at fedoraproject.org arc extras-orphan at fedoraproject.org at-poke extras-orphan at fedoraproject.org camstream extras-orphan at fedoraproject.org cgoban extras-orphan at fedoraproject.org cksfv extras-orphan at fedoraproject.org conglomerate extras-orphan at fedoraproject.org duplicity extras-orphan at fedoraproject.org freedroidrpg extras-orphan at fedoraproject.org gnofract4d extras-orphan at fedoraproject.org gnome-telnet extras-orphan at fedoraproject.org gnugo extras-orphan at fedoraproject.org gpa extras-orphan at fedoraproject.org gtkglarea2 extras-orphan at fedoraproject.org gurlchecker extras-orphan at fedoraproject.org libzvt extras-orphan at fedoraproject.org lua extras-orphan at fedoraproject.org manedit extras-orphan at fedoraproject.org mknbi extras-orphan at fedoraproject.org netdiag extras-orphan at fedoraproject.org nget extras-orphan at fedoraproject.org ots extras-orphan at fedoraproject.org parchive extras-orphan at fedoraproject.org prozilla extras-orphan at fedoraproject.org putty extras-orphan at fedoraproject.org sirius extras-orphan at fedoraproject.org tdl extras-orphan at fedoraproject.org tetex-lgrind extras-orphan at fedoraproject.org tla extras-orphan at fedoraproject.org wbxml2 extras-orphan at fedoraproject.org xmms-cdread extras-orphan at fedoraproject.org xtide fedora at leemhuis.info icu fedora.wickert at arcor.de emelfm2 fedora.wickert at arcor.de xfce4-mount-plugin fedora.wickert at arcor.de xfce4-netload-plugin fedora.wickert at arcor.de xfce4-sensors-plugin fredrik at dolda2000.com icmpdn gajownik at gmail.com athcool gauret at free.fr amarok gauret at free.fr amaya gauret at free.fr apachetop gauret at free.fr basket gauret at free.fr colorscheme gauret at free.fr elmo gauret at free.fr gmpc gauret at free.fr grisbi gauret at free.fr gwenview gauret at free.fr iftop gauret at free.fr libkexif gauret at free.fr libkipi gauret at free.fr libvisual gauret at free.fr mpc gauret at free.fr pdftohtml gauret at free.fr perl-Jcode gauret at free.fr perl-Unicode-Map gauret at free.fr perl-Unicode-Map8 gauret at free.fr perl-Unicode-String gauret at free.fr psi gauret at free.fr pure-ftpd gauret at free.fr qca gauret at free.fr qca-tls gauret at free.fr showimg gauret at free.fr taglib gauret at free.fr ulogd gauret at free.fr unrtf gauret at free.fr wv gauret at free.fr xbindkeys gauret at free.fr xlhtml gauret at free.fr zope gemi at bluewin.ch abcm2ps gemi at bluewin.ch audacity gemi at bluewin.ch bigloo gemi at bluewin.ch clisp gemi at bluewin.ch cook gemi at bluewin.ch erlang gemi at bluewin.ch gforth gemi at bluewin.ch global gemi at bluewin.ch graveman gemi at bluewin.ch GtkAda gemi at bluewin.ch lablgl gemi at bluewin.ch lablgtk gemi at bluewin.ch ocaml gemi at bluewin.ch pl gemi at bluewin.ch plt-scheme gemi at bluewin.ch qcad gemi at bluewin.ch skencil gemi at bluewin.ch TeXmacs gemi at bluewin.ch unison gemi at bluewin.ch yap ghenry at suretecsystems.com john ghenry at suretecsystems.com librsync ghenry at suretecsystems.com rdiff-backup green at redhat.com itext green at redhat.com jakarta-commons-cli green at redhat.com jogl green at redhat.com kawa green at redhat.com rssowl grenier at cgsecurity.org testdisk hamzy at us.ibm.com sblim-cmpi-base hamzy at us.ibm.com sblim-cmpi-devel hamzy at us.ibm.com sblim-wbemcli i at stingr.net flow-tools i at stingr.net pyflowtools i at stingr.net rzip ivazquez at ivazquez.net hamlib ivazquez at ivazquez.net lock-keys-applet ivazquez at ivazquez.net sqlite2 jamatos at fc.up.pt fftw2 jamatos at fc.up.pt R-mAr jcarpenter at condell.org ks3switch jcarpenter at condell.org lrmi jcarpenter at condell.org s3switch jcarpenter at condell.org tpb jcarpenter at condell.org xosd jdennis at redhat.com cyrus-imapd jeff.gilchrist at gmail.com pbzip2 jeff at ollie.clive.ia.us byzanz jeff at ollie.clive.ia.us libeXosip2 jeff at ultimateevil.org up-imapproxy jeff at ultimateevil.org zile jfontain at free.fr blt jfontain at free.fr tktable jnovy at redhat.com allegro jnovy at redhat.com cproto jnovy at redhat.com nedit Jochen at herr-schmitt.de blender joost at cnoc.nl fpc jpo at di.uminho.pt libol jpo at di.uminho.pt perl-AppConfig jpo at di.uminho.pt perl-Compress-Bzip2 jpo at di.uminho.pt perl-DBD-SQLite jpo at di.uminho.pt perl-DBD-XBase jpo at di.uminho.pt perl-Digest-MD4 jpo at di.uminho.pt perl-Error jpo at di.uminho.pt perl-ExtUtils-PkgConfig jpo at di.uminho.pt perl-Gtk2 jpo at di.uminho.pt perl-Image-Size jpo at di.uminho.pt perl-Image-Xbm jpo at di.uminho.pt perl-Image-Xpm jpo at di.uminho.pt perl-MLDBM jpo at di.uminho.pt perl-Net-SSLeay jpo at di.uminho.pt perl-Pod-Coverage jpo at di.uminho.pt perl-Test-Pod jpo at di.uminho.pt perl-Text-CSV_XS jspaleta at gmail.com glabels jspaleta at gmail.com istanbul j.w.r.degoede at hhs.nl Glide3 j.w.r.degoede at hhs.nl lacewing j.w.r.degoede at hhs.nl overgod j.w.r.degoede at hhs.nl svgalib jylitalo at iki.fi python-imaging jylitalo at iki.fi xplanet karsten at redhat.com x3270 katzj at redhat.com mercurial lemenkov at newmail.ru chmlib lemenkov at newmail.ru fuse lemenkov at newmail.ru fuse-encfs lemenkov at newmail.ru fuse-sshfs lemenkov at newmail.ru rlog lemenkov at newmail.ru wavpack llch at redhat.com libtabe llch at redhat.com xcin lmacken at redhat.com naim lmacken at redhat.com valknut luya256 at yahoo.com gdesklets mattdm at mattdm.org wxPythonGTK2 matthias at rpmforge.net advancecomp matthias at rpmforge.net bbkeys matthias at rpmforge.net blackbox matthias at rpmforge.net boa matthias at rpmforge.net camE matthias at rpmforge.net csmash matthias at rpmforge.net d4x matthias at rpmforge.net diradmin matthias at rpmforge.net djvulibre matthias at rpmforge.net easytag matthias at rpmforge.net fillets-ng matthias at rpmforge.net gcombust matthias at rpmforge.net gentoo matthias at rpmforge.net giblib matthias at rpmforge.net gkrellm-aclock matthias at rpmforge.net gkrellm-freq matthias at rpmforge.net Gtk-Perl matthias at rpmforge.net gtktalog matthias at rpmforge.net gtweakui matthias at rpmforge.net hackedbox matthias at rpmforge.net hercules matthias at rpmforge.net i8kutils matthias at rpmforge.net js matthias at rpmforge.net kannel matthias at rpmforge.net libcaca matthias at rpmforge.net liboil matthias at rpmforge.net lighttpd matthias at rpmforge.net linux_logo matthias at rpmforge.net lmarbles matthias at rpmforge.net metakit matthias at rpmforge.net ncftp matthias at rpmforge.net oidentd matthias at rpmforge.net p7zip matthias at rpmforge.net php-eaccelerator matthias at rpmforge.net php-pecl-mailparse matthias at rpmforge.net php-pecl-pdo matthias at rpmforge.net php-pecl-pdo-sqlite matthias at rpmforge.net plib matthias at rpmforge.net plib16 matthias at rpmforge.net portaudio matthias at rpmforge.net powermanga matthias at rpmforge.net proftpd matthias at rpmforge.net rrdtool matthias at rpmforge.net SDL_gfx matthias at rpmforge.net starfighter matthias at rpmforge.net synergy matthias at rpmforge.net thttpd matthias at rpmforge.net torcs matthias at rpmforge.net ucarp matthias at rpmforge.net udftools matthias at rpmforge.net viruskiller matthias at rpmforge.net xmms matthias at rpmforge.net xmms-acme matthias at rpmforge.net xmms-arts matthias at rpmforge.net xmms-crossfade matthias at rpmforge.net xmms-flac matthias at rpmforge.net xmms-lirc matthias at rpmforge.net xmms-speex matthias at rpmforge.net xvattr matthias at rpmforge.net yasm matthias at rpmforge.net zziplib matt at truch.net cfitsio matt at truch.net hpic mccann0011 at hotmail.com geos mccann0011 at hotmail.com proj meme at daughtersoftiresias.org nethack-vultures mfleming+rpm at enlartenment.com mlmmj mfleming+rpm at enlartenment.com mod_security michel.salim at gmail.com gai michel.salim at gmail.com gai-pal michel.salim at gmail.com grhino michel.salim at gmail.com quarry mihai at xcyb.org htb-util mitr at redhat.com foobillard mitr at redhat.com python-4Suite-XML mpeters at mac.com firestarter mpeters at mac.com gfontview mpeters at mac.com gnomesword mpeters at mac.com lcdf-typetools mpeters at mac.com libvisual-plugins mpeters at mac.com pan nhorman at redhat.com iozone nos at utelsystems.com dillo nos at utelsystems.com gktools nos at utelsystems.com gtkterm nos at utelsystems.com neverball nos at utelsystems.com soundtracker nos at utelsystems.com whowatch oliver.andrich at gmail.com ruby-mysql oliver at linux-kernel.at banner oliver at linux-kernel.at bwm-ng oliver at linux-kernel.at fish oliver at linux-kernel.at libdnet oliver at linux-kernel.at ngrep oliver at linux-kernel.at perl-Mail-Alias oliver at linux-kernel.at perl-Unix-Statgrab oliver at linux-kernel.at rblcheck oliver at linux-kernel.at scanssh oliver at linux-kernel.at syck orion at cora.nwra.com gdl orion at cora.nwra.com hdf5 orion at cora.nwra.com kompose orion at cora.nwra.com ncarg orion at cora.nwra.com perl-Cflow orion at cora.nwra.com perl-Net-IP-CMatch orion at cora.nwra.com perl-Net-Patricia orion at cora.nwra.com plplot orion at cora.nwra.com python-basemap orion at cora.nwra.com python-matplotlib otaylor at redhat.com libuninameslist paul at city-fan.org pptp paul at xtdnet.nl fetchlog paul at xtdnet.nl gaim-otr paul at xtdnet.nl l2tpd paul at xtdnet.nl ldns paul at xtdnet.nl libotr paul at xtdnet.nl nsd pawsa at theochem.kth.se balsa pawsa at theochem.kth.se libesmtp pertusus at free.fr BibTool pertusus at free.fr docbook2X pertusus at free.fr libdap pertusus at free.fr libnc-dap pertusus at free.fr libsx pertusus at free.fr tetex-tex4ht petersen at redhat.com darcs petersen at redhat.com FreeWnn petersen at redhat.com ghc petersen at redhat.com haddock petersen at redhat.com scim-fcitx pvrabec at redhat.com licq qspencer at ieee.org octave-forge rc040203 at freenet.de Coin2 rc040203 at freenet.de Inventor rc040203 at freenet.de lib3ds rc040203 at freenet.de OpenSceneGraph rc040203 at freenet.de perl-gettext rc040203 at freenet.de perl-Params-Validate rc040203 at freenet.de perl-Test-Taint rc040203 at freenet.de perl-Want rc040203 at freenet.de SIMVoleon rc040203 at freenet.de SoQt rdieter at math.unl.edu akode rdieter at math.unl.edu apollon rdieter at math.unl.edu dxpc rdieter at math.unl.edu factory rdieter at math.unl.edu gc rdieter at math.unl.edu geomview rdieter at math.unl.edu gift rdieter at math.unl.edu gift-openft rdieter at math.unl.edu gpgme rdieter at math.unl.edu gsview rdieter at math.unl.edu gtk-qt-engine rdieter at math.unl.edu jasper rdieter at math.unl.edu kasablanca rdieter at math.unl.edu kdocker rdieter at math.unl.edu kickpim rdieter at math.unl.edu kile rdieter at math.unl.edu kimdaba rdieter at math.unl.edu kiosktool rdieter at math.unl.edu kipi-plugins rdieter at math.unl.edu kmymoney2 rdieter at math.unl.edu kxdocker rdieter at math.unl.edu libassuan rdieter at math.unl.edu libfac rdieter at math.unl.edu libksba rdieter at math.unl.edu libsigsegv rdieter at math.unl.edu libtunepimp rdieter at math.unl.edu lyx rdieter at math.unl.edu Macaulay2 rdieter at math.unl.edu maxima rdieter at math.unl.edu openslp rdieter at math.unl.edu pinentry rdieter at math.unl.edu sbcl rdieter at math.unl.edu tidy rdieter at math.unl.edu uw-imap rdieter at math.unl.edu xforms redhat-bugzilla at camperquake.de bmp redhat-bugzilla at camperquake.de bmp-flac2 redhat-bugzilla at camperquake.de fwbuilder redhat-bugzilla at camperquake.de libfwbuilder redhat at flyn.org gnonlin redhat at flyn.org linkchecker redhat at flyn.org new redhat at flyn.org pam_mount redhat at flyn.org roundup rolandd at cisco.com libmthca roland at redhat.com monotone rpm at timj.co.uk altermime rvokal at redhat.com nuttcp ryo-dairiki at users.sourceforge.net scim-input-pad ryo-dairiki at users.sourceforge.net scim-skk ryo-dairiki at users.sourceforge.net scim-tomoe ryo-dairiki at users.sourceforge.net tomoe shahms at shahms.com python-psycopg sheltren at cs.ucsb.edu cfengine sheltren at cs.ucsb.edu fortune-mod simonb at thoughtpolice.co.uk fdupes skvidal at phy.duke.edu mock skvidal at phy.duke.edu seahorse steve at silug.org gl-117 steve at silug.org perl-BerkeleyDB steve at silug.org perl-Crypt-DES steve at silug.org perl-DateTime steve at silug.org perl-IPC-ShareLite steve at silug.org perl-Unix-Syslog steve at silug.org tuxpaint steve at silug.org tuxtype2 stickster at gmail.com drivel stickster at gmail.com nautilus-open-terminal stickster at gmail.com xmldiff stickster at gmail.com xmlstarlet tagoh at redhat.com Canna tagoh at redhat.com kakasi tagoh at redhat.com kinput2 tagoh at redhat.com mew tagoh at redhat.com namazu tagoh at redhat.com paps tagoh at redhat.com perl-Text-Kakasi tagoh at redhat.com uim tagoh at redhat.com w3m-el tcallawa at redhat.com alsamixergui tcallawa at redhat.com blacs tcallawa at redhat.com c-ares tcallawa at redhat.com check tcallawa at redhat.com comical tcallawa at redhat.com compat-wxGTK tcallawa at redhat.com gambas tcallawa at redhat.com gxemul tcallawa at redhat.com jam tcallawa at redhat.com lapack tcallawa at redhat.com libgdamm tcallawa at redhat.com libmcrypt tcallawa at redhat.com librx tcallawa at redhat.com lincity-ng tcallawa at redhat.com logjam tcallawa at redhat.com mcrypt tcallawa at redhat.com mfstools tcallawa at redhat.com netgo tcallawa at redhat.com perl-Clone tcallawa at redhat.com perl-DBD-SQLite2 tcallawa at redhat.com perl-Template-Toolkit tcallawa at redhat.com perl-version tcallawa at redhat.com physfs tcallawa at redhat.com QuantLib tcallawa at redhat.com R tcallawa at redhat.com rekall tcallawa at redhat.com R-gnomeGUI tcallawa at redhat.com rocksndiamonds tcallawa at redhat.com rootsh tcallawa at redhat.com scalapack tcallawa at redhat.com udunits tcallawa at redhat.com wlassistant tcallawa at redhat.com xbase tcallawa at redhat.com xbsql tcallawa at redhat.com xkeycaps tcallawa at redhat.com xsupplicant thomas at apestaart.org directfb thomas at apestaart.org flumotion thomas at apestaart.org gstreamer08-python thomas at apestaart.org gstreamer-python thomas at apestaart.org Hermes thomas at apestaart.org ladspa thomas at apestaart.org libannodex thomas at apestaart.org libcmml thomas at apestaart.org liboggz thomas at apestaart.org libshout thomas at apestaart.org mach thomas at apestaart.org mod_annodex thomas at apestaart.org python-twisted toniw at iki.fi silky tripwire-devel at genesis-x.nildram.co.uk tripwire ville.skytta at iki.fi dvb-apps ville.skytta at iki.fi hddtemp ville.skytta at iki.fi id3v2 ville.skytta at iki.fi jikes ville.skytta at iki.fi kid3 ville.skytta at iki.fi pcsc-tools ville.skytta at iki.fi xemacs wart at kobold.org tcldom wart at kobold.org tclhttpd wart at kobold.org tclxml wart at kobold.org xpilot-ng wtogami at redhat.com bonnie++ wtogami at redhat.com ccache wtogami at redhat.com lvcool wtogami at redhat.com perl-Digest-Nilsimsa wtogami at redhat.com perl-Razor-Agent wtogami at redhat.com scponly z.kota at gmx.net python-bibtex z.kota at gmx.net recode -- Thorsten Leemhuis -------------- next part -------------- A non-text attachment was scrubbed... Name: buildcheck Type: application/x-shellscript Size: 1857 bytes Desc: not available URL: -------------- next part -------------- [buildcheck-extras-development-x86] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/i386/ enabled=0 gpgcheck=0 [buildcheck-extras-development-x64] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/x86_64/ enabled=0 gpgcheck=0 [buildcheck-extras-development-ppc] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/ppc/ enabled=0 gpgcheck=0 [buildcheck-extras-development-sources] name=Fedora Extras $releasever - Development Tree baseurl=http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/ enabled=0 gpgcheck=0 [buildcheck-extras-development-buildsys] name=Fedora Extras $releasever - Development Tree baseurl=http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/ enabled=0 gpgcheck=0 From jpo at di.uminho.pt Fri Feb 17 20:06:35 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 17 Feb 2006 20:06:35 -0000 (WET) Subject: Please rebuild your packages in the development tree of FedoraExtras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <54305.192.168.82.254.1140206795.squirrel@webmail.lsd.di.uminho.pt> > Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > ... > The script found the following packages in extras/development for which > no entry in the owners.list could be found: fftw3, umfpack, > perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, > dia, libdsk, libspectrum, lib765 I believe perl-Gtk2-GladeXML, perl-Imager, and perl-Gnome2-Canvas belong to Gavin Henry (ghenry at suretecsystems.com). IIRC they are sprog requirements. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From jpo at di.uminho.pt Fri Feb 17 20:06:35 2006 From: jpo at di.uminho.pt (Jose Pedro Oliveira) Date: Fri, 17 Feb 2006 20:06:35 -0000 (WET) Subject: Please rebuild your packages in the development tree of FedoraExtras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <54305.192.168.82.254.1140206795.squirrel@webmail.lsd.di.uminho.pt> > Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > ... > The script found the following packages in extras/development for which > no entry in the owners.list could be found: fftw3, umfpack, > perl-Gtk2-GladeXML, perl-Imager, perl-Gnome2-Canvas, html-xml-utils, > dia, libdsk, libspectrum, lib765 I believe perl-Gtk2-GladeXML, perl-Imager, and perl-Gnome2-Canvas belong to Gavin Henry (ghenry at suretecsystems.com). IIRC they are sprog requirements. jpo -- Jos? Pedro Oliveira * mailto: jpo at di.uminho.pt * http://gsd.di.uminho.pt/~jpo * * gpg fingerprint = F9B6 8D87 859D 1C94 48F0 84C0 9749 9EB5 91BD 851B * From jwboyer at jdub.homelinux.org Sat Feb 18 15:05:05 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sat, 18 Feb 2006 10:05:05 -0500 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <1140275105.15568.14.camel@yoda.jdub.homelinux.org> On Fri, 2006-02-17 at 20:51 +0100, Thorsten Leemhuis wrote: > This time also: Replies to fedora-extras-list please, tia! > > Guys, please keep the buildsys busy. There are a lot of packages that > are still not rebuild afaics. > The following 565 arch specific packages still need a rebuild according > to the script. There might be some false positives in the list like for > example "icu" -- that was moved to core, but still is in the repo and > found by the script. Simply ignore those false positives. > dwmw2 at infradead.org ctrlproxy I've kicked off a rebuild for this one. David can yell at me later if he cares, but it hasn't been a problem in the past :). josh From jkeating at redhat.com Mon Feb 20 19:23:49 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Feb 2006 11:23:49 -0800 Subject: That name game... Message-ID: <1140463429.17286.16.camel@ender> So it is that time to get some names up and going. We need to get a good list of names that we can push through legal as acceptable. Once we have a list of 5 or so names, then we could do some voting by donating. A dollar donation to the Fedora Foundation counts as a vote for a given name. Something like this, we're still working the details. In the mean time we need some names that we can have Legal take a pass at. You as the maintainers get to generate the list of names to vote in, just a small way of saying Thank You. It is less of a secret now that names are related to each other. FC2 was Tettnang, FC3 was Heidelberg, and FC4 is Stentz. What we need is a name that is related to Stentz, but not in the same way that Stentz is related to Heidelberg. Extra credit if there is a semi-easy way out of the name for FC6. Please start discussing, I'd like to have a list of good names to throw at Legal later this week. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From icon at fedoraproject.org Mon Feb 20 19:42:35 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 20 Feb 2006 14:42:35 -0500 Subject: That name game... In-Reply-To: <1140463429.17286.16.camel@ender> References: <1140463429.17286.16.camel@ender> Message-ID: <43FA1BAB.8010803@fedoraproject.org> Jesse Keating wrote: > Please start discussing, I'd like to have a list of good names to throw > at Legal later this week. Jack Stentz was one of the creative consultants for the Andromeda Sci-fi series. I suggest going along that line and picking a generic enough and non-trademarked character name like Trance, Rev, Tyr, or Dylan. Should be geeky enough. :) Regards, -- Konstantin Ryabitsev McGill University WSG Jayne: "I'll be in my bunk." --Episode #10, "War Stories" From icon at fedoraproject.org Mon Feb 20 19:44:37 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Mon, 20 Feb 2006 14:44:37 -0500 Subject: That name game... In-Reply-To: <43FA1BAB.8010803@fedoraproject.org> References: <1140463429.17286.16.camel@ender> <43FA1BAB.8010803@fedoraproject.org> Message-ID: <43FA1C25.4050908@fedoraproject.org> Konstantin Ryabitsev wrote: > Jack Stentz *correction* That's Zack Stentz. Sorry. -- Konstantin Ryabitsev McGill University WSG Jayne: "I'll be in my bunk." --Episode #10, "War Stories" From pix at crazyfrogs.org Mon Feb 20 20:05:39 2006 From: pix at crazyfrogs.org (Pix) Date: Mon, 20 Feb 2006 21:05:39 +0100 Subject: That name game... In-Reply-To: <1140463429.17286.16.camel@ender> References: <1140463429.17286.16.camel@ender> Message-ID: <1140465939.2982.8.camel@localhost.wyplay.com> Why not "Bordeaux" ? In France, Aim? Stentz is a pretty big wine producer.. :) Le lundi 20 f?vrier 2006 ? 11:23 -0800, Jesse Keating a ?crit : > So it is that time to get some names up and going. > > We need to get a good list of names that we can push through legal as > acceptable. Once we have a list of 5 or so names, then we could do some > voting by donating. A dollar donation to the Fedora Foundation counts > as a vote for a given name. Something like this, we're still working > the details. In the mean time we need some names that we can have Legal > take a pass at. You as the maintainers get to generate the list of > names to vote in, just a small way of saying Thank You. > > It is less of a secret now that names are related to each other. > > FC2 was Tettnang, FC3 was Heidelberg, and FC4 is Stentz. What we need > is a name that is related to Stentz, but not in the same way that Stentz > is related to Heidelberg. Extra credit if there is a semi-easy way out > of the name for FC6. > > Please start discussing, I'd like to have a list of good names to throw > at Legal later this week. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From skvidal at linux.duke.edu Mon Feb 20 20:13:36 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 20 Feb 2006 15:13:36 -0500 Subject: That name game... In-Reply-To: <1140465939.2982.8.camel@localhost.wyplay.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> Message-ID: <1140466416.26007.0.camel@cutter> On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: > Why not "Bordeaux" ? > sounds nice. -sv From jkeating at redhat.com Mon Feb 20 20:14:39 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Feb 2006 12:14:39 -0800 Subject: That name game... In-Reply-To: <1140465939.2982.8.camel@localhost.wyplay.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> Message-ID: <1140466480.17286.25.camel@ender> On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: > > Why not "Bordeaux" ? > > In France, Aim? Stentz is a pretty big wine producer.. :) I like it. IS bordeaux a trademarked term? Whats our way out? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sopwith at redhat.com Mon Feb 20 20:20:30 2006 From: sopwith at redhat.com (Elliot Lee) Date: Mon, 20 Feb 2006 15:20:30 -0500 (EST) Subject: That name game... In-Reply-To: <1140466480.17286.25.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> Message-ID: On Mon, 20 Feb 2006, Jesse Keating wrote: > On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: > > > > Why not "Bordeaux" ? > > > > In France, Aim?? Stentz is a pretty big wine producer.. :) > > I like it. IS bordeaux a trademarked term? Whats our way out? I don't know enough about wine to say whether Bordeaux is also a big wine producer, but perhaps it would be useful to have a reminder of the rules for naming. Now if I could only remember them myself... :) -- Elliot From nicolas.mailhot at laposte.net Mon Feb 20 20:26:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Feb 2006 21:26:15 +0100 Subject: That name game... In-Reply-To: <1140466480.17286.25.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> Message-ID: <1140467175.2517.2.camel@rousalka.dyndns.org> Le lundi 20 f?vrier 2006 ? 12:14 -0800, Jesse Keating a ?crit : > On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: > > > > Why not "Bordeaux" ? > > > > In France, Aim? Stentz is a pretty big wine producer.. :) > > I like it. IS bordeaux a trademarked term? Whats our way out? Bordeaux is a city name. That's not something you can trademark. If you want to be 100% clear you can write the city council to see if they object. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pix at crazyfrogs.org Mon Feb 20 20:28:10 2006 From: pix at crazyfrogs.org (Pix) Date: Mon, 20 Feb 2006 21:28:10 +0100 Subject: That name game... In-Reply-To: <1140466480.17286.25.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> Message-ID: <1140467291.2982.12.camel@localhost.wyplay.com> Bordeaux is an "appellation" in France, i.e. you can't name a wine "Bordeaux" without a lots of authorizations. But i don't think this covers a linux distribution :) Moreover, it's the name of a city, in France (the city the wine come from, btw). But without a legal check, we can't be sure.. Le lundi 20 f?vrier 2006 ? 12:14 -0800, Jesse Keating a ?crit : > On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: > > > > Why not "Bordeaux" ? > > > > In France, Aim? Stentz is a pretty big wine producer.. :) > > I like it. IS bordeaux a trademarked term? Whats our way out? > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jkeating at redhat.com Mon Feb 20 20:31:30 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Feb 2006 12:31:30 -0800 Subject: That name game... In-Reply-To: <1140467291.2982.12.camel@localhost.wyplay.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467291.2982.12.camel@localhost.wyplay.com> Message-ID: <1140467490.17286.28.camel@ender> On Mon, 2006-02-20 at 21:28 +0100, Pix wrote: > > Bordeaux is an "appellation" in France, i.e. you can't name a wine > "Bordeaux" without a lots of authorizations. > But i don't think this covers a linux distribution :) > Moreover, it's the name of a city, in France (the city the wine come > from, btw). > But without a legal check, we can't be sure.. Hrm, wasn't the Stentz Heidelberg link was a city wasn't it? Or the Tettnang to Heidelberg? -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Mon Feb 20 19:33:07 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 20 Feb 2006 14:33:07 -0500 (EST) Subject: That name game... In-Reply-To: <1140467175.2517.2.camel@rousalka.dyndns.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> Message-ID: <41307.129.42.161.36.1140463987.squirrel@jdub.homelinux.org> > Le lundi 20 f??vrier 2006 ? 12:14 -0800, Jesse Keating a ??crit : >> On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: >> > >> > Why not "Bordeaux" ? >> > >> > In France, Aim?? Stentz is a pretty big wine producer.. :) >> >> I like it. IS bordeaux a trademarked term? Whats our way out? > > Bordeaux is a city name. That's not something you can trademark. > If you want to be 100% clear you can write the city council to see if > they object. In the US it is. Lincoln is the name of a city in just about every state, but it's also a trademark of a car. josh From gdk at redhat.com Mon Feb 20 20:34:46 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 20 Feb 2006 15:34:46 -0500 (EST) Subject: That name game... In-Reply-To: <41307.129.42.161.36.1140463987.squirrel@jdub.homelinux.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> <41307.129.42.161.36.1140463987.squirrel@jdub.homelinux.org> Message-ID: My advice: Let's come up with a half-dozen names we like, whether we think they're legally questionable or not. Rank them in the order that we like them, and then hand the whole thing off to legal and let them do what they do. Surely at least one will survive. --g --------------------------------------------------------------- Greg DeKoenigsberg || Fedora Foundation || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors --------------------------------------------------------------- On Mon, 20 Feb 2006, Josh Boyer wrote: > > Le lundi 20 f??vrier 2006 ? 12:14 -0800, Jesse Keating a ??crit : > >> On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: > >> > > >> > Why not "Bordeaux" ? > >> > > >> > In France, Aim?? Stentz is a pretty big wine producer.. :) > >> > >> I like it. IS bordeaux a trademarked term? Whats our way out? > > > > Bordeaux is a city name. That's not something you can trademark. > > If you want to be 100% clear you can write the city council to see if > > they object. > > In the US it is. Lincoln is the name of a city in just about every state, > but it's also a trademark of a car. > > josh > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From jkeating at redhat.com Mon Feb 20 20:37:00 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Feb 2006 12:37:00 -0800 Subject: That name game... In-Reply-To: References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> <41307.129.42.161.36.1140463987.squirrel@jdub.homelinux.org> Message-ID: <1140467820.17286.29.camel@ender> On Mon, 2006-02-20 at 15:34 -0500, Greg DeKoenigsberg wrote: > My advice: > > Let's come up with a half-dozen names we like, whether we think they're > legally questionable or not. Rank them in the order that we like them, > and then hand the whole thing off to legal and let them do what they do. > Surely at least one will survive. Good suggestion. I was just thinking that it is silly of me to argue legalities regarding names on this list, that's what our legal team is for (; -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jwboyer at jdub.homelinux.org Mon Feb 20 19:46:41 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Mon, 20 Feb 2006 14:46:41 -0500 (EST) Subject: That name game... In-Reply-To: <1140467820.17286.29.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> <41307.129.42.161.36.1140463987.squirrel@jdub.homelinux.org> <1140467820.17286.29.camel@ender> Message-ID: <6023.129.42.161.36.1140464801.squirrel@jdub.homelinux.org> > On Mon, 2006-02-20 at 15:34 -0500, Greg DeKoenigsberg wrote: >> My advice: >> >> Let's come up with a half-dozen names we like, whether we think they're >> legally questionable or not. Rank them in the order that we like them, >> and then hand the whole thing off to legal and let them do what they do. >> Surely at least one will survive. > > Good suggestion. I was just thinking that it is silly of me to argue > legalities regarding names on this list, that's what our legal team is > for (; BTW, I also like Bordeaux. I forgot to mention that in my quest to be a pedanitc arse. josh From ed at eh3.com Mon Feb 20 20:45:44 2006 From: ed at eh3.com (Ed Hill) Date: Mon, 20 Feb 2006 15:45:44 -0500 Subject: That name game... In-Reply-To: <1140463429.17286.16.camel@ender> References: <1140463429.17286.16.camel@ender> Message-ID: <1140468345.31903.163.camel@ernie> On Mon, 2006-02-20 at 11:23 -0800, Jesse Keating wrote: > It is less of a secret now that names are related to each other. > > FC2 was Tettnang, FC3 was Heidelberg, and FC4 is Stentz. What we need > is a name that is related to Stentz, but not in the same way that Stentz > is related to Heidelberg. Extra credit if there is a semi-easy way out > of the name for FC6. > > Please start discussing, I'd like to have a list of good names to throw > at Legal later this week. There is an algorithm sometimes referred to as "Stentz's Algorithm": http://planning.cs.uiuc.edu/node616.html A. Stentz. "Optimal and efficient path planning for partially-known environments." In Proceedings IEEE International Conference on Robotics & Automation, pages 3310-3317, 1994. used for finding paths when traversing terrain. I have no idea whether it was used by teams competing in the popular DARPA Grand Challenge autonomous vehicle races but it certainly looks related. In any case, here are two names known for their association with optimization algorithms. And, they have *plenty* of connections to other topics so they are a "way out" from the current (rather boring) city-names rut: "Metropolis" : from the Metropolis or Metropolis-Hastings algos for simulated annealing, the traveling salesman problems, etc. which are also used to find optimal paths: http://en.wikipedia.org/wiki/Metropolis_algorithm "Amoeba" : a common name used to describe the way the Nelder-Mead optimization algorithm and/or how it works. Nelder-Mead is a very frequently cited paper. As with the Stentz algorithm (and with many other optimization methods), this algo is "feeling around looking for a better answer". http://en.wikipedia.org/wiki/Nelder-Mead_method Does anyone else here think that Fedora is constantly "trying things looking for better answers" or is that too much of a stretch? :-) Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From jkeating at redhat.com Mon Feb 20 20:53:03 2006 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 20 Feb 2006 12:53:03 -0800 Subject: That name game... In-Reply-To: <1140468345.31903.163.camel@ernie> References: <1140463429.17286.16.camel@ender> <1140468345.31903.163.camel@ernie> Message-ID: <1140468783.17286.33.camel@ender> On Mon, 2006-02-20 at 15:45 -0500, Ed Hill wrote: > used for finding paths when traversing terrain. I have no idea whether > it was used by teams competing in the popular DARPA Grand Challenge > autonomous vehicle races but it certainly looks related. > > In any case, here are two names known for their association with > optimization algorithms. And, they have *plenty* of connections to > other topics so they are a "way out" from the current (rather boring) > city-names rut: That's pretty close to the Skipjack (7.3 beat 1) and Enigma (7.2) name link, encryption algorithms. Seems like we'd be repeating ourselves, but thats just my opinion. I could still see pushing it through Legal. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From gdk at redhat.com Mon Feb 20 20:56:31 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Mon, 20 Feb 2006 15:56:31 -0500 (EST) Subject: That name game... In-Reply-To: <1140468345.31903.163.camel@ernie> References: <1140463429.17286.16.camel@ender> <1140468345.31903.163.camel@ernie> Message-ID: On Mon, 20 Feb 2006, Ed Hill wrote: > In any case, here are two names known for their association with > optimization algorithms. And, they have *plenty* of connections to > other topics so they are a "way out" from the current (rather boring) > city-names rut: > > "Metropolis" : from the Metropolis or Metropolis-Hastings algos for > simulated annealing, the traveling salesman problems, etc. which > are also used to find optimal paths: > http://en.wikipedia.org/wiki/Metropolis_algorithm > > "Amoeba" : a common name used to describe the way the Nelder-Mead > optimization algorithm and/or how it works. Nelder-Mead is a > very frequently cited paper. As with the Stentz algorithm (and > with many other optimization methods), this algo is "feeling > around looking for a better answer". > http://en.wikipedia.org/wiki/Nelder-Mead_method > > Does anyone else here think that Fedora is constantly "trying things > looking for better answers" or is that too much of a stretch? :-) No, I'd say that's pretty much the definition of Fedora right there. :) --g --------------------------------------------------------------- Greg DeKoenigsberg || Fedora Foundation || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors --------------------------------------------------------------- From nicolas.mailhot at laposte.net Mon Feb 20 21:00:26 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 20 Feb 2006 22:00:26 +0100 Subject: That name game... In-Reply-To: <1140465939.2982.8.camel@localhost.wyplay.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> Message-ID: <1140469226.2517.16.camel@rousalka.dyndns.org> Le lundi 20 f?vrier 2006 ? 21:05 +0100, Pix a ?crit : > Why not "Bordeaux" ? The nice thing about Bordeaux is the city got a rich history, allowing for example to jump later to England just before the 100-hundred war, then to the middle-east via the crusades (or to popular literature if we prefer), then who knows where else. Bordeaux -> Alienor -> LionHeart -> Jerusalem -> ... Bordeaux -> Alienor -> Robin Hood -> ... Or else Bordeaux -> Madeira -> Africa or Brasil (actually you can do this one without going through Bordeaux but I like it this way) Nice find. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jkeating at j2solutions.net Mon Feb 20 21:05:19 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 20 Feb 2006 13:05:19 -0800 Subject: That name game... In-Reply-To: <1140469226.2517.16.camel@rousalka.dyndns.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140469226.2517.16.camel@rousalka.dyndns.org> Message-ID: <1140469520.17286.38.camel@ender> On Mon, 2006-02-20 at 22:00 +0100, Nicolas Mailhot wrote: > The nice thing about Bordeaux is the city got a rich history, allowing > for example to jump later to England just before the 100-hundred war, > then to the middle-east via the crusades (or to popular literature if we > prefer), then who knows where else. > > Bordeaux -> Alienor -> LionHeart -> Jerusalem -> ... > Bordeaux -> Alienor -> Robin Hood -> ... > > Or else > > Bordeaux -> Madeira -> Africa or Brasil (actually you can do this one > without going through Bordeaux but I like it this way) > > Nice find. Each new link cannot be in any way related to the last link used. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From ed at eh3.com Mon Feb 20 21:10:39 2006 From: ed at eh3.com (Ed Hill) Date: Mon, 20 Feb 2006 16:10:39 -0500 Subject: That name game... In-Reply-To: <1140468783.17286.33.camel@ender> References: <1140463429.17286.16.camel@ender> <1140468345.31903.163.camel@ernie> <1140468783.17286.33.camel@ender> Message-ID: <1140469840.31903.183.camel@ernie> On Mon, 2006-02-20 at 12:53 -0800, Jesse Keating wrote: > On Mon, 2006-02-20 at 15:45 -0500, Ed Hill wrote: > > used for finding paths when traversing terrain. I have no idea whether > > it was used by teams competing in the popular DARPA Grand Challenge > > autonomous vehicle races but it certainly looks related. > > > > In any case, here are two names known for their association with > > optimization algorithms. And, they have *plenty* of connections to > > other topics so they are a "way out" from the current (rather boring) > > city-names rut: > > That's pretty close to the Skipjack (7.3 beat 1) and Enigma (7.2) name > link, encryption algorithms. Seems like we'd be repeating ourselves, > but thats just my opinion. I could still see pushing it through Legal. Yes, encryption and optimization are both "math topics". But thats about where the connection begins and ends. The aims of encryption and the mathematical methods used to implement it are very different than the aims, tools, and syntax of optimization. And even in non-technical language, the words have very different connotations. The fact that "Bordeaux" is another city is as much (or more) of a connection to some of the previously used names. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From tiemann at redhat.com Mon Feb 20 21:15:41 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Mon, 20 Feb 2006 16:15:41 -0500 Subject: That name game... In-Reply-To: <1140463429.17286.16.camel@ender> References: <1140463429.17286.16.camel@ender> Message-ID: <1140470141.4342.19.camel@localhost.localdomain> On Mon, 2006-02-20 at 11:23 -0800, Jesse Keating wrote: > Please start discussing, I'd like to have a list of good names to throw > at Legal later this week. Stentz (worked on the show) -> Andromeda (also galaxy cataloged by) -> Messier (a Frenchman who inspired a) -> Marathon (that usually takes place in the month of) -> April M From pix at crazyfrogs.org Mon Feb 20 20:33:01 2006 From: pix at crazyfrogs.org (Pix) Date: Mon, 20 Feb 2006 21:33:01 +0100 Subject: That name game... In-Reply-To: <1140467490.17286.28.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467291.2982.12.camel@localhost.wyplay.com> <1140467490.17286.28.camel@ender> Message-ID: <1140467581.2982.14.camel@localhost.wyplay.com> Well, "my" link was wine! i'm french! :) Le lundi 20 f?vrier 2006 ? 12:31 -0800, Jesse Keating a ?crit : > On Mon, 2006-02-20 at 21:28 +0100, Pix wrote: > > > > Bordeaux is an "appellation" in France, i.e. you can't name a wine > > "Bordeaux" without a lots of authorizations. > > But i don't think this covers a linux distribution :) > > Moreover, it's the name of a city, in France (the city the wine come > > from, btw). > > But without a legal check, we can't be sure.. > > Hrm, wasn't the Stentz Heidelberg link was a city wasn't it? Or the > Tettnang to Heidelberg? > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From blizzard at redhat.com Tue Feb 21 02:52:38 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 20 Feb 2006 21:52:38 -0500 Subject: That name game... In-Reply-To: <1140470141.4342.19.camel@localhost.localdomain> References: <1140463429.17286.16.camel@ender> <1140470141.4342.19.camel@localhost.localdomain> Message-ID: <43FA8076.4010600@redhat.com> Michael Tiemann wrote: > On Mon, 2006-02-20 at 11:23 -0800, Jesse Keating wrote: > >> Please start discussing, I'd like to have a list of good names to throw >> at Legal later this week. > > Stentz (worked on the show) > -> Andromeda (also galaxy cataloged by) > -> Messier (a Frenchman who inspired a) > -> Marathon (that usually takes place in the month of) > -> April I don't know - the new X stuff is pretty spacy... --Chris From oliver at linux-kernel.at Tue Feb 21 10:12:22 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 21 Feb 2006 11:12:22 +0100 Subject: That name game... In-Reply-To: <1140466416.26007.0.camel@cutter> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> Message-ID: <43FAE786.4090704@linux-kernel.at> On 02/20/2006 09:13 PM, seth vidal wrote: > On Mon, 2006-02-20 at 21:05 +0100, Pix wrote: >> Why not "Bordeaux" ? > > sounds nice. There are 2 vinyards in Germany called 'Stentz'. (No idea if they are related to each other) :-) Googling for Stentz brings up one of these entries first, and the Aim? Stenz page as third... Mr. Zack Stentz wrote the script for 'Agent Cody Banks' and the following Andromeda titles: (imdb:) 1. The Banks of the Lethe (20 November 2000) - Writer (writer) 2. The Devil Take the Hindmost (16 April 2001) - Writer (writer) 3. The Honey Offering (23 April 2001) - Writer (writer) 4. All Too Human (5 November 2001) - Writer (writer) 5. Una Salus Victus (12 November 2001) - Writer (writer) 6. Into the Labyrinth (26 November 2001) - Writer (writer) 7. Lava and Rockets (4 February 2002) - Writer (writer) 8. Dance of the Mayflies (18 February 2002) - Writer (writer) 9. The Fair Unknown (15 April 2002) - Writer (writer) 10. The Knight, Death and the Devil (29 April 2002) - Writer (writer) However, my opinion on this: Try to get away from the city stuff and fly away to outer space, we have the chance with 'Stentz' now. :-) From Andromeda we can link to Star Wars and Star Trek stuff very easy. Please note, Andromeda is allready a registered software company (www.andromeda.com). So my ideas: - Trance or Gemini (from Andromeda; Mrs.Laura Bertram) * Possible links that could follow (movie related): + Solitaire + Deepwater + Platinum + Twister + Avonlea ... and more ... - Dylan or Hunt or Sorbo (Do I have to describe why? :-)) * Possible links that could follow (movie related): + Hercules (:-/) + Xena (:-/) + Kull + Thaddeus or Kocinski Using Andromeda as link and going to Star Trek, offers the following: - Kirk/Shatner - Spock/Nimoy - Uhura - Chekov - Sulu - McCoy - Picard - Paris - Janeway/Kathryn - Picardo - Kes - Seven of Nine - Archer .... and more ... (The are a lot of alien nations: Vulcans, Klingon,...) Using Star Wars: - Lucas - Skywalker/Hamill - Han/Solo - Leia/Organa - Obi-Wan/Kenobi - R2-D2 - C-3PO - Darth/Vader - Dodonna ... and more ... Using Georg Lucas: - Droids - Ewoks - Willow - Herbie ... and more ... Using Gene Roddenberry: - Nemesis - Farpoint - Genesis - Insurrection - Borg - Voyager - Khan ... and more ... Personally I would prefer Trance or Gemini from Andromeda, as Gemini is nice when thinking about the Fedora Core/Extras relation. :-) Nemesis is nice when thinking about some green chameleon that we *red* or *blue* hatted people don't like very much. :-) We can use many of the above words/names and find a nice story, why exactly this was taken. My 2/many cent... :-) -of From icon at fedoraproject.org Tue Feb 21 15:24:52 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Tue, 21 Feb 2006 10:24:52 -0500 Subject: That name game... In-Reply-To: <43FAE786.4090704@linux-kernel.at> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> Message-ID: <43FB30C4.2080701@fedoraproject.org> Oliver Falk wrote: > Personally I would prefer Trance or Gemini from Andromeda, as Gemini is > nice when thinking about the Fedora Core/Extras relation. :-) Yeah, I like "Gemini". I believe this is the first Fedora release where Anaconda can install from Extras, correct? Now Core+Extras are truly integrated, so calling them "twins" would be appropriate. This also gives us a jump to zodiac, though it's less geeky than "sci-fi shows." :) (PS: Oliver: I can't believe you forgot Firefly! :)) Regards, -- Konstantin Ryabitsev McGill University WSG Simon: "It's okay to leave them to die." --"Serenity" From skvidal at linux.duke.edu Tue Feb 21 15:41:15 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Tue, 21 Feb 2006 10:41:15 -0500 Subject: That name game... In-Reply-To: <43FB30C4.2080701@fedoraproject.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> Message-ID: <1140536475.31787.0.camel@cutter> On Tue, 2006-02-21 at 10:24 -0500, Konstantin Ryabitsev wrote: > Oliver Falk wrote: > > Personally I would prefer Trance or Gemini from Andromeda, as Gemini is > > nice when thinking about the Fedora Core/Extras relation. :-) > > Yeah, I like "Gemini". I believe this is the first Fedora release where > Anaconda can install from Extras, correct? Now Core+Extras are truly > integrated, so calling them "twins" would be appropriate. FC6 maybe - but not fc5. -sv From oliver at linux-kernel.at Tue Feb 21 15:51:20 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Tue, 21 Feb 2006 16:51:20 +0100 Subject: That name game... In-Reply-To: <43FB30C4.2080701@fedoraproject.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> Message-ID: <43FB36F8.7050805@linux-kernel.at> On 02/21/2006 04:24 PM, Konstantin Ryabitsev wrote: > Oliver Falk wrote: >> Personally I would prefer Trance or Gemini from Andromeda, as Gemini >> is nice when thinking about the Fedora Core/Extras relation. :-) > > Yeah, I like "Gemini". I believe this is the first Fedora release where > Anaconda can install from Extras, correct? Now Core+Extras are truly > integrated, so calling them "twins" would be appropriate. > > This also gives us a jump to zodiac, though it's less geeky than "sci-fi > shows." :) Since FC is more or less geek stuff, it would be fine I think... > (PS: Oliver: I can't believe you forgot Firefly! :)) The movie? Oh, yes, also possible :-) -of From fedora at leemhuis.info Tue Feb 21 17:07:49 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Tue, 21 Feb 2006 18:07:49 +0100 Subject: Please rebuild your packages in the development tree of Fedora Extras In-Reply-To: <1140205892.2904.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> Message-ID: <1140541669.2144.30.camel@localhost.localdomain> Hi All! Background info: Announcement of the mass-rebuild: https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00039.html The script that helped me to generate this lists: https://www.redhat.com/archives/fedora-maintainers/2006-February/msg00053.html This time also: Replies to fedora-extras-list please, tia! > Am Freitag, den 17.02.2006, 20:51 +0100 schrieb Thorsten Leemhuis: > >Am Montag, den 13.02.2006, 18:22 +0100 schrieb Thorsten Leemhuis: > > The last rawhide mass-rebuild is mostly done now so it's time for us to > > also rebuild **all packages** in the Fedora Extras development tree > > before it becomes Fedora Extras 5 (FE) when Fedora Core 5 is > > branched/released. > > Guys, please keep the buildsys busy. There are a lot of packages that > are still not rebuild afaics. That sentence still holds true ;-) > The following 565 arch specific packages still need a rebuild [...] We are down to 453 arch packages (271 noarch) packages now (1242 were build). See below for a list of arch packages that are not yet rebuild. Changes: I set the trigger date a bit back to the time of the rawhide-report on the day before the rebuild was announced. $ date --date='2006-02-13 02:48:00 -0500 ' +%s 1139816880 All arch packages before that point in time should be rebuild. I also looked up those packagers that have not yet rebuild a single package since the mass rebuild was announced (guys, please start): ---- aaron.bennett_AT_olin.edu ad+rh-bugzilla_AT_uni-x.org aportal_AT_univ-montp2.fr bojan_AT_rexursive.com ch.nolte_AT_fh-wolfenbuettel.de chris_AT_chrisgrau.com chrisw_AT_redhat.com colin_AT_fedoraproject.org danken_AT_cs.technion.ac.il davidhart_AT_tqmcube.com davidz_AT_redhat.com denis_AT_poolshark.org dwmw2_AT_redhat.com endur_AT_bennewitz.com fredrik_AT_dolda2000.com gauret_AT_free.fr grenier_AT_cgsecurity.org hamzy_AT_us.ibm.com jcarpenter_AT_condell.org jdennis_AT_redhat.com jeff_AT_ultimateevil.org jeff.gilchrist_AT_gmail.com jnovy_AT_redhat.com joost_AT_cnoc.nl jylitalo_AT_iki.fi llch_AT_redhat.com luya256_AT_yahoo.com matt_AT_truch.net mccann0011_AT_hotmail.com meme_AT_daughtersoftiresias.org michel.salim_AT_gmail.com mihai_AT_xcyb.org mitr_AT_redhat.com nhorman_AT_redhat.com nos_AT_utelsystems.com oliver.andrich_AT_gmail.com otaylor_AT_redhat.com paul_AT_all-the-johnsons.co.uk paul_AT_xtdnet.nl pawsa_AT_theochem.kth.se petersen_AT_redhat.com pvrabec_AT_redhat.com redhat-bugzilla_AT_camperquake.de roland_AT_redhat.com rvokal_AT_redhat.com ryo-dairiki_AT_users.sourceforge.net skvidal_AT_phy.duke.edu tagoh_AT_redhat.com tcallawa_AT_redhat.com thomas_AT_apestaart.org toniw_AT_iki.fi tripwire-devel_AT_genesis-x.nildram.co.uk ---- Below the complete list of arch packages not yet rebuild. If you name and/or package is in the list *and* there is a *good reason* for it then it's okay -- no need to send detailed mails why it is not rebuild yet. But we'll probably start tracking things closer by the end of the week -- then I'll ask for details ;-) aaron.bennett_AT_olin.edu ifplugd ad+rh-bugzilla_AT_uni-x.org pam_abl adrian_AT_lisas.de cvsup adrian_AT_lisas.de kover adrian_AT_lisas.de libcdio adrian_AT_lisas.de most adrian_AT_lisas.de nexuiz adrian_AT_lisas.de ninja adrian_AT_lisas.de sopwith adrian_AT_lisas.de source-highlight adrian_AT_lisas.de tin adrian_AT_lisas.de uudeview adrian_AT_lisas.de vnstat adrian_AT_lisas.de xdesktopwaves adrian_AT_lisas.de xlockmore adrian_AT_lisas.de xmlindent a.kurtz_AT_hardsun.net libdaemon andreas_AT_bawue.net barcode andreas_AT_bawue.net commoncpp2 andreas_AT_bawue.net ddrescue andreas_AT_bawue.net mod_suphp andreas_AT_bawue.net perl-Crypt-Blowfish andreas_AT_bawue.net scmxx andreas.bierfert_AT_lowlatency.de fbdesk andreas.bierfert_AT_lowlatency.de fluxbox andreas.bierfert_AT_lowlatency.de orange andreas.bierfert_AT_lowlatency.de synce andreas.bierfert_AT_lowlatency.de synce-gnomevfs andreas.bierfert_AT_lowlatency.de synce-software-manager andreas.bierfert_AT_lowlatency.de synce-trayicon andreas.bierfert_AT_lowlatency.de wine anvil_AT_livna.org aalib anvil_AT_livna.org bin2iso anvil_AT_livna.org imlib2 anvil_AT_livna.org irssi anvil_AT_livna.org libcddb anvil_AT_livna.org libebml anvil_AT_livna.org libmatroska anvil_AT_livna.org libsamplerate anvil_AT_livna.org libsndfile anvil_AT_livna.org libtar anvil_AT_livna.org lzo aportal_AT_univ-montp2.fr gpsim aportal_AT_univ-montp2.fr gputils aportal_AT_univ-montp2.fr gtk+extra aportal_AT_univ-montp2.fr utrac bdpepple_AT_ameritech.net gnomebaker bdpepple_AT_ameritech.net tagtool bojan_AT_rexursive.com libapreq2 bugs.michael_AT_gmx.net abicheck bugs.michael_AT_gmx.net aide bugs.michael_AT_gmx.net bchunk bugs.michael_AT_gmx.net chkrootkit bugs.michael_AT_gmx.net mhash ch.nolte_AT_fh-wolfenbuettel.de kbibtex chris_AT_chrisgrau.com frotz chris_AT_chrisgrau.com ifm chris_AT_chrisgrau.com perl-Time-Piece chrisw_AT_redhat.com git-core colin_AT_fedoraproject.org adns colin_AT_fedoraproject.org gaim-guifications colin_AT_fedoraproject.org MagicPoint colin_AT_fedoraproject.org python-adns danken_AT_cs.technion.ac.il bidiv danken_AT_cs.technion.ac.il hspell danken_AT_cs.technion.ac.il taarich davidhart_AT_tqmcube.com leafnode davidz_AT_redhat.com NetworkManager-vpnc denis_AT_poolshark.org galeon denis_AT_poolshark.org gconfmm26 denis_AT_poolshark.org glibmm24 denis_AT_poolshark.org gnome-vfsmm26 denis_AT_poolshark.org gtkmm24 denis_AT_poolshark.org inkscape denis_AT_poolshark.org libglademm24 denis_AT_poolshark.org libgnomecanvasmm26 denis_AT_poolshark.org libgnomemm26 denis_AT_poolshark.org libgnomeuimm26 denis_AT_poolshark.org libsigc++ denis_AT_poolshark.org libsigc++20 dwmw2_AT_redhat.com exim dwmw2_AT_redhat.com hfsplusutils endur_AT_bennewitz.com streamtuner enrico.scholz_AT_informatik.tu-chemnitz.de dhcp-forwarder enrico.scholz_AT_informatik.tu-chemnitz.de dietlibc enrico.scholz_AT_informatik.tu-chemnitz.de ip-sentinel enrico.scholz_AT_informatik.tu-chemnitz.de libtasn1 enrico.scholz_AT_informatik.tu-chemnitz.de util-vserver extras-orphan_AT_fedoraproject.org abe extras-orphan_AT_fedoraproject.org arc extras-orphan_AT_fedoraproject.org at-poke extras-orphan_AT_fedoraproject.org camstream extras-orphan_AT_fedoraproject.org cgoban extras-orphan_AT_fedoraproject.org cksfv extras-orphan_AT_fedoraproject.org duplicity extras-orphan_AT_fedoraproject.org freedroidrpg extras-orphan_AT_fedoraproject.org gnofract4d extras-orphan_AT_fedoraproject.org gnome-telnet extras-orphan_AT_fedoraproject.org gnugo extras-orphan_AT_fedoraproject.org gurlchecker extras-orphan_AT_fedoraproject.org libzvt extras-orphan_AT_fedoraproject.org lua extras-orphan_AT_fedoraproject.org manedit extras-orphan_AT_fedoraproject.org mknbi extras-orphan_AT_fedoraproject.org netdiag extras-orphan_AT_fedoraproject.org nget extras-orphan_AT_fedoraproject.org ots extras-orphan_AT_fedoraproject.org parchive extras-orphan_AT_fedoraproject.org prozilla extras-orphan_AT_fedoraproject.org putty extras-orphan_AT_fedoraproject.org sirius extras-orphan_AT_fedoraproject.org tdl extras-orphan_AT_fedoraproject.org tetex-lgrind extras-orphan_AT_fedoraproject.org tla extras-orphan_AT_fedoraproject.org wbxml2 extras-orphan_AT_fedoraproject.org xmms-cdread extras-orphan_AT_fedoraproject.org xtide fredrik_AT_dolda2000.com icmpdn gajownik_AT_gmail.com athcool gauret_AT_free.fr amarok gauret_AT_free.fr amaya gauret_AT_free.fr apachetop gauret_AT_free.fr basket gauret_AT_free.fr colorscheme gauret_AT_free.fr elmo gauret_AT_free.fr gmpc gauret_AT_free.fr grisbi gauret_AT_free.fr gwenview gauret_AT_free.fr iftop gauret_AT_free.fr libkexif gauret_AT_free.fr libkipi gauret_AT_free.fr libvisual gauret_AT_free.fr mpc gauret_AT_free.fr pdftohtml gauret_AT_free.fr perl-Jcode gauret_AT_free.fr perl-Unicode-Map gauret_AT_free.fr perl-Unicode-Map8 gauret_AT_free.fr perl-Unicode-String gauret_AT_free.fr psi gauret_AT_free.fr pure-ftpd gauret_AT_free.fr qca gauret_AT_free.fr qca-tls gauret_AT_free.fr showimg gauret_AT_free.fr taglib gauret_AT_free.fr ulogd gauret_AT_free.fr unrtf gauret_AT_free.fr wv gauret_AT_free.fr xbindkeys gauret_AT_free.fr xlhtml gauret_AT_free.fr zope gemi_AT_bluewin.ch audacity gemi_AT_bluewin.ch bigloo gemi_AT_bluewin.ch erlang gemi_AT_bluewin.ch lablgl gemi_AT_bluewin.ch lablgtk gemi_AT_bluewin.ch TeXmacs gemi_AT_bluewin.ch unison ghenry_AT_suretecsystems.com john ghenry_AT_suretecsystems.com librsync ghenry_AT_suretecsystems.com rdiff-backup green_AT_redhat.com itext green_AT_redhat.com jakarta-commons-cli green_AT_redhat.com jogl green_AT_redhat.com kawa green_AT_redhat.com rssowl grenier_AT_cgsecurity.org testdisk hamzy_AT_us.ibm.com sblim-cmpi-base hamzy_AT_us.ibm.com sblim-cmpi-devel hamzy_AT_us.ibm.com sblim-wbemcli i_AT_stingr.net pyflowtools ivazquez_AT_ivazquez.net lock-keys-applet ivazquez_AT_ivazquez.net sqlite2 jamatos_AT_fc.up.pt R-mAr jcarpenter_AT_condell.org ks3switch jcarpenter_AT_condell.org lrmi jcarpenter_AT_condell.org s3switch jcarpenter_AT_condell.org tpb jcarpenter_AT_condell.org xosd jdennis_AT_redhat.com cyrus-imapd jeff_AT_ultimateevil.org up-imapproxy jeff_AT_ultimateevil.org zile jeff.gilchrist_AT_gmail.com pbzip2 jfontain_AT_free.fr blt jfontain_AT_free.fr tktable jnovy_AT_redhat.com allegro jnovy_AT_redhat.com cproto jnovy_AT_redhat.com nedit joost_AT_cnoc.nl fpc jpo_AT_di.uminho.pt libol jpo_AT_di.uminho.pt perl-Array-Compare jpo_AT_di.uminho.pt perl-Cache-Cache jpo_AT_di.uminho.pt perl-Compress-Bzip2 jpo_AT_di.uminho.pt perl-DBD-SQLite jpo_AT_di.uminho.pt perl-File-Tail jpo_AT_di.uminho.pt perl-GDGraph jpo_AT_di.uminho.pt perl-Gtk2 jpo_AT_di.uminho.pt perl-Image-Info jpo_AT_di.uminho.pt perl-IPC-Shareable jpo_AT_di.uminho.pt perl-Net-SSLeay jpo_AT_di.uminho.pt perl-SQL-Statement jpo_AT_di.uminho.pt perl-Test-Manifest jpo_AT_di.uminho.pt perl-Test-Memory-Cycle jpo_AT_di.uminho.pt perl-Text-CSV_XS jpo_AT_di.uminho.pt perl-Text-WikiFormat jspaleta_AT_gmail.com istanbul jylitalo_AT_iki.fi python-imaging jylitalo_AT_iki.fi xplanet lemenkov_AT_newmail.ru chmlib lemenkov_AT_newmail.ru fuse-encfs lemenkov_AT_newmail.ru rlog lemenkov_AT_newmail.ru wavpack llch_AT_redhat.com libtabe llch_AT_redhat.com xcin lmacken_AT_redhat.com valknut luya256_AT_yahoo.com gdesklets matt_AT_truch.net cfitsio matt_AT_truch.net hpic mattdm_AT_mattdm.org wxPythonGTK2 matthias_AT_rpmforge.net advancecomp matthias_AT_rpmforge.net bbkeys matthias_AT_rpmforge.net blackbox matthias_AT_rpmforge.net boa matthias_AT_rpmforge.net camE matthias_AT_rpmforge.net csmash matthias_AT_rpmforge.net d4x matthias_AT_rpmforge.net diradmin matthias_AT_rpmforge.net djvulibre matthias_AT_rpmforge.net easytag matthias_AT_rpmforge.net fillets-ng matthias_AT_rpmforge.net gcombust matthias_AT_rpmforge.net gentoo matthias_AT_rpmforge.net giblib matthias_AT_rpmforge.net gkrellm-aclock matthias_AT_rpmforge.net gkrellm-freq matthias_AT_rpmforge.net Gtk-Perl matthias_AT_rpmforge.net gtktalog matthias_AT_rpmforge.net gtweakui matthias_AT_rpmforge.net hackedbox matthias_AT_rpmforge.net hercules matthias_AT_rpmforge.net i8kutils matthias_AT_rpmforge.net js matthias_AT_rpmforge.net kannel matthias_AT_rpmforge.net libcaca matthias_AT_rpmforge.net liboil matthias_AT_rpmforge.net lighttpd matthias_AT_rpmforge.net linux_logo matthias_AT_rpmforge.net lmarbles matthias_AT_rpmforge.net metakit matthias_AT_rpmforge.net ncftp matthias_AT_rpmforge.net oidentd matthias_AT_rpmforge.net p7zip matthias_AT_rpmforge.net php-eaccelerator matthias_AT_rpmforge.net php-pecl-mailparse matthias_AT_rpmforge.net php-pecl-pdo matthias_AT_rpmforge.net php-pecl-pdo-sqlite matthias_AT_rpmforge.net plib matthias_AT_rpmforge.net plib16 matthias_AT_rpmforge.net portaudio matthias_AT_rpmforge.net powermanga matthias_AT_rpmforge.net proftpd matthias_AT_rpmforge.net rrdtool matthias_AT_rpmforge.net SDL_gfx matthias_AT_rpmforge.net starfighter matthias_AT_rpmforge.net synergy matthias_AT_rpmforge.net thttpd matthias_AT_rpmforge.net torcs matthias_AT_rpmforge.net ucarp matthias_AT_rpmforge.net udftools matthias_AT_rpmforge.net viruskiller matthias_AT_rpmforge.net xvattr matthias_AT_rpmforge.net yasm matthias_AT_rpmforge.net zziplib mccann0011_AT_hotmail.com geos mccann0011_AT_hotmail.com proj meme_AT_daughtersoftiresias.org nethack-vultures mfleming+rpm_AT_enlartenment.com mlmmj mfleming+rpm_AT_enlartenment.com mod_security michel.salim_AT_gmail.com gai michel.salim_AT_gmail.com gai-pal michel.salim_AT_gmail.com grhino michel.salim_AT_gmail.com quarry mihai_AT_xcyb.org htb-util mitr_AT_redhat.com foobillard mitr_AT_redhat.com python-4Suite-XML nhorman_AT_redhat.com iozone nos_AT_utelsystems.com dillo nos_AT_utelsystems.com gktools nos_AT_utelsystems.com gtkterm nos_AT_utelsystems.com neverball nos_AT_utelsystems.com soundtracker nos_AT_utelsystems.com whowatch oliver.andrich_AT_gmail.com ruby-mysql oliver_AT_linux-kernel.at fish oliver_AT_linux-kernel.at libdnet orion_AT_cora.nwra.com gdl orion_AT_cora.nwra.com hdf5 orion_AT_cora.nwra.com kompose orion_AT_cora.nwra.com ncarg orion_AT_cora.nwra.com perl-Cflow orion_AT_cora.nwra.com perl-Net-IP-CMatch orion_AT_cora.nwra.com perl-Net-Patricia orion_AT_cora.nwra.com plplot orion_AT_cora.nwra.com python-basemap orion_AT_cora.nwra.com python-matplotlib otaylor_AT_redhat.com libuninameslist paul_AT_all-the-johnsons.co.uk anjuta paul_AT_all-the-johnsons.co.uk lib765 paul_AT_all-the-johnsons.co.uk libdsk paul_AT_all-the-johnsons.co.uk libspectrum paul_AT_xtdnet.nl fetchlog paul_AT_xtdnet.nl gaim-otr paul_AT_xtdnet.nl l2tpd paul_AT_xtdnet.nl ldns paul_AT_xtdnet.nl libotr paul_AT_xtdnet.nl nsd pawsa_AT_theochem.kth.se balsa pawsa_AT_theochem.kth.se libesmtp pertusus_AT_free.fr BibTool pertusus_AT_free.fr libdap pertusus_AT_free.fr libnc-dap pertusus_AT_free.fr libsx petersen_AT_redhat.com darcs petersen_AT_redhat.com FreeWnn petersen_AT_redhat.com ghc petersen_AT_redhat.com haddock petersen_AT_redhat.com scim-fcitx pvrabec_AT_redhat.com licq rc040203_AT_freenet.de lib3ds rc040203_AT_freenet.de SIMVoleon rdieter_AT_math.unl.edu akode rdieter_AT_math.unl.edu apollon rdieter_AT_math.unl.edu dxpc rdieter_AT_math.unl.edu factory rdieter_AT_math.unl.edu gc rdieter_AT_math.unl.edu geomview rdieter_AT_math.unl.edu gift rdieter_AT_math.unl.edu gift-openft rdieter_AT_math.unl.edu gpa rdieter_AT_math.unl.edu gpgme rdieter_AT_math.unl.edu gsview rdieter_AT_math.unl.edu gtk-qt-engine rdieter_AT_math.unl.edu jasper rdieter_AT_math.unl.edu kasablanca rdieter_AT_math.unl.edu kdocker rdieter_AT_math.unl.edu kickpim rdieter_AT_math.unl.edu kile rdieter_AT_math.unl.edu kimdaba rdieter_AT_math.unl.edu kiosktool rdieter_AT_math.unl.edu kipi-plugins rdieter_AT_math.unl.edu kmymoney2 rdieter_AT_math.unl.edu kxdocker rdieter_AT_math.unl.edu libassuan rdieter_AT_math.unl.edu libfac rdieter_AT_math.unl.edu libksba rdieter_AT_math.unl.edu libsigsegv rdieter_AT_math.unl.edu libtunepimp rdieter_AT_math.unl.edu lyx rdieter_AT_math.unl.edu Macaulay2 rdieter_AT_math.unl.edu maxima rdieter_AT_math.unl.edu openslp rdieter_AT_math.unl.edu pinentry rdieter_AT_math.unl.edu sbcl rdieter_AT_math.unl.edu tidy rdieter_AT_math.unl.edu uw-imap rdieter_AT_math.unl.edu xforms redhat_AT_flyn.org pam_mount redhat-bugzilla_AT_camperquake.de bmp redhat-bugzilla_AT_camperquake.de bmp-flac2 redhat-bugzilla_AT_camperquake.de fwbuilder redhat-bugzilla_AT_camperquake.de libfwbuilder roland_AT_redhat.com monotone rolandd_AT_cisco.com libmthca rvokal_AT_redhat.com nuttcp ryo-dairiki_AT_users.sourceforge.net scim-input-pad ryo-dairiki_AT_users.sourceforge.net scim-skk ryo-dairiki_AT_users.sourceforge.net scim-tomoe ryo-dairiki_AT_users.sourceforge.net tomoe shahms_AT_shahms.com python-psycopg skvidal_AT_phy.duke.edu mock skvidal_AT_phy.duke.edu seahorse steve_AT_silug.org perl-DateTime steve_AT_silug.org tuxpaint tagoh_AT_redhat.com Canna tagoh_AT_redhat.com kakasi tagoh_AT_redhat.com kinput2 tagoh_AT_redhat.com mew tagoh_AT_redhat.com namazu tagoh_AT_redhat.com paps tagoh_AT_redhat.com perl-Text-Kakasi tagoh_AT_redhat.com uim tagoh_AT_redhat.com w3m-el tcallawa_AT_redhat.com alsamixergui tcallawa_AT_redhat.com blacs tcallawa_AT_redhat.com c-ares tcallawa_AT_redhat.com check tcallawa_AT_redhat.com comical tcallawa_AT_redhat.com compat-wxGTK tcallawa_AT_redhat.com gambas tcallawa_AT_redhat.com gxemul tcallawa_AT_redhat.com jam tcallawa_AT_redhat.com lapack tcallawa_AT_redhat.com libgdamm tcallawa_AT_redhat.com libmcrypt tcallawa_AT_redhat.com librx tcallawa_AT_redhat.com lincity-ng tcallawa_AT_redhat.com logjam tcallawa_AT_redhat.com mcrypt tcallawa_AT_redhat.com mfstools tcallawa_AT_redhat.com netgo tcallawa_AT_redhat.com perl-Clone tcallawa_AT_redhat.com perl-DBD-SQLite2 tcallawa_AT_redhat.com perl-Template-Toolkit tcallawa_AT_redhat.com perl-version tcallawa_AT_redhat.com physfs tcallawa_AT_redhat.com QuantLib tcallawa_AT_redhat.com R tcallawa_AT_redhat.com rekall tcallawa_AT_redhat.com R-gnomeGUI tcallawa_AT_redhat.com rocksndiamonds tcallawa_AT_redhat.com rootsh tcallawa_AT_redhat.com scalapack tcallawa_AT_redhat.com udunits tcallawa_AT_redhat.com wlassistant tcallawa_AT_redhat.com xbase tcallawa_AT_redhat.com xbsql tcallawa_AT_redhat.com xkeycaps tcallawa_AT_redhat.com xsupplicant thomas_AT_apestaart.org directfb thomas_AT_apestaart.org flumotion thomas_AT_apestaart.org gstreamer08-python thomas_AT_apestaart.org gstreamer-python thomas_AT_apestaart.org Hermes thomas_AT_apestaart.org ladspa thomas_AT_apestaart.org libannodex thomas_AT_apestaart.org libcmml thomas_AT_apestaart.org liboggz thomas_AT_apestaart.org libshout thomas_AT_apestaart.org mach thomas_AT_apestaart.org mod_annodex thomas_AT_apestaart.org python-twisted toniw_AT_iki.fi silky tripwire-devel_AT_genesis-x.nildram.co.uk tripwire ville.skytta_AT_iki.fi dvb-apps ville.skytta_AT_iki.fi hddtemp ville.skytta_AT_iki.fi xemacs wart_AT_kobold.org tcldom wart_AT_kobold.org tclhttpd wart_AT_kobold.org tclxml wart_AT_kobold.org xpilot-ng wtogami_AT_redhat.com bonnie++ wtogami_AT_redhat.com lvcool wtogami_AT_redhat.com perl-Digest-Nilsimsa wtogami_AT_redhat.com perl-Razor-Agent -- Thorsten Leemhuis From dledford at redhat.com Tue Feb 21 20:43:56 2006 From: dledford at redhat.com (Doug Ledford) Date: Tue, 21 Feb 2006 15:43:56 -0500 Subject: That name game... In-Reply-To: <43FB36F8.7050805@linux-kernel.at> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> Message-ID: <20060221204356.GC5082@redhat.com> On Tue, Feb 21, 2006 at 04:51:20PM +0100, Oliver Falk wrote: > On 02/21/2006 04:24 PM, Konstantin Ryabitsev wrote: > > >(PS: Oliver: I can't believe you forgot Firefly! :)) > > The movie? Oh, yes, also possible :-) Firefly was the series, Serenity was the movie (and also one of the series episodes IIRC). -- Doug Ledford 919-754-3700 x44233 Red Hat, Inc. 1801 Varsity Dr. Raleigh, NC 27606 From blizzard at redhat.com Tue Feb 21 21:24:54 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 21 Feb 2006 16:24:54 -0500 Subject: That name game... In-Reply-To: <20060221204356.GC5082@redhat.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> Message-ID: <43FB8526.3090601@redhat.com> Zod. --Chris From jkeating at j2solutions.net Tue Feb 21 23:06:03 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 21 Feb 2006 15:06:03 -0800 Subject: That name game... In-Reply-To: <43FB8526.3090601@redhat.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> Message-ID: <1140563164.17286.128.camel@ender> On Tue, 2006-02-21 at 16:24 -0500, Christopher Blizzard wrote: > Zod. You lose. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From roland at redhat.com Tue Feb 21 23:43:41 2006 From: roland at redhat.com (Roland McGrath) Date: Tue, 21 Feb 2006 15:43:41 -0800 (PST) Subject: That name game... In-Reply-To: Christopher Blizzard's message of Tuesday, 21 February 2006 16:24:54 -0500 <43FB8526.3090601@redhat.com> Message-ID: <20060221234341.9AB82180C28@magilla.sf.frob.com> Zod!!! From tchung at fedoraproject.org Tue Feb 21 23:56:42 2006 From: tchung at fedoraproject.org (Thomas Chung) Date: Tue, 21 Feb 2006 15:56:42 -0800 Subject: That name game... In-Reply-To: <20060221234341.9AB82180C28@magilla.sf.frob.com> References: <43FB8526.3090601@redhat.com> <20060221234341.9AB82180C28@magilla.sf.frob.com> Message-ID: <20060221235459.M77718@fedoraproject.org> On Tue, 21 Feb 2006 16:24:54 -0500, Christopher Blizzard wrote > Zod. > > --Chris > On Tue, 21 Feb 2006 15:43:41 -0800 (PST), Roland McGrath wrote > Zod!!! > Are you guys campaigning for General Zod in 2008? :) http://www.zod2008.com/ -- Thomas Chung http://fedoraproject.org/wiki/ThomasChung From blizzard at redhat.com Wed Feb 22 03:05:59 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Tue, 21 Feb 2006 22:05:59 -0500 Subject: That name game... In-Reply-To: <1140563164.17286.128.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> Message-ID: <43FBD517.3060804@redhat.com> Jesse Keating wrote: > On Tue, 2006-02-21 at 16:24 -0500, Christopher Blizzard wrote: >> Zod. > > You lose. > You will be the first to suffer when your Future President and Eternal Ruler brings order to this miserable planet. --Chris From riel at redhat.com Wed Feb 22 03:12:43 2006 From: riel at redhat.com (Rik van Riel) Date: Tue, 21 Feb 2006 22:12:43 -0500 (EST) Subject: That name game... In-Reply-To: <1140467175.2517.2.camel@rousalka.dyndns.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> Message-ID: > > I like it. IS bordeaux a trademarked term? Whats our way out? > > Bordeaux is a city name. That's not something you can trademark. > If you want to be 100% clear you can write the city council to see if > they object. Bordeaux is also a colour. You can't trademark those... -- All Rights Reversed From jspaleta at gmail.com Wed Feb 22 03:08:41 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 21 Feb 2006 22:08:41 -0500 Subject: That name game... In-Reply-To: <43FBD517.3060804@redhat.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> <43FBD517.3060804@redhat.com> Message-ID: <604aa7910602211908s2cbeb5c4wb0bdc8402c3c1327@mail.gmail.com> On 2/21/06, Christopher Blizzard wrote: > You will be the first to suffer when your Future President and Eternal > Ruler brings order to this miserable planet. Just as long as he makes oneko part of Fedora Core... I'm more than happy to submit to his will. -jef From smooge at gmail.com Wed Feb 22 03:44:38 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Tue, 21 Feb 2006 20:44:38 -0700 Subject: That name game... In-Reply-To: References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> Message-ID: <80d7e4090602211944y1a115847i97c1e2c7708365b0@mail.gmail.com> On 2/21/06, Rik van Riel wrote: > > > > I like it. IS bordeaux a trademarked term? Whats our way out? > > > > Bordeaux is a city name. That's not something you can trademark. > > If you want to be 100% clear you can write the city council to see if > > they object. > > Bordeaux is also a colour. You can't trademark those... > A color in France.. who knows what strange French law covers it to make sure you do not dilute their wines. -- Stephen J Smoogen. CSIRT/Linux System Administrator From wtogami at redhat.com Wed Feb 22 04:02:03 2006 From: wtogami at redhat.com (Warren Togami) Date: Tue, 21 Feb 2006 23:02:03 -0500 Subject: That name game... In-Reply-To: <43FA1BAB.8010803@fedoraproject.org> References: <1140463429.17286.16.camel@ender> <43FA1BAB.8010803@fedoraproject.org> Message-ID: <43FBE23B.40608@redhat.com> Konstantin Ryabitsev wrote: > Jesse Keating wrote: >> Please start discussing, I'd like to have a list of good names to throw >> at Legal later this week. > > Jack Stentz was one of the creative consultants for the Andromeda Sci-fi > series. I suggest going along that line and picking a generic enough and > non-trademarked character name like Trance, Rev, Tyr, or Dylan. > > Should be geeky enough. :) > > Regards, My suggestion... - Zack Stentz writer of scifi show - Ronald D. Moore writer of scifi show Stentz -> Moore possible outs could be two directions 1) Moore the nutjob left-wing film maker Moore -> Bacon 2) Moore the scifi producer Moore -> Caprica For these reasons I strongly believe that "Moore" is a great, because either Bacon or Caprica would be awesome future names. Warren Togami wtogami at redhat.com From nicolas.mailhot at laposte.net Wed Feb 22 07:18:24 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 22 Feb 2006 08:18:24 +0100 Subject: That name game... In-Reply-To: <80d7e4090602211944y1a115847i97c1e2c7708365b0@mail.gmail.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> <80d7e4090602211944y1a115847i97c1e2c7708365b0@mail.gmail.com> Message-ID: <1140592704.22535.2.camel@rousalka.dyndns.org> Le mardi 21 f?vrier 2006 ? 20:44 -0700, Stephen J. Smoogen a ?crit : > On 2/21/06, Rik van Riel wrote: > > > > > > I like it. IS bordeaux a trademarked term? Whats our way out? > > > > > > Bordeaux is a city name. That's not something you can trademark. > > > If you want to be 100% clear you can write the city council to see if > > > they object. > > > > Bordeaux is also a colour. You can't trademark those... > > > > A color in France.. who knows what strange French law covers it to > make sure you do not dilute their wines. The French (European) law is actually perfectly sensical - if you name your wine according to a geographical location (city, region) you have to produce it in the actual region and follow regional traditions. It's not the far-reaching IP mess americans are accustomed to. -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From alexl at redhat.com Wed Feb 22 09:17:48 2006 From: alexl at redhat.com (Alexander Larsson) Date: Wed, 22 Feb 2006 10:17:48 +0100 Subject: That name game... In-Reply-To: <43FB8526.3090601@redhat.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> Message-ID: <1140599868.17723.11.camel@greebo> On Tue, 2006-02-21 at 16:24 -0500, Christopher Blizzard wrote: > Zod. Zod!!! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a globe-trotting chivalrous werewolf with a robot buddy named Sparky. She's a scantily clad psychic snake charmer from a different time and place. They fight crime! From jwboyer at jdub.homelinux.org Wed Feb 22 10:50:15 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 22 Feb 2006 05:50:15 -0500 Subject: That name game... In-Reply-To: <1140592704.22535.2.camel@rousalka.dyndns.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466480.17286.25.camel@ender> <1140467175.2517.2.camel@rousalka.dyndns.org> <80d7e4090602211944y1a115847i97c1e2c7708365b0@mail.gmail.com> <1140592704.22535.2.camel@rousalka.dyndns.org> Message-ID: <1140605416.8689.1.camel@yoda.jdub.homelinux.org> On Wed, 2006-02-22 at 08:18 +0100, Nicolas Mailhot wrote: > Le mardi 21 f?vrier 2006 ? 20:44 -0700, Stephen J. Smoogen a ?crit : > > On 2/21/06, Rik van Riel wrote: > > > > > > > > I like it. IS bordeaux a trademarked term? Whats our way out? > > > > > > > > Bordeaux is a city name. That's not something you can trademark. > > > > If you want to be 100% clear you can write the city council to see if > > > > they object. > > > > > > Bordeaux is also a colour. You can't trademark those... > > > > > > > A color in France.. who knows what strange French law covers it to > > make sure you do not dilute their wines. > > The French (European) law is actually perfectly sensical - if you name > your wine according to a geographical location (city, region) you have > to produce it in the actual region and follow regional traditions. > > It's not the far-reaching IP mess americans are accustomed to. Oh we have that too. Technically, bourbon cannot be called bourbon unless it is made in Bourbon County, Kentucky. So we get the perfectly sensible European laws _and_ the far-reaching IP mess. Yay for us ;) josh From alan at redhat.com Wed Feb 22 12:00:30 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Feb 2006 07:00:30 -0500 Subject: That name game... In-Reply-To: <1140563164.17286.128.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> Message-ID: <20060222120030.GB20029@devserv.devel.redhat.com> On Tue, Feb 21, 2006 at 03:06:03PM -0800, Jesse Keating wrote: > On Tue, 2006-02-21 at 16:24 -0500, Christopher Blizzard wrote: > > Zod. > You lose. We do have to do a Zod release some day. From alan at redhat.com Wed Feb 22 12:01:26 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Feb 2006 07:01:26 -0500 Subject: That name game... In-Reply-To: <20060221235459.M77718@fedoraproject.org> References: <43FB8526.3090601@redhat.com> <20060221234341.9AB82180C28@magilla.sf.frob.com> <20060221235459.M77718@fedoraproject.org> Message-ID: <20060222120126.GC20029@devserv.devel.redhat.com> On Tue, Feb 21, 2006 at 03:56:42PM -0800, Thomas Chung wrote: > Are you guys campaigning for General Zod in 2008? :) Sort of - there has been a campaign to get a RH/Fedora released called Zod internally to Red Hat since 1998 or maybe earlier From gdk at redhat.com Wed Feb 22 14:19:31 2006 From: gdk at redhat.com (Greg DeKoenigsberg) Date: Wed, 22 Feb 2006 09:19:31 -0500 (EST) Subject: That name game... In-Reply-To: <20060222120126.GC20029@devserv.devel.redhat.com> References: <43FB8526.3090601@redhat.com> <20060221234341.9AB82180C28@magilla.sf.frob.com> <20060221235459.M77718@fedoraproject.org> <20060222120126.GC20029@devserv.devel.redhat.com> Message-ID: The key question is... what's the naming path to and from Zod? --g --------------------------------------------------------------- Greg DeKoenigsberg || Fedora Foundation || fedoraproject.org Be an Ambassador || http://fedoraproject.org/wiki/Ambassadors --------------------------------------------------------------- On Wed, 22 Feb 2006, Alan Cox wrote: > On Tue, Feb 21, 2006 at 03:56:42PM -0800, Thomas Chung wrote: > > Are you guys campaigning for General Zod in 2008? :) > > Sort of - there has been a campaign to get a RH/Fedora released called Zod > internally to Red Hat since 1998 or maybe earlier > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From blizzard at redhat.com Wed Feb 22 14:34:13 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Wed, 22 Feb 2006 09:34:13 -0500 Subject: That name game... In-Reply-To: References: <43FB8526.3090601@redhat.com> <20060221234341.9AB82180C28@magilla.sf.frob.com> <20060221235459.M77718@fedoraproject.org> <20060222120126.GC20029@devserv.devel.redhat.com> Message-ID: <43FC7665.5050801@redhat.com> Greg DeKoenigsberg wrote: > The key question is... what's the naming path to and from Zod? Do you think your Eternal Ruler cares about such trivial matters? --Chris From kaboom at oobleck.net Wed Feb 22 14:40:47 2006 From: kaboom at oobleck.net (Chris Ricker) Date: Wed, 22 Feb 2006 09:40:47 -0500 (EST) Subject: That name game... In-Reply-To: References: <43FB8526.3090601@redhat.com> <20060221234341.9AB82180C28@magilla.sf.frob.com> <20060221235459.M77718@fedoraproject.org> <20060222120126.GC20029@devserv.devel.redhat.com> Message-ID: On Wed, 22 Feb 2006, Greg DeKoenigsberg wrote: > > The key question is... what's the naming path to and from Zod? There are no paths from Zod, only paths to him later, chris From bressers at redhat.com Wed Feb 22 15:15:59 2006 From: bressers at redhat.com (Josh Bressers) Date: Wed, 22 Feb 2006 10:15:59 -0500 Subject: That name game... In-Reply-To: Your message of "Wed, 22 Feb 2006 09:40:47 EST." Message-ID: <200602221515.k1MFFx2d024711@devserv.devel.redhat.com> > On Wed, 22 Feb 2006, Greg DeKoenigsberg wrote: > > > > > The key question is... what's the naming path to and from Zod? > > There are no paths from Zod, only paths to him Nonsense. The obvious successor to Zod would be Walken: http://www.walken2008.com/ -- JB From notting at redhat.com Wed Feb 22 17:02:53 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Feb 2006 12:02:53 -0500 Subject: That name game... In-Reply-To: <43FBE23B.40608@redhat.com> References: <1140463429.17286.16.camel@ender> <43FA1BAB.8010803@fedoraproject.org> <43FBE23B.40608@redhat.com> Message-ID: <20060222170253.GA5568@devserv.devel.redhat.com> Warren Togami (wtogami at redhat.com) said: > 2) Moore the scifi producer > Moore -> Caprica That's a) not a good direct 'is-a' link and b) basically reuses the link we got to get there... Bill From dmalcolm at redhat.com Wed Feb 22 17:05:03 2006 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 22 Feb 2006 12:05:03 -0500 Subject: That name game... In-Reply-To: <20060222170253.GA5568@devserv.devel.redhat.com> References: <1140463429.17286.16.camel@ender> <43FA1BAB.8010803@fedoraproject.org> <43FBE23B.40608@redhat.com> <20060222170253.GA5568@devserv.devel.redhat.com> Message-ID: <1140627903.16385.3.camel@cassandra.boston.redhat.com> On Wed, 2006-02-22 at 12:02 -0500, Bill Nottingham wrote: > Warren Togami (wtogami at redhat.com) said: > > 2) Moore the scifi producer > > Moore -> Caprica > > That's a) not a good direct 'is-a' link and b) basically reuses the > link we got to get there... Moore->Bond ? From dcbw at redhat.com Wed Feb 22 17:44:01 2006 From: dcbw at redhat.com (Dan Williams) Date: Wed, 22 Feb 2006 12:44:01 -0500 Subject: FC-4 Extras buildsystem breakage details Message-ID: <1140630242.18225.10.camel@localhost.localdomain> Hi, Some of you have noticed and pointed out the fact that the FC-4 Extras target wasn't successfully building any packages and wasn't giving much failure information. So after a bit of detective work this morning we've figured out that: 1) boa, which provides "webserver", is the immediate culprit of the breakage because it does not hardcode its UID for /usr/sbin/useradd. This leads useradd to select its first default of 100 for the UID, which is a direct conflict with mock, which hardcodes 100. It's unclear if mock should use a different UID or not. 2) dap-server, which appeared on 20-Feb-2006 around when the problems started, is the real culprit. dap-server requires webserver, which pulls in 'boa' because it has the shortest package name of those packages which provide 'webserver'. dap-server is getting pulled into all buildroots because it mistakenly provides built-in versions of perl-HTML-Parser modules 3) plague-builder appears to be dropping output from mock that's printed to stderr, causing the real error message not to appear in the logs To correct the problem, dap-server has been temporarily removed from Extras repositories, since it even blocks rebuilds of a fixed dap-server itself. When the buildsystem local repository rsyncs the new repo data down, dap-server will be rebuilt and builds on the fc-4 target should be able to continue as normal. We should also start up a discussion about how to prevent problems of this nature in the future. We would not have noticed the problem had boa not been conflicting with mock, but the real issue of dap-server providing perl-HTML-Parser modules itself would still have been a problem, albeit a silent one. If there are scripts, rules, and/or pre-submit checks which could be performed at various stages, it might go a long way towards prevent this sort of breakage in the future. Dan From notting at redhat.com Wed Feb 22 17:56:40 2006 From: notting at redhat.com (Bill Nottingham) Date: Wed, 22 Feb 2006 12:56:40 -0500 Subject: That name game... In-Reply-To: <1140627903.16385.3.camel@cassandra.boston.redhat.com> References: <1140463429.17286.16.camel@ender> <43FA1BAB.8010803@fedoraproject.org> <43FBE23B.40608@redhat.com> <20060222170253.GA5568@devserv.devel.redhat.com> <1140627903.16385.3.camel@cassandra.boston.redhat.com> Message-ID: <20060222175640.GA5383@devserv.devel.redhat.com> David Malcolm (dmalcolm at redhat.com) said: > On Wed, 2006-02-22 at 12:02 -0500, Bill Nottingham wrote: > > Warren Togami (wtogami at redhat.com) said: > > > 2) Moore the scifi producer > > > Moore -> Caprica > > > > That's a) not a good direct 'is-a' link and b) basically reuses the > > link we got to get there... > > Moore->Bond ? Technically, to follow that road, it would be Moore->Lazenby/Connery/Brosnan/Dalton/Craig. Bill From skvidal at linux.duke.edu Wed Feb 22 18:01:57 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 22 Feb 2006 13:01:57 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140630242.18225.10.camel@localhost.localdomain> References: <1140630242.18225.10.camel@localhost.localdomain> Message-ID: <1140631317.3959.21.camel@cutter> > 1) boa, which provides "webserver", is the immediate culprit of the > breakage because it does not hardcode its UID for /usr/sbin/useradd. > This leads useradd to select its first default of 100 for the UID, which > is a direct conflict with mock, which hardcodes 100. It's unclear if > mock should use a different UID or not. I'm open to mock making a different uid in the chroot. iirc - it's just the builder user that's uid 100. changing that to some arbitrarily large number should not negatively impact it. -sv From dennis at ausil.us Wed Feb 22 18:06:23 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 22 Feb 2006 12:06:23 -0600 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140631317.3959.21.camel@cutter> References: <1140630242.18225.10.camel@localhost.localdomain> <1140631317.3959.21.camel@cutter> Message-ID: <200602221206.23128.dennis@ausil.us> On Wednesday 22 February 2006 12:01, seth vidal wrote: > > 1) boa, which provides "webserver", is the immediate culprit of the > > breakage because it does not hardcode its UID for /usr/sbin/useradd. > > This leads useradd to select its first default of 100 for the UID, which > > is a direct conflict with mock, which hardcodes 100. It's unclear if > > mock should use a different UID or not. > > I'm open to mock making a different uid in the chroot. iirc - it's just > the builder user that's uid 100. > > changing that to some arbitrarily large number should not negatively > impact it. 65100 is my suggestion -- Regards Dennis Gilmore, RHCE Proud Australian From skvidal at linux.duke.edu Wed Feb 22 18:09:34 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Wed, 22 Feb 2006 13:09:34 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <200602221206.23128.dennis@ausil.us> References: <1140630242.18225.10.camel@localhost.localdomain> <1140631317.3959.21.camel@cutter> <200602221206.23128.dennis@ausil.us> Message-ID: <1140631775.3959.26.camel@cutter> > > > > changing that to some arbitrarily large number should not negatively > > impact it. > 65100 is my suggestion I'll see your 65100 and raise you 100 - 65200! :) -sv From smooge at gmail.com Wed Feb 22 18:12:22 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 22 Feb 2006 11:12:22 -0700 Subject: That name game... In-Reply-To: <20060222120126.GC20029@devserv.devel.redhat.com> References: <43FB8526.3090601@redhat.com> <20060221234341.9AB82180C28@magilla.sf.frob.com> <20060221235459.M77718@fedoraproject.org> <20060222120126.GC20029@devserv.devel.redhat.com> Message-ID: <80d7e4090602221012s393b34f5h501d2b5f3e085f2f@mail.gmail.com> On 2/22/06, Alan Cox wrote: > On Tue, Feb 21, 2006 at 03:56:42PM -0800, Thomas Chung wrote: > > Are you guys campaigning for General Zod in 2008? :) > > Sort of - there has been a campaign to get a RH/Fedora released called Zod > internally to Red Hat since 1998 or maybe earlier > My earliest recollection is 1997 after I got there... I think the 4.90 beta release someone listed Zod as what they wanted. It was considered to be infeasible for copyright, trademark, and all the rest. [We just made money this quarter, do you want to blow it on lawsuits?] > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > -- Stephen J Smoogen. CSIRT/Linux System Administrator From dennis at ausil.us Wed Feb 22 18:16:15 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 22 Feb 2006 12:16:15 -0600 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140631775.3959.26.camel@cutter> References: <1140630242.18225.10.camel@localhost.localdomain> <200602221206.23128.dennis@ausil.us> <1140631775.3959.26.camel@cutter> Message-ID: <200602221216.16088.dennis@ausil.us> On Wednesday 22 February 2006 12:09, seth vidal wrote: > > > changing that to some arbitrarily large number should not negatively > > > impact it. > > > > 65100 is my suggestion > > I'll see your 65100 and raise you 100 - 65200! > > :) > > -sv > Ill match your 100 and raise with another 100 to 65300 :D -- Regards Dennis Gilmore, RHCE Proud Australian From icon at fedoraproject.org Wed Feb 22 18:33:45 2006 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Wed, 22 Feb 2006 13:33:45 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <200602221216.16088.dennis@ausil.us> References: <1140630242.18225.10.camel@localhost.localdomain> <200602221206.23128.dennis@ausil.us> <1140631775.3959.26.camel@cutter> <200602221216.16088.dennis@ausil.us> Message-ID: <43FCAE89.5020208@fedoraproject.org> Dennis Gilmore wrote: >>>> changing that to some arbitrarily large number should not negatively >>>> impact it. >>> 65100 is my suggestion >> I'll see your 65100 and raise you 100 - 65200! >> >> :) >> >> -sv >> > Ill match your 100 and raise with another 100 to 65300 *shakes his 64-bit wallet at everyone* Don't make me use this! -- Konstantin Ryabitsev McGill University WSG Simon: "Could you not do that while we're... ever?" --Episode #9, "Ariel" From jkeating at j2solutions.net Wed Feb 22 18:42:06 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 22 Feb 2006 10:42:06 -0800 Subject: That name game... In-Reply-To: <20060222120030.GB20029@devserv.devel.redhat.com> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> <20060222120030.GB20029@devserv.devel.redhat.com> Message-ID: <1140633727.4578.21.camel@ender> On Wed, 2006-02-22 at 07:00 -0500, Alan Cox wrote: > We do have to do a Zod release some day. AFAIR Legal has emphatically said NO. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From pix at crazyfrogs.org Wed Feb 22 19:02:36 2006 From: pix at crazyfrogs.org (Pix) Date: Wed, 22 Feb 2006 20:02:36 +0100 Subject: That name game... In-Reply-To: <1140633727.4578.21.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> <20060222120030.GB20029@devserv.devel.redhat.com> <1140633727.4578.21.camel@ender> Message-ID: <1140634957.6474.29.camel@localhost.wyplay.com> Ok, more names.. There is a Zack Stentz somewhere on the Internet. The hero of the well known Maniac Mansion game was... Zack McKraken. So "Mansion" or "Maniac".. or "McKraken" ? Le mercredi 22 f?vrier 2006 ? 10:42 -0800, Jesse Keating a ?crit : > On Wed, 2006-02-22 at 07:00 -0500, Alan Cox wrote: > > We do have to do a Zod release some day. > > AFAIR Legal has emphatically said NO. > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From jwboyer at jdub.homelinux.org Wed Feb 22 18:17:09 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Wed, 22 Feb 2006 13:17:09 -0500 (EST) Subject: That name game... In-Reply-To: <1140633727.4578.21.camel@ender> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> <20060222120030.GB20029@devserv.devel.redhat.com> <1140633727.4578.21.camel@ender> Message-ID: <36583.129.42.161.36.1140632229.squirrel@jdub.homelinux.org> > On Wed, 2006-02-22 at 07:00 -0500, Alan Cox wrote: >> We do have to do a Zod release some day. > > AFAIR Legal has emphatically said NO. Hm.. how about Z?d? Would that help... josh From tiemann at redhat.com Wed Feb 22 19:35:14 2006 From: tiemann at redhat.com (Michael Tiemann) Date: Wed, 22 Feb 2006 14:35:14 -0500 Subject: That name game... In-Reply-To: <36583.129.42.161.36.1140632229.squirrel@jdub.homelinux.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> <20060222120030.GB20029@devserv.devel.redhat.com> <1140633727.4578.21.camel@ender> <36583.129.42.161.36.1140632229.squirrel@jdub.homelinux.org> Message-ID: <1140636914.3730.87.camel@localhost.localdomain> On Wed, 2006-02-22 at 13:17 -0500, Josh Boyer wrote: > > On Wed, 2006-02-22 at 07:00 -0500, Alan Cox wrote: > >> We do have to do a Zod release some day. > > > > AFAIR Legal has emphatically said NO. > > Hm.. how about Z?d? Would that help... Or better: Z?d? M From jamatos at fc.up.pt Wed Feb 22 19:43:30 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Wed, 22 Feb 2006 19:43:30 +0000 Subject: That name game... In-Reply-To: <1140636914.3730.87.camel@localhost.localdomain> References: <1140463429.17286.16.camel@ender> <36583.129.42.161.36.1140632229.squirrel@jdub.homelinux.org> <1140636914.3730.87.camel@localhost.localdomain> Message-ID: <200602221943.31147.jamatos@fc.up.pt> On Wednesday 22 February 2006 19:35, Michael Tiemann wrote: > Or better: Z?d? I thought about that too as well as all other Unicode variants available, the margin size is too narrow for so many entries... ;-) Z.d -> Z?d -> Zod -> Z?d -> ZOd ... > M -- Jos? Ab?lio From orion at cora.nwra.com Wed Feb 22 21:44:16 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 22 Feb 2006 14:44:16 -0700 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140630242.18225.10.camel@localhost.localdomain> References: <1140630242.18225.10.camel@localhost.localdomain> Message-ID: <43FCDB30.3010709@cora.nwra.com> Dan Williams wrote: > > We should also start up a discussion about how to prevent problems of > this nature in the future. We would not have noticed the problem had > boa not been conflicting with mock, but the real issue of dap-server > providing perl-HTML-Parser modules itself would still have been a > problem, albeit a silent one. If there are scripts, rules, and/or > pre-submit checks which could be performed at various stages, it might > go a long way towards prevent this sort of breakage in the future. > A crude one might be to have mock check the names of the packages installed by "groupinstall build" against a list of "approved" packages. This list should be static for all releases, and nearly so for rawhide. I've been bitten too by a package providing a file that conflicts with another package. Provides should be checked for conflicts too, although there would have to be a white list of Provides that are allowed to be duplicated - like webserver. Since this info is all in the repo data, shouldn't be too bad to write. :-) -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From jrb at redhat.com Wed Feb 22 22:01:51 2006 From: jrb at redhat.com (Jonathan Blandford) Date: Wed, 22 Feb 2006 17:01:51 -0500 Subject: That name game... In-Reply-To: <1140599868.17723.11.camel@greebo> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140599868.17723.11.camel@greebo> Message-ID: <1140645711.2765.56.camel@localhost.localdomain> On Wed, 2006-02-22 at 10:17 +0100, Alexander Larsson wrote: > On Tue, 2006-02-21 at 16:24 -0500, Christopher Blizzard wrote: > > Zod. > > Zod!!! Zod. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From jkeating at redhat.com Wed Feb 22 23:17:31 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 22 Feb 2006 15:17:31 -0800 Subject: Narrow down the name list Message-ID: <1140650251.13287.24.camel@ender> I've gathered a list of possible names. Anybody have any objections to me submitting these to Legal for vetting? Rev Tyr Dylan Moore Bordeaux Trance Gemini Hunt Sorbo Mansion Maniac McKraken Metropolis Amoeba Andromeda -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From smooge at gmail.com Wed Feb 22 23:32:09 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 22 Feb 2006 16:32:09 -0700 Subject: Narrow down the name list In-Reply-To: <1140650251.13287.24.camel@ender> References: <1140650251.13287.24.camel@ender> Message-ID: <80d7e4090602221532r6adf513g5d85905eeaefc4f3@mail.gmail.com> On 2/22/06, Jesse Keating wrote: > I've gathered a list of possible names. Anybody have any objections to > me submitting these to Legal for vetting? > > > Sorbo The idea from Michael Johnsons day was to pick the worst name for jumping next too because it had to be a challenge for the next developer stuck with the job. I do like Metropolis because you can jump to Los Alamos :) -- Stephen J Smoogen. CSIRT/Linux System Administrator From alan at redhat.com Thu Feb 23 00:13:38 2006 From: alan at redhat.com (Alan Cox) Date: Wed, 22 Feb 2006 19:13:38 -0500 Subject: Narrow down the name list In-Reply-To: <80d7e4090602221532r6adf513g5d85905eeaefc4f3@mail.gmail.com> References: <1140650251.13287.24.camel@ender> <80d7e4090602221532r6adf513g5d85905eeaefc4f3@mail.gmail.com> Message-ID: <20060223001338.GC30322@devserv.devel.redhat.com> On Wed, Feb 22, 2006 at 04:32:09PM -0700, Stephen J. Smoogen wrote: > > Sorbo > > The idea from Michael Johnsons day was to pick the worst name for > jumping next too because it had to be a challenge for the next > developer stuck with the job. Shouldn't be too hard. Its a film person, a cleaning company and a few other things 8) > I do like Metropolis because you can jump to Los Alamos :) Or motorhead ;) From rc040203 at freenet.de Thu Feb 23 04:18:31 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 23 Feb 2006 05:18:31 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140630242.18225.10.camel@localhost.localdomain> References: <1140630242.18225.10.camel@localhost.localdomain> Message-ID: <1140668312.14289.162.camel@mccallum.corsepiu.local> On Wed, 2006-02-22 at 12:44 -0500, Dan Williams wrote: > Hi, > > Some of you have noticed and pointed out the fact that the FC-4 Extras > target wasn't successfully building any packages and wasn't giving much > failure information. So after a bit of detective work this morning > we've figured out that: > 3) plague-builder appears to be dropping output from mock that's printed > to stderr, causing the real error message not to appear in the logs > > To correct the problem, dap-server has been temporarily removed from > Extras repositories, since it even blocks rebuilds of a fixed dap-server > itself. When the buildsystem local repository rsyncs the new repo data > down, dap-server will be rebuilt and builds on the fc-4 target should be > able to continue as normal. Still no-go: ... /usr/sbin/mock-helper yum --installroot /var/lib/mock/fedora-4-i386-core-72dfa3dc071fedce33db998bb2b4024b3ffa4531/root groupinstall build http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. Error: failure: dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: [Errno 256] No more mirrors to try. Cleaning up... Done. ... seems as if now the repo is broked. Ralf From oliver at linux-kernel.at Thu Feb 23 07:07:59 2006 From: oliver at linux-kernel.at (Oliver Falk) Date: Thu, 23 Feb 2006 08:07:59 +0100 Subject: Narrow down the name list In-Reply-To: <1140650251.13287.24.camel@ender> References: <1140650251.13287.24.camel@ender> Message-ID: <43FD5F4F.5020401@linux-kernel.at> On 02/23/2006 12:17 AM, Jesse Keating wrote: > I've gathered a list of possible names. Anybody have any objections to > me submitting these to Legal for vetting? > > Rev > Tyr > Dylan > Moore > Bordeaux > Trance > Gemini > Hunt > Sorbo > Mansion > Maniac > McKraken > Metropolis > Amoeba > Andromeda At least a few of my ideas made it into this list. Fine, fine... :-) I'm still voting for Trance or Gemini! -of From ville.skytta at iki.fi Thu Feb 23 07:33:36 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 23 Feb 2006 09:33:36 +0200 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140668312.14289.162.camel@mccallum.corsepiu.local> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> Message-ID: <1140680016.11840.11.camel@bobcat.mine.nu> On Thu, 2006-02-23 at 05:18 +0100, Ralf Corsepius wrote: > > To correct the problem, dap-server has been temporarily removed from > > Extras repositories, since it even blocks rebuilds of a fixed dap-server > > itself. When the buildsystem local repository rsyncs the new repo data > > down, dap-server will be rebuilt and builds on the fc-4 target should be > > able to continue as normal. > > Still no-go: > > ... > /usr/sbin/mock-helper yum > --installroot /var/lib/mock/fedora-4-i386-core-72dfa3dc071fedce33db998bb2b4024b3ffa4531/root groupinstall build > http://buildsys.fedoraproject.org/plague-results/fedora-4-extras/dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm: [Errno 4] IOError: HTTP Error 404: Not Found > Trying other mirror. > Error: failure: > dap-server/3.5.3-1.fc4/i386/dap-server-3.5.3-1.fc4.i386.rpm from local: > [Errno 256] No more mirrors to try. > Cleaning up... > Done. > > ... seems as if now the repo is broked. Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? My retry last night may have been interrupted by net connectivity glitches. Re-retrying now. From pix at crazyfrogs.org Thu Feb 23 10:18:46 2006 From: pix at crazyfrogs.org (pix at crazyfrogs.org) Date: Thu, 23 Feb 2006 11:18:46 +0100 Subject: Narrow down the name list In-Reply-To: <43FD5F4F.5020401@linux-kernel.at> References: <1140650251.13287.24.camel@ender> <43FD5F4F.5020401@linux-kernel.at> Message-ID: <20060223101846.GA806@fort.crazyfrogs.org> Bordeaux is a wine, everybody should vote to this name ! :P On Thu, Feb 23, 2006 at 08:07:59AM +0100, Oliver Falk wrote: > On 02/23/2006 12:17 AM, Jesse Keating wrote: > >I've gathered a list of possible names. Anybody have any objections to > >me submitting these to Legal for vetting? > > > >Rev > >Tyr > >Dylan > >Moore > >Bordeaux > >Trance > >Gemini > >Hunt > >Sorbo > >Mansion > >Maniac > >McKraken > >Metropolis > >Amoeba > >Andromeda > > At least a few of my ideas made it into this list. Fine, fine... :-) I'm > still voting for Trance or Gemini! > > -of > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From skvidal at linux.duke.edu Thu Feb 23 14:05:08 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Feb 2006 09:05:08 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140680016.11840.11.camel@bobcat.mine.nu> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> Message-ID: <1140703508.14667.21.camel@cutter> > Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? > My retry last night may have been interrupted by net connectivity > glitches. Re-retrying now. I ran the repobuild and repoview before syncing. -sv From rc040203 at freenet.de Thu Feb 23 14:25:49 2006 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 23 Feb 2006 15:25:49 +0100 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140703508.14667.21.camel@cutter> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> Message-ID: <1140704749.14289.254.camel@mccallum.corsepiu.local> On Thu, 2006-02-23 at 09:05 -0500, seth vidal wrote: > > Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? > > My retry last night may have been interrupted by net connectivity > > glitches. Re-retrying now. > > I ran the repobuild and repoview before syncing. No progress so far: http://buildsys.fedoraproject.org/logs/fedora-4-extras/5169-Coin2-2.4.4-3.2.fc4/ Are you using a caching createrepo? Did you verify the cache is in sync with the files? Ralf From skvidal at linux.duke.edu Thu Feb 23 15:22:26 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Feb 2006 10:22:26 -0500 Subject: FC-4 Extras buildsystem breakage details In-Reply-To: <1140704749.14289.254.camel@mccallum.corsepiu.local> References: <1140630242.18225.10.camel@localhost.localdomain> <1140668312.14289.162.camel@mccallum.corsepiu.local> <1140680016.11840.11.camel@bobcat.mine.nu> <1140703508.14667.21.camel@cutter> <1140704749.14289.254.camel@mccallum.corsepiu.local> Message-ID: <1140708146.20619.7.camel@cutter> On Thu, 2006-02-23 at 15:25 +0100, Ralf Corsepius wrote: > On Thu, 2006-02-23 at 09:05 -0500, seth vidal wrote: > > > Yep, maybe the FE4 repodata wasn't regenerated after dap-server removal? > > > My retry last night may have been interrupted by net connectivity > > > glitches. Re-retrying now. > > > > I ran the repobuild and repoview before syncing. > > No progress so far: > http://buildsys.fedoraproject.org/logs/fedora-4-extras/5169-Coin2-2.4.4-3.2.fc4/ > > Are you using a caching createrepo? Did you verify the cache is in sync > with the files? the cache doesn't work like that. See my last message. A mirror is out of sync. -sv From smooge at gmail.com Thu Feb 23 19:27:59 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Thu, 23 Feb 2006 12:27:59 -0700 Subject: Narrow down the name list In-Reply-To: <20060223001338.GC30322@devserv.devel.redhat.com> References: <1140650251.13287.24.camel@ender> <80d7e4090602221532r6adf513g5d85905eeaefc4f3@mail.gmail.com> <20060223001338.GC30322@devserv.devel.redhat.com> Message-ID: <80d7e4090602231127k1b844240hd0e2498f8f3e15d1@mail.gmail.com> On 2/22/06, Alan Cox wrote: > On Wed, Feb 22, 2006 at 04:32:09PM -0700, Stephen J. Smoogen wrote: > > > Sorbo > > > > The idea from Michael Johnsons day was to pick the worst name for > > jumping next too because it had to be a challenge for the next > > developer stuck with the job. > > Shouldn't be too hard. Its a film person, a cleaning company and a few other > things 8) > > > I do like Metropolis because you can jump to Los Alamos :) > > Or motorhead ;) > That would be good. You can then go to Poker via Ace of Spades Ace of Spades Ace... -- Stephen J Smoogen. CSIRT/Linux System Administrator From mharris at mharris.ca Sat Feb 25 16:47:57 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 25 Feb 2006 11:47:57 -0500 Subject: That name game... In-Reply-To: References: <43FB8526.3090601@redhat.com> <20060221234341.9AB82180C28@magilla.sf.frob.com> <20060221235459.M77718@fedoraproject.org> <20060222120126.GC20029@devserv.devel.redhat.com> Message-ID: <44008A3D.9000305@mharris.ca> Chris Ricker wrote: > On Wed, 22 Feb 2006, Greg DeKoenigsberg wrote: > > >>The key question is... what's the naming path to and from Zod? > > > There are no paths from Zod, only paths to him There are paths to and from Zod. I had a perfect path back in the RHL days. Unfortunately, even though "zod" comes up as a name every single OS release, and has a massive cult following inside Red Hat, there is always at least one person who vetoes zod as the name, regardless of any nifty path in and out that is devised. I guess you could say that despite the massive zod cult we have, all it takes is one person to think it is silly, and kill the idea. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Sat Feb 25 16:50:23 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Sat, 25 Feb 2006 11:50:23 -0500 Subject: That name game... In-Reply-To: <36583.129.42.161.36.1140632229.squirrel@jdub.homelinux.org> References: <1140463429.17286.16.camel@ender> <1140465939.2982.8.camel@localhost.wyplay.com> <1140466416.26007.0.camel@cutter> <43FAE786.4090704@linux-kernel.at> <43FB30C4.2080701@fedoraproject.org> <43FB36F8.7050805@linux-kernel.at> <20060221204356.GC5082@redhat.com> <43FB8526.3090601@redhat.com> <1140563164.17286.128.camel@ender> <20060222120030.GB20029@devserv.devel.redhat.com> <1140633727.4578.21.camel@ender> <36583.129.42.161.36.1140632229.squirrel@jdub.homelinux.org> Message-ID: <44008ACF.6010409@mharris.ca> Josh Boyer wrote: >>On Wed, 2006-02-22 at 07:00 -0500, Alan Cox wrote: >> >>>We do have to do a Zod release some day. >> >>AFAIR Legal has emphatically said NO. > > > Hm.. how about Z?d? Would that help... The only thing that might help, is if we hired Terrence Stamp. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From fedora at leemhuis.info Sun Feb 26 18:22:26 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Feb 2006 19:22:26 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140541669.2144.30.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> Message-ID: <1140978146.18127.112.camel@localhost.localdomain> Hi all! Replies to fedora-extras-list please to avoid confusion. Small update: 366 arch packages still need a rebuild. The following 43 maintainers didn't rebuild a single package since the rebuild was announced: aaron.bennett_AT_olin.edu ad+rh-bugzilla_AT_uni-x.org aportal_AT_univ-montp2.fr bojan_AT_rexursive.com ch.nolte_AT_fh-wolfenbuettel.de chris_AT_chrisgrau.com chrisw_AT_redhat.com colin_AT_fedoraproject.org danken_AT_cs.technion.ac.il davidhart_AT_tqmcube.com davidz_AT_redhat.com denis_AT_poolshark.org dwmw2_AT_redhat.com endur_AT_bennewitz.com fredrik_AT_dolda2000.com grenier_AT_cgsecurity.org jcarpenter_AT_condell.org jdennis_AT_redhat.com jeff_AT_ultimateevil.org jeff.gilchrist_AT_gmail.com jnovy_AT_redhat.com joost_AT_cnoc.nl jylitalo_AT_iki.fi llch_AT_redhat.com luya256_AT_yahoo.com matt_AT_truch.net mccann0011_AT_hotmail.com meme_AT_daughtersoftiresias.org michel.salim_AT_gmail.com mihai_AT_xcyb.org nhorman_AT_redhat.com nos_AT_utelsystems.com oliver.andrich_AT_gmail.com otaylor_AT_redhat.com pawsa_AT_theochem.kth.se petersen_AT_redhat.com pvrabec_AT_redhat.com roland_AT_redhat.com ryo-dairiki_AT_users.sourceforge.net tagoh_AT_redhat.com thomas_AT_apestaart.org toniw_AT_iki.fi tripwire-devel_AT_genesis-x.nildram.co.uk Site note: - 12 of those 43 maintainers have a redhat.com address ;-) - 2 of those 43 are FESCo members. - those 43 own 110 packages in total Okay, let's be fair. Let's say 8 of them are on holiday and didn't read about the rebuild yet. But what about the other 35? Vanished? Lost interest in fedora-extras? Or do they route mail from fedora-maintainers to /dev/null? Or did they unsubscribe from the list (iirc it is mandatory to be subscribed to fedora-maintainers if you maintain a package in extras. Or am I wrong here?). Okay, let's look at the whole situation from a different perspective. The following list shows maintainers that still have to rebuild more than 5 packages: 54 matthias_AT_rpmforge.net 36 tcallawa_AT_redhat.com 35 rdieter_AT_math.unl.edu 28 extras-orphan_AT_fedoraproject.org 13 thomas_AT_apestaart.org 12 denis_AT_poolshark.org 11 anvil_AT_livna.org 11 adrian_AT_lisas.de 9 tagoh_AT_redhat.com 7 gemi_AT_bluewin.ch 7 andreas.bierfert_AT_lowlatency.de 6 ghenry_AT_suretecsystems.com 6 andreas_AT_bawue.net 5 petersen_AT_redhat.com 5 orion_AT_cora.nwra.com 5 nos_AT_utelsystems.com 5 jcarpenter_AT_condell.org 5 green_AT_redhat.com Site notes: - there might be good reasons to be in the list if you have a lot of packages that don't build yet with gcc 4.1. Okay, then let's look at the whole situation from a different perspective again. Any packages in the repo that still have fc4 in the name? That would be really confusing for everybody IMHO. Ohh, yeah, we have: anvil_AT_livna.org libsamplerate 0.1.2-3.fc4 anvil_AT_livna.org libsndfile 1.0.11-3.fc4 gijs_AT_gewis.nl python-cherrytemplate 1.0.0-2.fc4 ivazquez_AT_ivazquez.net python-HTMLgen 2.2.2-7.fc4 jdennis_AT_redhat.com cyrus-imapd 2.2.12-6.fc4 jpo_AT_di.uminho.pt pdfjam 1.20-3.fc4 jpo_AT_di.uminho.pt perl-Test-Builder-Tester 1.01-4.fc4 matthias_AT_rpmforge.net rrdtool 1.0.49-5.fc4 rdieter_AT_math.unl.edu Macaulay2 0.9.2-17.fc4 tcallawa_AT_redhat.com scalapack 1.7-7.fc4 wtogami_AT_redhat.com pyzor 0.4.0-9.fc4 /me is really disappointed by all these results. Disclaimer: Maybe I or the scripts I wrote did an error here and there. If that's the case I'm very sorry and must apologize. Okay, let's face it. The "rebuild by maintainer solution" that was agreed upon in FESCo did not work very well up to this point. Actually I suspected that in the beginning, but I had hoped that it would work at least a bit better. But the result is quite interesting. But that's a different story. So, how to proceed? Bug the maintainers with a E-Mail directly? Probably a good idea. I'll try to write a script that does this. But we have not much time until FC5 is shipped. Do we simply want to ignore that a lot of packages were not rebuild until then? Or do we want to let a script rebuild the rest of the packages? More important: How do we find out if these 43 people are still Fedora Extras maintainers? I'm sure a majority of them will show up in time. But I suspect that at least some of them are vanished and their packages are orphaned in fact -- we need to know that sooner or later, otherwise Fedora Extras results in a mess over time (site note: there are probably also some noarch packages where the maintainer is vanished, But we don't request a rebuild of those, so we don't). And I suspect that some others from those 43 maintainers probably should face that they have a lot of other, more important work to do and should probably orphan their packages so that other interested people can take them over. Suggestions how to solve this whole mess in the short and in the long term welcome. Anyway, here a complete list of packages that still need a rebuild. It is also in the wiki now at http://www.fedoraproject.org/wiki/Extras/FC5Status If there is a good reason why the package is not yet rebuild please add a short note to the page. tia aaron.bennett_AT_olin.edu ifplugd 0.24-6 ad+rh-bugzilla_AT_uni-x.org pam_abl 0.2.2-2.fc5 adrian_AT_lisas.de kover 2.9.6-4 adrian_AT_lisas.de libcdio 0.76-1.fc5 adrian_AT_lisas.de most 4.10.2-2.fc5 adrian_AT_lisas.de nexuiz 1.2.1-3.fc5 adrian_AT_lisas.de ninja 1.5.8.1-2 adrian_AT_lisas.de sopwith 1.7.1-2 adrian_AT_lisas.de source-highlight 2.2-1.fc5 adrian_AT_lisas.de tin 1.6.2-4 adrian_AT_lisas.de uudeview 0.5.20-4 adrian_AT_lisas.de vnstat 1.4-5 adrian_AT_lisas.de xdesktopwaves 1.3-4 a.kurtz_AT_hardsun.net libdaemon 0.6-6 andreas_AT_bawue.net barcode 0.98-8.fc5 andreas_AT_bawue.net commoncpp2 1.3.23-1.fc5 andreas_AT_bawue.net ddrescue 1.10-2 andreas_AT_bawue.net mod_suphp 0.6.1-1.fc5 andreas_AT_bawue.net perl-Crypt-Blowfish 2.09-2.fc5 andreas_AT_bawue.net scmxx 0.8.2-1.fc5 andreas.bierfert_AT_lowlatency.de fbdesk 1.2.1-2 andreas.bierfert_AT_lowlatency.de fluxbox 0.9.14-1.fc5 andreas.bierfert_AT_lowlatency.de orange 0.3-0.cvs20051118.fc5.1 andreas.bierfert_AT_lowlatency.de synce 0.9.1-6.fc5 andreas.bierfert_AT_lowlatency.de synce-gnomevfs 0.9.0-2.fc5 andreas.bierfert_AT_lowlatency.de synce-software-manager 0.9.0-4.fc5 andreas.bierfert_AT_lowlatency.de synce-trayicon 0.9.0-5.fc5 anvil_AT_livna.org aalib 1.4.0-0.rc5.7 anvil_AT_livna.org bin2iso 1.9-2.b anvil_AT_livna.org imlib2 1.2.1-5.fc5 anvil_AT_livna.org irssi 0.8.10-3.fc5 anvil_AT_livna.org libcddb 1.2.1-1.fc5 anvil_AT_livna.org libebml 0.7.6-1.fc5 anvil_AT_livna.org libmatroska 0.8.0-1.fc5 anvil_AT_livna.org libsamplerate 0.1.2-3.fc4 anvil_AT_livna.org libsndfile 1.0.11-3.fc4 anvil_AT_livna.org libtar 1.2.11-5 anvil_AT_livna.org lzo 1.08-5.fc5 aportal_AT_univ-montp2.fr gpsim 0.21.11-1.fc5 aportal_AT_univ-montp2.fr gputils 0.13.3-1.fc5 aportal_AT_univ-montp2.fr gtk+extra 2.1.1-1.fc5 bdpepple_AT_ameritech.net gnomebaker 0.5.1-2.fc5 bdpepple_AT_ameritech.net tagtool 0.12.2-4.fc5 bojan_AT_rexursive.com libapreq2 2.07-1.fc5 bugs.michael_AT_gmx.net abicheck 1.2-9 bugs.michael_AT_gmx.net aide 0.10-2 ch.nolte_AT_fh-wolfenbuettel.de kbibtex 0.1.3-3.fc5 chris_AT_chrisgrau.com frotz 2.43-3.fc5 chris_AT_chrisgrau.com ifm 5.1-2.fc5 chris_AT_chrisgrau.com perl-Time-Piece 1.08-2.fc5 chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 colin_AT_fedoraproject.org adns 1.1-5 colin_AT_fedoraproject.org gaim-guifications 2.12-2.fc5 colin_AT_fedoraproject.org MagicPoint 1.11b-2.fc5 colin_AT_fedoraproject.org python-adns 1.1.0-1 danken_AT_cs.technion.ac.il bidiv 1.5-2.fc5 danken_AT_cs.technion.ac.il hspell 0.9-6 danken_AT_cs.technion.ac.il taarich 1.20051120-3.fc5 davidhart_AT_tqmcube.com leafnode 1.9.53-3 davidz_AT_redhat.com NetworkManager-vpnc 0.5.0-1 denis_AT_poolshark.org galeon 2.0.0-2.fc5 denis_AT_poolshark.org gconfmm26 2.12.0-2 denis_AT_poolshark.org glibmm24 2.8.3-1 denis_AT_poolshark.org gnome-vfsmm26 2.12.0-1 denis_AT_poolshark.org gtkmm24 2.8.1-1 denis_AT_poolshark.org inkscape 0.43-1.fc5 denis_AT_poolshark.org libglademm24 2.6.1-2 denis_AT_poolshark.org libgnomecanvasmm26 2.12.0-2 denis_AT_poolshark.org libgnomemm26 2.12.1-1 denis_AT_poolshark.org libgnomeuimm26 2.12.0-2 denis_AT_poolshark.org libsigc++ 1.2.5-8 denis_AT_poolshark.org libsigc++20 2.0.16-2 dwmw2_AT_redhat.com exim 4.60-2.fc5 dwmw2_AT_redhat.com hfsplusutils 1.0.4-5 endur_AT_bennewitz.com streamtuner 0.99.99-11.fc5 enrico.scholz_AT_informatik.tu-chemnitz.de libtasn1 0.2.6-3 enrico.scholz_AT_informatik.tu-chemnitz.de util-vserver 0.30.210-1.fc5 extras-orphan_AT_fedoraproject.org abe 1.0-5 extras-orphan_AT_fedoraproject.org arc 5.21o-1.fc5 extras-orphan_AT_fedoraproject.org at-poke 0.2.2-2 extras-orphan_AT_fedoraproject.org camstream 0.26.3-8 extras-orphan_AT_fedoraproject.org cgoban 1.9.14-4 extras-orphan_AT_fedoraproject.org cksfv 1.3-4 extras-orphan_AT_fedoraproject.org duplicity 0.4.1-4 extras-orphan_AT_fedoraproject.org freedroidrpg 0.9.13-1.fc5 extras-orphan_AT_fedoraproject.org gnofract4d 2.6-3 extras-orphan_AT_fedoraproject.org gnome-telnet 2.5-5 extras-orphan_AT_fedoraproject.org gnugo 3.6-3 extras-orphan_AT_fedoraproject.org gurlchecker 0.6.3-5 extras-orphan_AT_fedoraproject.org libzvt 2.0.1-7 extras-orphan_AT_fedoraproject.org lua 5.0.2-5.fc5 extras-orphan_AT_fedoraproject.org manedit 0.5.11-5 extras-orphan_AT_fedoraproject.org mknbi 1.4.4-2 extras-orphan_AT_fedoraproject.org netdiag 2.4-7 extras-orphan_AT_fedoraproject.org nget 0.27.1-4 extras-orphan_AT_fedoraproject.org ots 0.4.2-7 extras-orphan_AT_fedoraproject.org parchive 1.1-4 extras-orphan_AT_fedoraproject.org prozilla 1.3.7.4-2.fc5 extras-orphan_AT_fedoraproject.org putty 0.58-1 extras-orphan_AT_fedoraproject.org sirius 0.8.0-5 extras-orphan_AT_fedoraproject.org tdl 1.5.2-3 extras-orphan_AT_fedoraproject.org tetex-lgrind 3.67-9.fc5 extras-orphan_AT_fedoraproject.org wbxml2 0.9.0-4 extras-orphan_AT_fedoraproject.org xmms-cdread 0.14-6.a extras-orphan_AT_fedoraproject.org xtide 2.8-4 fredrik_AT_dolda2000.com icmpdn 0.3-2 gemi_AT_bluewin.ch audacity 1.2.3-5 gemi_AT_bluewin.ch bigloo 2.7a-2.fc5 gemi_AT_bluewin.ch erlang R10B-8.3.fc5 gemi_AT_bluewin.ch lablgl 1.02-2.fc5 gemi_AT_bluewin.ch lablgtk 2.6.0-2.fc5 gemi_AT_bluewin.ch TeXmacs 1.0.5.12-2.fc5 gemi_AT_bluewin.ch unison 2.13.16-1.fc5 ghenry_AT_suretecsystems.com html-xml-utils 3.7-3.fc5 ghenry_AT_suretecsystems.com john 1.6-4 ghenry_AT_suretecsystems.com librsync 0.9.7-4 ghenry_AT_suretecsystems.com perl-Gnome2-Canvas 1.002-4.fc5 ghenry_AT_suretecsystems.com perl-Gtk2-GladeXML 1.005-4.fc5 ghenry_AT_suretecsystems.com perl-Imager 0.45-2.fc5 green_AT_redhat.com itext 1.3-1jpp_6.fc5 green_AT_redhat.com jakarta-commons-cli 1.0-6jpp_5.fc5 green_AT_redhat.com jogl 1.1.1-13.fc5 green_AT_redhat.com kawa 1.8-3.fc5 green_AT_redhat.com rssowl 1.2-10.fc5 grenier_AT_cgsecurity.org testdisk 6.2-3.fc5 i_AT_stingr.net pyflowtools 0.3-5.fc5 ivazquez_AT_ivazquez.net lock-keys-applet 1.0-9 ivazquez_AT_ivazquez.net sqlite2 2.8.16-2.fc5 jamatos_AT_fc.up.pt R-mAr 1.1-3.fc5 jcarpenter_AT_condell.org ks3switch 0.1-1.fc5 jcarpenter_AT_condell.org lrmi 0.9-2.fc5 jcarpenter_AT_condell.org s3switch 0.0-6.20020912 jcarpenter_AT_condell.org tpb 0.6.4-2.fc5 jcarpenter_AT_condell.org xosd 2.2.14-4.fc5 jdennis_AT_redhat.com cyrus-imapd 2.2.12-6.fc4 jeff_AT_ultimateevil.org up-imapproxy 1.2.4-4.fc5 jeff_AT_ultimateevil.org zile 2.2.4-2.fc5 jeff.gilchrist_AT_gmail.com pbzip2 0.9.5-1.fc5 jfontain_AT_free.fr blt 2.4-11.z jfontain_AT_free.fr tktable 2.9-2 jnovy_AT_redhat.com allegro 4.2.0-7 jnovy_AT_redhat.com cproto 4.7d-2 jnovy_AT_redhat.com nedit 5.5-6 joost_AT_cnoc.nl fpc 2.0.2-3.fc5 jpo_AT_di.uminho.pt libol 0.3.16-2.fc5 jpo_AT_di.uminho.pt perl-DBD-SQLite 1.11-1.fc5 jpo_AT_di.uminho.pt perl-Net-SSLeay 1.30-2.fc5 jspaleta_AT_gmail.com istanbul 0.1.1-5 jylitalo_AT_iki.fi python-imaging 1.1.4-9 jylitalo_AT_iki.fi xplanet 1.0.1-7 lemenkov_AT_newmail.ru chmlib 0.37.4-4.fc5 lemenkov_AT_newmail.ru fuse-encfs 1.2.5-1.fc5 lemenkov_AT_newmail.ru rlog 1.3.7-1.fc5 lemenkov_AT_newmail.ru wavpack 4.31-1.fc5 llch_AT_redhat.com libtabe 0.2.6-14 llch_AT_redhat.com xcin 2.5.3.pre3-27 lmacken_AT_redhat.com valknut 0.3.7-5.fc5 luya256_AT_yahoo.com gdesklets 0.35.3-2.fc5 matt_AT_truch.net cfitsio 3.005-0.1.beta.fc5 matt_AT_truch.net hpic 0.52-5.fc5 mattdm_AT_mattdm.org wxPythonGTK2 2.4.2.4-7 matthias_AT_rpmforge.net advancecomp 1.15-3.fc5 matthias_AT_rpmforge.net bbkeys 0.9.0-3.fc5 matthias_AT_rpmforge.net blackbox 0.70.1-3.fc5 matthias_AT_rpmforge.net boa 0.94.14-0.3.rc21.fc5 matthias_AT_rpmforge.net camE 1.9-5.fc5 matthias_AT_rpmforge.net csmash 0.6.6-11.fc5 matthias_AT_rpmforge.net d4x 2.5.6-1.fc5 matthias_AT_rpmforge.net diradmin 1.7.1-3.fc5 matthias_AT_rpmforge.net djvulibre 3.5.15-2.fc5 matthias_AT_rpmforge.net easytag 1.1-2.fc5 matthias_AT_rpmforge.net fillets-ng 0.7.3-2.fc5 matthias_AT_rpmforge.net gcombust 0.1.55-7 matthias_AT_rpmforge.net gentoo 0.11.55-2.fc5 matthias_AT_rpmforge.net giblib 1.2.4-5.fc5 matthias_AT_rpmforge.net gkrellm-aclock 0.3.3-3.fc5 matthias_AT_rpmforge.net gkrellm-freq 1.0-1.fc5 matthias_AT_rpmforge.net Gtk-Perl 0.7008-39.fc5 matthias_AT_rpmforge.net gtktalog 1.0.4-6.fc5 matthias_AT_rpmforge.net gtweakui 0.4.0-1.fc5 matthias_AT_rpmforge.net hackedbox 0.8.4-5.fc5 matthias_AT_rpmforge.net hercules 3.02-3 matthias_AT_rpmforge.net i8kutils 1.25-5.fc5 matthias_AT_rpmforge.net js 1.5-3.fc5 matthias_AT_rpmforge.net kannel 1.4.0-7.fc5 matthias_AT_rpmforge.net libcaca 0.9-9.fc5 matthias_AT_rpmforge.net liboil 0.3.6-1.fc5 matthias_AT_rpmforge.net lighttpd 1.4.10-1.fc5 matthias_AT_rpmforge.net linux_logo 4.13-1.fc5 matthias_AT_rpmforge.net lmarbles 1.0.7-4 matthias_AT_rpmforge.net metakit 2.4.9.5-1.fc5 matthias_AT_rpmforge.net ncftp 3.1.9-2.fc5 matthias_AT_rpmforge.net oidentd 2.0.7-8.fc5 matthias_AT_rpmforge.net p7zip 4.30-2.fc5 matthias_AT_rpmforge.net php-eaccelerator 5.0.4_0.9.3-3.fc5 matthias_AT_rpmforge.net php-pecl-mailparse 2.1.1-2.fc5 matthias_AT_rpmforge.net php-pecl-pdo 1.0.2-1.fc5 matthias_AT_rpmforge.net php-pecl-pdo-sqlite 0.3-3.fc5 matthias_AT_rpmforge.net plib16 1.6.0-4.fc5 matthias_AT_rpmforge.net plib 1.8.4-2.fc5 matthias_AT_rpmforge.net portaudio 18.1-6.fc5 matthias_AT_rpmforge.net powermanga 0.79-7.fc5 matthias_AT_rpmforge.net proftpd 1.3.0-0.1.rc3.fc5 matthias_AT_rpmforge.net rrdtool 1.0.49-5.fc4 matthias_AT_rpmforge.net SDL_gfx 2.0.13-3.fc5 matthias_AT_rpmforge.net starfighter 1.1-6.fc5 matthias_AT_rpmforge.net synergy 1.2.7-1.fc5 matthias_AT_rpmforge.net thttpd 2.25b-9.fc5 matthias_AT_rpmforge.net torcs 1.2.4-1.fc5 matthias_AT_rpmforge.net ucarp 1.1-4.fc5 matthias_AT_rpmforge.net udftools 1.0.0b3-4.fc5 matthias_AT_rpmforge.net viruskiller 0.9-6.fc5 matthias_AT_rpmforge.net xvattr 1.3-8.fc5 matthias_AT_rpmforge.net yasm 0.4.0-5.fc5 matthias_AT_rpmforge.net zziplib 0.13.45-1.fc5 mccann0011_AT_hotmail.com geos 2.2.1-3.fc5 mccann0011_AT_hotmail.com proj 4.4.9-1.fc5 meme_AT_daughtersoftiresias.org nethack-vultures 1.11.2-4.fc5 mfleming+rpm_AT_enlartenment.com mlmmj 1.2.11-2.fc5 mfleming+rpm_AT_enlartenment.com mod_security 1.9.2-2.fc5 michel.salim_AT_gmail.com gai 0.5.10-5.fc5 michel.salim_AT_gmail.com gai-pal 0.7-7 michel.salim_AT_gmail.com grhino 0.15.0-3.fc5 michel.salim_AT_gmail.com quarry 0.1.16-1.fc5 mihai_AT_xcyb.org htb-util 0.2.4-0.4.pre1 nhorman_AT_redhat.com iozone 3-1 nos_AT_utelsystems.com dillo 0.8.4-3 nos_AT_utelsystems.com gktools 0.9.1-3 nos_AT_utelsystems.com gtkterm 0.99.4-4 nos_AT_utelsystems.com neverball 1.4.0-4 nos_AT_utelsystems.com whowatch 1.6.0-1 oliver.andrich_AT_gmail.com ruby-mysql 2.7-6.fc5 oliver_AT_linux-kernel.at fish 1.12.0-1.fc5 oliver_AT_linux-kernel.at libdnet 1.10-2.fc5 orion_AT_cora.nwra.com kompose 0.5.3-4.fc5 orion_AT_cora.nwra.com perl-Net-IP-CMatch 0.02-2.fc5 orion_AT_cora.nwra.com perl-Net-Patricia 1.014-1.fc5 orion_AT_cora.nwra.com python-basemap 0.7.2.1-1.fc5 orion_AT_cora.nwra.com python-matplotlib 0.86-1.fc5 otaylor_AT_redhat.com libuninameslist 0.0-4.040707 paul_AT_xtdnet.nl fetchlog 1.0-2.fc5 paul_AT_xtdnet.nl l2tpd 0.69-0.2.20051030.fc5 pawsa_AT_theochem.kth.se balsa 2.3.10-1.fc5 pawsa_AT_theochem.kth.se libesmtp 1.0.3r1-7.fc5 pertusus_AT_free.fr libdap 3.5.3-2.fc5 pertusus_AT_free.fr libnc-dap 3.5.2-5.fc5 petersen_AT_redhat.com darcs 1.0.5-1.fc5 petersen_AT_redhat.com FreeWnn 1.10pl020-6.fc5 petersen_AT_redhat.com ghc 6.4.1-2.fc5 petersen_AT_redhat.com haddock 0.7-1.fc5 petersen_AT_redhat.com scim-fcitx 3.1.1-3.fc5 pvrabec_AT_redhat.com licq 1.3.2-4 rc040203_AT_freenet.de lib3ds 1.2.0-6.fc5 rc040203_AT_freenet.de SIMVoleon 2.0.1-2.fc5 rdieter_AT_math.unl.edu akode 2.0-1.fc5 rdieter_AT_math.unl.edu apollon 1.0.1-4.fc5.1 rdieter_AT_math.unl.edu dxpc 3.8.2-3.fc5.1 rdieter_AT_math.unl.edu factory 2.0.5-6 rdieter_AT_math.unl.edu gc 6.6-5.fc5 rdieter_AT_math.unl.edu geomview 1.8.2-0.2.cvs20040221.fc5.2 rdieter_AT_math.unl.edu gift 0.11.8.1-4.fc5.1 rdieter_AT_math.unl.edu gift-openft 0.2.1.6-2.fc5.1 rdieter_AT_math.unl.edu gpa 0.7.0-4 rdieter_AT_math.unl.edu gpgme 1.1.0-3.fc5.1 rdieter_AT_math.unl.edu gsview 4.7-5.fc5.1 rdieter_AT_math.unl.edu gtk-qt-engine 0.60-7.fc5.1 rdieter_AT_math.unl.edu jasper 1.701.0-9.fc5.1 rdieter_AT_math.unl.edu kasablanca 0.4.0.2-7.fc5.2 rdieter_AT_math.unl.edu kdocker 1.3-4.fc5.3 rdieter_AT_math.unl.edu kickpim 0.5.3-9.fc5.2 rdieter_AT_math.unl.edu kile 1.8.1-7.fc5.1 rdieter_AT_math.unl.edu kimdaba 2.1-6.fc5.1 rdieter_AT_math.unl.edu kiosktool 1.0-5.fc5.1 rdieter_AT_math.unl.edu kipi-plugins 0.1.0-0.2.rc1.fc5 rdieter_AT_math.unl.edu kxdocker 0.39-3.fc5.1 rdieter_AT_math.unl.edu libassuan 0.6.10-2.fc5.1 rdieter_AT_math.unl.edu libfac 2.0.5-3 rdieter_AT_math.unl.edu libksba 0.9.13-2.fc5.1 rdieter_AT_math.unl.edu libsigsegv 2.2-1.fc5.1 rdieter_AT_math.unl.edu libtunepimp 0.4.0-5.fc5.1 rdieter_AT_math.unl.edu lyx 1.3.6-3.fc5 rdieter_AT_math.unl.edu Macaulay2 0.9.2-17.fc4 rdieter_AT_math.unl.edu maxima 5.9.2-9.fc5 rdieter_AT_math.unl.edu openslp 1.2.1-4.fc5.1 rdieter_AT_math.unl.edu pinentry 0.7.2-1.fc5.1 rdieter_AT_math.unl.edu sbcl 0.9.9-1.fc5.2 rdieter_AT_math.unl.edu tidy 0.99.0-9.20051025.fc5.1 rdieter_AT_math.unl.edu uw-imap 2004g-4.fc5.1 rdieter_AT_math.unl.edu xforms 1.0.90-6.fc5.1 redhat_AT_flyn.org pam_mount 0.9.25-4 roland_AT_redhat.com monotone 0.25-2.fc5 rolandd_AT_cisco.com libmthca 1.0-0.3.rc5.fc5 ryo-dairiki_AT_users.sourceforge.net scim-input-pad 0.1.1-3.fc5 ryo-dairiki_AT_users.sourceforge.net scim-skk 0.5.2-3.fc5 ryo-dairiki_AT_users.sourceforge.net scim-tomoe 0.1.0-3.fc5 ryo-dairiki_AT_users.sourceforge.net tomoe 0.2.1-3.fc5 shahms_AT_shahms.com python-psycopg 1.1.21-1.fc5 skvidal_AT_phy.duke.edu mock 0.4-5.fc5 steve_AT_silug.org perl-DateTime 0.2901-2.fc5 steve_AT_silug.org tuxpaint 0.9.13-3 tagoh_AT_redhat.com Canna 3.7p3-14.fc5 tagoh_AT_redhat.com kakasi 2.3.4-20 tagoh_AT_redhat.com kinput2 v3.1-26.fc5 tagoh_AT_redhat.com mew 4.2-1 tagoh_AT_redhat.com namazu 2.0.14-3 tagoh_AT_redhat.com paps 0.6.3-1.fc5 tagoh_AT_redhat.com perl-Text-Kakasi 2.04-1 tagoh_AT_redhat.com uim 1.0.1-1.fc5 tagoh_AT_redhat.com w3m-el 1.4.4-1 tcallawa_AT_redhat.com alsamixergui 0.9.0-0.2.rc1.fc5 tcallawa_AT_redhat.com blacs 1.1-18.fc5 tcallawa_AT_redhat.com c-ares 1.3.0-1.fc5 tcallawa_AT_redhat.com check 0.9.3-3.fc5 tcallawa_AT_redhat.com comical 0.7-1.fc5 tcallawa_AT_redhat.com compat-wxGTK 2.4.2-16.fc5 tcallawa_AT_redhat.com gambas 1.0.13-2.fc5 tcallawa_AT_redhat.com gxemul 0.3.7-1.fc5 tcallawa_AT_redhat.com jam 2.5-2.fc5 tcallawa_AT_redhat.com lapack 3.0-36.fc5 tcallawa_AT_redhat.com libgdamm 1.3.7-2.fc5 tcallawa_AT_redhat.com libmcrypt 2.5.7-2.fc5 tcallawa_AT_redhat.com librx 1.5-5 tcallawa_AT_redhat.com lincity-ng 1.0.2-2.fc5 tcallawa_AT_redhat.com logjam 4.5.1-5.fc5 tcallawa_AT_redhat.com mcrypt 2.6.4-1.fc5 tcallawa_AT_redhat.com mfstools 2.0-8.snapshot050221.fc5 tcallawa_AT_redhat.com netgo 0.5-3.fc5 tcallawa_AT_redhat.com perl-Clone 0.18-2.fc5 tcallawa_AT_redhat.com perl-DBD-SQLite2 0.33-4.fc5 tcallawa_AT_redhat.com perl-Template-Toolkit 2.14-5.fc5 tcallawa_AT_redhat.com perl-version 0.51-3.fc5 tcallawa_AT_redhat.com physfs 1.0.1-2.fc5 tcallawa_AT_redhat.com QuantLib 0.3.11-3.fc5 tcallawa_AT_redhat.com R 2.2.1-3.fc5 tcallawa_AT_redhat.com rekall 2.2.4-8.fc5 tcallawa_AT_redhat.com R-gnomeGUI 2.1.0-4 tcallawa_AT_redhat.com rocksndiamonds 3.1.1-2.fc5 tcallawa_AT_redhat.com rootsh 1.5.2-2.fc5 tcallawa_AT_redhat.com scalapack 1.7-7.fc4 tcallawa_AT_redhat.com udunits 1.12.4-9.fc5 tcallawa_AT_redhat.com wlassistant 0.5.4a-3.fc5 tcallawa_AT_redhat.com xbase 2.0.0-3.fc5 tcallawa_AT_redhat.com xbsql 0.11-5.fc5 tcallawa_AT_redhat.com xkeycaps 2.46-3.fc5 tcallawa_AT_redhat.com xsupplicant 1.2.2-7.fc5 thomas_AT_apestaart.org directfb 0.9.24-4.fc5 thomas_AT_apestaart.org flumotion 0.1.8-1 thomas_AT_apestaart.org gstreamer08-python 0.8.3-1.fc5 thomas_AT_apestaart.org gstreamer-python 0.10.2-1.fc5 thomas_AT_apestaart.org Hermes 1.3.3-7 thomas_AT_apestaart.org ladspa 1.12-5 thomas_AT_apestaart.org libannodex 0.7.2-1.fc5 thomas_AT_apestaart.org libcmml 0.9.0-2.fc5 thomas_AT_apestaart.org liboggz 0.9.3-2.fc5 thomas_AT_apestaart.org libshout 1.0.9-4 thomas_AT_apestaart.org mach 0.4.8-1.fc5 thomas_AT_apestaart.org mod_annodex 0.2.2-2.fc5 thomas_AT_apestaart.org python-twisted 1.3.0-4 toniw_AT_iki.fi silky 0.5.4-1 tripwire-devel_AT_genesis-x.nildram.co.uk tripwire 2.3.1-22 ville.skytta_AT_iki.fi hddtemp 0.3-0.7.beta14.fc5 ville.skytta_AT_iki.fi xemacs 21.4.18-2.fc5 wtogami_AT_redhat.com bonnie++ 1.03a-4 wtogami_AT_redhat.com lvcool 1.0.0-3 wtogami_AT_redhat.com perl-Digest-Nilsimsa 0.06-5 wtogami_AT_redhat.com perl-Razor-Agent 2.77-2.fc5 -- Thorsten Leemhuis From jwboyer at jdub.homelinux.org Sun Feb 26 17:35:57 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 26 Feb 2006 12:35:57 -0500 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140978146.18127.112.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <1140975357.32357.20.camel@yoda.jdub.homelinux.org> On Sun, 2006-02-26 at 19:22 +0100, Thorsten Leemhuis wrote: > Hi all! > > Replies to fedora-extras-list please to avoid confusion. > > Small update: > > Anyway, here a complete list of packages that still need a rebuild. It > is also in the wiki now at > http://www.fedoraproject.org/wiki/Extras/FC5Status > > > If there is a good reason why the package is not yet rebuild please add > a short note to the page. tia > chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 Erm.. I think your script is slightly broken. git-core has been rebuilt quite a bit because upstream releases a new version about once a week :) [jwboyer at yoda ~]$ rpm -q git-core git-core-1.2.2-1.fc5 [jwboyer at yoda ~]$ On a side note, I've been debugging a build error for tla on PPC. It looks like it might be a glibc problem at the moment related to the recent ABI change. If it is, it may required another respin of core. I'm not quite sure about that yet, since Jakub hasn't had a chance to look at the bug. Just an FYI. josh From fedora at leemhuis.info Sun Feb 26 18:54:08 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sun, 26 Feb 2006 19:54:08 +0100 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140975357.32357.20.camel@yoda.jdub.homelinux.org> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1140975357.32357.20.camel@yoda.jdub.homelinux.org> Message-ID: <1140980049.18825.1.camel@localhost.localdomain> Am Sonntag, den 26.02.2006, 12:35 -0500 schrieb Josh Boyer: > On Sun, 2006-02-26 at 19:22 +0100, Thorsten Leemhuis wrote: > > Hi all! > > > > Replies to fedora-extras-list please to avoid confusion. > > > > Small update: > > > > Anyway, here a complete list of packages that still need a rebuild. It > > is also in the wiki now at > > http://www.fedoraproject.org/wiki/Extras/FC5Status > > > > > > If there is a good reason why the package is not yet rebuild please add > > a short note to the page. tia > > > chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 > > Erm.. I think your script is slightly broken. git-core has been rebuilt > quite a bit because upstream releases a new version about once a week :) > > [jwboyer at yoda ~]$ rpm -q git-core > git-core-1.2.2-1.fc5 > [jwboyer at yoda ~]$ Yep, it didn't catch this one because it was renamed -- git-core is still at http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-core-0.99.9a-2.fc5.src.rpm and the script does not check that it is obsoleted by http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-1.2.3-1.fc5.src.rpm git-core-*.fc5.src.rpm probably should be removed. It not only confuses my script, it is also useless afaics -- correct me if I'm wrong. BTW, the latest version of the script attached. -- Thorsten Leemhuis -------------- next part -------------- A non-text attachment was scrubbed... Name: buildcheck Type: application/x-shellscript Size: 1906 bytes Desc: not available URL: From jspaleta at gmail.com Sun Feb 26 19:28:35 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 26 Feb 2006 14:28:35 -0500 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140978146.18127.112.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> Message-ID: <604aa7910602261128l18c821baj4c8dd15f1037559@mail.gmail.com> On 2/26/06, Thorsten Leemhuis wrote: > If there is a good reason why the package is not yet rebuild please add > a short note to the page. tia > jspaleta_AT_gmail.com istanbul 0.1.1-5 Dependancy issues... which i do not think will get resolved in time for 5c5 release. 1)gst08 was pulled out of Core and needs to get into Extras 2)ditto for gst08-plugins 3)gstream08-python has a 64bit specific problem that I don't have the hardware available to diagnose or patch myself... and which is made moot by the larger issues of (1) and (2) 4)upstream will have a cvs version which is gst 0.10 pure very very soon which I am keen on moving over to as soon as possible 5)the current version of gst 0.10 in rawhide doesn't have the necessary bits for the istanbul cvs to be able to operate against... the next gst 0.10 release will have it which I expect will be an update to fc5. 6)istanbul is not published for fc4 and is only currently available in extras-development. Considering the timing of the gst08 removal from Core and the the fact that istanbul has no "release" versions that need to be worried about... I am not very interested in expending personal time cleaning up the dependancies to get istanbul against gst08 out the dore for fc5 release. Especially since i'm pretty confident I can get an istanbul gst 0.10 based release out in short order after fc5 release, once there is a gst update. Personally... instead of being told repeatedly that I need to rebuild this when I know I can not because of gst08 dep transition.. I'd prefer if you just pulled the binary from the extras-development tree for now until i can get instabul built against gst 0.10. I'm not overly concerned about getting this built for gst08, in fact I'm dis-interested in trying to do it at all. The only reason I continue to keep the related bugreports open is because other people seem to be interested and seem to be under the fantasy that the gst08 transfer is going to happen in time for fc5 release. Given the late date as to when it was dropped in Core, I have no such delusion as to expect the gst08 dep chain to be sorted out in time. I'm going to be moving istanbul over to gst 0.10 asap anyways so any work done now to get the gst08 one in a released tree is basically a deadend anyways. -jef From jwboyer at jdub.homelinux.org Sun Feb 26 18:53:30 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Sun, 26 Feb 2006 13:53:30 -0500 Subject: Rebuild status of FE5 (Was: Re: Please rebuild your packages in the development tree of Fedora Extras) In-Reply-To: <1140980049.18825.1.camel@localhost.localdomain> References: <1139851362.2904.79.camel@localhost.localdomain> <1140205892.2904.30.camel@localhost.localdomain> <1140541669.2144.30.camel@localhost.localdomain> <1140978146.18127.112.camel@localhost.localdomain> <1140975357.32357.20.camel@yoda.jdub.homelinux.org> <1140980049.18825.1.camel@localhost.localdomain> Message-ID: <1140980010.32357.23.camel@yoda.jdub.homelinux.org> On Sun, 2006-02-26 at 19:54 +0100, Thorsten Leemhuis wrote: > Am Sonntag, den 26.02.2006, 12:35 -0500 schrieb Josh Boyer: > > > > > > > > > If there is a good reason why the package is not yet rebuild please add > > > a short note to the page. tia > > > > > chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 > > > > Erm.. I think your script is slightly broken. git-core has been rebuilt > > quite a bit because upstream releases a new version about once a week :) > > > > [jwboyer at yoda ~]$ rpm -q git-core > > git-core-1.2.2-1.fc5 > > [jwboyer at yoda ~]$ > > Yep, it didn't catch this one because it was renamed -- git-core is > still at > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-core-0.99.9a-2.fc5.src.rpm > and the script does not check that it is obsoleted by > http://download.fedora.redhat.com/pub/fedora/linux/extras/development/SRPMS/git-1.2.3-1.fc5.src.rpm > > git-core-*.fc5.src.rpm probably should be removed. It not only confuses > my script, it is also useless afaics -- correct me if I'm wrong. You're correct. I forgot that the package was renamed. The SRPM for the old package should indeed be removed. josh From nicolas.mailhot at laposte.net Sun Feb 26 22:58:45 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 26 Feb 2006 23:58:45 +0100 Subject: zoo contains exploitable buffer overflows Message-ID: <1140994725.2876.8.camel@rousalka.dyndns.org> Hi, Since the Fedora Extras security SIG does not exist yet I'll do a maintainers post. As the FE zoo maintainer I've applied the security patch suggested on https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183109 I'm not sure the security analysis here is right, but since the patch seems harmless and zoo is exposed to external input via mail filters such as amavisd-new I preferred to err on the side of caution. If some people could review the alert and the patch I'd be grateful. To my knowledge other distributions have not acted on the alert yet (it's been published on many security lists in the last days). Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From bressers at redhat.com Mon Feb 27 00:09:31 2006 From: bressers at redhat.com (Josh Bressers) Date: Sun, 26 Feb 2006 19:09:31 -0500 Subject: zoo contains exploitable buffer overflows In-Reply-To: Your message of "Sun, 26 Feb 2006 23:58:45 +0100." <1140994725.2876.8.camel@rousalka.dyndns.org> Message-ID: <200602270009.k1R09VoG002970@devserv.devel.redhat.com> > > As the FE zoo maintainer I've applied the security patch suggested on=20 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D183109 > > I'm not sure the security analysis here is right, but since the patch > seems harmless and zoo is exposed to external input via mail filters > such as amavisd-new I preferred to err on the side of caution. The issue seems to exist. You can get cause zoo to segfault upon archive creation (this is a new and different issue) by creating a very long directory path. mkdir `perl -e 'print "A"x254'` cd `perl -e 'print "A"x254'` mkdir `perl -e 'print "A"x254'` cd `perl -e 'print "A"x254'` touch feh cd ../.. zoo a arch.zoo `perl -e 'print "A"x254 . "/" . "A"x254 . "/feh"'` This causes zoo to crash here: void parse (path_st, fname) register struct path_st *path_st; char *fname; { char tempname[LFNAMESIZE]; /* working copy of supplied fname */ char *namep; /* points to relevant part of tempname */ char *p; strcpy (tempname, fname); <== Buffer overflow This points out that zoo is a very poorly written program. Luckily with the new changes to gcc and glibc, these horrible stack buffer overflows are non issues. Run the above commands, you'll see on FC5 it doesn't crash, libc catches it. > If some people could review the alert and the patch I'd be grateful. > To my knowledge other distributions have not acted on the alert yet > (it's been published on many security lists in the last days). The patch attached to the mail (in bugzilla) looks pretty hokey. I would either malloc however much space is needed, or verify the path won't overflow the static space. Adding more space to a static buffer doesn't help, it should still be possible to overflow the buffer. The only good way to fix this I can see is modify the combine() function to either accept a maximum string length, or malloc the space itself. If you pass a length to combine(), you have the issue of uncleanly exiting. The code I see has no nice way to report potential errors, which means you'll have to exit() inside combine(), which will leave things in an unknown state. Fixing zoo is probably never going to happen, this is just one of the things that is horribly broken by design. From my quick look through the source, it's pretty bad. There are going to be countless similar problems -- JB From j.w.r.degoede at hhs.nl Mon Feb 27 08:25:33 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 09:25:33 +0100 Subject: zoo contains exploitable buffer overflows In-Reply-To: <200602270009.k1R09VoG002970@devserv.devel.redhat.com> References: <200602270009.k1R09VoG002970@devserv.devel.redhat.com> Message-ID: <4402B77D.4040108@hhs.nl> Josh Bressers wrote: >> As the FE zoo maintainer I've applied the security patch suggested on=20 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D183109 >> >> I'm not sure the security analysis here is right, but since the patch >> seems harmless and zoo is exposed to external input via mail filters >> such as amavisd-new I preferred to err on the side of caution. > > The issue seems to exist. You can get cause zoo to segfault upon archive > creation (this is a new and different issue) by creating a very long > directory path. > > mkdir `perl -e 'print "A"x254'` > cd `perl -e 'print "A"x254'` > mkdir `perl -e 'print "A"x254'` > cd `perl -e 'print "A"x254'` > touch feh > cd ../.. > zoo a arch.zoo `perl -e 'print "A"x254 . "/" . "A"x254 . "/feh"'` > > This causes zoo to crash here: > > void parse (path_st, fname) > register struct path_st *path_st; > char *fname; > { > char tempname[LFNAMESIZE]; /* working copy of supplied fname */ > char *namep; /* points to relevant part of tempname */ > > char *p; > strcpy (tempname, fname); <== Buffer overflow > > This points out that zoo is a very poorly written program. Luckily with > the new changes to gcc and glibc, these horrible stack buffer overflows are > non issues. Run the above commands, you'll see on FC5 it doesn't crash, > libc catches it. > > >> If some people could review the alert and the patch I'd be grateful. >> To my knowledge other distributions have not acted on the alert yet >> (it's been published on many security lists in the last days). > > The patch attached to the mail (in bugzilla) looks pretty hokey. I would > either malloc however much space is needed, or verify the path won't > overflow the static space. Adding more space to a static buffer doesn't > help, it should still be possible to overflow the buffer. The only good > way to fix this I can see is modify the combine() function to either accept > a maximum string length, or malloc the space itself. > > If you pass a length to combine(), you have the issue of uncleanly exiting. > The code I see has no nice way to report potential errors, which means > you'll have to exit() inside combine(), which will leave things in an > unknown state. > > Fixing zoo is probably never going to happen, this is just one of the > things that is horribly broken by design. From my quick look through the > source, it's pretty bad. There are going to be countless similar problems > Please add this to the relevant bugzilla entry for tracking. Thanks, Hans From arjan at fenrus.demon.nl Mon Feb 27 08:46:15 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 27 Feb 2006 09:46:15 +0100 Subject: zoo contains exploitable buffer overflows In-Reply-To: <200602270009.k1R09VoG002970@devserv.devel.redhat.com> References: <200602270009.k1R09VoG002970@devserv.devel.redhat.com> Message-ID: <1141029976.2992.73.camel@laptopd505.fenrus.org> On Sun, 2006-02-26 at 19:09 -0500, Josh Bressers wrote: > > > > As the FE zoo maintainer I've applied the security patch suggested on=20 > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D183109 > > > > I'm not sure the security analysis here is right, but since the patch > > seems harmless and zoo is exposed to external input via mail filters > > such as amavisd-new I preferred to err on the side of caution. > > The issue seems to exist. You can get cause zoo to segfault upon archive > creation (this is a new and different issue) by creating a very long > directory path. > > mkdir `perl -e 'print "A"x254'` > cd `perl -e 'print "A"x254'` > mkdir `perl -e 'print "A"x254'` > cd `perl -e 'print "A"x254'` > touch feh > cd ../.. > zoo a arch.zoo `perl -e 'print "A"x254 . "/" . "A"x254 . "/feh"'` > > This causes zoo to crash here: > > void parse (path_st, fname) > register struct path_st *path_st; > char *fname; > { > char tempname[LFNAMESIZE]; /* working copy of supplied fname */ > char *namep; /* points to relevant part of tempname */ > > char *p; > strcpy (tempname, fname); <== Buffer overflow > > This points out that zoo is a very poorly written program. Luckily with > the new changes to gcc and glibc, these horrible stack buffer overflows are > non issues. Run the above commands, you'll see on FC5 it doesn't crash, > libc catches it. not just FC5; FORTIFY_SOURCE ought to have caught this one as well in FC4 (and even in FC3 if you enabled it there) From nicolas.mailhot at laposte.net Mon Feb 27 09:12:15 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 27 Feb 2006 10:12:15 +0100 (CET) Subject: zoo contains exploitable buffer overflows In-Reply-To: <200602270009.k1R09VoG002970@devserv.devel.redhat.com> References: Your message of "Sun, 26 Feb 2006 23:58:45 +0100." <1140994725.2876.8.camel@rousalka.dyndns.org> <200602270009.k1R09VoG002970@devserv.devel.redhat.com> Message-ID: <58555.192.54.193.25.1141031535.squirrel@rousalka.dyndns.org> Le Lun 27 f?vrier 2006 01:09, Josh Bressers a ?crit : >> >> As the FE zoo maintainer I've applied the security patch suggested on=20 >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D183109 > The issue seems to exist. ... > This points out that zoo is a very poorly written program. Luckily with > the new changes to gcc and glibc, these horrible stack buffer overflows > are non issues. >> If some people could review the alert and the patch I'd be grateful. >> To my knowledge other distributions have not acted on the alert yet >> (it's been published on many security lists in the last days). > > The patch attached to the mail (in bugzilla) looks pretty hokey. ... > Fixing zoo is probably never going to happen, this is just one of the > things that is horribly broken by design. From my quick look through the > source, it's pretty bad. There are going to be countless similar problems I mostly agree with all these assesments (that's one reason I started this thread). I was never very confortable with zoo given it has no upstream anymore, but since everyone seems to ship it anyway I figured someone must have checked the code. What is the general feeling on the list? 1. apply the patch (or a cleaner one if someone writes one - not me my C is much too rusty) and trust other problems will be caught by glibc? 2. do not apply the patch, trust glibc to catch problems? 3. pull zoo from FE, instruct current users like amavisd-new to kill zoo files on sight instead of trying to check them, make them conflict with zoo to make sure it's removed from user systems? 4. a mix of all this, depending on the FE version? Regards, -- Nicolas Mailhot From j.w.r.degoede at hhs.nl Mon Feb 27 10:06:07 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Mon, 27 Feb 2006 11:06:07 +0100 Subject: zoo contains exploitable buffer overflows In-Reply-To: <58555.192.54.193.25.1141031535.squirrel@rousalka.dyndns.org> References: Your message of "Sun, 26 Feb 2006 23:58:45 +0100." <1140994725.2876.8.camel@rousalka.dyndns.org> <200602270009.k1R09VoG002970@devserv.devel.redhat.com> <58555.192.54.193.25.1141031535.squirrel@rousalka.dyndns.org> Message-ID: <4402CF0F.6060206@hhs.nl> Nicolas Mailhot wrote: > > What is the general feeling on the list? > > 1. apply the patch (or a cleaner one if someone writes one - not me my C > is much too rusty) and trust other problems will be caught by glibc? > > 2. do not apply the patch, trust glibc to catch problems? > I would rather not trust glibc, it might very well do its job, but I would rather just see the code fixed. > 3. pull zoo from FE, instruct current users like amavisd-new to kill zoo > files on sight instead of trying to check them, make them conflict with > zoo to make sure it's removed from user systems? > > 4. a mix of all this, depending on the FE version? > Hmm, dunno. What about: 5. Get someone todo a proper audit (how big is it anyways, I recently completed an audit of scorched3d which is huge). 6. Find a replacement: I've been thinking about packaging http://sourceforge.net/projects/sevenzip Recently as that will give us opensource support for arj, rar and cab all in one utility, I dunno if it supports zoo format too, it does support lots of other formats. Regards, Hans From arjan at fenrus.demon.nl Mon Feb 27 09:58:50 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 27 Feb 2006 10:58:50 +0100 Subject: zoo contains exploitable buffer overflows In-Reply-To: <58555.192.54.193.25.1141031535.squirrel@rousalka.dyndns.org> References: Your message of "Sun, 26 Feb 2006 23:58:45 +0100." <1140994725.2876.8.camel@rousalka.dyndns.org> <200602270009.k1R09VoG002970@devserv.devel.redhat.com> <58555.192.54.193.25.1141031535.squirrel@rousalka.dyndns.org> Message-ID: <1141034330.2992.86.camel@laptopd505.fenrus.org> > > 1. apply the patch (or a cleaner one if someone writes one - not me my C > is much too rusty) and trust other problems will be caught by glibc? well first of all make 100% sure that -fstack-protector-all is used in the CFLAGS, as well as -D__FORTIFY_SOURCE=2. The later works from FC3 onwards, the former only in FC5. > > 2. do not apply the patch, trust glibc to catch problems? fixing bugs is better than catching them with a crash. Always. From kwade at redhat.com Mon Feb 27 19:34:26 2006 From: kwade at redhat.com (Karsten Wade) Date: Mon, 27 Feb 2006 11:34:26 -0800 Subject: [Fwd: [ANN] Last call for release notes to go into ISO] Message-ID: <1141068866.17062.64.camel@erato.phig.org> FYI, in case you miss this in the devel list noise. -------- Forwarded Message -------- From: Karsten Wade Reply-To: Development discussions related to Fedora Core To: fedora-devel-list at redhat.com Subject: [ANN] Last call for release notes to go into ISO Date: Mon, 27 Feb 2006 11:31:54 -0800 We are in the final four hours before freezing the release notes content from the Wiki to move it out for translation. There is still a 08 March 2006 deadline for content that goes into the Web-published latest notes. You can review your area(s) of interest here: http://fedoraproject.org/wiki/Docs/Beats Edit the Wiki directly. Drop by #fedora-websites if you have any problems getting your account working again, remember that you need to have signed your CLA before you can be in the EditGroup (again). Thanks - Karsten -- fedora-devel-list mailing list fedora-devel-list at redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: