Right of a maintainer not to respect FHS
I have a problem with a bug filed on r-doc-html (#300765). The documentation was entirely in /usr/lib, and it seems that all R packages have all their files under /usr/lib, whatever their type or purpose. I filed a bug with severity serious, as this breaks Policy 9.1.1 (FHS is mandatory). But the maintainer argued that R was packaged like this from the beginning, and that because it must stay in the distribution, the bug had to be downgraded to wishlist. SHouldn't he get the approval of the release team or ftpmasters before doing such an arbitrary downgrade? Surprinsingly, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Right of a maintainer not to respect FHS
On Mon, Apr 04, 2005 at 09:28:22AM +0200, Pierre THIERRY wrote: > I have a problem with a bug filed on r-doc-html (#300765). The > documentation was entirely in /usr/lib, and it seems that all R packages > have all their files under /usr/lib, whatever their type or purpose. > I filed a bug with severity serious, as this breaks Policy 9.1.1 (FHS is > mandatory). But the maintainer argued that R was packaged like this from > the beginning, and that because it must stay in the distribution, the > bug had to be downgraded to wishlist. > SHouldn't he get the approval of the release team or ftpmasters before > doing such an arbitrary downgrade? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=14 He has the approval of the release team. When architecture-independent files located in /usr/lib aren't referenced by the rest of the package and can be trivially relocated to /usr/share, we certainly should consider it release-critical that they be moved to the FHS-mandated location. When a package has many such files whose paths are deeply embedded in the package, some latitude is warranted. A similar exception was already made for gnustep for sarge. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: intend-to-implement: script to obtain Debian Source
Scribit Adam Heath dies 01/04/2005 hora 19:10: > Additionally, as a way to weed out other problems, any patches that > are leafs(ie, don't depend on anything) are applied in a random order. For the sake of my curiosity: - what problems do thsi random order could weed? - won't it be more difficult to trakcs bugs if it isn't predictable? Curiously, Nowhere man -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A signature.asc Description: Digital signature
Re: Right of a maintainer not to respect FHS
On Mon, 04 Apr 2005, Pierre THIERRY wrote: > I filed a bug with severity serious, as this breaks Policy 9.1.1 > (FHS is mandatory). But the maintainer argued that R was packaged > like this from the beginning, and that because it must stay in the > distribution, the bug had to be downgraded to wishlist. Then you upgraded it to serious again,[1] then Steve downgraded it[2], then Dirk downgraded it,[3] then you upgraded it *again*,[4] then he downgraded it again.[5] If you have a specific problem with the way a maintainer is handling the severity of a bug, the appropriate mechanism is to talk to them and convince them to upgrade the bug *themselves*, not to play BTS tennis with them. If you're sure that the bug should actually be upgraded, then discuss it on -devel, and get rough consensus, which should then convince the maintainer. If not, proceed to the ctte or similar as a last resort. Otherwise, all you're doing is abusing the BTS, no matter how correct your actual appraisal of the severity bug is. Don Armstrong 1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=13 2: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=14 3: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=19 4: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=26 5: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=300765&msg=30 -- Build a fire for a man, an he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -- Jules Bean http://www.donarmstrong.com http://rzlab.ucr.edu signature.asc Description: Digital signature
Re: NEW handling: About rejects, and kernels
On Sun, Apr 03, 2005 at 02:10:34PM -0400, Daniel Burrows wrote: > On Sunday 03 April 2005 05:51 am, Wouter Verhelst wrote: > > Putting items from the non-free archive in the installer images does > > just that. It is debatable whether the intention is the same, but by our > > rulebook, this is not allowed. > > Wait...so you're saying it's OK to put non-free stuff in the > installer image if we close our eyes and put our fingers in our ears > and pretend that it's free and put it in "main" No, absolutely not. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Sun, Apr 03, 2005 at 11:22:51PM +1000, Hamish Moffatt wrote: > Given some options: > > 1. Don't distribute the firmware blob at all; > 2. Provide a way to download the blob during install (while admitting >this won't work if the blob is the code for your ADSL modem); > 3. Provide the blob on disk in the regular install media (ie in main); > 4. Provide the blob on disk in a special tained installer >(ie in non-free or a special firmware section). > > Which do you think makes the system *depend* less or more on non-free > software? (Depend is the key word.) Option 3, which I thought people were advocating (it now is clear to me that they were really advocating option 4) -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Sun, Apr 03, 2005 at 12:36:57PM +0200, Marco d'Itri wrote: > On Apr 03, Wouter Verhelst <[EMAIL PROTECTED]> wrote: > > On Sat, Apr 02, 2005 at 04:51:18PM +0100, Henning Makholm wrote: > > > | Installer images x, y, and z belong to the 'main' distribution of > > > | Debian, and therefore do support various recent makes of hardware > > > | (link to list) that require non-free firmware that cannot go into > > > | 'main'. If you need to have one these devices work before you can > > > | access the network, you will want to use one of the installer images > > > | u, v, and w, from the 'non-free' section. > > Ah, that is what you mean. I thought you were advocating to put the > > non-free firmware blobs in the installer images in main. > Indeed, this would mean that Debian would not support these devices, so > I'm opposed to this "solution". Then either go and ask the hardware developers to make their firmware blobs Free, or start your own distribution. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Right of a maintainer not to respect FHS
Hi Pierre, On Mon, Apr 04, 2005 at 09:28:22AM +0200, Pierre THIERRY wrote: > I have a problem with a bug filed on r-doc-html (#300765). The > documentation was entirely in /usr/lib, and it seems that all R packages > have all their files under /usr/lib, whatever their type or purpose. How is that a problem in itself? I agree that those files should move to /usr/share but that may be a problem to get done. I'd suggest putting them in /usr/share and adding symlinks in /usr/lib. For invidual files this is too much work though - it could work for directories. > SHouldn't he get the approval of the release team or ftpmasters before > doing such an arbitrary downgrade? He did it seems. And anyway it is his decision how much work to spend on this. Greetings Torsten signature.asc Description: Digital signature
Re: intend-to-implement: script to obtain Debian Source
On 04-Apr-05, 02:48 (CDT), Pierre THIERRY <[EMAIL PROTECTED]> wrote: > Scribit Adam Heath dies 01/04/2005 hora 19:10: > > Additionally, as a way to weed out other problems, any patches that > > are leafs(ie, don't depend on anything) are applied in a random order. > > For the sake of my curiosity: > > - what problems do thsi random order could weed? Unnoted dependencies that just happen to be fulfilled due to a consistent (though arbitrary) application order. By applying in a different order each time, you should trigger an error fairly quickly. > - won't it be more difficult to trakcs bugs if it isn't predictable? If you get an error during the patching process, it should be fairly easy to determine that it's an un-marked dependency, and then find it by hand. You can also impose arbitrary dependencies among your supposedly "independent" patches until you find the troublesome combination. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
On Mon, Apr 04, 2005 at 11:13:55AM +0200, Wouter Verhelst wrote: > On Sun, Apr 03, 2005 at 11:22:51PM +1000, Hamish Moffatt wrote: > > Given some options: > > > > 1. Don't distribute the firmware blob at all; > > 2. Provide a way to download the blob during install (while admitting > >this won't work if the blob is the code for your ADSL modem); > > 3. Provide the blob on disk in the regular install media (ie in main); > > 4. Provide the blob on disk in a special tained installer > >(ie in non-free or a special firmware section). > > > > Which do you think makes the system *depend* less or more on non-free > > software? (Depend is the key word.) > > Option 3 Why? In all 4 cases, your hardware depends on the blob being loaded, regardless of whether Debian is involved. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: init.d script dependencies for etch?
martin f krafft wrote: also sprach Bastian Blank <[EMAIL PROTECTED]> [2005.04.01.2104 +0200]: Uh, this looks like a "pull" type of thing in which ever init.d script starts its dependencies. I don't think this is a good idea. No, it is not. The dependencies are cached. Cached? As in queried beforehand? As in two-pass algorithm, once iterating init.d with 'depends' as option, then with 'start' ? Yeah, that sounds nice. My sarcasm detector went off with this one, so I'll try to intervene. AFAIK the Gentoo /etc/rc does the following: 1. for all init.d scripts, read it, call depend(), determine its dependencies, store its start() function somewhere; 2. for all dependency-ordered determined, call the start() functions paralelizing when possible And, yes, it's very nice. HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An alternative analysis of the etch architecture proposal
Frank Lichtenheld wrote:
> On Tue, Mar 15, 2005 at 05:50:23PM +0100, Adrian Bunk wrote:
> [...]
> > - issues with space on ftp.debian.org and on mirrors
> > (especially hindering amd64)
> >
> > It might be a better point to start moving non-released architectures
> > (GNU Hurd and sh) to a different location. Depending on what exactly
> > hinders amd64 today, this might be sufficient [2].
>
> No. The plan is definetly to get the main archive down from currently
> over 100 GB to something way more reasonable (as there are currently planned
> two archs, this would mean something between 30 and 40 GB) and to get the
> needed daily pulses down from currently up to 2.5 GB.
Why not improving the mirror network and the mirror software?
I.e. why not requiring only the five tier-1 mirrors to mirror the
entire archive *and* providing Tools for easy mirroring a subset of
DISTR x ARCHS
DISTR =
{stable,testing,unstable,stable-proposed-updates,testing-proposed-updates}
ARCHS = {alpha arm hppa i386 ia64 m68k mips mipsel powerpc s390 sparc}
(plus whatever will be added in the future)
In order to support simple mirroring I could even think about a
slightly modified directory layout, such as:
.../pool/... contains source + i386 binary packages
.../ports/... contains all other binary packages
The Package files would then point to the proper locations. This
would help non-tier-1 mirrors that don't want to mirror all
architectures to do so without more complicated mirror software. And
it wouldn't drop architectures the way it is planned.
Maybe I'm missing the point. I'd appreciate an explanation.
Regards,
Joey
--
Ten years and still binary compatible. -- XFree86
Please always Cc to me when replying to me on the lists.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The sarge release disaster - some thoughts
Adrian Bunk wrote: > The milestone that included the start of the official security support > for sarge was only 6 days after the announcement, but is was missed by > more than 6 months. > > Whyever it was expected to get testing-security for sarge that quick, it > should have been obvious 6 days later that it wasn't possible that > quick. > > What would have been a second plan? > Use testing-proposed-updates. > > Using testing-proposed-updates for security fixes, users might have > gotten security updates one or two days after the DSA on some > architectures. > > Would this have been an ideal solution? > No. > But it would have worked without a great impact on the release date. No, it wouldn't, since t-p-u isn't autobuilt for all architectures either. We would win nothing by using it without manually building the packages on the missing architectures. > RC bugs - only a metric > --- > > Nowadays, it seems the main metric to measure the quality of a release > inside Debian is the RC bug count. > > As with any metrics, work on improving the metric might make the metric > look much better, but doesn't at the same time imply that the overall > quality improved that much. > > > An example: > > A major problem in Debian are MIA developers. > > Consider a MUA maintained by a MIA developer with the following bugs: > - #1 missing build dependency (RC) > - #2 MUA segfaults twice a day (not RC) These are fixed during BSPs, so no problem to spend more time on. > Consider the two possible solutions: > 1. a NMU fixing #1 done. > 2. - ensure that the maintainer is MIA >- orphan all packages of the MIA maintainer >- new maintainer adopts MUA >- new maintainer fixes both bugs This is already the case > Dump testing? > - > > It seems noone asks the following question: > Testing - is it worth it? As a preparation for stable and an interim "solution" between stable and unstable it's quite well. > Several people have stated that with the size of Debian today, it > wasn't possible to manage a release without testing with a "traditional" > freeze (unstable will be frozen at a date, announced several months > before), and that only testing makes releasing possible. I believe that it helps a lot to get and keep the software in proper shape for a release with all supported architectures and depending packages. > I remember that when testing was introduced, it was said that testing > might always be in a releasable state. History has shown that testing > was sometimes in a better shape as unstable, but also sometimes in a > worse shape. Testing has some advantages over unstable (always > fulfillable dependencies, some kinds of brown paperbag bugs are very > unlikely), but serious data loss bugs like #220983 are always possible. As in unstable... Assume a working testing-proposed-updates and testing sounds near perfect. > testing was expected to make shorter freezes possible. > Neither the woody nor the sarge freeze support this claim. > This might not only be the fault of testing, but the positive effects of > testing (if any) aren't visible. Hmm, we're not waiting for testing to freeze but we're waiting for missing infrastructure to be implemented. Or am I mistaken? > This might make a freeze a bit longer? > Perhaps. > But consider the disadvantages of testing: > - Testing causes additional work for both the release team and all > Debian developers. > As an example, library transitions are always a pain due to testing. Uh? For the user, they're a lot better since they will happen instantly, something that usually doesn't work with unstable. Yes, they do cause work for the release people and some maintainers are annoyed by the delay to get all affected packages and architectures in sync. > And RC bugs already fixed in unstable but not in testing need to be > tracked. When testing ist not partially frozen and the package runs fine in the archive, it'll migrate into testing automatically. Tracking is only required during a (partial) freeze. > - Architectures have to be in sync due to testing. ... due to an upcoming release. > An architecture without an autobuilder is dead. Ack. > But if an architecture doesn't has any autobuilder for two weeks > this wouldn't cause any problems if testing wouldn't exist. It would be easier if more buildds would be accepted for such architectures or if it would be easier to add an interim buildd for these architectures. Regards, Joey -- Ten years and still binary compatible. -- XFree86 Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The sarge release disaster - some thoughts
Eduard Bloch wrote: > > Also, bear in mind that if we'd have done that, then we would still be > > where we are right now, but would not have the debian installer ready to > > release with sarge. > > Maybe. But AFAICS there are only few developers that have worked on > both, b-f and d-i. So how would keeping b-f have damaged d-i? Maybe it > would give less motivation and so not attract enough new developers, but > from my point of view, it just has been the other way round. d-i people > took over debian-boot overnight and most previous b-f people > disappeared because of feeling beeing replaced. Unfortunately (?!) only very few people were motivated to work on b-f to get it in proper shape for any release after potato. We may have had working b-f earlier than working d-i but that's only speculation. I believe that the chances are good that d-i was ready earlier still. Regards, Joey -- Ten years and still binary compatible. -- XFree86 Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Can we be friends?
Hi , I have the feeling that this piece of mail will reach you in a perfect state of mind and in a better healthy codition. While searching through the net, I came accross your contact address and decided to contact you. I believe and also have the feeling that in todays world, neither race, nationality nor religion will any longer posse a barrier to male/female relationships. Although, we do not know each other well but I will really like to have you as a friend or pen pal if that is better for you.I am a single lady of 25years old, currently studing international relations at the University of California Los Angeles (UCLA), a citizen of the United States of America residing in Los Angeles with my parents, Presently, I am doing my final year in the University and so anncious to graduagate from the University into the free world. While I hope to hear from you soon, Ialso look forward to receiving some information concerning you, your family, country and even your personal life experiences. This will give us the opportunity of knowing each other better and be able to understand ourselves more. May God bless you as I wait to hear from you soon through this email address. [EMAIL PROTECTED] Thanks. Yours Love, Cindy Ruben. 2E -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.296 / Virus Database: 266.9.1 - Release Date: 01/04/2005
Re: More DDTP problems
[EMAIL PROTECTED] wrote: > > The questions below were posted at long time in the DDTP-Coors list, but > weren't replied :((( > > IMHO the ddts code needs a revision to correct bugs, I am wrong? This > revision is possible? I can help. It needs a thorough source code review before it can be reactivated again. Regards, Joey -- Ten years and still binary compatible. -- XFree86 Please always Cc to me when replying to me on the lists. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to detect which user is connected to $DISPLAY
Michelle Konzack wrote:
> I asume your are using TESTING or UNSTABLE...
> Under STABLE I get only something like
>
> joss pts/0Mar 26 14:42
> joss pts/1Mar 26 14:42
> toto pts/2Mar 26 15:06
>
> This is, why I have asked...
> The test I must do, should work under WOODY and higher Releases.
FWIW: That's not always the case. Below is a real-world example
from a woody system with XDM:
koulutie!joey(pts/4):~> w
19:28:13 up 29 days, 8:52, 6 users, load average: 0.02, 0.04, 0.06
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
joey tty2 -09Mar05 9days 1:15 1:14 ssh finlandia
joey :0 -06Mar05 ?xdm? 0.00s ? -
joey pts/0:0.0 06Mar05 29days 0.26s 0.26s bash
joey pts/2:0:S.0 06Mar05 3days 6:13 6:13 ssh finlandia
joey pts/3:0:S.1 06Mar05 29days 32:05m 32:05m ssh finlandia
joey pts/4finlandia.home.i 07Mar05 1.00s 5.44s 0.18s w
koulutie!joey(pts/4):~> w | awk '{print $1" "$2}' | grep ":0$" | awk '{print
$1}'
joey
koulutie!joey(pts/4):~>
So Sean's script works fine as it should be.
It doesn't, if X is started via startx, though.
Regards,
Joey
--
Ten years and still binary compatible. -- XFree86
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
dynamic partial mirror, apt-get fails
Hi everybody, I am trying to implement a cgi script for mirroring a small part of a large collection of files (the debian distribution). The idea is to mirror only those files which are requested, by downloading them "on the fly" when the clients request them. Requests in the form "wget http://local.mirror.pt/~debian/cgi-bin/get.cgi?pool/main/a/abcde/abcde.deb"; work fine already. The script get.cgi verifies if the file exists. If it exists, the script simply sends a "Location: ..." directive to its standart output and exists. If the file does not exist, the script downloads it from one of several predefined locations, and after the downloading process has succeeded it sends a "Location: ..." directive to its standard output and exits. This is more or less what apt-proxy (and other proxies) do, except that my script is independent of the directory structure (it should work for any collection of files, not only for the debian distribution) and it can be run by an ordinary user (you don't have to be root in order to install it). Now, the problem is that the debian package manager (dselect or apt-get) does not work exactly like wget. Requests in the form "apt-get http://..."; fail with the strange message "302 Found". I looked a little bit into the source of both wget and apt-get and it seems to me that wget has code which deals specifically with the "Location: ..." directive, while apt-get has not. The questions are: Is my conclusion above correct ? Are future versions of apt-get going to accept "Location: ..." directives ? Should I try and modify the source of apt-get in order to teach it to handle these directives ? You can find all the details about my problem at my web page: http://cmaf.ptmat.fc.ul.pt/~barbaros -> english -> computers and programming -> deb_part_mirr Thank you. Cristian Barbarosie -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
watch file for SourceForge packages
Recently I've been using umn [1] in my watch files for SourceForge packages. It looks like this link is dead now. I find I have to update the watch file for all my SourceForge packages every six months or so. Finding a new link that works is usually not trivial. Does anyone maintain a list of working SourceForge mirrors suitable for watch files? Thanks, Shaun [1] ftp://sourceforge.cs.umn.edu/pub/sourceforge/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: watch file for SourceForge packages
On Mon, Apr 04, 2005 at 11:21:41AM -0700, Shaun Jackman wrote: > Recently I've been using umn [1] in my watch files for SourceForge > packages. It looks like this link is dead now. I find I have to update > the watch file for all my SourceForge packages every six months or so. > Finding a new link that works is usually not trivial. Does anyone > maintain a list of working SourceForge mirrors suitable for watch > files? Use something like http://prdownloads.sourceforge.net/projectname/somefile-(.*)\.tar\.gz Works for me. BTW: are you still working on SWT and SwingWT packages? Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More DDTP problems
Hi Martin, On Monday, 04 Apr 2005, you wrote: > [EMAIL PROTECTED] wrote: > > > > The questions below were posted at long time in the DDTP-Coors list, but > > weren't replied :((( > > > > IMHO the ddts code needs a revision to correct bugs, I am wrong? This > > revision is possible? I can help. > > It needs a thorough source code review before it can be reactivated > again. I am currently on that (started last weekend). Jeroen sent me the CVS tarball. I hoped to finished it at the weekend but it's more than expected and i did not yet understand all code. Perhaps it is also a good idea if some more people could go over the code, as many eyes see more than two eyes do. Joey, would it be okay for you if i/we think that the code is okay, i/we send you a signed mail including the md5sum of every file? Or is the md5sum of the tarball enough? Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The sarge release disaster - some thoughts
On Mon, Apr 04, 2005 at 05:19:41PM +0200, Martin Schulze wrote: > Adrian Bunk wrote: > > The milestone that included the start of the official security support > > for sarge was only 6 days after the announcement, but is was missed by > > more than 6 months. > > > > Whyever it was expected to get testing-security for sarge that quick, it > > should have been obvious 6 days later that it wasn't possible that > > quick. > > > > What would have been a second plan? > > Use testing-proposed-updates. > > > > Using testing-proposed-updates for security fixes, users might have > > gotten security updates one or two days after the DSA on some > > architectures. > > > > Would this have been an ideal solution? > > No. > > But it would have worked without a great impact on the release date. > > No, it wouldn't, since t-p-u isn't autobuilt for all architectures > either. We would win nothing by using it without manually building > the packages on the missing architectures. Please correct me if my understanding was wrong. As far as I understood it, the situation was: t-p-u lacks autobuilders on some architectures. s-p-u required a non-trivial amount of changes in Debian-internal software. My point is: It turned out that the work to get s-p-u running requires more than half a year. If this was the _the_ show-stopper for the release, I can't believe it could take more than a few weeks for getting running autobuilders for architectures lacking autobuilders for getting t-p-u running. Then you can work around the missing s-p-u by using t-p-u. This way, you'd have reduced a delay by half a year to a delay by a few weeks. > > RC bugs - only a metric > > --- > > > > Nowadays, it seems the main metric to measure the quality of a release > > inside Debian is the RC bug count. > > > > As with any metrics, work on improving the metric might make the metric > > look much better, but doesn't at the same time imply that the overall > > quality improved that much. > > > > > > An example: > > > > A major problem in Debian are MIA developers. > > > > Consider a MUA maintained by a MIA developer with the following bugs: > > - #1 missing build dependency (RC) > > - #2 MUA segfaults twice a day (not RC) > > These are fixed during BSPs, so no problem to spend more time on. Unfortunately not. BSPs tend to focus on RC bugs and the success is often measured only in the RC bugs metric. Quoting what I already said in a different email in this thread: The first example that comes into my mind is the info package where the two NMUs didn't fix the many open segfault bugs (e.g. #259561 contained a trivial patch ACK'ed by upstream being one and a half months in the BTS before the latest NMU - note that this NMU was even done by a Release Assistant). This shouldn't be a personal offense against the person who did this particular NMU - it's simply the first example coming into my mind. >... > > Dump testing? > > - > > > > It seems noone asks the following question: > > Testing - is it worth it? > > As a preparation for stable and an interim "solution" between stable > and unstable it's quite well. > > > Several people have stated that with the size of Debian today, it > > wasn't possible to manage a release without testing with a "traditional" > > freeze (unstable will be frozen at a date, announced several months > > before), and that only testing makes releasing possible. > > I believe that it helps a lot to get and keep the software in proper > shape for a release with all supported architectures and depending > packages. Testing has it's advantages. There's always some manual work required for keeping testing running. And the complete release team signed the announcement stating that the testing release process is not capable of release cycles in the order of 12-18 months with 11 architectures. Are the advantages of the testing release process worth both the extra work and dropping two thirds of the Debian architectures from releases? >... > > testing was expected to make shorter freezes possible. > > Neither the woody nor the sarge freeze support this claim. > > This might not only be the fault of testing, but the positive effects of > > testing (if any) aren't visible. > > Hmm, we're not waiting for testing to freeze but we're waiting for > missing infrastructure to be implemented. Or am I mistaken? I don't know more than you. My point is: If there are areas where the testing release process has advantages over the previous release process, they weren't visible during the two releases that used the testing release process. > > This might make a freeze a bit longer? > > Perhaps. > > But consider the disadvantages of testing: > > - Testing causes additional work for both the release team and all > > Debian developers. > > As an example, library transitions are always a pain due to testing. > > Uh? For the user, they're a lot better
Re: dynamic partial mirror, apt-get fails
Op ma, 04-04-2005 te 19:16 +0100, schreef Cristian Barbarosie: > Hi everybody, > > I am trying to implement a cgi script for mirroring a small part of a > large collection of files (the debian distribution). The idea is to > mirror only those files which are requested, by downloading them "on the > fly" when the clients request them. That's such a great idea, that it has already been implemented ;-) You may want to have a look at apt-cacher. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: watch file for SourceForge packages
On Apr 4, 2005 11:06 AM, Michael Koch <[EMAIL PROTECTED]> wrote: > Use something like > http://prdownloads.sourceforge.net/projectname/somefile-(.*)\.tar\.gz > > Works for me. Doesn't work for me though. Instead of a tarball, I get an HTML file that starts with... Select a Mirror for File: /libnjb/libnjb-2.0.tar.gz > BTW: are you still working on SWT and SwingWT packages? Sure am. I'm hoping to one day compile freeguide [1] natively using SWT [2] and SwingWT [3]. If that works, Azureus is next. Cheers, Shaun [1] http://packages.debian.org/testing/source/freeguide [2] http://packages.debian.org/testing/source/swt-gtk [3] http://packages.debian.org/testing/source/swingwt [4] http://packages.debian.org/testing/source/azureus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
debram and packages temporarily absent from sarge
This mail is somewhat lengthy, and most of you do not need to read it. You want to read this mail if you maintain packages which (as of 2 April) sarge temporarily lacks. These are packages which used to be in sarge and still have hope to join the official sarge release but, for whatever reason (probably RC bugs), are not in sarge at the moment. If you do not have this problem, you can safely skip this mail. On Thursday night, I intend to update debram-data for the last time before the freeze, purging metadata on all binaries not in sarge main (i386) 2 April. If you hope that your binary will return to sarge, and if you want sarge debram users to be able to look your package up, then please e-mail me off list a copy of the relevant debian/control by 20:00 GMT Wednesday. (You don't know what debram is? E-mail me your relevant debian/control anyway. Debram is a package catalog, a primitive precursor to Debtags. You probably want your sarge packages listed in debram.) If you do not e-mail me, this is fine, but then I will reckon according to the 2 April /dists/sarge/main/binary-i386/Packages file. Preparing debram-data is not an exact science, but if you want your package ramified and listed, then I don't want to omit it; so just tell me. Send me the debian/control. You may edit the copy of debian/control appropriately before you send it to me. For example, if some of the binaries mentioned there are already safely in sarge, then you should delete mention of them from the copy. I only need to know about the problem binaries. If your binary is a new binary which has never yet entered sarge by 2 April, then I have never yet ramified it, hence debram is going to exclude it. If you want debram to include your new package anyway, this is fine, but in this case I must ask you to take the initiative and help me a little. Please first install debram, enter "debram -cp | less -r", determine the appropriate four-digit ramification number, and tentatively ramify the binary yourself. That is, add an appropriate line like Ramification: 1234 to the debian/control copy you send me. You need to do this only for binaries never before in sarge. If your package used to be in sarge, I probably still have an old ramification number on file for it; and if I don't, I will assign one promptly. Nothing really bad is going to happen to maintainers who fail to attend promptly to this mail, incidentally. It will be okay. The only thing at stake is, in a few cases debram-data may neglect to mention their packages. Following for information are listed the binaries in sid main which sarge main (i386) lacks as of 2 April. If you maintain one of these binaries, and if it used to be in sarge and you hope that it will return to sarge, reply off list. Include the relevant debian/control with your reply. abuse abuse-frabs abuse-lib abuse-sdl adonthell adonthell-data amavis-ng amavis-ng-milter-helper apcupsd-cgi apt-proxy apticron aptitude-doc-fr arpack++ asciidoc asp.net-examples aspell-bn aspseek aspseek-cgi aspseek-cgi-common aspseek-common aspseek-libmysqldb asterisk-chan-misdn asterisk-oh323 asterisk-prompt-se atomix atomix-data avifile-mad-plugin avifile-mjpeg-plugin avifile-player avifile-utils avifile-vorbis-plugin axiom-graphics axiom-graphics-data axiom-hypertex axiom-hypertex-data barrendero bayonne bayonne-doc bayonne-prompts-en bayonne-prompts-sys bbconf beep-media-player-scrobbler belocs-locales-bin belocs-locales-data bindgraph biococoa.app bitchx bitchx-dev bitchx-gtk bitchx-ssl blam blootbot bmon bookmarkbridge bookview boot-icons boson boson-base boson-data boson-music cabot cacti-cactid cantlr cbios cce ccs cgi-mapserver chdrv checkstyle chise-db cl-sql-sqlite3 clamcour cman cman-kernel-dev coco-cs coco-doc configlet-frontends convertfs coq-doc crystalspace crystalspace-data crystalspace-dev crystalspace-doc cursel dbmail-mysql dbmail-pgsql dcl debbuggtk debget debpartial-mirror decompyle2.2 didiwiki directory-administrator divine doctorj doodle doodled dosage drip drpython dvbsnoop dvr eglade ejabberd elastic-base elastic-doc emacspeak emacspeak-ss encfs erlang erlang-base eroaster evolution-data-server1.2 evolution-data-server1.2-dev ext2resize f-spot falconseye falconseye-data fence fenris flexloader flydraw fp-ide fp-units-fv freewrl fsviewer fsviewer-icons gabber2 gaim-encryption gaim-guifications gaim-themes gallimimus gauche-dev gauche-doc gauche-gdbm gcc-m68hc1x gcc-snapshot gcjwebplugin gdb-avr geda-gattrib gfs-tools ggz-docs ggz-game-servers ggz-gnome-client ggz-grubby ggz-gtk-client ggz-gtk-game-data ggz-gtk-games ggz-kde-client ggz-kde-game-data ggz-kde-games ggz-txt-client ggz-utils ggzd gjots2 gkdial gkdial-gnome gnokii gnokii-smsd gnokii-smsd-mysql gnokii-smsd-pgsql gnome-chess gnome-pim gnome-ppp gnome-xine gnomebaker gnu-smalltalk gnu-smalltalk-doc gnumach gnumach-dbg gnumach-dev gnuradio-doc gnuradio-examples gnurobbo goldedplus golem gozer gphpedit gpsim-led gr-audio-oss gramofil
Re: Right of a maintainer not to respect FHS
On Mon, 2005-04-04 at 11:53 +0200, Torsten Landschoff wrote: > For invidual files > this is too much work though - it could work for directories. Why would it be hard with individual files? Just use a shell fragment like: FILES="foo bar baz" for i in $FILES do mv "$DESTDIR/usr/lib/$i" "$DESTDIR/usr/share/$i" ln -s "/usr/share/$i" "$DESTDIR/usr/lib/$i" done -- David Mandelberg <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: Where to install ROX applications?
On Sat, Apr 02, 2005 at 06:17:33PM +0100, Tony Houghton wrote: > I was thinking of something like /usr/share/rox-desktop/Apps (I would > probably make a meta-package called rox-desktop anyway, to conveniently > install a nice bundle of applications), but that would mean having to > move the binaries into /usr/bin and modifying the AppRun scripts because > /usr/share is arch-independent. Several ROX developers seem to be rather > against that and it would make packaging a little harder. > > A location within /opt would satisfy both the FHS and the ROX community, > but not Debian I think, because I've never known any other package to > use it. > I removed an Apps dir in the old package for rox-filer which was located in /usr/lib exactly for that reason. An arch-indep dir like /usr/share/rox it's the perfect location for that kind of contents. BTW, you are welcome on the rox ML on alioth for this kind of issues. -- Francesco P. Lovergine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dynamic partial mirror, apt-get fails
On Mon, Apr 04, 2005 at 09:11:45PM +0200, Wouter Verhelst wrote: > Op ma, 04-04-2005 te 19:16 +0100, schreef Cristian Barbarosie: > > Hi everybody, > > > > I am trying to implement a cgi script for mirroring a small part of a > > large collection of files (the debian distribution). The idea is to > > mirror only those files which are requested, by downloading them "on the > > fly" when the clients request them. > > That's such a great idea, that it has already been implemented ;-) > > You may want to have a look at apt-cacher. Or approx which was just uploaded to NEW, but is also available the debian-ocaml-maint svn repo on svn.debian.org :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where to install ROX applications?
In <[EMAIL PROTECTED]>, Francesco Paolo Lovergine wrote: > I removed an Apps dir in the old package for rox-filer which was located > in /usr/lib exactly for that reason. An arch-indep dir like /usr/share/rox > it's the perfect location for that kind of contents. BTW, you are > welcome on the rox ML on alioth for this kind of issues. Thanks for that. I thought /usr/share would be the best approach. Those ROX developers who don't like Debian packaging will just have to put up with it! I've just joined the alioth mailing list, subject to confirmation. -- TH * http://www.realh.co.uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More DDTP problems
On Apr 4, 2005 4:04 PM, Martin Zobel-Helas <[EMAIL PROTECTED]> wrote: > I am currently on that (started last weekend). Jeroen sent me the CVS > tarball. I hoped to finished it at the weekend but it's more than > expected and i did not yet understand all code. > > Perhaps it is also a good idea if some more people could go over the > code, as many eyes see more than two eyes do. We've been talking about this with other people involved and I even asked Michael Bramer independently (hadn't seen your message). It would be a great thing if DDTP code could be put in alioth, so that all of us who want to make it better have access to it. Michael said it was ok with him. Could you start the alioth project with the code Jeroen sent you? -- Besos, Marga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
James Troup wrote: > Hi, > > On Sunday evening gluck.debian.org started experiencing problems > writing to it's disks. The local admins investigated and after > physically power cycling machine it became apparent that the RAID > controller was deeply unhappy - it claimed to have lost 2 out of it's > 6 RAID5'd drives. After reclaiming the drives it was left fscking > overnight for more than 9 hours. > Strange: Could there be any correlation with my observed problems about resolving anything of debian.org during exactly that time? (http://lists.debian.org/debian-isp/2005/04/msg00023.html) Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
Christian Storch wrote: >Strange: Could there be any correlation with my observed problems >about resolving anything of debian.org during exactly that time? >(http://lists.debian.org/debian-isp/2005/04/msg00023.html) > > Name Server:SAENS.DEBIAN.ORG Name Server:KLECKER.DEBIAN.ORG Name Server:SPOHR.DEBIAN.ORG Gluck doesn't appear to host DNS of any kind. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Right of a maintainer not to respect FHS
On Mon, Apr 04, 2005 at 03:13:36PM -0400, David Mandelberg wrote: > On Mon, 2005-04-04 at 11:53 +0200, Torsten Landschoff wrote: > > For invidual files > > this is too much work though - it could work for directories. > Why would it be hard with individual files? Just use a shell fragment > like: > FILES="foo bar baz" > for i in $FILES > do > mv "$DESTDIR/usr/lib/$i" "$DESTDIR/usr/share/$i" > ln -s "/usr/share/$i" "$DESTDIR/usr/lib/$i" > done Moving the files doesn't actually satisfy the FHS requirement, which says that the canonical FHS paths are the ones that must be used *by the software* when referring to these files. If you have to symlink the files back to the non-FHS locations for compatibility with the package itself, I don't really see the point. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: watch file for SourceForge packages
|--==> Shaun Jackman writes: SJ> On Apr 4, 2005 11:06 AM, Michael Koch <[EMAIL PROTECTED]> wrote: >>Use something like >>http://prdownloads.sourceforge.net/projectname/somefile-(.*)\.tar\.gz >> >>Works for me. SJ> Doesn't work for me though. Instead of a tarball, I get an HTML file SJ> that starts with... SJ> Select a Mirror for File: /libnjb/libnjb-2.0.tar.gz Example: http://prdownloads.sf.net/a/al/alsamodular/ams-(.*)\.tar\.bz2 Cheers, Free -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to detect which user is connected to $DISPLAY
Hello Martin,
Am 2005-04-04 19:31:45, schrieb Martin Schulze:
> FWIW: That's not always the case. Below is a real-world example
> from a woody system with XDM:
>
> koulutie!joey(pts/4):~> w
> 19:28:13 up 29 days, 8:52, 6 users, load average: 0.02, 0.04, 0.06
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
> joey tty2 -09Mar05 9days 1:15 1:14 ssh finlandia
> joey :0 -06Mar05 ?xdm? 0.00s ? -
> joey pts/0:0.0 06Mar05 29days 0.26s 0.26s bash
> joey pts/2:0:S.0 06Mar05 3days 6:13 6:13 ssh finlandia
> joey pts/3:0:S.1 06Mar05 29days 32:05m 32:05m ssh finlandia
> joey pts/4finlandia.home.i 07Mar05 1.00s 5.44s 0.18s w
> koulutie!joey(pts/4):~> w | awk '{print $1" "$2}' | grep ":0$" | awk '{print
> $1}'
> joey
> koulutie!joey(pts/4):~>
>
> So Sean's script works fine as it should be.
>
> It doesn't, if X is started via startx, though.
Argh !!! - My test system IS startet from the console and startx.
So, this was the error...
> Regards,
>
> Joey
Thanks Joey
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com)
signature.pgp
Description: Digital signature
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
>Name Server:SAENS.DEBIAN.ORG >Name Server:KLECKER.DEBIAN.ORG >Name Server:SPOHR.DEBIAN.ORG spohr changed IP addresses last week, and the glue record returned by the .org nameservers still had the old address when I checked a few hours ago. This has been reported to debian-admin. (The new address is 140.211.166.43) -- Blars Blarson [EMAIL PROTECTED] http://www.blars.org/blars.html With Microsoft, failure is not an option. It is a standard feature. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
Blars Blarson wrote: >>Name Server:SAENS.DEBIAN.ORG >>Name Server:KLECKER.DEBIAN.ORG >>Name Server:SPOHR.DEBIAN.ORG >> >> > >spohr changed IP addresses last week, and the glue record returned by >the .org nameservers still had the old address when I checked a few >hours ago. This has been reported to debian-admin. (The new address >is 140.211.166.43) > > > Ok, but that should not cause DNS failure unless the old spohr address returned authoritative no such domain or the other two DNSes didn't work either. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: watch file for SourceForge packages
On Apr 4, 2005 5:02 PM, Free Ekanayaka <[EMAIL PROTECTED]> wrote: > Example: > > http://prdownloads.sf.net/a/al/alsamodular/ams-(.*)\.tar\.bz2 This doesn't work for me: $ cat debian/watch version=2 http://prdownloads.sourceforge.net/n/ne/neutrino/neutrino-(.*)\.tar\.gz debian uupdate $ uscan neutrino: Newer version (0.8.2) available on remote site (local version is 0.7.3) neutrino: Successfully downloaded updated package neutrino-0.8.2.tar.gz and symlinked neutrino_0.8.2.orig.tar.gz to it New Release will be 0.8.2-1. -- Untarring the new sourcecode archive ../neutrino_0.8.2.orig.tar.gz gzip: stdin: not in gzip format tar: Child returned status 1 tar: Error exit delayed from previous errors uupdate: can't unpack: tar zxf ../neutrino_0.8.2.orig.tar.gz failed; aborting... $ file ../neutrino-0.8.2.tar.gz ../neutrino-0.8.2.tar.gz: HTML document text $ head -2 ../neutrino-0.8.2.tar.gz Select a Mirror for File: /n/ne/neutrino/neutrino-0.8.2.tar.gz Cheers, Shaun -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What to do about penis problems...
Title: dairymen rk mole cqr chanson hnk irving xig pickaxe qgn sticky lb consolidate xg jackdaw ow Controlled ejaculation more info here differentiate dvx concession jz harp vfm dissident dnr bondage yu trundle lc insecure wuz gypsite yzv sophia yyg miguel nvj exalt fms nullstellensatz tw abstain mk pecan xe no -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: watch file for SourceForge packages
Shaun Jackman wrote: >This doesn't work for me: > >$ cat debian/watch >version=2 >http://prdownloads.sourceforge.net/n/ne/neutrino/neutrino-(.*)\.tar\.gz >debian uupdate >$ uscan >neutrino: Newer version (0.8.2) available on remote site > (local version is 0.7.3) >neutrino: Successfully downloaded updated package neutrino-0.8.2.tar.gz >and symlinked neutrino_0.8.2.orig.tar.gz to it >New Release will be 0.8.2-1. >-- Untarring the new sourcecode archive ../neutrino_0.8.2.orig.tar.gz > > Download it manually. watch files' main purpose is to watch upstream for a new version. - Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: watch file for SourceForge packages
On Mon, 4 Apr 2005, Shaun Jackman wrote: $ file ../neutrino-0.8.2.tar.gz ../neutrino-0.8.2.tar.gz: HTML document text $ head -2 ../neutrino-0.8.2.tar.gz Select a Mirror for File: /n/ne/neutrino/neutrino-0.8.2.tar.gz Same for me $ grep -v "#" debian/watch version=2 http://prdownloads.sf.net/z/zm/zmspublishing/zms-(.*)\.tar\.gz $ uscan zope-zms: Newer version (2.3.2-b45) available on remote site (local version is 2.1.2.7) zope-zms: Successfully downloaded updated package zms-2.3.2-b45.tar.gz and symlinked zope-zms_2.3.2-b45.orig.tar.gz to it $ file zms-2.3.2-b45.tar.gz zms-2.3.2-b45.tar.gz: HTML document text $ head -2 zms-2.3.2-b45.tar.gz Select a Mirror for File: /z/zm/zmspublishing/zms-2.3.2-b45.tar.gz Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NEW handling: About rejects, and kernels
* Henning Makholm ([EMAIL PROTECTED]) [050402 18:10]: > Scripsit [EMAIL PROTECTED] (Marco d'Itri) > > On Apr 02, Henning Makholm <[EMAIL PROTECTED]> wrote: > > >> >> >> I'm ok with (1), provided we do it in the non-free archive. > > >> >> > This does present certain logistical problems for producing > >> >> > installers. > > >> >> Which ones? > > >> > The fact that they need these firmwares to work. > > >> So what? > > > So it is a problem, because currently it would not be allowed. > > Where does it say that such images are not allowed? For sarge, I'm quite convinced that we're not going to do such a big change (and you can translate it to "not allowed by $team", if you want). For etch, things are different. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why allow broken packages to get all the way to mirrors?
* Mike Hommey ([EMAIL PROTECTED]) [050403 14:55]: > I think he's talking about mirrored Packages files being updated before > all the packages get mirrored and/or arch all packages reaching the > archive before arch specific builds (except the maintainer's arch), > because of buildd queue. For the first, there are well working mirror scripts that prevent that, and for the second, this can be fixed by changing the mirror scripts (there are ideas, but some changes need to be done). Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: watch file for SourceForge packages
Thanks, Seo! heanet works for me too. Cheers, Shaun On Apr 4, 2005 9:44 PM, Seo Sanghyeon <[EMAIL PROTECTED]> wrote: > Hello, I am not subscribed to debian-devel, but I read your message > from the web archive. > > I'm using this: > > version=3 > http://heanet.dl.sourceforge.net/sourceforge/pyenchant/ \ > pyenchant-([\d.]*).tar.gz debian uupdate > > HEAnet never failed for me, by the way. > > Hope this help, > > Seo Sanghyeon On Apr 4, 2005 11:21 AM, Shaun Jackman <[EMAIL PROTECTED]> wrote: > Recently I've been using umn [1] in my watch files for SourceForge > packages. It looks like this link is dead now. I find I have to update > the watch file for all my SourceForge packages every six months or so. > Finding a new link that works is usually not trivial. Does anyone > maintain a list of working SourceForge mirrors suitable for watch > files? > > Thanks, > Shaun > > [1] ftp://sourceforge.cs.umn.edu/pub/sourceforge/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug #255367: Lake of PPTP in Debian first CD
* Henrique de Moraes Holschuh ([EMAIL PROTECTED]) [050403 21:20]: > On Sun, 03 Apr 2005, Lior Kaplan wrote: > > I'd like to raise a discussion about PPTP (package name is pptp-linux). > > The package is used to connect to the internet, mostly with DSL connections. > I thought that was pppoe? Isn't pptp some half-assed encripted VPN protocol > from MS ? Which some DSL-provider use (like mine here). Others use pppoe. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gluck (cvs, people, planet, etc.) downtime - ongoing raid problems
Adam M. schrieb: > Blars Blarson wrote: > > >>>Name Server:SAENS.DEBIAN.ORG >>>Name Server:KLECKER.DEBIAN.ORG >>>Name Server:SPOHR.DEBIAN.ORG >>> >>> >> >>spohr changed IP addresses last week, and the glue record returned by >>the .org nameservers still had the old address when I checked a few >>hours ago. This has been reported to debian-admin. (The new address >>is 140.211.166.43) >> >> >> > > > Ok, but that should not cause DNS failure unless the old spohr address > returned authoritative no such domain or the other two DNSes didn't work > either. You could be right, but when ORG-nameservers are returning NO glue record as on last sunday night there is no chance. It looks like these nameservers had lost their g-r's during update as mentioned above. But why/how could this happen? Christian -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
