Debian Day @ LinuxTag 2005 / and additional talks
Debian Day @ LinuxTag 2005 / and additional talks - I'm happy to announce (even though I should have done this one week ago already) the schedule for the Debian Day, the mini-conference of the Debian project traditionally held during LinuxTag. It will take place on Thursday, 23rd of June during this year's LinuxTag in Karlsruhe, Germany. The talks will describe certain parts of the distribution or the project and will be held in English. Thursday, June 23rd, 2005, Room 2.05 Time | Speaker Title --+- 10:00 | Norbert Tretkowski: Backporting Practice 11:00 | Joey Schulze: Debian Security 12:00 | Luk Claes:Internationalisation localisation 13:00 | Goswin von Brederlow: Debian Archive Structure 14:00 | Martin Zobel-Helas: The volatile Archive 15:00 | Meike Reichle:The Debian Women Project 16:00 | Andreas Tille:CDD: Current and Future 17:00 | Jörg Jaspert: Bootable multi-arch CDs Due to the large number of talks submitted and interesting topics we have decided to extended the Debian day by another day. Hence, part two will take place on Friday, 24th of June. Friday, June 24th, 2005, Room 2.05 Time | Speaker Title --+- 12:00 | Yutaka Niibe: Porting to m32r Architecture 13:00 | Mike Wiesner: Kerberos V5 mit Debian 14:00 | Stefano Zacchiroli: OCaml @ Debian 15:00 | Andreas Tille:Knowledge, Power and free Beer 16:00 | Hauke Goos-Habermann: m23 Distribution System 17:00 | Michael Banck:The Ubuntu Development Model In addition to these talks, we'd like to add another list of talks that have a connection to the Debian distribution or the Debian project, in addition to the keysigning party. Some of these may also be of interest for visitors who are interested in ongoings of Debian. Only some of these talks will be held in English. Wednesday, June 22nd, 2005 10:00 Fabian Franz: Einführung in Knoppix (EG Weinbrenner) Thursday, June 23rd, 2005 13:30 Florian Schießl: Linux in München (UG2 Mombert) 17:00 Alexander Schmehl:Neues in Debian Sarge (EG Forum) Friday, June 24th, 2005 12:00 Fernanda Weiden: Free Software with a female touch (UG2 Mombert) 16:00 Mako Hill:Strategies in Financing (UG2 Mombert) 17:00 Fabian Franz: Einführung in Knoppix (Practical Linux Forum) Saturday, June 25th, 2005 14:00 Peter Palfrader: Key Signing Party (R 2.05) 15:00 Debian Developers*: Debian Projekt intern (UG3 Hebel) 16:00 Alexander Schmehl:Paybacktime (EG Forum) 17:00 Mako Hill:Debian and Ubuntu (UG3 Hebel) 17:00 Michael Kofler: Ubuntu - Das menschliche Linux (EG Weinbrenner) 17:00 Gregorio Robles: Quo vadis, libre software? (UG3 Hebel) * Jörg Jaspert, Frank Lichtenheld, Andreas Barth, Joey Schulze For more information, please check the Debian day page at http://www.infodrom.org/Debian/events/LinuxTag2005/day.html For locating the conference rooms, please see the building overview: http://www.infodrom.org/Debian/events/LinuxTag2005/conference.html In addition to this hopefully overwhelming conference program the Debian project will maintainer a booth in the exhibition area. The new sarge release will be demonstrated at the booth. -- Reading is a lost art nowadays. -- Michael Weber signature.asc Description: Digital signature
Re: Release update: minor delay; no non-RC fixes; upgrade reports
On Mon, May 30, 2005 at 10:21:45AM -0700, Russ Allbery wrote: Roger Leigh [EMAIL PROTECTED] writes: That's still requiring /manual intervention/, and lying about the true state of the bug to the BTS. Ideally the BTS should understand that the bug was closed by a particular version of the package (the one which had Closes: in it), and the bug is still present in earlier versions (perhaps it should also have the ability to record the version the bug appeared in as well). The BTS should be able to know that a bug is closed in testing automatically, rather than me sending messages to [EMAIL PROTECTED]; I must have sent at least 30 the past week alone. Agreed; I'd really like to see this as well. Another somewhat related matter that's bothered me for a while is that right now the Debian bug tracking system is not particularly useful for users of the stable version. The BTS is not likely to have much sign of most of their bugs, the maintainers have to carry around stable-tagged bugs (that then may show up as RC bugs in various summary reports) in order to document stable issues that are already fixed in unstable or testing, and the whole situation seems a bit confusing to what we would anticipate is the average Debian user (someone who uses stable). I'm not sure what the best fix is. Obviously, most bugs can't be fixed for stable -- even a lot of RC bugs are questionable to fix for stable once it's actually released. It would still be nice to give the user the known information about a bug they're running into, including any workarounds that had been found. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ Hi Russ, maybe use the wiki -- SargeKnowIssuesAndFixes page? -Kev -- counter.li.org #238656 -- goto counter.li.org and be counted! `$' $' $ $ _ ,d$$$g$ ,d$$$b. $,d$$$b`$' g$b $,d$$b ,$P' `$ ,$P' `Y$ $$' `$ $ ' `$ $$' `$ $$ $ $$g$ $ $ $ ,$P $ $$ `$g. ,$$ `$$._ _. $ _,g$P $ `$b. ,$$ $$ `Y$$P'$. `YP $$$P' ,$. `Y$$P'$ $. ,$. signature.asc Description: Digital signature
Re: Example where testing-security was used?
Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote: On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote: But setting up autobuilders doesn't require a new infrastructure (and shouldn't require more than half a year). Wasn't the infrastructure a prerequisite for woody and is working? It turned out that the central part of the existing infrastructure didn't scale up well enough to cope with the new architectures in sarge. There are no new architectures in sarge. That's right, but the buildd network has to work for both oldstable and stable. potato + woody didn't need as many buildds as woody + sarge will need. Marc -- BOFH #221: The mainframe needs to rest. It's getting old, you know. pgp1LSjXjahP0.pgp Description: PGP signature
Your in-home source of health information
Achieving a strong erection in 15 minutes is easy as 1-2-3! http://rjb.7ms0tqp0mz7fbqp.visional72d3.com The only atheism is the denial of truth. There is never enough time, unless you're serving it. Reality is a crutch for people who can't cope with drugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with: Bug#295706: Preferences is empty
* Michelle Konzack | The BUG, described by me, occures if you upgrade from WOODY to SARGE. Could you please stop yelling at our releases? -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Libraries with ABI changes
* Hamish Moffatt | An advantage of keeping the old library in oldlibs for a while is that | local admins may have their own binaries compiled against these | libraries. Rapid replacements of libraries break local binaries. Not as long as you bump the package name. There's nothing pulling the old library package off an admin's system so unless the admin removes it himself the local binaries should work fine. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311321: RFP: redet -- regular expression development and execution tool
Package: wnpp Severity: wishlist Owner: Bartosz Fenski aka fEnIo [EMAIL PROTECTED] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: redet Version : 6.5 Upstream Author : William J. Poser [EMAIL PROTECTED] * URL : http://www.cis.upenn.edu/~wjposer/redet.html * License : GPL Description : regular expression development and execution tool Redet allows the user to construct regular expressions and test them against input data by executing any of a variety of search programs, editors, and programming languages that make use of regular expressions. When a suitable regular expression has been constructed it may be saved to a file. redet stands for Regular Expression Development and Execution Tool. For each program, a palette showing the available regular expression syntax is provided. Selections from the palette may be copied to the regular expression window with a mouse click. Users may add their own definitions to the palette via their initialization file. Redet also keeps a list of the regular expressions executed, from which entries may be copied back into the regular expression under construction. The history list is saved to a file and restored on startup, so it persists across sessions. So long as the underlying program supports Unicode, redet allows UTF-8 Unicode in both test data and regular expressions. Comparision with other similar tools: * Redet supports many programs. Most other regexp tools are aimed at a single language or style of regular expression. * Redet determines the properties of the programs that actually execute the regular expressions empirically. This guarantees that the version of the program you are using will actually behave as described. It also makes it likely that if new features are added to a program's regular expression repertoire, they will be detected and shown on the palette without any modification to the program. * Redet is explicitly designed for use in a variety of languages and writing systems. It provides the ability to change locale without exiting and reports whether Unicode support is available for each combination of program and locale. It provides special support for Unicode, such as lists of Unicode ranges and character properties. Redet itself is fully internationalized. By adding a suitable translation catalogue, buttons, labels, and messages may all be provided in any language. * Most regular expression tools are useful for constructing and understanding regular expressions but are not designed for use as search environments. Redet provides a number of facilities that make it a good search environment, including a relatively large, re-sizable text window, the ability to enter both regular expressions and data in various ways and to save them to files, editable, persistent history, and journalling. * Redet handles both matching and substitution. Most programs deal only with matching. * Redet allows the user to define named character classes and to intersect them. - -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.4.27-2-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnBLshQui3hP+/EARAnkUAKDNprseGrGeNATPicQxvNNnG3sGewCfUdQM ZJlUrRXg/M72XnsBhtKuGNU= =+8ki -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with: Bug#295706: Preferences is empty
In article [EMAIL PROTECTED] you wrote: So Upgraders must move the old mozilla config manualy out of the way. Can this BUG solved ? This happens very often. I think it is a Mozilla Bug to require too much manuel intervention on upgrade. It is not related to releases (however more likely between releases). I think we had something about this in the last release notes and can put the same text in the upcoming. If thats your only upgrade problem, we are really very very good:) Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dear Adrian Bunk, Please hold off a week or two
On Mon, May 30, 2005 at 03:45:07PM -0400, Joey Hess wrote: Adrian Bunk wrote: Or do you _really_ want to release sarge with many dozens of already known and fixed bugs? I'd worry about it more if we hadn't suffered from the same or similar problems with ever previous Debian release, TBPH. Even back when we froze unstable, this just pushed certian bugfixes out of the archive entirely. ... How can this happen whenyou freeze unstable? see shy jo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dear Adrian Bunk, Please hold off a week or two
On Tue, May 31, 2005 at 04:07:11PM +1200, Nigel Jones wrote: I noticed that Adrian moved a bug report for a kernel in sid (2.6.10 IIRC) to the 2.6.8 kernel so it appeared as a Sarge RC Bug? I didn't see anything that showed that it was a 2.6.8 problem, maybe it is, but it looked like second guessing to me... The important part of the bug log is the following by one of the Debian kernel maintainers: well reiserfs doesn't work well with preempt, could you please try the 2.6.11 kernel-iamge. there preempt is disabled afair. PREEMPT is enabled in both the 2.6.8 and the 2.6.10 kernel images but no longer in the 2.6.11 kernel images. It might look like second guessing, but if ReiserFS has problems with PREEMPT in 2.6.10, the probability that this is also present in 2.6.8 is quite high. How is this helping Sarge? If it turns out that it does affect part of Sarge then isn't there a means provided to upload the new .deb files after release? The main question is not when and how to fix such an issue. The problem is that the release team's scripts to measure their RC bugs metric can't handle pseudo-packages correctly. Steve has already acknowledged this limitation (and AFAIK it has yet to be fixed). Therefore my reassigning was required to get this bug on the radar of the release team. Bug in question is #303200, also it seems it was downgraded to a non-RC bug, so now doesn't that mean that it is now filed in wrong places? ... The most important thing seems to be the added moreinfo tag. The maintainer know better about such issues than I do. I do not claim to have been able to reproduce this problem, all I claim is that if it's a problem (IOW: not a local hardware problem of the submitter) it's most likely also present in kernel 2.6.8. And my reassigning was requred to get it on the radar of the release team. N Jones cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Example where testing-security was used?
On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote: Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote: On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote: But setting up autobuilders doesn't require a new infrastructure (and shouldn't require more than half a year). Wasn't the infrastructure a prerequisite for woody and is working? It turned out that the central part of the existing infrastructure didn't scale up well enough to cope with the new architectures in sarge. There are no new architectures in sarge. That's right, but the buildd network has to work for both oldstable and stable. potato + woody didn't need as many buildds as woody + sarge will need. 17 - 22 architectures is an increase, but doesn't look like a very serious one. Marc cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dear Adrian Bunk, Please hold off a week or two
On Tue, 31 May 2005, Adrian Bunk wrote: On Mon, May 30, 2005 at 03:45:07PM -0400, Joey Hess wrote: Adrian Bunk wrote: Or do you _really_ want to release sarge with many dozens of already known and fixed bugs? I'd worry about it more if we hadn't suffered from the same or similar problems with ever previous Debian release, TBPH. Even back when we froze unstable, this just pushed certian bugfixes out of the archive entirely. ... How can this happen whenyou freeze unstable? I guess you will not understand at each other if you use the term freezing unstable with two different meanings. I see that the term may have at least two meanings: * frozen is created initially as a copy of unstable. After this, frozen and unstable evolve separately, unless you upload some package for frozen unstable, as we did in the old days. I bet Adrian would not call this a proper freeze of unstable, as it would be the frozen distribution who would be really frozen, not unstable. * unstable is actually frozen, which means uploads for unstable are either discouraged, they remain in the limbo, or they are automatically put in some other distribution above unstable, like new-unstable, until testing or unstable becomes the new stable. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311332: ITP: gofax -- Fax solution based on hylafax and LDAP
Package: wnpp Severity: wishlist Owner: scheiter [EMAIL PROTECTED] * Package name: gofax Version : 1.4 Upstream Author : Lars Scheiter [EMAIL PROTECTED] * URL : http://oss.gonicus.de/project/?group_id=2 * License : GPL Description : Fax solution based on hylafax and LDAP GOfax is an extendable fax solution based on hylafax. It provides pluggable facilities to store user account data, preferred in LDAP directories. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.30 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311333: ITP: gopdc -- Helper Scripts to build up an Samba DC
Package: wnpp Severity: wishlist Owner: scheiter [EMAIL PROTECTED] * Package name: gopdc Version : 1.0.0 Upstream Author : Lars Scheiter [EMAIL PROTECTED] * URL : http://oss.gonicus.de/project/?group_id=8 * License : GPL Description : Helper Scripts to build up an Samba DC GOpdc Scripts may be used to build up an Samba DC, which will help you to build up a fully integrated Domain Controller. In combination with GOsa and Samba these scripts make a nearly NT4 style complete Domain Controller posssible. GOpdc is in most cases similar to the smbldap-tools but written in PHP for the ease of use. Configuration is managed via an xml file. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.30 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dear Adrian Bunk, Please hold off a week or two
On Tue, May 31, 2005 03:43, Miles Bader wrote: Bernd Eckenfels [EMAIL PROTECTED] writes: Actually I am glad somebody is working public visible on the release issues and would not critisize him for that. Pointing out a problem is nice, but doing so in an obnoxious manner hurts. I would like to add: pointing out a problem is easy, providing good solutions is a lot harder. Continuously pointing out problems (the metric is wrong, testing is bad) is destructive critisism, while what we really need is constructive thinking about the issues for etch, after the release. In the vast majority of his mails I see mr Bunk only hammering on perceived problems. Very tiring. Thijs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release update: minor delay; no non-RC fixes; upgrade reports
On Mon, May 30, 2005 at 12:59:26PM +0200, Adrian Bunk wrote: Since it seems noone of the release team bothered to pay this part of the price for the testing release process, I'm sometimes using one or two spare hours to go a bit through update_excuses and report half a dozen of such issues. Steve saw this, and before the latest release update he sent (which was the one before yours), he asked me in a private mail about a prediction how many such RC bugs I'd expect in sarge for inclusion in his release update. It seems my prediction about the number of such issues didn't match his wishes regarding the state of sarge, and he did therefore neither answer my email nor mention this in the release update nor does it seem he assigned a member of the release team to do this work properly. On the contrary, I found your answer reasonably satisfactory, and as a result had postponed replying to you in favor of dealing with more directly pressing release issues. You indicated that as of two weeks ago, you'd been through the middle seventh of update_excuses checking for unidentified RC bugs, and that most of the packages below this range were not in testing and therefore wouldn't hold many hidden RC bugs; and I've been tracking the status of RC bugs closed since the freeze began, which accounts for many (though not all) of the more recent uploads. So it is probably true that sarge will release with some RC bugs that could have easily been fixed had we known about them, but I don't think this number will be so great that we want to redirect resources or delay the release in order to try to catch them. I don't think it's realistic to charge the release team with identifying all RC bugs in the distribution, only to take care that we don't release with them once they are so identified. [1] And no, version tracking in the BTS wouldn't prevent this problem. In my experience, there are so many of these issues reported with a wrong version or manually closed or even without any bug report in the BTS that claiming version tracking might eliminate this problem sounds like a bad joke. shrug The problems you describe are not ones that would go away with the removal of testing; if maintainers are not engaged in the process of ensuring their packages are free of RC bugs for release, and do not take care that RC bugs are a) documented in the BTS, b) filed at the correct severity, and c) fixed in the version of the package that's releasing (in case something goes wrong with a and b), we are going to miss RC bugs that could have been caught. This is a social problem, not a technical one, and I don't think there are any viable technical solutions. For my part, I have explicitly *not* given a free pass to packages with RC bugs that were filed a long time ago but only recently raised to their proper severity. It's great if bug submitters know what severity a bug should be filed at, but it's the *responsibility* of the maintainer to adjust the severity if it's wrong -- even if that means raising the severity, something none of us want to do. Even more, it's the maintainer's responsibility to *deal with* such bugs at the proper severity even if they were filed wrong. It simply can't be the responsibility of any central group to babysit the severities of bugs filed: that's not scalable in the least. So yes, sarge will ship with bugs that should have been considered RC. But this is inevitable in any case because of the many RC bugs that are never *identified* by our testing, so there's no reason for the release team to treat these bugs as blocking issues if no one cares enough to make sure they're brought to our attention. This doesn't mean that your work to identify overlooked RC bugs is any less valuable, Adrian, or that I'm any less grateful to you for it (in spite of the visceral irritation sometimes at seeing the bug count moving in the wrong direction ;). It just means having a pragmatic, big-picture view of what it means to release, and whether the improvement to sarge is worth it to our users every time we delay another week to fix a handful of bugs. After all, let's not forget that sarge is already quite good, and nothing to be ashamed of! -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Example where testing-security was used?
On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote: On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote: Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote: On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote: But setting up autobuilders doesn't require a new infrastructure (and shouldn't require more than half a year). Wasn't the infrastructure a prerequisite for woody and is working? It turned out that the central part of the existing infrastructure didn't scale up well enough to cope with the new architectures in sarge. There are no new architectures in sarge. That's right, but the buildd network has to work for both oldstable and stable. potato + woody didn't need as many buildds as woody + sarge will need. 17 - 22 architectures is an increase, but doesn't look like a very serious one. There were never security autobuilders for potato; and security and proposed-updates are separate queues. So in terms of centralized load on the wanna-build server, this is a jump from 22 (11 stable-security + 11 proposed-updates) to 33 (11 oldstable-security + 11 stable-security + 11 proposed-updates; AFAIK there is no oldstable-proposed-updates). If testing-security is brought on-line again for etch within the year following sarge's release (as I certainly hope it will), the peak number of wanna-build *databases* being served by ftp-master.d.o (saying nothing of the number of actual buildd connections) would be 66 (oldstable-security + stable-security + proposed-updates + testing-proposed-updates + testing-security + unstable, x 11 archs -- not counting prospective archs). The greatest number newraff has ever really been asked to handle at any one time up to this point has been 55 (the number we have currently), which was only done *after* newraff's scalability problems were addressed; prior to that, AFAIK there were only ever as many as 44 databases actively used (p-u + s-s + t-p-u + u, from the release of woody w/ security autobuilder support up until this spring). So at 44 the server was already at its limit, the release required a 25% increase in the number of databases (and roughly the same increase in the number of connections), and etch would have brought us up to 50% over that limit. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Example where testing-security was used?
On Tue, May 31, 2005 at 04:56:52AM -0700, Steve Langasek wrote: On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote: On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote: Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote: On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote: But setting up autobuilders doesn't require a new infrastructure (and shouldn't require more than half a year). Wasn't the infrastructure a prerequisite for woody and is working? It turned out that the central part of the existing infrastructure didn't scale up well enough to cope with the new architectures in sarge. There are no new architectures in sarge. That's right, but the buildd network has to work for both oldstable and stable. potato + woody didn't need as many buildds as woody + sarge will need. 17 - 22 architectures is an increase, but doesn't look like a very serious one. There were never security autobuilders for potato; and security and proposed-updates are separate queues. So in terms of centralized load on the wanna-build server, this is a jump from 22 (11 stable-security + 11 proposed-updates) to 33 (11 oldstable-security + 11 stable-security + 11 proposed-updates; AFAIK there is no oldstable-proposed-updates). If testing-security is brought on-line again for etch within the year following sarge's release (as I certainly hope it will), the peak number of wanna-build *databases* being served by ftp-master.d.o (saying nothing of the number of actual buildd connections) would be 66 (oldstable-security + stable-security + proposed-updates + testing-proposed-updates + testing-security + unstable, x 11 archs -- not counting prospective archs). ... So at 44 the server was already at its limit, the release required a 25% increase in the number of databases (and roughly the same increase in the number of connections), and etch would have brought us up to 50% over that limit. I'm glad to hear that you do no longer plan to drop architectures from etch. :-) Steve Langasek cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: New Nokia device is Debian-based?
On Fri, May 27, 2005 at 11:23:14AM +0400, Nikita V. Youshchenko wrote: The open source software component of the Nokia 770 can be downloaded from Maemo.org as a complete filesystem, or managed as a collection of Debian source and binary packages. Yep, and many of the packages match the Debian versions an half year ago. Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, The Enemy Within, stardate unknown signature.asc Description: Digital signature
Re: Example where testing-security was used?
On Tue, May 31, 2005 at 02:01:48PM +0200, Adrian Bunk wrote: On Tue, May 31, 2005 at 04:56:52AM -0700, Steve Langasek wrote: On Tue, May 31, 2005 at 11:25:39AM +0200, Adrian Bunk wrote: On Mon, May 30, 2005 at 10:56:16PM +0200, Marc 'HE' Brockschmidt wrote: Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote: On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote: But setting up autobuilders doesn't require a new infrastructure (and shouldn't require more than half a year). Wasn't the infrastructure a prerequisite for woody and is working? It turned out that the central part of the existing infrastructure didn't scale up well enough to cope with the new architectures in sarge. There are no new architectures in sarge. That's right, but the buildd network has to work for both oldstable and stable. potato + woody didn't need as many buildds as woody + sarge will need. 17 - 22 architectures is an increase, but doesn't look like a very serious one. There were never security autobuilders for potato; and security and proposed-updates are separate queues. So in terms of centralized load on the wanna-build server, this is a jump from 22 (11 stable-security + 11 proposed-updates) to 33 (11 oldstable-security + 11 stable-security + 11 proposed-updates; AFAIK there is no oldstable-proposed-updates). If testing-security is brought on-line again for etch within the year following sarge's release (as I certainly hope it will), the peak number of wanna-build *databases* being served by ftp-master.d.o (saying nothing of the number of actual buildd connections) would be 66 (oldstable-security + stable-security + proposed-updates + testing-proposed-updates + testing-security + unstable, x 11 archs -- not counting prospective archs). ... So at 44 the server was already at its limit, the release required a 25% increase in the number of databases (and roughly the same increase in the number of connections), and etch would have brought us up to 50% over that limit. I'm glad to hear that you do no longer plan to drop architectures from etch. :-) I no longer have any illusions that we'll be able to persuade the project that this is in Debian's best interest, or that we'll find an alternate solution that's acceptable to the porters of the architectures in question. In any case, given the number of prospective ports waiting in the wings, 11 is probably a roughly correct estimate even if we *do* drop some architectures. (And since non-release ports are likely to stay in unstable, and adding a release port adds three w-b databases where dropping one only removes two w-b databases, it takes 1 1/2 dropped archs to balance one added arch...) -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Example where testing-security was used?
In any case, given the number of prospective ports waiting in the wings, 11 is probably a roughly correct estimate even if we *do* drop some architectures. (And since non-release ports are likely to stay in unstable, and adding a release port adds three w-b databases where dropping one only removes two w-b databases, it takes 1 1/2 dropped archs to balance one added arch...) in all those debates about the lack of buildds, sth seems odd to me. I've always thought that moore's law was quite accurate... and my understanding (I may be wrong, it's only how I understand the whole thing) is that debian growth is quite linear, compared to the cpu speed, disk size, BW ... growth, the time passing, we should have less and less limitations. I'm aware that more's law is not appliable on some archs (like arm I believe) but the question is, well, who uses openoffice.org or kde on an arm (only to cite those) ? In fact, the point is, I don't understand how hardware limitations are really possible. I understand fully that many ports needs *a lot* of work for porters/security teams (it's a pity human brains does not follow moore's law) ... but I find hard to believe that hardware is the reason why we cannot manage many arches. -- O Pierre Habouzit O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdaVPkl87ui.pgp Description: PGP signature
Bug#311348: ITP: ptunnel -- Send TCP traffic over ICMP
Package: wnpp Severity: wishlist Owner: Romain Beauxis [EMAIL PROTECTED] * Package name: ptunnel Version : 0.61 Upstream Author : Daniel Stoedle [EMAIL PROTECTED] * URL : http://www.cs.uit.no/~daniels/PingTunnel/ * License : BSD like Description : Send TCP traffic over ICMP Ptunnel is an application that allows you to reliably tunnel TCP connections to a remote host using ICMP echo request and reply packets, commonly known as ping requests and replies. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.8-romidaboss Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Example where testing-security was used?
On Tue, May 31, 2005 at 03:08:09PM +0200, Pierre Habouzit wrote: In any case, given the number of prospective ports waiting in the wings, 11 is probably a roughly correct estimate even if we *do* drop some architectures. (And since non-release ports are likely to stay in unstable, and adding a release port adds three w-b databases where dropping one only removes two w-b databases, it takes 1 1/2 dropped archs to balance one added arch...) in all those debates about the lack of buildds, sth seems odd to me. I've always thought that moore's law was quite accurate... and my understanding (I may be wrong, it's only how I understand the whole thing) is that debian growth is quite linear, compared to the cpu speed, disk size, BW ... growth, the time passing, we should have less and less limitations. Moore's Law governs the rate at which the speed of hardware (at a given price-point) doubles. It says nothing about the speed at which current software will *run* on current machines; and it certainly has nothing to say about the speed at which such software will run on machines that are no longer on the Moore's Law curve due to a lack of new hardware being designed/manufactured for that architecture. IOW, it doesn't (directly) give meaningful predictions about the rate at which a given piece of hardware becomes obsolete. It also has no capacity to predict an organization's *ability* to replace hardware. I'm aware that more's law is not appliable on some archs (like arm I believe) but the question is, well, who uses openoffice.org or kde on an arm (only to cite those) ? This mitigates the linear growth of the archive itself (assuming we did subset the archive for slower archs), but it doesn't mitigate the growth of software complexity that causes subsequent revisions of the same software to run slower on the same hardware over time -- which, if it's true of nothing else, is at least true of compilers. In fact, the point is, I don't understand how hardware limitations are really possible. I understand fully that many ports needs *a lot* of work for porters/security teams (it's a pity human brains does not follow moore's law) ... but I find hard to believe that hardware is the reason why we cannot manage many arches. I don't remember anyone ever saying this was a hardware problem. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Example where testing-security was used?
Steve Langasek [EMAIL PROTECTED] writes: In any case, given the number of prospective ports waiting in the wings, 11 is probably a roughly correct estimate even if we *do* drop some architectures. Speaking of prospective ports, what would be the feasibility of keeping testing frozen after sarge releases, do whatever toolchain updates are needed to support amd64 via t-p-u, and release etch as a sarge+amd64 release in, say, 3 months? The rationale is that amd64 would be immediately useful whereas other architectures like s390x or whatever other port we plan to support can probably wait the 2+ years before the next release... (I don't know if it's possible to add an architecture without having all binaries go through unstable first so the idea is probably doomed, but it certainly appeals.) -- ,''`. : :' :Romain Francoise [EMAIL PROTECTED] `. `' http://people.debian.org/~rfrancoise/ `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Example where testing-security was used?
IOW, it doesn't (directly) give meaningful predictions about the rate at which a given piece of hardware becomes obsolete. It also has no capacity to predict an organization's *ability* to replace hardware. ok, true I'm aware that more's law is not appliable on some archs (like arm I believe) but the question is, well, who uses openoffice.org or kde on an arm (only to cite those) ? This mitigates the linear growth of the archive itself (assuming we did subset the archive for slower archs), but it doesn't mitigate the growth of software complexity that causes subsequent revisions of the same software to run slower on the same hardware over time -- which, if it's true of nothing else, is at least true of compilers. hmmm, if you don't give such monsters like openoffice or any big c++ application to build on slow/rare arches, I guess that will ease the autobuilders a lot too, not only the archive. maybe the solution is to write a [EMAIL PROTECTED] (like [EMAIL PROTECTED] or [EMAIL PROTECTED] does) in order to ease the autobuilders :D (kidding of course) -- O Pierre Habouzit O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQCOiqDjrqK.pgp Description: PGP signature
Re: Dear Adrian Bunk, Please hold off a week or two
On Tue, May 31, 2005 at 11:22:20AM +0200, Adrian Bunk wrote: I noticed that Adrian moved a bug report for a kernel in sid (2.6.10 IIRC) to the 2.6.8 kernel so it appeared as a Sarge RC Bug? I didn't see anything that showed that it was a 2.6.8 problem, maybe it is, but it looked like second guessing to me... The important part of the bug log is the following by one of the Debian kernel maintainers: well reiserfs doesn't work well with preempt, could you please try the 2.6.11 kernel-iamge. there preempt is disabled afair. PREEMPT is enabled in both the 2.6.8 and the 2.6.10 kernel images but no longer in the 2.6.11 kernel images. It might look like second guessing, but if ReiserFS has problems with PREEMPT in 2.6.10, the probability that this is also present in 2.6.8 is quite high. How is this helping Sarge? If it turns out that it does affect part of Sarge then isn't there a means provided to upload the new .deb files after release? The main question is not when and how to fix such an issue. The problem is that the release team's scripts to measure their RC bugs metric can't handle pseudo-packages correctly. Steve has already acknowledged this limitation (and AFAIK it has yet to be fixed). Therefore my reassigning was required to get this bug on the radar of the release team. Actually, I've started using lynx -width=160 -dump http://bugs.debian.org/release-critical/other/all.html \ | grep -v '\[[EUS]*X*\]\|I\]\|\[TX\]' | grep -B3 '\[\]' as a means of tracking the status of sarge-affecting RC bugs according to bugs.debian.org. The diff between this and bts.turmzimmer.net includes two bugs against packages that are only in non-US; two bugs against installation-reports which most likely need to be downgraded; one upgrade-reports bug which is probably unreproducible; one bug on 'kernel' that is probably sarge-ignore but I haven't looked at it in any detail yet; one unreproducible bug against general which is probably a fixed bug in an old package; and one RC bug against ftp.debian.org asking for d-i udeb packages to be synced for the release (95% resolved as far as the release is concerned, current overall status seen at http://www.wolffelaar.nl/~jeroen/d-i/sarge-sarge.txt). -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Keysigning without physically meeting ... thoughts?
Hi folks, I wrote this up to someone. I thought I'd share it, and get your thoughts. (e.g. anybody see any weaknesses in #1-#3 that *aren't* present in the typical meet, check ID, get GPG fingerprint, assuming #4 is always used afterwards?) On Tuesday 31 May 2005 08:44, Wesley J. Landaker wrote: For instance, I don't know if this is officially acceptable or not, but I would probably be willing to sign someone's key even if I hadn't met them in person, if I got in the mail: 1) A picture of them holding a recent newspaper with their GPG fingerprint and signature written on it. (This would relate the person's face signature with their GPG key, and verify that it's recent). 2) A copy of an acceptable (probably government-issued, non-expired) picture ID. (This would relate the person's face with their government identity). 3) A signed, dated, and notarized statement saying something to the effect of My name is __, my active e-mail that I control is [EMAIL PROTECTED], and the GPG fingerprint of my active key that I control and is not compromised is __. Attached to this statement is a picture of me with a newspaper dated ___ with the same GPG fingerprint, and a copy of my ___ photo ID, which I have shown to the undersigned notary. Signed __, notarized by ___. (Relates the date (which should be reasonably close to the time when the picture in #1 was taken--a few weeks at the most), their name, e-mail, and GPG fingerprint together by the statement, and the picture from #1, and with their government identity, as that is checked by the notary). 4) I'd sign the key, and send the updated key to the e-mail address given, signed by the GPG key with the fingerprint given. (Relates the e-mail address with the GPG key, as if they can't get the e-mail or decrypt the e-mail to get the signature, it effectively hasn't really been signed). -- Wesley J. Landaker [EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpTmKyVwiLKk.pgp Description: PGP signature
Bug#311371: ITP: elektra -- A framework to store configuration atoms hierarchically
Package: wnpp Version: N/A; reported 2005-05-31 Severity: wishlist * Package name: elektra Version : 0.5 Upstream Author : Avi Alkalay [EMAIL PROTECTED] * URL : http://elektra.sourceforge.net/ * License : BSD Description : A framework to store configuration atoms hierarchically Elektra provides a universal and secure framework to store configuration parameters in a hierarchical key-value pair mechanism, instead of each program using its own text configuration files. This allows any program to read and save its configuration with a consistent API, and allows them to be aware of other applications' configurations, permitting easy application integration. While architecturally similar to other OS registries, Elektra does not have most of the problems found in those implementations. -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux alps 2.4.18-1-686 #1 Wed Apr 14 18:20:10 UTC 2004 i686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311373: ITP: wifi-radar -- GUI utility for managing WiFi profiles
Package: wnpp Severity: wishlist Owner: Stephen Birch [EMAIL PROTECTED] * Package name: wifi-radar Version : 1.9.3 Upstream Author : [EMAIL PROTECTED] * URL : http://www.bitbuilder.com/wifi_radar/ * License : GPL Description : GUI utility for managing WiFi profiles WiFi Radar is a Python/PyGTK2 utility for managing WiFi profiles. It enables you to scan for available networks and create profiles for your preferred networks. At boot time, running WiFi Radar will automatically scan for an available preferred network and connect to it. You can drag and drop your preferred networks to arrange the profile priority. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: All Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Is Ubuntu a debian derivative or is it a fork?
Forgive me if this has already been discussed ... if so could someone give me a pointer to the thread. I find myself fairly confused about Ubuntu packages. I had thought that Ubuntu is a Debian derivative. Therefore I expected new packages to be first placed in Debian and then flow to Ubuntu. However, I recently found this page: https://www.ubuntulinux.org/wiki/MOTUNewPackages The project seems to have established a mechanism for putting new packeges directly into Ubuntu. Are new Ubuntu packages also put in Debian by the Ubuntu team members? The Ubuntu literature indicates that Ubuntu is a derivative of debian but it looks more like a fork to me. Also, when Ubuntu makes improvements to packages how do those improvements flow back to Debian? Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
* Stephen Birch | The project seems to have established a mechanism for putting new | packeges directly into Ubuntu. Are new Ubuntu packages also put in | Debian by the Ubuntu team members? Yes. | The Ubuntu literature indicates that Ubuntu is a derivative of debian | but it looks more like a fork to me. It's a spoon. | Also, when Ubuntu makes improvements to packages how do those | improvements flow back to Debian? Patches to bugs, debian maintainers picking up the patches from the patch repository, inter-team communication. It depends. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
subscribe
-- Enrique Ocaña González Ingeniero en Informática mailto:[EMAIL PROTECTED] Igalia S.L. http://www.igalia.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Example where testing-security was used?
On Tue, 31 May 2005, Steve Langasek wrote: Moore's Law governs the rate at which the speed of hardware (at a given price-point) doubles. It says nothing about the speed at which current software will *run* on current machines; and it certainly has nothing to say about the speed at which such software will run on machines that are no longer on the Moore's Law curve due to a lack of new hardware being designed/manufactured for that architecture. Actually, doesn't Moore's Law mean the average for all new silicon? So, some cutting-edge new hardware may evolve faster than the average. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Tollef Fog Heen([EMAIL PROTECTED])@2005-05-31 18:06: * Stephen Birch | The project seems to have established a mechanism for putting new | packeges directly into Ubuntu. Are new Ubuntu packages also put in | Debian by the Ubuntu team members? Yes. Let me give you an example. I filed an ITP this morning on a promising package called wifi-radar. After writing the ITP I discovered someone has already built a deb for Ubuntu and placed it on the Ubuntu wiki. But they did not file an ITP. Normal debian etiquette identifies the maintainer of a new package as the first person to file an ITP. So how is this coordinated with Ubuntu? Unless I missed the ITP and filed a double by mistake we appear to have two independent wifi-radar maintainers now. The Ubuntu one and the debian one. In this instance there isnt an issue, I just want to see the software packaged and I'll happily yeald to the other maintainer if he/she wants. But I can see the possibility of a conflict in future when this happens with other packages. | The Ubuntu literature indicates that Ubuntu is a derivative of debian | but it looks more like a fork to me. It's a spoon. And a very good looking spoon indeed. I like Ubuntu and am switching my customer base over to it from Debian. But I sure want to see good coordination between Ubuntu and Debian. | Also, when Ubuntu makes improvements to packages how do those | improvements flow back to Debian? Patches to bugs, debian maintainers picking up the patches from the patch repository, inter-team communication. It depends. Still looks more like a fork than a derivative . or a spoon :-) Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
proficiency-level tag for debian packages
Pardon me if this has already been discussed, but I wonder if there should be a tag in debian packages indicating the a minimum proficiency level that a user should have in order for a package to be useful to the user. For example, a package like OpenOffice or Firefox are end-user applications which most users (even those completely unfamiliar with linux) would have a good chance at understanding and being able to use. On the other hand, a package like nmap might not be something my Grandma would be wanting to use every day, and thus it might be better to have a higher proficiency-level rating for such a package. The motivation for such a thing is that it would make it possible for package-management tools to operate in an easy mode which would only display (or display in a separate category) packages which have a proficiency-rating x. This would be very handy in that it would permit using Debian and an apt frontend like synaptic to make it easy for more-or-less computer-illiterate people to install new packages which match their skill-level, without having to wade through hundreds of libraries and technical tools which they would never use. Perhaps there's a better way to accomplish this, but the ability to limit the display of packages in this manner is something that it seems would be beneficial to have. -Mark -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proficiency-level tag for debian packages
El Martes 31 Mayo 2005 19:41, Mark Edgington escribió: Pardon me if this has already been discussed, but I wonder if there should be a tag in debian packages indicating the a minimum proficiency level that a user should have in order for a package to be useful to the user. For example, a package like OpenOffice or Firefox are end-user applications which most users (even those completely unfamiliar with linux) would have a good chance at understanding and being able to use. On the other hand, a package like nmap might not be something my Grandma would be wanting to use every day, and thus it might be better to have a higher proficiency-level rating for such a package. The motivation for such a thing is that it would make it possible for package-management tools to operate in an easy mode which would only display (or display in a separate category) packages which have a proficiency-rating x. This would be very handy in that it would permit using Debian and an apt frontend like synaptic to make it easy for more-or-less computer-illiterate people to install new packages which match their skill-level, without having to wade th rough hundreds of libraries and technical tools which they would never use. Perhaps there's a better way to accomplish this, but the ability to limit the display of packages in this manner is something that it seems would be beneficial to have. -Mark I find it a quite interesting idea. If it was implemented, there should be an scale, so that maintainers have some reference in order to tag their packages. Something similar to: Firefox, OpenOffice, koffice, gxine - 100 Thunderbird, Kmail, Evolution - 95 Dia, Inkscape, Gimp, - 90 konsole, gnome-terminal - 50 Libraries - 0 Of course, such scale should be further discussed and studied than my fast-done one... Cesar
Re: proficiency-level tag for debian packages
On Tuesday 31 May 2005 19:06, Cesar Martinez Izquierdo wrote: El Martes 31 Mayo 2005 19:41, Mark Edgington escribió: Pardon me if this has already been discussed, but I wonder if there should be a tag in debian packages indicating the a minimum proficiency level that a user should have in order for a package to be useful to the user. For example, a package like OpenOffice or Firefox are end-user applications which most users (even those completely unfamiliar with linux) would have a good chance at understanding and being able to use. On the other hand, a package like nmap might not be something my Grandma would be wanting to use every day, and thus it might be better to have a higher proficiency-level rating for such a package. The motivation for such a thing is that it would make it possible for package-management tools to operate in an easy mode which would only display (or display in a separate category) packages which have a proficiency-rating x. This would be very handy in that it would permit using Debian and an apt frontend like synaptic to make it easy for more-or-less computer-illiterate people to install new packages which match their skill-level, without having to wade th rough hundreds of libraries and technical tools which they would never use. Perhaps there's a better way to accomplish this, but the ability to limit the display of packages in this manner is something that it seems would be beneficial to have. -Mark I find it a quite interesting idea. If it was implemented, there should be an scale, so that maintainers have some reference in order to tag their packages. This would be rather arbitrary and probably be liable to cause disagreements. I think you could get much the same affect with some well chosen tags and debtags. e.g. you could filter on: command line only tools enterprise tools (e.g. groupware, RDBMS) scientific tools (e.g. octave, R) sysadmin tools (e.g. mrtg) Alternatively create a custom distro based on Debian with only the required packages installed by default.
Hungary (Pecs and Budapest), meeting and key signing
Hello, I will be in Hungary from Saturday 4 to Sunday 12 June, mainly in Pecs except one day in Budapest, but I don't know yet which day will be. If someone is there and has some spare time, let me know. :) Thanks, -- Fabio Tranchitella [EMAIL PROTECTED].''`. Proud Debian GNU/Linux developer, admin and user.: :' : `. `'` http://people.debian.org/~kobold/ `- _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 signature.asc Description: Digital signature
New Penis Enlargement Patches!
Penis enhancement system that works for countless men worldwide. http://www.jnaz.net/ss/ Good taste is always an asset. I'm tough, ambitious and I know exactly what I want. Do not envy a sinner; you don't know what disaster awaits him. Military intelligence is a contradiction in terms. Health is not valued till sickness comes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tuesday 31 May 2005 19.17, Stephen Birch wrote: Still looks more like a fork than a derivative . or a spoon :-) I have problems with your terminology - what do you mean by 'fork', and what do you mean by 'derivative'? To my understanding, Ubuntu is certainly a derivative of Debian (since it derives most of its packaging from Debian), and it's a fork (since Debian is not dead, and both projects are maintained.) Passing of code between branches of a fork is something that can happen - for example, the gcc/egcs fork was originally announce that way: both branches would take code from the other side.) cheers -- vbi -- Manoj madduck: Umm, if you wanna hack at kernel-package in non-standard ways, you need to be one with the source madduck make is not one with its own Makefiles. -- #debian-devel, Fri, 04 Mar 2005 17:50 +0100 pgpHd9i0WCRAw.pgp Description: PGP signature
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 10:17:38AM -0700, Stephen Birch wrote: And a very good looking spoon indeed. I like Ubuntu and am switching my customer base over to it from Debian. I may do that too, but its architecture support is abysmal compared to Debian, so I have no choice in the matter at this point (and lack the time to port ubuntu to all my archs). Which is too bad; it shouldn't be too hard to have ubuntu support every arch that debian does. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
I may do that too, but its architecture support is abysmal compared to Debian, so I have no choice in the matter at this point (and lack the time to port ubuntu to all my archs). Perhaps the SCC plan will help make that choice easier for you. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Wifi-radar
On Tue, 2005-05-31 at 11:11 -0700, Stephen Birch wrote: I would be very happy to handle the debian side for this package if that works for you. If I understand you well, you would like to repackage it for Sid? Or just upload it in it? -- Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225 http://master.grad.hr/~ivoks/|--|ICQ: 64631782 May, 15. herve we're fixing the universe, it's not an easy duty! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
First of all, hi to all developers! I packaged that wifi-radar for Ubuntu. It was my first package and I didn't fill ITP, untill it was reviewed by others. I'm sorry for not filling ITP. I didn't know I have to. I'm new in creating packages and don't know all the rules. So, could someone point me to some HOWTO or documentation regarind the ITP and debian etiquette? Speaking of package. It has few changes regarding upstream (man page, autodetection of wifi interface, menu entry and uses gksudo instead of sudo). -- Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225 http://master.grad.hr/~ivoks/|--|ICQ: 64631782 May, 15. herve we're fixing the universe, it's not an easy duty! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proficiency-level tag for debian packages
On Tue, May 31, 2005 at 07:09:38PM +0100, Will Newton wrote: On Tuesday 31 May 2005 19:06, Cesar Martinez Izquierdo wrote: I find it a quite interesting idea. If it was implemented, there should be an scale, so that maintainers have some reference in order to tag their packages. This would be rather arbitrary and probably be liable to cause disagreements. Not much more so than with the priorities for the alternatives system. I find this quite an interesting idea, really. I think you could get much the same affect with some well chosen tags and debtags. e.g. you could filter on: command line only tools enterprise tools (e.g. groupware, RDBMS) scientific tools (e.g. octave, R) sysadmin tools (e.g. mrtg) That could work too; however, in that case the proviciency level of your filter would need to be pretty expert-ish, I'm afraid. Which would defeat the purpose, kinda. -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
31.05.2005 pisze Stephen Birch ([EMAIL PROTECTED]): Still looks more like a fork than a derivative . or a spoon :-) ``The question is: who cares?''. Or, better: does it really matter, what name will be used? Are you perchance a free software taxonomist? Jubal -- [ Miros/law L Baran, baran-at-knm-org-pl, neg IQ, cert AI ] [ 0101010 is ] [ BOF2510053411, makabra.knm.org.pl/~baran/, alchemy pany ] [ The Answer ] Cauliflower is nothing but Cabbage with a College Education. -- Mark Twain -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proficiency-level tag for debian packages
On Tuesday 31 May 2005 19:55, Wouter Verhelst wrote: This would be rather arbitrary and probably be liable to cause disagreements. Not much more so than with the priorities for the alternatives system. I find this quite an interesting idea, really. Alternatives are down a fairly narrow axis - is text editor X more appropriate to install by default than editor Y which can be argued quite sensibly along the lines of popularity or ease of use for the novice. Is KMail easier to use than the Gimp? Does that question even make sense to ask? command line only tools enterprise tools (e.g. groupware, RDBMS) scientific tools (e.g. octave, R) sysadmin tools (e.g. mrtg) That could work too; however, in that case the proviciency level of your filter would need to be pretty expert-ish, I'm afraid. Which would defeat the purpose, kinda. I'm not sure I understand your meaning, could you expand on that a little? I was suggesting that an install that is tagged novice or similar would not by default show packages with those tags in listings and searches, installing them only as dependencies. The only user intervention required would be to enable some kind of expert mode to get at the hidden packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Linux / Debian / Ubuntu
Listening to BBC world service right now - good mentions of Linux, Open Source, Hacker Ethic - and specifically Ubuntu (mentioned as derived from Debian Linux). Go Digital - on air and on line Also mentioning open source ethic as a possible way of developing e.g. drugs and other collaborative developments and that Linux enthusiasts came along to advise/share experience. GO DEBIAN :) Andy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proficiency-level tag for debian packages
Will Newton [EMAIL PROTECTED] writes: This would be rather arbitrary and probably be liable to cause disagreements. I think you could get much the same affect with some well chosen tags and debtags. e.g. you could filter on: command line only tools enterprise tools (e.g. groupware, RDBMS) scientific tools (e.g. octave, R) sysadmin tools (e.g. mrtg) Even within these categories there is some need for finer grain. For example, groupware clients are mostly easy, end-user, corporate groupware servers are mostly impossible, sysadmin, corporate, server But debtags should cope with this? I can see an installer screen like the old tasksel menu, where I can say to someone over the phone: Yes, now the installer should have brought up a long list of words with tick-boxes by them. Select easy, desktop, internet, end-user, corporate and OurLocalPackages. Now click [Install All Relevant] cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Debian Packaging Question
Hello all, I hope I have the right list. If not, just kindly point me in the right direction. I am attempting to develop my own .deb packages that customize a debian installation for our network. Some of my packages attempt to divert files out of the way in preinst before unpacking my custom files in their place. A good example is autofs. My autofs configuration package will attempt to divert /etc/auto.master in preinst, and unpack my own /etc/auto.master in it's place. But, when I try to have the autofs packages and my autofs configuration package installed at the same time, I get some errors back from my preinst script: | Unpacking autofs (from .../autofs_4.1.3+4.1.4beta2-10_i386.deb) ... | Selecting previously deselected package libhesiod0. | Unpacking libhesiod0 (from .../libhesiod0_3.0.2-15.1_i386.deb) ... | Selecting previously deselected package autofs-hesiod. | Unpacking autofs-hesiod (from .../autofs-hesiod_4.1.3+4.1.4beta2-10_i386.deb | ) ... | Selecting previously deselected package tiem.autofs-config. | Unpacking tiem.autofs-config (from .../tiem.autofs-config_1.0_all.deb) ... | tiem.autofs-config::preinst::install (new version) | *** WARNING: Cannot divert file: | File: /etc/auto.master | File does not exist | *** WARNING: Cannot divert file: | File: /etc/auto.media | File does not exist | dpkg: error processing /var/cache/apt/archives/tiem.autofs-config_1.0_all.de | b (--unpack): | trying to overwrite `/etc/auto.master', which is also in package autofs | tiem.autofs-config::postrm::abort-install (new version) The error messages are from my preinst script, which checks for the existence of the files-to-be-diverted before attempting to divert them. I thought I had this licked, because I made my autofs configuration package (tiem.autofs-config) Pre-Depend on autofs and autofs-hesiod. I thought that doing so would force dpkg to configure autofs and autofs-hesiod *BEFORE* installing my tiem.autofs-config. What *should* I be doing instead? Thanks for your help, Michael Peek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 01:34:51PM -0500, John Goerzen wrote: I may do that too, but its architecture support is abysmal compared to Debian, so I have no choice in the matter at this point (and lack the time to port ubuntu to all my archs). Ubuntu currently has first-class ports for i386, amd64 and powerpc, and second-class ports for ia64 and sparc. Whether that qualifies as abysmal, of course, depends on the needs of the individual or organization involved. Which is too bad; it shouldn't be too hard to have ubuntu support every arch that debian does. Given that Ubuntu is based on Debian, there isn't much porting work to be done at all for architectures that Debian already supports. However, any new port needs a custodian (or better, a team of them) to take responsibility for it. Given that, it is not a problem to get the relevant infrastructure in place for building and distributing packages. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 10:17:38AM -0700, Stephen Birch wrote: Normal debian etiquette identifies the maintainer of a new package as the first person to file an ITP. So how is this coordinated with Ubuntu? In some cases, Ubuntu maintainers are not also Debian maintainers, and as such would require sponsorship in order to upload their packages to Debian. Ubuntu, on the other hand, imports all new source packages from Debian, so there's no problem in that direction. At first glance, it would seem sensible for Ubuntu maintainers to file ITPs in order to avoid duplication of effort. However, it's not clear to me how they should proceed once they have packaged the software and uploaded it to Ubuntu. Ideally, they would be connected with a sponsor to upload the package to Debian, but this can't be a requirement Unless I missed the ITP and filed a double by mistake we appear to have two independent wifi-radar maintainers now. The Ubuntu one and the debian one. I don't see a wifi-radar package in Ubuntu, so unless I've missed something, yours is the most authoritative package. But I sure want to see good coordination between Ubuntu and Debian. As do we, of course. Patches to bugs, debian maintainers picking up the patches from the patch repository, inter-team communication. It depends. Still looks more like a fork than a derivative . or a spoon :-) I don't know what basis you're using for this terminology, but fork in the context of open source projects tends to have a negative connotation of non-cooperation, which is certainly not the intent in the case of Ubuntu. The -mm branch of Linux could technically be called a fork, but given that it serves a purpose complementary to that of Linus' tree, and provides a source of patches to be merged into mainline, it would be misleading to refer to it as such. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proficiency-level tag for debian packages
On Tuesday 31 May 2005 20:07, Rich Walker wrote: Even within these categories there is some need for finer grain. For example, groupware clients are mostly easy, end-user, corporate groupware servers are mostly impossible, sysadmin, corporate, server If you are installing a groupware server you probably want to do more research than that. Groupware clients like evolution and kmail I would guess would come under the end-user classification. But debtags should cope with this? Debtags would cope with the scheme I proposed above, which I would not suggest would be 100% ideal, but is probably an 80/20 solution. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dear Adrian Bunk, Please hold off a week or two
On Tue, May 31, 2005 at 11:36:06AM +0200, Thijs Kinkhorst wrote: On Tue, May 31, 2005 03:43, Miles Bader wrote: Bernd Eckenfels [EMAIL PROTECTED] writes: Actually I am glad somebody is working public visible on the release issues and would not critisize him for that. Pointing out a problem is nice, but doing so in an obnoxious manner hurts. I would like to add: pointing out a problem is easy, providing good solutions is a lot harder. Continuously pointing out problems (the metric is wrong, testing is bad) is destructive critisism, There's nothing wrong with destructive criticism. The correct solution to an activity which is actually bad *is* to destroy it. Some activities don't need replacing with a more productive one, they just need eliminating. Being obnoxious is unproductive, but that's not the annoying thing here either. The thing about Bunk which is annoying is the way he is continually searching for reasons to destroy testing by proving it bad, and continually *failing*. Not many people would mind if he was actually right. It's being wrong every time, on a weekly basis (because he has an axe to grind but no actual point) which annoys people. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Example where testing-security was used?
On Tue, May 31, 2005 at 11:46:29AM -0500, Adam Heath wrote: On Tue, 31 May 2005, Steve Langasek wrote: Moore's Law governs the rate at which the speed of hardware (at a given price-point) doubles. It says nothing about the speed at which current software will *run* on current machines; and it certainly has nothing to say about the speed at which such software will run on machines that are no longer on the Moore's Law curve due to a lack of new hardware being designed/manufactured for that architecture. Actually, doesn't Moore's Law mean the average for all new silicon? So, some cutting-edge new hardware may evolve faster than the average. No, it's just the rate of growth of one given *line* of chips. The 'fastest chip available' has never really followed it, too many external factors. Although it may do now that x86-64 is going mainstream; the principal reason it's never worked historically is because the 'fastest' machines have been obscure stuff that gets fucked for business reasons. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Example where testing-security was used?
On Tue, May 31, 2005 at 03:08:09PM +0200, Pierre Habouzit wrote: In any case, given the number of prospective ports waiting in the wings, 11 is probably a roughly correct estimate even if we *do* drop some architectures. (And since non-release ports are likely to stay in unstable, and adding a release port adds three w-b databases where dropping one only removes two w-b databases, it takes 1 1/2 dropped archs to balance one added arch...) in all those debates about the lack of buildds, sth seems odd to me. I've always thought that moore's law was quite accurate... and my understanding (I may be wrong, it's only how I understand the whole thing) is that debian growth is quite linear, compared to the cpu speed, disk size, BW ... growth, the time passing, we should have less and less limitations. Moore's law is cpu speed. The effective speed of software roughly halves every 18 months (java, python, XML, SOAP, etc). In other words, the rate of hardware performance increase is almost entirely cancelled out by the rate of growth of software inefficiency; demands expand to fill available resources. We scrape together some new features, but aside from specialist/scientific stuff, the actual *functional* speed of computers does not increase much at all. If you sit down at a gnome desktop on a modern box, it's not actually all that different in performance or general behaviour to what'd you got on Acorn RiscOS or OS/2 ten years ago. Openoffice Write takes about as long to load from hard drive as Impression Style took to load from a floppy - and it doesn't do a hell of a lot more that you're actually going to use. This probably says something significant. [Note that trying *modern* software on an old box, and observing how much slower it is, just underlines my point. The comparison here is to the software you would have run on it when the box was new]. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Debian Packaging Question
On Tue, 2005-05-31 at 14:51 -0400, Michael S. Peek wrote: What *should* I be doing instead? You should forward it to -mentors mailing list. -- David Moreno Garza [EMAIL PROTECTED] | http://www.damog.net/ Windows isn't a virus, viruses do something. GPG: C671257D - 6EF6 C284 C95D 78F6 0B78 FFD3 981C 5FD7 C671 257D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning without physically meeting ... thoughts?
On Tue, May 31, 2005 at 09:03:12AM -0600, Wesley J. Landaker wrote: I wrote this up to someone. I thought I'd share it, and get your thoughts. (e.g. anybody see any weaknesses in #1-#3 that *aren't* present in the typical meet, check ID, get GPG fingerprint, assuming #4 is always used afterwards?) Falsifying a government-issued ID is a criminal offence, regardless of how often it happens (using it to buy alcohol is not important; they simply raise the minimum age to compensate, so there's no need to enforce it there). Falsifying a random photograph is not illegal at all, and there is no reason why somebody wouldn't do it. Nothing here has verified their identity with any strength to speak of. A person who wants to generate an identity can do so with minimal effort and no repercussions - so why wouldn't they? On Tuesday 31 May 2005 08:44, Wesley J. Landaker wrote: For instance, I don't know if this is officially acceptable or not, but I would probably be willing to sign someone's key even if I hadn't met them in person, if I got in the mail: 1) A picture of them holding a recent newspaper with their GPG fingerprint and signature written on it. (This would relate the person's face signature with their GPG key, and verify that it's recent). 2) A copy of an acceptable (probably government-issued, non-expired) picture ID. (This would relate the person's face with their government identity). 3) A signed, dated, and notarized statement saying something to the effect of My name is __, my active e-mail that I control is [EMAIL PROTECTED], and the GPG fingerprint of my active key that I control and is not compromised is __. Attached to this statement is a picture of me with a newspaper dated ___ with the same GPG fingerprint, and a copy of my ___ photo ID, which I have shown to the undersigned notary. Signed __, notarized by ___. (Relates the date (which should be reasonably close to the time when the picture in #1 was taken--a few weeks at the most), their name, e-mail, and GPG fingerprint together by the statement, and the picture from #1, and with their government identity, as that is checked by the notary). 4) I'd sign the key, and send the updated key to the e-mail address given, signed by the GPG key with the fingerprint given. (Relates the e-mail address with the GPG key, as if they can't get the e-mail or decrypt the e-mail to get the signature, it effectively hasn't really been signed). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
* Stephen Birch | Tollef Fog Heen([EMAIL PROTECTED])@2005-05-31 18:06: | * Stephen Birch | | | The project seems to have established a mechanism for putting new | | packeges directly into Ubuntu. Are new Ubuntu packages also put in | | Debian by the Ubuntu team members? | | Yes. Sorry, I originally misread your question. They aren't necessarily put in Debian, but they may be. It depends on whether the person uploading to Ubuntu is also a DD or has a Debian sponsor. | Let me give you an example. I filed an ITP this morning on a | promising package called wifi-radar. | | After writing the ITP I discovered someone has already built a deb for | Ubuntu and placed it on the Ubuntu wiki. But they did not file an | ITP. | | Normal debian etiquette identifies the maintainer of a new package as | the first person to file an ITP. So how is this coordinated with | Ubuntu? It's not coordinated per se, but this isn't a problem either. If the version in Ubuntu is modified from the version in Debian, they won't be synced automatically. If you want to work with the maintainer in Ubuntu -- that's great and the result will hopefully be even better. | Unless I missed the ITP and filed a double by mistake we appear to | have two independent wifi-radar maintainers now. The Ubuntu one and | the debian one. In this instance there isnt an issue, I just want to | see the software packaged and I'll happily yeald to the other | maintainer if he/she wants. But I can see the possibility of a | conflict in future when this happens with other packages. If the person maintaining the Ubuntu version wants to make some changes and those aren't accepted by Debian, it's just a forked package with no harm done (except for any wasted effort). | | Also, when Ubuntu makes improvements to packages how do those | | improvements flow back to Debian? | | Patches to bugs, debian maintainers picking up the patches from the | patch repository, inter-team communication. It depends. | | Still looks more like a fork than a derivative . or a spoon :-) It's both and not. I think of a fork as we want to do this differently and we're not going to waste effort getting stuff merged again. Ubuntu isn't that; Ubuntu is trying to get the changes back into Debian so they don't have to maintain their own versions forever. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 08:56:15AM -0700, Stephen Birch wrote: Forgive me if this has already been discussed ... if so could someone give me a pointer to the thread. All the time. Just look for anything about ubuntu on -devel or -project. I find myself fairly confused about Ubuntu packages. I had thought that Ubuntu is a Debian derivative. Therefore I expected new packages to be first placed in Debian and then flow to Ubuntu. However, I recently found this page: https://www.ubuntulinux.org/wiki/MOTUNewPackages The project seems to have established a mechanism for putting new packeges directly into Ubuntu. Are new Ubuntu packages also put in Debian by the Ubuntu team members? The Ubuntu literature indicates that Ubuntu is a derivative of debian but it looks more like a fork to me. It's a fork. Also, when Ubuntu makes improvements to packages how do those improvements flow back to Debian? They generally don't. Ubuntu considers it more effective to spend their time on PR to make people think they are giving stuff back, than to actually do it; it generates more 'goodwill', since most people won't bother to check. This thread will probably become a good example, most of the others did. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Example where testing-security was used?
Andrew Suffield [EMAIL PROTECTED] writes: Moore's law is cpu speed. *TRANSISTORS* on a single die http://www.intel.com/research/silicon/mooreslaw.htm cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
John Goerzen([EMAIL PROTECTED])@2005-05-31 13:34: I may do that too, but its architecture support is abysmal compared to Debian, so I have no choice in the matter at this point (and lack the time to port ubuntu to all my archs). That is unfortunate for you. I am lucky (or unlucky perhaps) in that all of my customers' machines are x86 based. May be a sub-optimal platform but it does make sys admin easier. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: proficiency-level tag for debian packages
Will Newton [EMAIL PROTECTED] writes: On Tuesday 31 May 2005 20:07, Rich Walker wrote: Even within these categories there is some need for finer grain. For example, groupware clients are mostly easy, end-user, corporate groupware servers are mostly impossible, sysadmin, corporate, server If you are installing a groupware server you probably want to do more research than that. Hence the impossible tag. Having attempted to install a bunch of groupware servers on a machine, I'd agree with you that More Research Is Needed - but having a tag that tells you you only want to do this if you are a wizard will at least ensure others don't try without fair warning :- Groupware clients like evolution and kmail I would guess would come under the end-user classification. Yes, I just like the idea of being able to filter on multiple keys simultaneously. easy + ( end-user | corporate ) you would expect to install, say, the Mozilla packages, some kind of LDAP support, DHCP-clients, and so on. But debtags should cope with this? Debtags would cope with the scheme I proposed above, which I would not suggest would be 100% ideal, but is probably an 80/20 solution. Better than 0! cheers, Rich. -- rich walker | Shadow Robot Company | [EMAIL PROTECTED] technical director 251 Liverpool Road | need a Hand? London N1 1LX | +UK 20 7700 2487 www.shadow.org.uk/products/newhand.shtml -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux / Debian / Ubuntu
I demand that Andrew M.A. Cater may or may not have written... Listening to BBC world service right now - good mentions of Linux, Open Source, Hacker Ethic - and specifically Ubuntu (mentioned as derived from Debian Linux). Go Digital - on air and on line Also mentioning open source ethic as a possible way of developing e.g. drugs and other collaborative developments and that Linux enthusiasts came along to advise/share experience. GO DEBIAN :) For those who've missed the first three broadcasts today, there's one more at 01:05 GMT; also see URL:http://news.bbc.co.uk/2/hi/technology/1478157.stm. -- | Darren Salt | linux (or ds) at | nr. Ashington, | sarge,| youmustbejoking | Northumberland | RISC OS | demon co uk | Toon Army | URL:http://www.youmustbejoking.demon.co.uk/ (PGP 2.6, GPG keys) Many receive advice, few profit by it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Miros/law Baran([EMAIL PROTECTED])@2005-05-31 21:02: ``The question is: who cares?''. Or, better: does it really matter, what name will be used? Its not the name that would bother me, it is the result. As Matt Zimmerman pointed out elsewhere in this thread a fork is quite negative and has the potential to badly damage both projects. The Unix world was badly hurt by deliberate code forking during the 80s. Those of us who lived through it are scared of a repeat. It does look as if Ubuntu has none of the characteristics of a code fork that can create such damage. Are you perchance a free software taxonomist? No .. not at all. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Example where testing-security was used?
On Tue, May 31, 2005 at 09:30:40PM +0100, Rich Walker wrote: Andrew Suffield [EMAIL PROTECTED] writes: Moore's law is cpu speed. *TRANSISTORS* on a single die http://www.intel.com/research/silicon/mooreslaw.htm Bah, yeah, but it's more or less the same thing for a given line of chips, even when it's not a linear relationship. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | signature.asc Description: Digital signature
Re: Is Ubuntu a debian derivative or is it a fork?
Tollef Fog Heen([EMAIL PROTECTED])@2005-05-31 22:21: ... snip It's both and not. I think of a fork as ??we want to do this differently and we're not going to ???waste??? effort getting stuff merged again??. Ubuntu isn't that; Ubuntu is trying to get the changes back into Debian so they don't have to maintain their own versions forever. Ah .. that is what I wanted to read. That makes sense. Cool. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On 5/31/05, Andrew Suffield [EMAIL PROTECTED] wrote: Also, when Ubuntu makes improvements to packages how do those improvements flow back to Debian? They generally don't. Ubuntu considers it more effective to spend their time on PR to make people think they are giving stuff back, than to actually do it; it generates more 'goodwill', since most people won't bother to check. This thread will probably become a good example, most of the others did. If you've been around d-d awhile, you know not to take Andrew's randomly directed flame cannon very seriously. I have no relationship to Debian and Ubuntu other than satisfied industrial-scale user (and kibitzer), but I think it's inane to kvetch about Ubuntu's pattern of giving stuff back over the last year. Software process is hard work, especially when you add an extra layer of judgment calls between upstream and release engineering. What is the point of, say, harassing the glibc maintainer to take a patch against the version in sid, when he's planning on jumping to 2.3.4 as soon as sarge releases? If you want evidence on which to judge the sincerity of Ubuntu's giving back, watch what happens post-sarge. I'm optimistic, largely because the Ubuntu folks seem to have thick enough skins to shrug off attitudes like Andrew's. Cheers, - Michael
Re: Is Ubuntu a debian derivative or is it a fork?
Hi Ante, welcome to the debian project! Ante Karamati?([EMAIL PROTECTED])@2005-05-31 20:09: First of all, hi to all developers! I packaged that wifi-radar for Ubuntu. It was my first package and I didn't fill ITP, untill it was reviewed by others. I'm sorry for not filling ITP. I didn't know I have to. I'm new in creating packages and don't know all the rules. No problem at all, I am the guy that filed the ITP (Intent To Package) before I knew of your work. Lets chat off the list about how you want to proceed. I'll do the best I can to help. I only started this thread because it seems there is the possibility of problems later on with other packages with packages being created by two people, one on Ubuntu and one on Debian. Duplicated effort. So, could someone point me to some HOWTO or documentation regarind the ITP and debian etiquette? Debian is quite well documented in most areas, but there is a ton to read. Here is a good place to start http://www.debian.org/devel/join/ Speaking of package. It has few changes regarding upstream (man page, Genereally it is a good idea to contact the upstream developer. Most are delighted to hear that somebody is planning to do the packaging work on their behalf. Most times they will accept patches and try to incorporate your improvements into the package. That is excellent because you don't have too keep patching with each new release from upstream. autodetection of wifi interface, menu entry and uses gksudo instead of sudo). Why did you not use sudo? Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Packaging Question
* Michael S. Peek | I am attempting to develop my own .deb packages that customize a debian | installation for our network. Some of my packages attempt to divert files out | of the way in preinst before unpacking my custom files in their place. A good | example is autofs. My autofs configuration package will attempt to divert | /etc/auto.master in preinst, and unpack my own /etc/auto.master in it's place. Be aware of the fact that diverting conffiles doesn't work. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, 2005-05-31 at 11:54 -0700, Matt Zimmerman wrote: I don't see a wifi-radar package in Ubuntu, so unless I've missed something, yours is the most authoritative package. wifi-radar will get in Ubuntu. But, I can stop this process and open a discussion about it. If I'm not mistaken, Stephen agreed over private corespondance that I'll do maintaining in Ubuntu, and he'll upload package to Debian. This would be perfect example of vice versa contribution. But, as I said, I'm willing to stop importing wifi-radar into Ubuntu, untill we get agreement about this kind of situations. -- Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225 http://master.grad.hr/~ivoks/|--|ICQ: 64631782 May, 15. herve we're fixing the universe, it's not an easy duty! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, 2005-05-31 at 14:08 -0700, Stephen Birch wrote: Debian is quite well documented in most areas, but there is a ton to read. Here is a good place to start http://www.debian.org/devel/join/ Thanks. Genereally it is a good idea to contact the upstream developer. Most are delighted to hear that somebody is planning to do the packaging work on their behalf. Most times they will accept patches and try to incorporate your improvements into the package. That is excellent because you don't have too keep patching with each new release from upstream. I contacted upstream week or two ago, notifying him about debianized wifi-radar. He said he would put package on website, but that didn't happend. Why did you not use sudo? I find wifi-radar.sh useless script. It's used only to start wifi-radar as root. Instead of runing that script, I created .desktop entry that will exec 'gksudo wifi-radar'. gksudo is much nicer than runing shell script. But, you can allways open terminal, and run sudo wifi-radar. It's same thing. -- Ante Karamatic|--|ivoks(@)grad.hr|--|PGP: D3BDA225 http://master.grad.hr/~ivoks/|--|ICQ: 64631782 May, 15. herve we're fixing the universe, it's not an easy duty! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 11:14:53PM +0200, Ante Karamati wrote: On Tue, 2005-05-31 at 11:54 -0700, Matt Zimmerman wrote: I don't see a wifi-radar package in Ubuntu, so unless I've missed something, yours is the most authoritative package. wifi-radar will get in Ubuntu. But, I can stop this process and open a discussion about it. If I'm not mistaken, Stephen agreed over private corespondance that I'll do maintaining in Ubuntu, and he'll upload package to Debian. This would be perfect example of vice versa contribution. But, as I said, I'm willing to stop importing wifi-radar into Ubuntu, untill we get agreement about this kind of situations. If you've come to an agreement with Stephen, then please carry on with it according to your agreement, regardless of any discussions about how to handle this situation in the future. Thanks, -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Steve writes: The Unix world was badly hurt by deliberate code forking during the 80s. Those of us who lived through it are scared of a repeat. I don't believe that a Free Software fork can cause such damage. The Unix wars of the eighties depended on closed-source licensing. They also resulted from deliberate policies of attempting to lock-in customers with differentiation. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Release update: minor delay; no non-RC fixes; upgrade reports
On Tue, May 31, 2005 at 04:29:31AM -0700, Steve Langasek wrote: On Mon, May 30, 2005 at 12:59:26PM +0200, Adrian Bunk wrote: Since it seems noone of the release team bothered to pay this part of the price for the testing release process, I'm sometimes using one or two spare hours to go a bit through update_excuses and report half a dozen of such issues. Steve saw this, and before the latest release update he sent (which was the one before yours), he asked me in a private mail about a prediction how many such RC bugs I'd expect in sarge for inclusion in his release update. It seems my prediction about the number of such issues didn't match his wishes regarding the state of sarge, and he did therefore neither answer my email nor mention this in the release update nor does it seem he assigned a member of the release team to do this work properly. On the contrary, I found your answer reasonably satisfactory, and as a result had postponed replying to you in favor of dealing with more directly pressing release issues. You indicated that as of two weeks ago, you'd been through the middle seventh of update_excuses checking for unidentified RC bugs, and that most of the packages below this range were not in testing and therefore wouldn't hold many hidden RC bugs; and I've been tracking the status of RC bugs closed since the freeze began, which accounts for many (though not all) of the more recent uploads. What's the current number of RC bugs you've tracked this way? Am I right to assume that you count them when looking whether you reach your 15 RC bugs in your metric you want to achieve today? So it is probably true that sarge will release with some RC bugs that could have easily been fixed had we known about them, but I don't think this number will be so great that we want to redirect resources or delay the release in order to try to catch them. I don't think it's realistic to charge the release team with identifying all RC bugs in the distribution, only to take care that we don't release with them once they are so identified. Not all RC bugs (there are most likely many not yet reported RC bugs in sarge). It's all RC bugs that are both known and already fixed in unstable. It might sound old-fashioned, but Debian used to be famous for it's stability. I remember times when there where two weeks test cycles where the whole thing was frozen with zero changes for at about a week, and if any serious problems were found they were fixed and then there was the next test cycle. Why is there now always such a hurry to get everything out within a week? Why are there always extremely aggressive timelines (with at least three publically announced release dates for sarge already passed) instead of making everything more relaxed for being able to improve sarge without being in a big hurry? [1] And no, version tracking in the BTS wouldn't prevent this problem. In my experience, there are so many of these issues reported with a wrong version or manually closed or even without any bug report in the BTS that claiming version tracking might eliminate this problem sounds like a bad joke. shrug The problems you describe are not ones that would go away with the removal of testing; if maintainers are not engaged in the process of ensuring their packages are free of RC bugs for release, and do not take care that RC bugs are a) documented in the BTS, b) filed at the correct severity, and c) fixed in the version of the package that's releasing (in case something goes wrong with a and b), we are going to miss RC bugs that could have been caught. This is a social problem, not a technical one, and I don't think there are any viable technical solutions. Relying on version tracking will add one more point where this existing social problem might have negative impacts on the quality of your releases. For my part, I have explicitly *not* given a free pass to packages with RC bugs that were filed a long time ago but only recently raised to their proper severity. It's great if bug submitters know what severity a bug should be filed at, but it's the *responsibility* of the maintainer to adjust the severity if it's wrong -- even if that means raising the severity, something none of us want to do. Even more, it's the maintainer's responsibility to *deal with* such bugs at the proper severity even if they were filed wrong. It simply can't be the responsibility of any central group to babysit the severities of bugs filed: that's not scalable in the least. So yes, sarge will ship with bugs that should have been considered RC. But this is inevitable in any case because of the many RC bugs that are never *identified* by our testing, so there's no reason for the release team to treat these bugs as blocking issues if no one cares enough to make sure they're brought to our attention. This doesn't mean that your work
Re: Example where testing-security was used?
* Marc 'HE' Brockschmidt ([EMAIL PROTECTED]) [050531 08:58]: Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, May 30, 2005 at 11:48:54AM +0100, Mark Brown wrote: On Mon, May 30, 2005 at 12:34:21PM +0200, Adrian Bunk wrote: But setting up autobuilders doesn't require a new infrastructure (and shouldn't require more than half a year). Wasn't the infrastructure a prerequisite for woody and is working? It turned out that the central part of the existing infrastructure didn't scale up well enough to cope with the new architectures in sarge. There are no new architectures in sarge. That's right, but the buildd network has to work for both oldstable and stable. potato + woody didn't need as many buildds as woody + sarge will need. Especially as potato didn't had security buildds. :) Cheers, Andi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311413: ITP: nunit -- Automated testing framework for .NET
Package: wnpp Severity: wishlist Owner: Jelmer Vernooij [EMAIL PROTECTED] * Package name: nunit Version : 2.2.0 Upstream Author : Charlie Poole [EMAIL PROTECTED] * URL : http://www.nunit.org/ * License : zlib/png license Description : Automated testing framework for .NET NUnit is a unit testing framework for all .NET languages. It serves the same purpose as JUnit does in the Java world. It supports test categories, testing for exceptions and writing test results in plain text or XML. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8.1 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311420: ITP: cl-aspectl -- provides aspect orientation for the Common Lisp Object System
Package: wnpp Severity: wishlist Owner: Rene van Bevern [EMAIL PROTECTED] * Package name: cl-aspectl Version : 0.6.4 Upstream Author : Pascal Constanza [EMAIL PROTECTED] * URL : http://common-lisp.net/project/aspectl/ * License : Creative Commons 2.0 Description : provides aspect orientation for the Common Lisp Object System AspectL provides support for aspect oriented programming to Common Lisp. Features include: * Generic Pointcuts: Join points and aspect weavers * Mixins: Incrementally modify class definitions * Rebinding places instead of assigning them * Special generic functions: methods that are executable in the current dynamic scope only . Homepage: http://common-lisp.net/project/aspectl/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Murphy's Law.
Confusion not only reigns, it pours. Safe Sex It is a good thing for an uneducated man to read books of quotations. Shake a leg Chip on his Shoulder http://www.tamountophtime.com/ Shake a leg Vampire Jaywalk Van Gogh's ear for music Why is the third hand on the watch called the second hand? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311421: ITP: haploview -- [Biology] visualisation of SNP data with linkage disequilibrium
Package: wnpp Severity: wishlist Owner: Steffen Moeller [EMAIL PROTECTED] * Package name: haploview Version : 3.2 Upstream Author : Jeffrey Barrett, Julian Maller in Mark Daly's lab [EMAIL PROTECTED] * URL : http://www.broad.mit.edu/mpg/haploview/index.php * License : Comes with its own DFSG-compliant license Description : [Biology] visualisation of SNP data with linkage disequilibrium Haploview is designed to simplify and expedite the process of haplotype analysis by providing a common interface to several tasks relating to such analyses. Haploview currently allows users to examine block structures, generate haplotypes in these blocks, run association tests, and save the data in a number of formats. All functionalities are highly customizable. The problem with haploview is its use of Java2 features that are not yet implemented by free tools. Anybody willing to help out sponsoring please contact me. The package is on http://bioinformatics.pzr.uni-rostock.de/~moeller/debian/haploview Many thanks and regards Steffen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
2005-05-31, k keltezssel 16.24-kor John Hasler ezt rta: Steve writes: The Unix world was badly hurt by deliberate code forking during the 80s. Those of us who lived through it are scared of a repeat. I don't believe that a Free Software fork can cause such damage. Forks in OSS do have drawbacks, this is why they are generally frowned upon. Of course there are cases when advantages greater than drawbacks, esp. when the latter are minimized, e.g. by submitting back patches. Taxonomists may argue that such forks has to be called spoons;) Other taxonomist may also argue that Debian is an infrastructural distribution, which is well suited to be the base of such spoons.
Re: Dear Adrian Bunk, Please hold off a week or two
Santiago Vila [EMAIL PROTECTED] writes: * unstable is actually frozen, which means uploads for unstable are either discouraged, they remain in the limbo, or they are automatically put in some other distribution above unstable, like new-unstable, until testing or unstable becomes the new stable. At which point there are *still* fixed bugs that don't make it into the release. They're fixed upstream, fixed in experimental, fixed in private working repositories that don't get uploaded due to the freeze, etc. There are also the bugs that people just don't notice. As near as I can tell (and I've had a package affected by this), the release team is doing a great job making sure that fixes that they know about propagate into sarge. There will be fixes they don't know about. There will be RC bugs found after the release. Debian is just far, far too large to be able to release a bug-free distribution. This isn't a serious problem; this is just life. If they're RC and actually significant (some of the missing dependencies are RC but not really that important for normal use scenarios), hopefully they can be fixed through proposed-updates. Let's not spend a bunch of time fretting about the last 1%. Doing something reasonable and then going with it will produce results that will be quite acceptable in practice. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Wed, Jun 01, 2005 at 04:49:20AM +0200, mag wrote: 2005-05-31, k keltezéssel 16.24-kor John Hasler ezt írta: Forks in OSS do have drawbacks, this is why they are generally frowned upon. Of course there are cases when advantages greater than drawbacks, esp. when the latter are minimized, e.g. by submitting back patches. Taxonomists may argue that such forks has to be called spoons;) Other taxonomist may also argue that Debian is an infrastructural distribution, which is well suited to be the base of such spoons. Perhaps, but there are some issues with that. In the ubuntu case in particular, I wish that they would be more proactive in sending their patches to the Debian maintainers. Asking us Debian folk to go to an obscure site somewhere, wade through listings of thousands of diffs, and find changes is difficult. For example, Python 2.4 is in sid, and I don't mind making my packages use it now. I'd appreciate any and all diffs from ubuntu folks. Sometimes they are changing things for some unique ubuntu way. I'd like to ask them: why must the Ubuntu way be different from Debian? Is there a better way we could minimize patches and perhaps do something like provide differing defaults? I've also been on the other side of the coin, and something that makes it difficult for the derivers is lack of communication from some quarters of Debian. I certainly recall frustration about inactive maintainers, and we must remember that there are maintainers in Debian that can't even be bothered to apply good patches when they see them. Finally, I would like to see many more developers putting their packages a distributed version control system like Arch or, better yet, Darcs. It makes it a lot easier for others to collaborate with you. For an example of what I'm talking about, see http://darcs.complete.org. Most of the directories there are Debian packages, and most of my Debian packages are in darcs. darcs-buildpackage and tla-buildpackage are your friends :-) -- John
Re: Is Ubuntu a debian derivative or is it a fork?
Steve writes: The Unix world was badly hurt by deliberate code forking during the 80s. Those of us who lived through it are scared of a repeat. I wrote: I don't believe that a Free Software fork can cause such damage. mag writes: Forks in OSS do have drawbacks, this is why they are generally frowned upon. I agree that they may have drawbacks, but I don't believe that they can cause the sort of damage that the Unix wars caused. -- John Hasler [EMAIL PROTECTED] Elmwood, WI USA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning without physically meeting ... thoughts?
On Tuesday 31 May 2005 14:11, Andrew Suffield wrote: On Tue, May 31, 2005 at 09:03:12AM -0600, Wesley J. Landaker wrote: I wrote this up to someone. I thought I'd share it, and get your thoughts. (e.g. anybody see any weaknesses in #1-#3 that *aren't* present in the typical meet, check ID, get GPG fingerprint, assuming #4 is always used afterwards?) Falsifying a government-issued ID is a criminal offence, regardless of how often it happens (using it to buy alcohol is not important; they simply raise the minimum age to compensate, so there's no need to enforce it there). Falsifying a random photograph is not illegal at all, and there is no reason why somebody wouldn't do it. Nothing here has verified their identity with any strength to speak of. A person who wants to generate an identity can do so with minimal effort and no repercussions - so why wouldn't they? Right, but they have to get it notarized (or forge a notary's seal, which is a criminal offense, at least in the US) which requires government ID (again, at least in the US). Regardless, how is this different from meeting someone in person? They can just show me their fake ID--I won't know it's fake. (And, as you said, forged ID happens a lot and is easily available. =) -- Wesley J. Landaker [EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpwZ651ztwc2.pgp Description: PGP signature
Re: Keysigning without physically meeting ... thoughts?
On Tue, 31 May 2005 14:13:54 -0600 Wesley J. Landaker [EMAIL PROTECTED] wrote: On Tuesday 31 May 2005 14:11, Andrew Suffield wrote: On Tue, May 31, 2005 at 09:03:12AM -0600, Wesley J. Landaker wrote: I wrote this up to someone. I thought I'd share it, and get your thoughts. (e.g. anybody see any weaknesses in #1-#3 that *aren't* present in the typical meet, check ID, get GPG fingerprint, assuming #4 is always used afterwards?) Falsifying a government-issued ID is a criminal offence, regardless of how often it happens (using it to buy alcohol is not important; they simply raise the minimum age to compensate, so there's no need to enforce it there). Falsifying a random photograph is not illegal at all, and there is no reason why somebody wouldn't do it. Nothing here has verified their identity with any strength to speak of. A person who wants to generate an identity can do so with minimal effort and no repercussions - so why wouldn't they? Right, but they have to get it notarized (or forge a notary's seal, which is a criminal offense, at least in the US) which requires government ID (again, at least in the US). Regardless, how is this different from meeting someone in person? They can just show me their fake ID--I won't know it's fake. (And, as you said, forged ID happens a lot and is easily available. =) So why bother with steps 1 2 when 3 is the only one that carries any weight? Maybe there is a good reason that I do not know of, but I can not think of any. I am genuinely curious, though. Just my $0.02. Jacob -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 08:21:01PM -0500, John Hasler wrote: mag writes: Forks in OSS do have drawbacks, this is why they are generally frowned upon. I agree that they may have drawbacks, but I don't believe that they can cause the sort of damage that the Unix wars caused. Not only that, but we're developing some quite sophisticated tools to manage them. Darcs is my favorite example of this, with its every checkout is a fork, and every push is a merge way of operation. Quite powerful and elegant, IMHO. I no longer subscribe to the forking is inherently bad idea. Cooperative forking can, and often has, been a Good Thing. Example: baz, which is more or less a fork of tla. In some ways, it serves as an unstable tla, where new ideas get tested. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning without physically meeting ... thoughts?
On Tuesday 31 May 2005 20:48, Jacob S wrote: Regardless, how is this different from meeting someone in person? They can just show me their fake ID--I won't know it's fake. (And, as you said, forged ID happens a lot and is easily available. =) So why bother with steps 1 2 when 3 is the only one that carries any weight? Maybe there is a good reason that I do not know of, but I can not think of any. I am genuinely curious, though. The general idea was to be purposefully overkill--that if they were going to forge something, they'd have to forge a whole lot of it. Partly, this was in response to the (perceived(?)) guideline that you shouldn't ever sign someone's public key unless you've met them in person--I was trying to narrow down all of the links that were important (seeing the person's face, seeing their ID, seeing that the two match, knowing that it was actually the person I saw who has control of the key and that same person has control of their e-mail address, etc). Barring something I just totally missed, I believe what I wrote up is at least as good at determining that a person is who they say they are as meeting in person and checking ID's. Obviously there are always the issue of forgeries, but I don't think this method is any *worse* in the respect. But I thought I'd give anyone interested a chance to bang at the idea, because I'm curious if someone else knows something I don't. =) -- Wesley J. Landaker [EMAIL PROTECTED] OpenPGP FP: 4135 2A3B 4726 ACC5 9094 0097 F0A9 8A4C 4CD6 E3D2 pgpCORrW0LTyO.pgp Description: PGP signature
Re: More about GFDL
Cesar Martinez Izquierdo wrote: El Viernes 22 Abril 2005 14:37, Maciej Dems escribi: I have a simple question concerning the GFDL discussion. Does the GFDL documentation which currently does not contain any invariant section have to go to non-free as well? Yes, until the GFDL is revised, mainly due to the so-called anti-DRM clause. First of all, to avoid Invariant-Section-like problems, the document also must include no cover texts. Acknowledgements and Dedications appear to suffer similar problems (though it's unclear). (One of the things which makes these worse than similar requirements in other licenses is that these apparently must be included *in* rather than *alongside* the document, and presumably in the table of contents as well. The title preservation requirements are also troublesome.) But without all of these? Still not free. The anti-DRM clause, as written, makes the GFDL documentation non-free. (We believe that this is a mistake and hope that it will be fixed in the next version.) In addition, the transparent and opaque forms section is of uncertain freeness, and we haven't got a clarification. It's unclear, but the license may also prohibit pseudonymous authorship, which would be non-free, and we haven't got a clarification. -- This space intentionally left blank.
Re: Is Ubuntu a debian derivative or is it a fork?
2005-05-31, k keltezssel 21.00-kor John Goerzen ezt rta: Other taxonomist may also argue that Debian is an infrastructural distribution, which is well suited to be the base of such spoons. Perhaps, but there are some issues with that. In the ubuntu case in particular, I wish that they would be more proactive in sending their patches to the Debian maintainers. Sometimes they are changing things for some unique ubuntu way. Okay, these were the problems. And here is a good part of the solution: Finally, I would like to see many more developers putting their packages a distributed version control system like Arch or, better yet, Darcs. If everyone in the food chain, at least down from the debian maintainer, would use that, it would greatly simplify problems with patch management. Just I highly doubt it is doable. It could also help to apply upper stream patches for spoons while sticking to their spoonerisms ;), and even not giving them back in patches again and again. I guess that we, as Debian developers have no ground to criticise downstream for doing things in their own way, provided they don't keep pushing things deemed unacceptable. It is another thing that I also used to be nervous to an other Debian spoon;) when my friends ask for help, and I face its own little ugly ways like completely changed init, or postinst scripts made completely unintelligible...
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 09:00:33PM -0500, John Goerzen wrote: In the ubuntu case in particular, I wish that they would be more proactive in sending their patches to the Debian maintainers. Asking us Debian folk to go to an obscure site somewhere, wade through listings of thousands of diffs, and find changes is difficult. For example, Python 2.4 is in sid, and I don't mind making my packages use it now. I'd appreciate any and all diffs from ubuntu folks. I don't want to repeat the discussion about pushing patches; there's a perfectly reasonable one already in the list archives. There are good reasons why we do this the way that we do. FWIW, the diffs you would get from Ubuntu would build for Python 2.4 _as the default version_, which isn't what you want. After Sarge, releases, it should be pretty straightforward for someone to set up a script to mass-mail Debian maintainers copies of the Python transition patches from Ubuntu (or all of the patches, if that's really what they believe that Debian maintainers want). Sometimes they are changing things for some unique ubuntu way. I'd like to ask them: why must the Ubuntu way be different from Debian? Is there a better way we could minimize patches and perhaps do something like provide differing defaults? You might as well ask the same question of any Debian derivative. The reason that derivatives exist is because people want different things. In the case of Ubuntu, we outline on our website what we do differently. It is of course in our best interest to keep the delta manageable, and we try to do that. I've also been on the other side of the coin, and something that makes it difficult for the derivers is lack of communication from some quarters of Debian. I certainly recall frustration about inactive maintainers, and we must remember that there are maintainers in Debian that can't even be bothered to apply good patches when they see them. Indeed, for all of the gripes about submitting patches, a disappointingly small fraction of the patches that Ubuntu proactively submits are actually uploaded to Debian by the maintainer. Finally, I would like to see many more developers putting their packages a distributed version control system like Arch or, better yet, Darcs. It makes it a lot easier for others to collaborate with you. For an example of what I'm talking about, see http://darcs.complete.org. Most of the directories there are Debian packages, and most of my Debian packages are in darcs. In the not-so-distant future, a huge proportion of Ubuntu development will take place in Arch branches, with the intent of promoting more efficient collaboration both within Ubuntu and with Debian. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
Michael K. Edwards([EMAIL PROTECTED])@2005-05-31 13:56: What is the point of, say, harassing the glibc maintainer to take a patch against the version in sid, when he's planning on jumping to 2.3.4 as soon as sarge releases? If you want evidence on which to judge the sincerity of Ubuntu's giving back, watch what happens post-sarge. I'm optimistic, largely because the Ubuntu folks seem to Okay - you have my attention. If you are right etch will be as beautiful as Hoary within a few weeks of the sarge release. Oh my gosh, I hope and pray you are right. We are all watching ... Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Linux / Debian / Ubuntu
Darren Salt([EMAIL PROTECTED])@2005-05-31 21:49: For those who've missed the first three broadcasts today, there's one more at 01:05 GMT; also see URL:http://news.bbc.co.uk/2/hi/technology/1478157.stm. Why on earth does the BBC force its listeners to all hit its servers at the same time. Doesn't make sense at all, why not ogg the program up and put it on its servers so the audience can listen when they want. Okay, so I know the answer. The BBC is still coming to grips with the idea that boradcasting is dead. The tech generation wants to time and space shift programming to a convenient time/location. Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is Ubuntu a debian derivative or is it a fork?
On Tue, May 31, 2005 at 07:47:19PM -0700, Matt Zimmerman wrote: On Tue, May 31, 2005 at 09:00:33PM -0500, John Goerzen wrote: example, Python 2.4 is in sid, and I don't mind making my packages use it now. I'd appreciate any and all diffs from ubuntu folks. I don't want to repeat the discussion about pushing patches; there's a perfectly reasonable one already in the list archives. There are good reasons why we do this the way that we do. A discussion, yes... perfectly reasonable, not so much :-( Anyway, it was not my intention to beat that particular dead horse. Want to do us Debian folks a big favor for little work? Provide a view of your patches sorted by maintainer, then by source package. After Sarge, releases, it should be pretty straightforward for someone to set up a script to mass-mail Debian maintainers copies of the Python transition patches from Ubuntu (or all of the patches, if that's really what they believe that Debian maintainers want). I'd prefer wishlist bugs tagged patch when there is a patch relevant for Debian, personally. You might as well ask the same question of any Debian derivative. The reason that derivatives exist is because people want different things. In the case of Ubuntu, we outline on our website what we do differently. I'm aware of that. There are cases, though, where people tend to create a difference when it's not necessary. A common place is graphics on the default desktop. I don't know if Ubuntu changes those, but I know some derivatives do, and thus have to fork some packages. I figure it would be easier to use /etc/alternatives to manage those defaults, but that's just me. It is of course in our best interest to keep the delta manageable, and we try to do that. Yes, of course. Indeed, for all of the gripes about submitting patches, a disappointingly small fraction of the patches that Ubuntu proactively submits are actually uploaded to Debian by the maintainer. Out of curiousity, do you have a rough estimate of the percentage that actually make it into Debian? Or the percentage that are held back with no good reason? In the not-so-distant future, a huge proportion of Ubuntu development will take place in Arch branches, with the intent of promoting more efficient collaboration both within Ubuntu and with Debian. Very nice. Looks like someone needs to write the Arch backend for darcs :-) BTW, the baz folks could get some very neat ideas from darcs. The offline mode comes free way of working is very nice, and the branching being easier than Arch is nice, too. -- John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Keysigning without physically meeting ... thoughts?
On Tue, 31 May 2005 14:13:54 -0600, Wesley J. Landaker [EMAIL PROTECTED] wrote: Right, but they have to get it notarized (or forge a notary's seal, which is a criminal offense, at least in the US) which requires government ID (again, at least in the US). The entire procedure is quite US centric. I don't understand why you US guys are so fond of your notaries. Over here, it's a three digit bill for the notary to open the office door and to offer you a chair, so there might be cultures where one thinks twice or even three times before having something notarized. Additionally, the web of trust is the web of trust because it is entirely self-contained, without putting any trust on government and state official. Your suggestion violates this principle by moving the verification state to the notary. Even if the notary were sufficiently advanced to offer PGP key signing with her official key this were not good enough for Debian, since the Debian web of trust explicitly relies on being self-contained. You'd need to have a DD notary, which at this point makes the signature valid because of the DD property, and being notary becomes irrelevant. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fon: *49 621 72739834
Accepted mozilla-locale-de-at 1.7.8-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Mon, 30 May 2005 13:05:11 +0200 Source: mozilla-locale-de-at Binary: mozilla-locale-de-at Architecture: source all Version: 1.7.8-1 Distribution: unstable Urgency: high Maintainer: Florian M. Weps [EMAIL PROTECTED] Changed-By: Johannes Rohr [EMAIL PROTECTED] Description: mozilla-locale-de-at - Mozilla German Language/Region Package Closes: 311228 Changes: mozilla-locale-de-at (1.7.8-1) unstable; urgency=high . * New upstream release (closes: #311228) Urgency set to high to reach Sarge just in time (Andreas Tille) * Bumped Standards-Version to 3.6.1.1. (No changes required) (Andreas Tille) Files: 1fb08430c5df0f2b52283fcf4cb25daf 680 web optional mozilla-locale-de-at_1.7.8-1.dsc 4ec8583c0ef07fb77fd1082bfa7ce476 1741532 web optional mozilla-locale-de-at_1.7.8.orig.tar.gz 9fc796bf6f3e98204f60dd9674dc81a3 29844 web optional mozilla-locale-de-at_1.7.8-1.diff.gz 3d710824308f208ef74d179b0725c0f1 724844 web optional mozilla-locale-de-at_1.7.8-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCm/qXYDBbMcCf01oRAjn/AJ91Zbnn19R2Wz6A/4kNYUDQelLARgCgiXAA 2jkIGlFCJaQ0iQAuevfLSrM= =9soe -END PGP SIGNATURE- Accepted: mozilla-locale-de-at_1.7.8-1.diff.gz to pool/main/m/mozilla-locale-de-at/mozilla-locale-de-at_1.7.8-1.diff.gz mozilla-locale-de-at_1.7.8-1.dsc to pool/main/m/mozilla-locale-de-at/mozilla-locale-de-at_1.7.8-1.dsc mozilla-locale-de-at_1.7.8-1_all.deb to pool/main/m/mozilla-locale-de-at/mozilla-locale-de-at_1.7.8-1_all.deb mozilla-locale-de-at_1.7.8.orig.tar.gz to pool/main/m/mozilla-locale-de-at/mozilla-locale-de-at_1.7.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted mozilla-locale-pl 1:1.7.8-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 31 May 2005 08:44:24 +0200 Source: mozilla-locale-pl Binary: mozilla-locale-pl Architecture: source all Version: 1:1.7.8-1 Distribution: unstable Urgency: low Maintainer: Robert Luberda [EMAIL PROTECTED] Changed-By: Robert Luberda [EMAIL PROTECTED] Description: mozilla-locale-pl - Mozilla Polish Language/Region Package Changes: mozilla-locale-pl (1:1.7.8-1) unstable; urgency=low . * New upstream version. Files: 6243464f2a57d13a2b8c8cb8b7793b09 663 web optional mozilla-locale-pl_1.7.8-1.dsc b2d7a1f0fb140085f7dcc839b3c34cb2 1406027 web optional mozilla-locale-pl_1.7.8.orig.tar.gz f44b16cfe7e575ff4c0fc839cd9aa4c9 14185 web optional mozilla-locale-pl_1.7.8-1.diff.gz 32b5a8f28ae91af9ae14125946a15037 627314 web optional mozilla-locale-pl_1.7.8-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnAgsThh1cJ0wnDsRAhCSAJ4ozQCmIGL3efmyNOJaCeber8SxIgCbBWXB g7yywT2lMunczStLyGOZoa0= =OjuF -END PGP SIGNATURE- Accepted: mozilla-locale-pl_1.7.8-1.diff.gz to pool/main/m/mozilla-locale-pl/mozilla-locale-pl_1.7.8-1.diff.gz mozilla-locale-pl_1.7.8-1.dsc to pool/main/m/mozilla-locale-pl/mozilla-locale-pl_1.7.8-1.dsc mozilla-locale-pl_1.7.8-1_all.deb to pool/main/m/mozilla-locale-pl/mozilla-locale-pl_1.7.8-1_all.deb mozilla-locale-pl_1.7.8.orig.tar.gz to pool/main/m/mozilla-locale-pl/mozilla-locale-pl_1.7.8.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted wordpress 1.5.1.2-1 (all source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sun, 29 May 2005 00:52:39 +1000 Source: wordpress Binary: wordpress Architecture: source all Version: 1.5.1.2-1 Distribution: unstable Urgency: high Maintainer: Kai Hendry [EMAIL PROTECTED] Changed-By: Kai Hendry [EMAIL PROTECTED] Description: wordpress - a semantic personal publishing platform or weblog manager Changes: wordpress (1.5.1.2-1) unstable; urgency=high . * New upstream release * Another security release: http://wordpress.org/development/2005/05/security-update/ Files: 1500a651e379742b7eb73ae39b0ba7ed 563 web optional wordpress_1.5.1.2-1.dsc 8822ea8c096ccb7d0c23f34c5a270481 297629 web optional wordpress_1.5.1.2.orig.tar.gz 0c2f20d8e54c57616281dec7a51e17a3 6170 web optional wordpress_1.5.1.2-1.diff.gz 70ff97d5f4feecfa1d9fb4810ed05618 302226 web optional wordpress_1.5.1.2-1_all.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnBbpK/juK3+WFWQRAkn6AKCMzuDmE1nIzPu6jSFIDlYxXcYtjACdGiAc UEA8+YhW1NdE0/GwcqK5zb0= =1d/1 -END PGP SIGNATURE- Accepted: wordpress_1.5.1.2-1.diff.gz to pool/main/w/wordpress/wordpress_1.5.1.2-1.diff.gz wordpress_1.5.1.2-1.dsc to pool/main/w/wordpress/wordpress_1.5.1.2-1.dsc wordpress_1.5.1.2-1_all.deb to pool/main/w/wordpress/wordpress_1.5.1.2-1_all.deb wordpress_1.5.1.2.orig.tar.gz to pool/main/w/wordpress/wordpress_1.5.1.2.orig.tar.gz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted smart 0.35-1 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 25 May 2005 12:14:18 +0200 Source: smart Binary: smartpm Architecture: source i386 Version: 0.35-1 Distribution: unstable Urgency: low Maintainer: Michael Vogt [EMAIL PROTECTED] Changed-By: Michael Vogt [EMAIL PROTECTED] Description: smartpm- An alternative package manager that works with dpkg/rpm Changes: smart (0.35-1) unstable; urgency=low . * New upstream release * uses dpatch Files: a0866d2e29ad7267d5fd16a8523d41e4 605 admin optional smart_0.35-1.dsc 26361dab53afc7b0b6f753f0f2ae5469 601067 admin optional smart_0.35.orig.tar.gz e1291bb9bf7c9bad8c1a93fc955f9c1a 3566 admin optional smart_0.35-1.diff.gz 374c68f1d87e5dcf4cbdbefcc092d180 275818 admin optional smartpm_0.35-1_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCnB+zliSD4VZixzQRAgWZAJsFxVpOW4jsIylevgVIBg4UgyVYegCgouBx 61gu0+5O399/UrT2bE+Gjfg= =WIg+ -END PGP SIGNATURE- Accepted: smart_0.35-1.diff.gz to pool/main/s/smart/smart_0.35-1.diff.gz smart_0.35-1.dsc to pool/main/s/smart/smart_0.35-1.dsc smart_0.35.orig.tar.gz to pool/main/s/smart/smart_0.35.orig.tar.gz smartpm_0.35-1_i386.deb to pool/main/s/smart/smartpm_0.35-1_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Accepted roxen4 4.0.325-3 (i386 source all)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Tue, 31 May 2005 10:54:29 +0200 Source: roxen4 Binary: roxen4-doc roxen4 Architecture: source i386 all Version: 4.0.325-3 Distribution: unstable Urgency: low Maintainer: Turbo Fredriksson [EMAIL PROTECTED] Changed-By: Turbo Fredriksson [EMAIL PROTECTED] Description: roxen4 - The Roxen Challenger Webserver roxen4-doc - Roxen 4.0 documentation Closes: 309247 Changes: roxen4 (4.0.325-3) unstable; urgency=low . * Make sure that roxen4-doc depends on roxen4 since the documentation is in MySQL DB format _and_ only viewable through a Roxen4 server (because of Roxen specific RXML tags). Closes: #309247 Files: db984ec1f069e03b27cc01f37b6f750d 581 web optional roxen4_4.0.325-3.dsc 6a2e51321b54e5e3381adb44b42b5e41 48210 web optional roxen4_4.0.325-3.diff.gz f08b047823f9f6c6f15000d3d3decd25 3600186 doc optional roxen4-doc_4.0.325-3_all.deb f0dc3198d5c3e02660419e2ee32aa154 7700632 web optional roxen4_4.0.325-3_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCnCaZmlWzPKccHgARAul4AJ4jrR9w6PKnQKe7kPFmujkWRjycdQCffhe0 /B7V3J21pOeBp8ESi5zXMhc= =dNVI -END PGP SIGNATURE- Accepted: roxen4-doc_4.0.325-3_all.deb to pool/main/r/roxen4/roxen4-doc_4.0.325-3_all.deb roxen4_4.0.325-3.diff.gz to pool/main/r/roxen4/roxen4_4.0.325-3.diff.gz roxen4_4.0.325-3.dsc to pool/main/r/roxen4/roxen4_4.0.325-3.dsc roxen4_4.0.325-3_i386.deb to pool/main/r/roxen4/roxen4_4.0.325-3_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
