Bug#348655: ITP: ipfilter -- Stateful and packet based IP network firewall
Package: wnpp Severity: wishlist Owner: Steve King [EMAIL PROTECTED] * Package name: ipfilter Version : 4.1.10 Upstream Author : Darren Reed darrenr (at) pobox (dot) com * URL : http://coombs.anu.edu.au/~avalon/ip_fil4.1.10.tar.gz * License : BSD Description : Stateful and packet based IP network firewall ipfilter is a similar tool to ipchains/netfilter, and is not intended as a replacement. It provides sophisiticated stateful filtering, which is more intelligent than netfilter, but lacks some of the other functions. ipfilter's main strength is that it is portable across many UNIX and UNIX-like systems. Thus you can use ipfilters on your Solaris, Net/Free/OpenBSD, IRIX, HPUX and Linux boxen. It is also installed as the default firewall on some of these systems. Unfortunately, it does require a kernel module to function. Steve -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wed, 2006-01-18 at 10:01 +0100, Gerfried Fuchs wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-17 11:36]: Kennedy wasn't a citizen of Berlin, either, not literally. The world understood what he meant, though, when he said (somewhat awkwardly) that he was. Again my question: Do you seriously consider calling Linus and RMS Debian Developers? Shuttleworth is using a *figure of speech*. A figure of speech is something not to be taken literally. Figures of speech are used all the time and they make language more interesting. Mr Zimmerman's reference to Kennedy is an excellent example of such a metaphorical construct. When Kennedy said that, there will undoubtedly have been people who uttered Hey, he's not German! He's lying!. But luckily most people will have understood what he meant. Same goes for Shuttleworth here, if it wasn't obvious from the context already (which IMO it was), it's certainly clear now that this a way to express how important Debian developers are to the state of Ubuntu. And yes indeed, in the same sense could he have said that Stallman or Torvalds are Ubuntu or Debian developers. As an indication of how important these two people are for the foundations of our OS. Not literally. I hope this confusion is cleared up a bit now. Thijs signature.asc Description: This is a digitally signed message part
Re: when and why did python(-minimal) become essential?
On Wed, Jan 18, 2006 at 12:10:25AM +0100, Matthias Klose wrote: Joe Wreschnig writes: On Tue, 2006-01-17 at 09:32 -0800, Matt Zimmerman wrote: On Tue, Jan 17, 2006 at 02:31:47PM +0100, Adam Borowski wrote: You're underestimating the grave consequences of losing 25MB off every memory stick and virtual machine. python-minimal is about two megabytes installed, with no non-Essential dependencies. (strictly an observation of fact; I'm not expressing an opinion either way about the change) The python-minimal I see depends on all of python2.3. In Ubuntu perhaps it's 2MB, but in Debian right now it's almost all of Python. correct, the change was made to introduce the package name, so that the package doesn't stick in the NEW queue, when we actually do the change. two other packages were introduced, so it only needs to be approved one time by the FTP masters. Er... when we actually do the change? Given that python-minimal is Essential: yes in Ubuntu, the *only* use for this package in Debian (given that there would be no packages in the wild that depend on it -- the definition of Essential is that you don't need to depend on it) is if we make it Essential: yes as well. Are you claiming that adoption of python-minimal as an Essential package is a foregone conclusion? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: For those who care about their packages in Ubuntu
On 1/17/06, Bill Allombert [EMAIL PROTECTED] wrote: 1) No changes rebuild-only upload should still be versionned so that we do not end up with two .deb with the same version but different contents. Rebuilding a package with a newer toolchain can cause different dependencies and bugs. In ubuntu, no changes rebuild-only get the suffix 'buildX' or 'ubuntuX+1', depending if it has already diverged. Packages with 'buildX' suffix get synced automatically on the next upload to debian. 2) I find a bit odd to be called the maintainer of a package I did not test and that I cannot change anyway. Ubuntu has a different understanding of the maintainer field of a package. 3) The name of the Ubuntu developers which have tested the package before uploading it is not mentionned in the case of a no-changes upload. I am refraining from assuming there were none. It is in debian/changelog. -- regards, Reinhard
Re: [ad-hominem construct deleted]
[EMAIL PROTECTED], if you read that: Fix your mail setup, I'm not interested in getting double mails from whatever setup you have there. Thanks] * Matt Zimmerman [EMAIL PROTECTED] [2006-01-17 11:36]: On Tue, Jan 17, 2006 at 06:46:26PM +0100, Gerfried Fuchs wrote: Do we call RMS a Debian developer? Do we call Linus a Debian Developer? Does anyone seriously consider that? Kennedy wasn't a citizen of Berlin, either, not literally. The world understood what he meant, though, when he said (somewhat awkwardly) that he was. Again my question: Do you seriously consider calling Linus and RMS Debian Developers? Even when you know exactly what this term refers so? Tell me why I should think that a derivated Debian distribution doesn't seem to be aware of the definition of this term within Debian. Sorry, Matt, but that does show to me that you aren't aware of the difference of these statements, which very much they are. Pardon, but that's ridiculous. I don't have upload permission at all, can't do anything about my packages, there are changed packages with still my name as maintainer that I never got any information about -- and you still have the guts to call me a Ubuntu developer? Sorry for laughing into your face for that... It isn't productive to take this kind of jeering tone. So you want to turn down this honest (and yes, I admit emotional driven, though still honest) question with such a statement? Do you really call people Ubuntu developers who don't have a real chance to do anything about what it is done to their packages and aren't informed about such actions? Please don't avoid this question again, because it is there. I'm saying that you should pause and consider that you're looking at a world-writable resource before treating its contents as a position statement on behalf of the project, and that malicious intent is far from the only (or even the most common) reason for errors. It could very well be that Mark or someone else originally wrote from Debian and the quote was transcribed incorrectly. Then pretty please fix it. In any case, as I said, I think the meaning of the sentence as a whole is sufficiently unambiguous, though for the sake of clarity I will ask Mark to look and correct it if appropriate. It isn't. The difference between to and from is a thing that is very much a difference. Because the to is the thing that isn't really working, or do you really think there would be so much fuss if the sync from Ubuntu back to Debian would really work? This had been commonplace for Debian derivatives for years before Ubuntu existed, and when the issue was raised regarding Ubuntu, I asked for input from the Debian community as to what to do. The issue is not at all obvious, and in fact it's quite similar to the attribution of upstream authors of packages which are modified in Debian, which is even older. I don't know what was done for years, but I know for one thing that I was never contacted about changes to packages and if I'd approve them. Leaving my name in their as maintainer for a _changed_ package implies to some degree that I'm sort-of approving it. Either by being MIA through an NMU, through some team maintenance or similar. I can't do anything to revert such changes (no matter how good or bad I consider them) in packages in Ubuntu. I'm not responsible for the package in Ubuntu, so why should my name be in there? About the reasoning others have done that, too, that is mainly used in kindergardens, I don't buy it. It sounds like a very cheap excuse. We aren't discussing others (and yes, I would have raised the same concerns there too, if I would have been made aware of it), we are discussing Ubuntu. I haven't a clue what you're talking about here. What press release, and how does d-d-a enter into it? You do read d-d-a, don't you? I am refering to buxy's mail, which stirred this all up. If you had doubts about which packages were included, it wouldn't have taken much effort on your part to find out. So again you are saing it's the Debian Developer's job to look around and do what would had been so easy for Ubuntu, to inform the maintainers of packages, maybe only those that were changed upon? Do you truly see this as such a radical departure from how Debian and other distributions already work? Yes, I do. Free software is rarely so clear-cut. By the time a piece of free software arrives in the hands of a user, it has passed through more than one set of hands and more often than not, modified from its original version. But then the people who change it don't publish it under the name of others. And it is more common than uncommon that the people who change something send the changes back, instead of waiting for their upstream to stumble upon it and notice that there were changes in there. As soon as the issue was raised (and although it was raised in a Debian forum, without any attempt to contact a representative of
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 04:54:36PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Besides which, do you honestly know which packages other Debian derivatives rebuild? As a rule, they are far less communicative about their practices than Ubuntu. How does the behavior of other Debian derivatives matter? How does it not matter? -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Mirror split stuff
I am afraid, in such split packages with arch all will be duplicated in all architectures. IMHO, there are only two solutions: Move every arch in separate directory/server, and arch all too. Or havely use hard links, like in debian-amd64 port. The second solution looked worse, because don't solve duplication in case arch will be moved in separate servers. -- Olleg Samoylov smime.p7s Description: S/MIME Cryptographic Signature
Re: [ad-hominem construct deleted]
On Tuesday 17 January 2006 00:39, Matt Zimmerman wrote: On Sun, Jan 15, 2006 at 02:59:58AM +0100, Gerfried Fuchs wrote: It's also about false statements like We sync our packages to Debian regularly, because that simply doesn't happen for quite a lot of us, otherwise all these heated discussions wouldn't happen. Given that you saw this on a wiki page, a disclaimer about wiki contents should be implicit. However, regardless of whether it's an accurate quote, it's quite clear to me from context that your interpretation doesn't match the text. The full quote is We sync our packages to Debian regularly, because that introduces the latest work, the latest upstream code, and the newest packaging efforts from a huge and competent open source community. Without Debian, Ubuntu would not be possible. It should be obvious from the remainder of the sentence that it is talking about propagation of changes *from* Debian *to* Ubuntu. syncinc _to_ debian implies that changes are _pushed_ to Debian regularly, whereas in actuallity they're simply made available for pull by Debian (in most cases) what you're describing above is reforking from the latest upstream regularly, while that will indeed minimize divergence, it's not even close to being the same thing as syncing the package with Debian there's notting inherently wrong with the ubuntu approach you just described, but it is not wat is listed as ubuntu behavior. I can only speak for myself (like everyone anyway, but it seems to be mentioned), I haven't noticed anyone reaching me, so I hadn't had any chance to burn anyone. The only contact with respect to Ubuntu was a user disappointed that one of my packages in Debian had a fix that the one in Ubuntu hadn't... for several weeks. All I could do is thank him for appreciating my work but that it's out of my hands to fix it for Ubuntu because I never was notified about that it's included there, and wouldn't know at all who to contact therefore. It was inappropriate for this user to raise this issue with you, rather than with Ubuntu, but that's been discussed elsewhere in this thread already. What I find interesting about your statement is that you seem to imply that the situation would have been better if you had been notified that your package was a part of Ubuntu. Considere the following: - right now there are no Ubuntu changes to my package - if Ubuntu suddenly does change my package for whatever reason, there's absolutely no way I'll suddenly know to go check the patch page. The above problem becomes worse when - 1 DD needs to do this for lots of packages - a package has lots of changes, some/most of which are not applicable to Debian (mentioned earlier were whitespace changes, grateous autotool-changes, changes to dpatch...), all which have to be sepperated from the applicable changes each time one checks for new differences That's a clear problem that becomes nightmarish for large amounts of packages and/or non-applicable changes, it's also the problem pointed at in the above IMHO This would be technically simple to implement, but I'm not convinced that it's possible to do it in a socially acceptable way. Emailing every Debian maintainer to notify them that their package is present in Ubuntu sounds like spam to me, and posting Ubuntu-related announcements to Debian mailing lists has been deemed inappropriate by many in Debian as well. Not what's being asked: the question was to notify every Debian maintainer every time a new change is being made to the ubuntu version that they should look at merging back (dare I suggest by using Debian BTS?) I find this type of disclaimer very frustrating. I see a number of opinions expressed about the Ubuntu community by persons with no first-hand experience with it. Most Debian maintainers have probably never interacted with Ubuntu, and there's no reason that most of them should expect to. Setting aside the debate about patch submission for a moment, in the case of most packages, there are no patches in Ubuntu relative to Debian. right, so please notify the maintainer when there is indeed a (new) patch so they know to go look for it? As you've just pointed out presence of patches is not the default state. In fact, I just looked, and I found only one package with maintainer [EMAIL PROTECTED] which has a delta in Ubuntu: libmetakit2.4.9.3. I read the patch just now; here's what's in it: - Transition to python2.4 as the default Python version in Ubuntu. You don't want this patch for Debian yet. - Packaging transition for the gcc4 C++ ABI. Debian developers were notified about the availability of these patches in Ubuntu when the transition began in Debian, though it looks like you chose not to use it, and rebuilt the package instead. - autoconf has been re-run. In other words, I don't see what it is that you're dissatisfied about, in your role as maintainer of these
Re: when and why did python(-minimal) become essential?
Steve Langasek wrote: Given that python-minimal is Essential: yes in Ubuntu, the *only* use for this package in Debian (given that there would be no packages in the wild that depend on it -- the definition of Essential is that you don't need to depend on it) is if we make it Essential: yes as well. I don't see why. If python-minimal were included in Debian then some packages that currently Depend on python could (if their needs are minimal) Depend on python-minimal instead. This would be an improvement, and obtaining this benefit does not require that python-minimal be Essential: yes in Debian. In any case I am hoping to see python-minimal included in Debian. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wednesday 18 January 2006 11:01, Gerfried Fuchs wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-17 11:36]: So again you are saing it's the Debian Developer's job to look around Yes it is. and you shouldn't restrict yourself to ubuntu, checking what other Debian derivates, Fedora, OpenSuSe or even Gentoo etc have done for the same software you are packaging might reveal patches and changes. It is true that all that information is not available at one central place, which makes this job a bit troublesome. Setting such setup should not be that hard, it just requires LOTS of diskspace and bandwidth.. So you are saying it's the Debian Developer's job to pull changes from ubuntu back? If that is an official statement, then that would be useful for a d-d-a mail so we are aware of it. This is what also wonder about ubuntu-haters. Somehow it is OK for Debian to have different opinions and preferences (Tell me about changes vs don't spam me or You don't Attribute my work vs Don't put my name there). But at the same time you require a explict policy from ubuntu and anytime a ubuntu developer says something about it is considered a official position statetement.. Until we can do a official statement of debian derivate policy ourselfs, we can hardly require it from them.. Do you imply with this message that Ubuntu doesn't care about quality in their upstreams but rather keep their stuff to themselfes? The same can be claimed about about Debian and our upstreams. Not all maintainers submit their patches upstream, and sometimes our lack of co-operation have made our upstreams really unhappy (Remember micq?). However, that is not an excuse for Debian Derivate Developers not to co-operate with Debian Maintainers, or for us with our upstreams. And I like to point out that there isn't any correspondence between the ubuntu developers and the debian developers in respect to getting sensible patches they do back into debian, which very much disappoints me, if not does get me a bad opinion on the intentions of ubuntu. Ubuntu (and other derivates) are using the same freedoms Debian is built upon. We would not accept a licence that required us to submit our patches upstream (dissident and desert island tests), so howcome it is OK to require such behaviour from our downstreams? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Wed, Jan 18, 2006 at 10:47:35AM +0100, Reinhard Tartler wrote: On 1/17/06, Bill Allombert [EMAIL PROTECTED] wrote: 1) No changes rebuild-only upload should still be versionned so that we do not end up with two .deb with the same version but different contents. Rebuilding a package with a newer toolchain can cause different dependencies and bugs. In ubuntu, no changes rebuild-only get the suffix 'buildX' or 'ubuntuX+1', depending if it has already diverged. Packages with 'buildX' suffix get synced automatically on the next upload to debian. Are you sure ? Compare the menu package at http://packages.ubuntu.com/dapper/admin/menu with the one in sid. They have the same versions (2.1.27) but not the same content (at least the dependencies are different.) No buildX or ubuntuX suffix. 2) I find a bit odd to be called the maintainer of a package I did not test and that I cannot change anyway. Ubuntu has a different understanding of the maintainer field of a package. Wonderful. 3) The name of the Ubuntu developers which have tested the package before uploading it is not mentionned in the case of a no-changes upload. I am refraining from assuming there were none. It is in debian/changelog. Grab the package at the URL above abnd check the changelog: no mention of any Ubuntu developers. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On 1/18/06, Bill Allombert [EMAIL PROTECTED] wrote: On Wed, Jan 18, 2006 at 10:47:35AM +0100, Reinhard Tartler wrote: On 1/17/06, Bill Allombert [EMAIL PROTECTED] wrote: 1) No changes rebuild-only upload should still be versionned so that we do not end up with two .deb with the same version but different contents. Rebuilding a package with a newer toolchain can cause different dependencies and bugs. In ubuntu, no changes rebuild-only get the suffix 'buildX' or 'ubuntuX+1', depending if it has already diverged. Packages with 'buildX' suffix get synced automatically on the next upload to debian. Are you sure ? Compare the menu package at http://packages.ubuntu.com/dapper/admin/menu with the one in sid. They have the same versions (2.1.27) but not the same content (at least the dependencies are different.) No buildX or ubuntuX suffix. As pointed out several times, the source package in the ubuntu archive is NOT different to the source package in the debian archive. The binary package have been rebuilt in an different environment, which can caus different dependencies on the resulting binary package. 3) The name of the Ubuntu developers which have tested the package before uploading it is not mentionned in the case of a no-changes upload. I am refraining from assuming there were none. It is in debian/changelog. Grab the package at the URL above abnd check the changelog: no mention of any Ubuntu developers. output of apt-cache on my system: apt-cache show menu Package: menu Priority: optional Section: universe/admin Installed-Size: 1532 Maintainer: Bill Allombert [EMAIL PROTECTED] Architecture: i386 Version: 2.1.27 Depends: libc6 (= 2.3.4-1), libgcc1 (= 1:4.0.2), libstdc++6 (= 4.0.2-4), dpkg (= 1.10) Suggests: gksu | kdebase-bin | sux Filename: pool/universe/m/menu/menu_2.1.27_i386.deb Size: 376506 MD5sum: 054648b9fdc883b1a09e48dd3346e824 Description: generates programs menu for all menu-aware applications Debian menu keeps transparently the menus in the different window-managers in sync with the list of installed programs. . Debian menu relies on a list of menu entries provided by programs and a list of menu-methods provided by window-managers and other menu-aware applications. . Menu provides system-level and user-level configuration and overrides for both menu entries and menu-methods. Bugs: mailto:[EMAIL PROTECTED] Origin: Ubuntu As you can see, there has been a Bugs: and an Origin: Field added. Some debian developers have raised the opinion that this is not enough, and the Maintainer field should be mangled during the build process. As there seems to be no consensus on this issue yet, this is not done yet, but would be possible, AFAIU. But there should be really a consensus on this since we don't want to have this discussion over and over again. -- regards, Reinhard
udev naming problems for eth*
Hi all
I'm trying to get static naming for my network interfaces with udev,
without success.
the system is debian sarge based, with udev version 0.076-6 and kernel
2.6.14-7-686-smp on a P4. the network interfaces are a realtek 8139
integrated in the motherboard (eth0) and a 3com pci (eth1)
usually the two interfaces are named the wrong way, but sometimes they
are named fine.
beside the fact that I find useful to name eth0 the realtek and eth1 the
other, there is a casuality in the naming process that I cannot remove :-(
my /etc/udev/rules.d/000local.rules looks like this:
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
SYSFS{address}==00:10:4b:b2:1e:6e, NAME=eth1, RUN+=/bin/echo 2
/root/udev.log
KERNEL==eth*, ID==:02:05.0, NAME=eth1, RUN+=/bin/echo 3
/root/udev.log
DRIVER==3c59x, NAME=eth1, RUN+=/bin/echo 4 /root/udev.log
SUBSYSTEM==net, SYSFS{address}==00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 5 /root/udev.log
KERNEL==eth*, SYSFS{address}!=00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 6 /root/udev.log
SYSFS{device}==0x9055, NAME=eth1, RUN+=/bin/echo 7 /root/udev.log
in the hope that the creation of the ethernet interface could match at
least one of these rules (and log wich), but this isn't happening.
I tried to add this at the top of the file:
ACTION==add, DEVPATH==/devices/*, ENV{PHYSDEVBUS}==?*, \
WAIT_FOR_SYSFS=bus
but it didn't help.
can anybody tell me what I'm doing wrong?
thanks
davide
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Adam Heath [EMAIL PROTECTED] writes:
* 1 FETCH (BODY[TEXT] {1008}
On Tue, 17 Jan 2006, Otavio Salvador wrote:
In my point of view, maintainer field just need to be change when
Ubuntu does a non-trivial change on it. Otherwise, at least to me, is
OK to leave the maintainer field unchanged. Directly imported source
(that will be just recompiled by Ubuntu) doesn't need to be change
since it's the same source code that runs on Debian.
But linked against other libraries. The binary is downloaded from another
location(or installed from a different cd set). The program used to do the
download may be different.
Using this as rule, then all Debian CDD distributions would need to
recompile all sources to change the maintainer field. This include
Debian-EDU, Debian-BR-CDD and others. That's what you think is
correct?
In case of CDDs, the only exception is it isn't build against other
libraries but it is installed by different cd set and downloaded from
another location in many cases.
--
O T A V I OS A L V A D O R
-
E-mail: [EMAIL PROTECTED] UIN: 5906116
GNU/Linux User: 239058 GPG ID: 49A5F855
Home Page: http://www.freedom.ind.br/otavio
-
Microsoft gives you Windows ... Linux gives
you the whole house.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
[don't be confused about the To header, this is merly just for testing a propable b0rked setup] * Thijs Kinkhorst [EMAIL PROTECTED] [2006-01-18 10:26]: Mr Zimmerman's reference to Kennedy is an excellent example of such a metaphorical construct. When Kennedy said that, there will undoubtedly have been people who uttered Hey, he's not German! He's lying!. But luckily most people will have understood what he meant. Then it's still Kennedy's problem, because he didn't claim something for others. I know what you mean, though Mark is forcing a claim onto us, where the term Debian Developer is quite strictly defined within our roles, people in the NM queue aren't called Debian Developers. For me and quite some others, if you read the thread, the term $foo Developer implies that the person is able to incorporate changes into $foo directly. I understand what Mark meant, but on the wiki page where the cite is there isn't any context at all, and no explenation on how it's meant. It's vastly misunderstandable. Same goes for Shuttleworth here, if it wasn't obvious from the context already (which IMO it was) The thing is, there isn't any context in that wiki page. I'm pleased that he sees us as (in)valueable, but given that still every now and then misguided reports appear doesn't really help, especially when it's about ubuntu changed packages which we can't do anything about. So long, Alfie -- use Mail::Signature; $sig = Mail::Signature-new; print $sig-random; signature.asc Description: Digital signature
Re: udev naming problems for eth*
Davide Natalini [EMAIL PROTECTED] writes:
Hi all
I'm trying to get static naming for my network interfaces with udev,
without success.
As far as I can tell, network interface names are given by the kernel
and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
the system is debian sarge based, with udev version 0.076-6 and kernel
2.6.14-7-686-smp on a P4. the network interfaces are a realtek 8139
integrated in the motherboard (eth0) and a 3com pci (eth1)
usually the two interfaces are named the wrong way, but sometimes they
are named fine.
beside the fact that I find useful to name eth0 the realtek and eth1
the other, there is a casuality in the naming process that I cannot
remove :-(
my /etc/udev/rules.d/000local.rules looks like this:
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
SYSFS{address}==00:10:4b:b2:1e:6e, NAME=eth1, RUN+=/bin/echo 2
/root/udev.log
KERNEL==eth*, ID==:02:05.0, NAME=eth1, RUN+=/bin/echo 3
/root/udev.log
DRIVER==3c59x, NAME=eth1, RUN+=/bin/echo 4 /root/udev.log
SUBSYSTEM==net, SYSFS{address}==00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 5 /root/udev.log
KERNEL==eth*, SYSFS{address}!=00:50:70:e3:16:c2, NAME=eth1,
RUN+=/bin/echo 6 /root/udev.log
SYSFS{device}==0x9055, NAME=eth1, RUN+=/bin/echo 7 /root/udev.log
in the hope that the creation of the ethernet interface could match at
least one of these rules (and log wich), but this isn't happening.
I tried to add this at the top of the file:
ACTION==add, DEVPATH==/devices/*, ENV{PHYSDEVBUS}==?*, \
WAIT_FOR_SYSFS=bus
but it didn't help.
can anybody tell me what I'm doing wrong?
I hope this helps,
Emilio
p.d: I think this is a debian-user question, setting MFT, but I'm not
subscribed to debian-user, so CC me please.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
also sprach Emilio Jesús Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for 2.4 kernels only these days. udev
can certainly rename interfaces, though I don't know what the OP's
problem is. I'd suggest talking to a udev-related list, or at least
to debian-user, for this isn't really something to do with -devel.
Anyway, this is what I use on one of my machines, and it works like
a charm:
KERNEL=eth*, SYSFS{address}=00:10:dc:c8:85:07, NAME=lan
I suggest not using NAME=ethX because there may be name clashes.
Use a completely different name instead.
--
Please do not send copies of list mail to me; I read the list!
.''`. martin f. krafft [EMAIL PROTECTED]
: :' :proud Debian developer and author: http://debiansystem.info
`. `'`
`- Debian - when you have better things to do than fixing a system
Invalid/expired PGP (sub)keys? Use subkeys.pgp.net as keyserver!
if you are going to run a rinky-dink distro made by a couple of
volunteers, why not run a rinky-dink distro made by a lot of
volunteers?
-- jaldhar h. vyas
signature.asc
Description: Digital signature (GPG/PGP)
Re: udev naming problems for eth*
On Jan 18, Davide Natalini [EMAIL PROTECTED] wrote:
the system is debian sarge based, with udev version 0.076-6 and kernel
Just to be sure, I suggest you upgrade your version of udev.
usually the two interfaces are named the wrong way, but sometimes they
are named fine.
IOW, renaming is not happening.
my /etc/udev/rules.d/000local.rules looks like this:
Renaming must happen after the WAIT_FOR_SYSFS, which is in
permissions.rules.
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
This RUN action will never work because /root is not writeable when the
rule is processed. You should use something like:
RUN+=/bin/touch /dev/flag-eth0-1
--
ciao,
Marco
signature.asc
Description: Digital signature
Re: udev naming problems for eth*
On Jan 18, Emilio Jesús Gallego Arias [EMAIL PROTECTED] wrote: As far as I can tell, network interface names are given by the kernel and they've nothing to do with udev. Obviously you have no clue about udev (nor about proper quoting). -- ciao, Marco signature.asc Description: Digital signature
Re: [ad-hominem construct deleted]
On Wed, Jan 18, 2006 at 09:41:58AM +0100, cobaco (aka Bart Cornelis) wrote: On Tuesday 17 January 2006 00:39, Matt Zimmerman wrote: Given that you saw this on a wiki page, a disclaimer about wiki contents should be implicit. However, regardless of whether it's an accurate quote, it's quite clear to me from context that your interpretation doesn't match the text. The full quote is We sync our packages to Debian regularly, because that introduces the latest work, the latest upstream code, and the newest packaging efforts from a huge and competent open source community. Without Debian, Ubuntu would not be possible. It should be obvious from the remainder of the sentence that it is talking about propagation of changes *from* Debian *to* Ubuntu. syncinc _to_ debian implies that changes are _pushed_ to Debian regularly, whereas in actuallity they're simply made available for pull by Debian (in most cases) It's meant to be shorthand for syncing [the package in Ubuntu] to [match the version in] Debian, or similar; I've certainly used the same colloquial shorthand in bug reports and such without realising that it could be confusing if stripped of all its context. Although, like Matt, I do think that the context (https://wiki.ubuntu.com/MarkShuttleworth, near the bottom) clarifies the meaning, I agree it's not the best phrasing and for grammatical reasons should be changed to synced from Debian. Matt has already said he'll ask for this to be changed (it's on Mark's personal wiki page, so changing it directly would be a bit rude), so hopefully we can stop going round in circles on this one. Cheers, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, 18 Jan 2006, Otavio Salvador wrote: But linked against other libraries. The binary is downloaded from another location(or installed from a different cd set). The program used to do the download may be different. Using this as rule, then all Debian CDD distributions would need to recompile all sources to change the maintainer field. I'm sorry if we agree that a CDD is what we defined under http://people.debian.org/~tille/cdd/ch-about.en.html#s-CDD then no change is necessary. To clarify a common misunderstanding: Custom Debian Distributions are not forks from Debian. They are completely included, and if you obtain the complete Debian GNU/Linux distribution, you have all available Custom Debian Distributions included. (I know that the name CDD is very confusing and many people think that it is something else.) In case of CDDs, the only exception is it isn't build against other libraries but it is installed by different cd set and downloaded from another location in many cases. If it is a CDD than it is installed from a Debian mirror and nothing else. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348683: ITP: libfcgi-procmanager-perl -- Functions for managing FastCGI applications.
Package: wnpp Severity: wishlist Owner: Krzysztof Krzyzaniak (eloy) [EMAIL PROTECTED] * Package name: libfcgi-procmanager-perl Version : 0.17 Upstream Author : James Jurach [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/J/JU/JURACH/FCGI-ProcManager-0.17.tar.gz * License : LGPL Description : Functions for managing FastCGI applications. FCGI::ProcManager is used to serve as a FastCGI process manager. By re-implementing it in perl, developers can more finely tune performance in their web applications, and can take advantage of copy-on-write semantics prevalent in UNIX kernel process management. The process manager should be invoked before the caller''s request loop . The primary routine, pm_manage, enters a loop in which it maintains a number of FastCGI servers (via fork(2)), and which reaps those servers when they die (via wait(2)). -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
beside the fact that I find useful to name eth0 the realtek and eth1 the other, there is a casuality in the naming process that I cannot remove If you want to avoid racing with the kernel then you should choose stable names from another namespace than the one that the kernel uses. Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'. Md: Or is there something in udevd now that will prevent such races? What I mean by 'races' are sequences like these: * Kernel creates eth0 * Userspace notices eth0, looks at its properties, and... * Kernel creates eth1 * ...tries to rename it to 'eth1', but that name is taken -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Wed, Jan 18, 2006 at 12:06:19PM +0100, Reinhard Tartler wrote: On 1/18/06, Bill Allombert [EMAIL PROTECTED] wrote: On Wed, Jan 18, 2006 at 10:47:35AM +0100, Reinhard Tartler wrote: On 1/17/06, Bill Allombert [EMAIL PROTECTED] wrote: 1) No changes rebuild-only upload should still be versionned so that we do not end up with two .deb with the same version but different contents. Rebuilding a package with a newer toolchain can cause different dependencies and bugs. In ubuntu, no changes rebuild-only get the suffix 'buildX' or 'ubuntuX+1', depending if it has already diverged. Packages with 'buildX' suffix get synced automatically on the next upload to debian. Are you sure ? Compare the menu package at http://packages.ubuntu.com/dapper/admin/menu with the one in sid. They have the same versions (2.1.27) but not the same content (at least the dependencies are different.) No buildX or ubuntuX suffix. As pointed out several times, the source package in the ubuntu archive is NOT different to the source package in the debian archive. The binary package have been rebuilt in an different environment, which can caus different dependencies on the resulting binary package. Yes, this is the definition of a no changes rebuild-only upload. What I asked was precisely that such upload should be versionned nevertheless. Debian version binNMU even while there is no source changes. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Wed, Jan 18, 2006 at 12:06:19PM +0100, Reinhard Tartler wrote: On 1/18/06, Bill Allombert [EMAIL PROTECTED] wrote: On Wed, Jan 18, 2006 at 10:47:35AM +0100, Reinhard Tartler wrote: On 1/17/06, Bill Allombert [EMAIL PROTECTED] wrote: 1) No changes rebuild-only upload should still be versionned so that we do not end up with two .deb with the same version but different contents. Rebuilding a package with a newer toolchain can cause different dependencies and bugs. In ubuntu, no changes rebuild-only get the suffix 'buildX' or 'ubuntuX+1', depending if it has already diverged. Packages with 'buildX' suffix get synced automatically on the next upload to debian. Are you sure ? Compare the menu package at http://packages.ubuntu.com/dapper/admin/menu with the one in sid. They have the same versions (2.1.27) but not the same content (at least the dependencies are different.) No buildX or ubuntuX suffix. As pointed out several times, the source package in the ubuntu archive is NOT different to the source package in the debian archive. The binary package have been rebuilt in an different environment, which can caus different dependencies on the resulting binary package. You said that no changes rebuild-only get the suffix 'buildX'. This is, apparently, not true. -- Peter Mathiasson, peter at mathiasson dot nu, http://www.mathiasson.nu GPG Fingerprint: A9A7 F8F6 9821 F415 B066 77F1 7FF5 C2E6 7BF2 F228 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On 1/18/06, Bill Allombert [EMAIL PROTECTED] wrote: As pointed out several times, the source package in the ubuntu archive is NOT different to the source package in the debian archive. The binary package have been rebuilt in an different environment, which can caus different dependencies on the resulting binary package. Yes, this is the definition of a no changes rebuild-only upload. What I asked was precisely that such upload should be versionned nevertheless. Debian version binNMU even while there is no source changes. Oh. There might be a misunderstanding: No binary package is taken from debian, only source packages. This means that EVERY package is being rebuilt in ubuntu on buildds, including arch: all packages. The output of apt-cache shows the field 'Origin' to indicate that this is not a package built on debian systems. If I understand your proposal correctly, you propose to introduce binNMU like versioning on ALL nondiverged packages (again, the source package is identical!). This seem not feasible because of practical problems. btw, the 'buildX' packages do change the source package, but by policy, only debian/changelog is touched, to increase the version number of the package. -- regards, Reinhard
Re: Debian derivatives and the Maintainer: field (again)
Andreas Tille [EMAIL PROTECTED] writes: In case of CDDs, the only exception is it isn't build against other libraries but it is installed by different cd set and downloaded from another location in many cases. If it is a CDD than it is installed from a Debian mirror and nothing else. Debian-EDU is available in Debian but also outside of it since they need to do more updated that aren't allowed in our stable versions. In that case, they would need to recompile all source again to change the maintainer field. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, 18 Jan 2006, Otavio Salvador wrote: Debian-EDU is available in Debian but also outside of it since they Well, that's a temporary hack until we have implemented solutions which makes this superfluous. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 18, Thomas Hood [EMAIL PROTECTED] wrote: If you want to avoid racing with the kernel then you should choose stable names from another namespace than the one that the kernel uses. Suggestion: Use 'eth_0' and 'eth_1' instead of 'eth0' and 'eth1'. Md: Or is there something in udevd now that will prevent such races? No. SuSE uses some scripts to handle persistent interface names, we need something similar but I had no time yet to investigate the details. (Any help would be appreciated.) http://ftp.opensuse.org/pub/opensuse/distribution/SL-OSS-factory/inst-source/suse/src/sysconfig-0.50.0-3.src.rpm -- ciao, Marco signature.asc Description: Digital signature
Re: when and why did python(-minimal) become essential?
In any case I am hoping to see python-minimal included in Debian. I now see that it is already in sid. :) $ apt-cache madison python-minimal python-minimal |2.3.5-5 | http://ftp.nl.debian.org sid/main Packages -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
(no subject)
please remove me from callwave, [EMAIL PROTECTED]. thank you. sharenknapp. 956 464 3214.
Re: Debian derivatives and the Maintainer: field (again)
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: On Tue, Jan 17, 2006 at 03:07:25PM -0500, Stephen Frost wrote: You're already rebuilding the package, which I expect entails possible Depends: line changes and other things which would pretty clearly 'normally' entail different Debian package revision numbers; changing the Maintainer field at the same time is just not that hard, *especially* when you're rebuilding the package. You're implying that this is alot of work and it's just not. It's also not 'forking' in any real sense of the word. You don't even have to change the version number if you don't want to. When done in Debian, it's also not even a new source package (in general anyway) as the thing which has the Maintainer field is actually the patch. You quite obviously haven't read http://lists.debian.org/debian-devel/2005/05/msg00260.html yet, where I wrote (among other important things), it would be fairly straightforward for Ubuntu to override the Maintainer field in binary packages. I explained exactly what is and isn't difficult and for whom. Wow, is this ever silly. Of course I read it and I appreciate your position that it's more work than not doing anything different from what you're doing now but I simply disagree about it and it seems like a pretty straight-forward solution to implement. I also understand that not all Debian derivatives are changing the Maintainer field and that Debian's not specifically chastising them for it. There are reasons for each though. Other Debian derivatives aren't (or at least, don't seem) as popular so it's less of an issue; other derivatives don't come across as pulling resources away from Debian (which Ubuntu seems to be doing, reality aside, that's the perception); other derivatives didn't ask and sometimes that's just the burden you have to bear when you're actively trying to do the right thing; other derivatives (some portion of them anyway, I expect) don't recompile packages (which makes leaving the Maintainer field alone somewhat less of an offense to some). If you're going to attack me, please do it on the basis of what I've actually said. Honestly, I expected better from you, give that you've acted like a human being toward me on IRC on several occasions in the past. Funny, I didn't think I was attacking you at all. Rereading what you quoted above I really don't see how that's an attack and I'm afraid perhaps you've gotten a little sensitive on this. I'm happy enough to excuse that as I'm sure you've gotten a fair number of poor reactions from others. Looking through my other emails on the subject it seems perhaps unkind of me to say you're ignoring the answer but, well, that's how it's coming across. :/ Thanks, Stephen signature.asc Description: Digital signature
Re: Debian derivatives and the Maintainer: field (again)
* Matt Zimmerman ([EMAIL PROTECTED]) wrote: On Wed, Jan 18, 2006 at 12:34:33AM +0100, Florian Weimer wrote: FWIW, I think your implied assumption that all Debian derivatives should be treated the same is flawed. Ubuntu is just not like any other derivative, it's a significant operation on its own. Its commercial backer is apparently able to pay quite a few Debian developers, several of them among the core team. There is a significant user base, and so on. Like it or not, Ubuntu is a bit special. I can't accept this; if there is no principle here which should be applied consistently, then it's entirely unfair to attack Ubuntu. Certainly, there are things about Ubuntu which are unique, but none of them change the issues at hand. Personally I think the principle *should* be applied consistently but as a volunteer and with generally not much time I'm not going to hunt down every Debian derivative out there, see what they do and complain at them if they're not doing it the right way. I doubt it'd have any effect in the majority of the cases anyway. Ubuntu, by trying to do the right thing (which many of us appreciate) and by asking the question of what *should* be done has put themselves in a position where if they don't do what 'should' be done, regardless of what others do, they're going to seem like bad guys. Also, I'm afraid, given Ubuntu's popularity and the impression (unfounded or not) that Ubuntu is taking resources away from Debian is going to mean Ubuntu will be held to a higher standard than other derivatives. I think many of us would like to see Ubuntu be the best derivative and always do the right thing and that's why there's more pressure on Ubuntu than other derivatives. Seriously, it's entirely unreasonable to single out Ubuntu on this issue. Perhaps so, but then Ubuntu's just another derivative and not the derivative many of us would like to see it be, and I expect the derivative that Ubuntu itself would like to be from a PR standpoint. Thanks, Stephen signature.asc Description: Digital signature
Re: udev naming problems for eth*
Md wrote: SuSE uses some scripts to handle persistent interface names [...] I had no time yet to investigate the details. I just looked at the rename_netiface script in that package. The following comments in the script give an idea of how it handles the race problem. # look for a network interface name that is still not # used as persistent name. At first it tries the name the # interface currently has. If this name is already occupied, # then increase the number and try again. # To check if a name is occupied we have to look in # /etc/udev/rules.d/60-net_*.rules and in /tmp/used_interface_names*. # The latter serves as temporary registration file to avoid race # conditions. It will be removed when the script exits. # Simply try to rename directly, because it will work in most cases # Generate a temporary interface name # Rename it to the temporary name. # Then try several times to rename it to new name Now trying several times, etc., may work, but it's a kludge. There are sound ways of resolving contention for a shared resource. -- Thomas Hood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Need for launchpad
On 1/17/06, Wouter Verhelst [EMAIL PROTECTED] wrote: As it is, to me, Ubuntu is just a group of people, some of which might have names[1]. I find it hard to work with such a thing; while I would love to work more closely with Ubuntu, the lack of personality is what's holding me back---and I'm afraid that telling me contact me, I'll forward it isn't going to change that. If you want a fast answer to a quick question, we are at #ubuntu-motu in freenode. Usually there is someone with an archive of dapper-changes who can look quickly who touched the package last, or you could check changelogs.ubuntu.com which holds changelog and copyright files of the packages. There are also some of us hanging around in debian-devel, if you don't want to join yet another channel ;) -- regards, Reinhard
Re: Debian derivatives and the Maintainer: field (again)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony Towns wrote: On Tue, Jan 17, 2006 at 04:38:29PM -0800, Matt Zimmerman wrote: On Tue, Jan 17, 2006 at 04:09:50PM -0800, Thomas Bushnell BSG wrote: Since you are rebuilding the package, you *must* change the version number *anyway*. It is not correct to recompile, and leave the version number alone. I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. However if a binNMU screws up a maintainer's package, the maintainer can easily fix it, and doing so is just part of contributing to Debian. The same thing applies when an autobuild on another architecture happens. That's not the case if an Ubuntu rebuild screws things up. Let me make it clear that this is not only a hypothetical worry, it's actually happened. (Sorry to people who already saw my similar email sent to -project, but I thought the point was worth repeating.) One of my packages (binary package paw, from source package cernlib) has seriously broken functionality in Breezy because it was compiled with a buggy version of gcc. The breakage did not appear in Debian until later [1], since Ubuntu switched to gcc-3.4 before Debian switched from 3.3 to 4.0. Once the breakage occurred in Debian I promptly uploaded a workaround and filed a bug on gcc [2]. Since paw is not very widely used, no one was bitten by the bug in Ubuntu until recently. An Ubuntu user emailed me about it [3] upon finding my name in the package maintainer field (and also asked upstream about it). If the Maintainer field included something like ubuntu-motu@lists.ubuntu.com, instead of keeping my name and email, I imagine the question would have worked its way to me eventually, but without first making it look like I must be clueless not to have fixed such an obvious bug. References: [1] the Debian bug report on paw: http://bugs.debian.org/324902 [2] the Debian bug report I filed on gcc: http://bugs.debian.org/325050 [3] the Ubuntu bug report on paw: https://launchpad.net/distros/ubuntu/+source/cernlib/+bug/6588 (the user who filed the bug was nice enough to add my emailed response to him as the second reply in the Launchpad entry) regards, - -- Kevin B. McCarty [EMAIL PROTECTED] Physics Department WWW: http://www.princeton.edu/~kmccarty/Princeton University GPG: public key ID 4F83C751 Princeton, NJ 08544 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDznTYfYxAIk+Dx1ERAn3UAKDI/W2yvJOcQyaH7UXeaps+cVCW1gCbBqjo nfcPVa0Yk+bz2hG/oXd8MM8= =xHNq -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
You have been successfully unsubscribed from Small Cap Reports
Dear, [EMAIL PROTECTED] You have been successfully unsubscribed from Small Cap Reports. We are sorry to see you go! Visit our Ezine Directory for more newsletters! http://subs.zinester.com Fill in our questionnaire and receive a bonus: no ads in newsletters! To fill in the questionnaire please follow this link: http://www.zinester.com/login/debian-devel@lists.debian.org/rL0Y20zC-Fzt72VPzMSk2A/?url=http://www.zinester.com/cgi/portrait.cgi -- Warm regards, Zinester.com http://www.zinester.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wednesday, 18 January 2006 11:30, Riku Voipio wrote: On Wednesday 18 January 2006 11:01, Gerfried Fuchs wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-17 11:36]: So again you are saing it's the Debian Developer's job to look around Yes it is. and you shouldn't restrict yourself to ubuntu, checking what other Debian derivates, Fedora, OpenSuSe or even Gentoo etc have done for the same software you are packaging might reveal patches and changes. So we agree that Fedora, Ubuntu and OpenSuSE give back something similar to Debian, but only Ubuntu uses Debian in its PR. Best regards -- Isaac Clerencia at Warp Networks, http://www.warp.es Work: [EMAIL PROTECTED] | Debian: [EMAIL PROTECTED] pgpPFkzASGL9z.pgp Description: PGP signature
Bug#348728: ITP: php-net-imap -- PHP PEAR module implementing IMAP protocol
Package: wnpp Severity: wishlist Owner: Steffen Joeris [EMAIL PROTECTED] * Package name: php-net-imap Version : 1.0.3 Upstream Author : Damian Alejandro Fernandez Sosa [EMAIL PROTECTED] * URL : http://pear.php.net/package/Net_IMAP * License : php license Description : PHP PEAR module implementing IMAP protocol Provides an implementation of the IMAP protocol using PEAR's Net_Socket class. . Homepage: http://pear.php.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
unsuscribe
Am Mittwoch, den 18.01.2006, 06:02 -0800 schrieb Sergio Talens-Oliag: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 18 Jan 2006 14:38:08 +0100 Source: gnome-u2ps Binary: gnome-u2ps Architecture: source i386 Version: 0.0.4-4 Distribution: unstable Urgency: low Maintainer: Sergio Talens-Oliag [EMAIL PROTECTED] Changed-By: Sergio Talens-Oliag [EMAIL PROTECTED] Description: gnome-u2ps - Tool to convert UTF-8 text to PostScript Closes: 348446 Changes: gnome-u2ps (0.0.4-4) unstable; urgency=low . * Add note about how to print to stdout on the manpage (Closes: Bug#348446). Files: cd6af8936a25ca682c2f2b8be52ba150 678 text optional gnome-u2ps_0.0.4-4.dsc 756e2caa542980c13c9866d910874158 13821 text optional gnome-u2ps_0.0.4-4.diff.gz 2c9da8b4fdb2ed224a1c0079b3d9c69a 28972 text optional gnome-u2ps_0.0.4-4_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDzkaIZ3AFK7jB+mkRAhq1AKCvrt5DBNCubx6bf2XEe3D4F3TXkwCdEx/P uwk7Uq/hOIHyBI6bocAPMpc= =gpv3 -END PGP SIGNATURE- Accepted: gnome-u2ps_0.0.4-4.diff.gz to pool/main/g/gnome-u2ps/gnome-u2ps_0.0.4-4.diff.gz gnome-u2ps_0.0.4-4.dsc to pool/main/g/gnome-u2ps/gnome-u2ps_0.0.4-4.dsc gnome-u2ps_0.0.4-4_i386.deb to pool/main/g/gnome-u2ps/gnome-u2ps_0.0.4-4_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
Le mercredi 18 janvier 2006 à 18:07 +0100, Martin Schulze a écrit : Andrew Suffield has lost his posting permission to debian-devel-announce after making a rather sarcastic point that off-topic mails to this list are unwanted. Sorry to feed again the troll, but I would like to know what is the rationale behind removing the permissions for Andrew and not for Raphaël. Both of them have been equally annoying and equally off-topic. Andrew may have harmed the project by posting a non-serious mail to an announcement list, but Raphaël has also harmed the project by implicitly linking it to Ubuntu. If you want to create a precedent for such removals - which I approve of - you'd better make it look consistent. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: For those who care about their packages in Ubuntu
On Wed, 2006-01-18 at 05:29, Reinhard Tartler wrote: Oh. There might be a misunderstanding: No binary package is taken from debian, only source packages. This means that EVERY package is being rebuilt in ubuntu on buildds, including arch: all packages. The output of apt-cache shows the field 'Origin' to indicate that this is not a package built on debian systems. Ubuntu does NOT set the origin in its packages: # dpkg -s dpkg | egrep -i '(origin|version):' Origin: debian Version: 1.13.10ubuntu4 # apt can be a useful tool but it tells you where it knows a package can be found, not the actual origin of an installed package: # dpkg -i --force-all xli_1.17.0-18sarge1_i386.deb (snip) # apt-cache show xli | grep -i origin: Origin: Ubuntu # If I understand your proposal correctly, you propose to introduce binNMU like versioning on ALL nondiverged packages (again, the source package is identical!). This seem not feasible because of practical problems. What practical problems? DDs can increment the two-dot version on a binary NMU. Why can't Ubuntu's copy-sources-from-debian script do the same? btw, the 'buildX' packages do change the source package, but by policy, only debian/changelog is touched, to increase the version number of the package. What please is the difference between a buildX package and all the other packages that were rebuilt without the buildX annotation? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
On Wed, Jan 18, 2006 at 06:44:32PM +0100, Josselin Mouette wrote: Sorry to feed again the troll, but I would like to know what is the rationale behind removing the permissions for Andrew and not for Raphaël. This has nothing to do with the technical aspects of Debian development (too bad the M-F-T from d-d-a makes replies come here). Can we move this to -project, pretty please? thanks, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
Reinhard Tartler [EMAIL PROTECTED] writes: On 1/18/06, Bill Allombert [EMAIL PROTECTED] wrote: As pointed out several times, the source package in the ubuntu archive is NOT different to the source package in the debian archive. The binary package have been rebuilt in an different environment, which can caus different dependencies on the resulting binary package. Yes, this is the definition of a no changes rebuild-only upload. What I asked was precisely that such upload should be versionned nevertheless. Debian version binNMU even while there is no source changes. Oh. There might be a misunderstanding: No binary package is taken from debian, only source packages. This means that EVERY package is being rebuilt in ubuntu on buildds, including arch: all packages. The output of apt-cache shows the field 'Origin' to indicate that this is not a package built on debian systems. If I understand your proposal correctly, you propose to introduce binNMU like versioning on ALL nondiverged packages (again, the source package is identical!). This seem not feasible because of practical problems. What exactly are these practical problems? I don't see how Ubuntu had no problem solving the problem of rebuilding *all* Debian packages, but can't automate making some simple changes to the package before the build. -- Captain Logic is not steering this tugboat. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
Reinhard Tartler [EMAIL PROTECTED] writes: Oh. There might be a misunderstanding: No binary package is taken from debian, only source packages. This means that EVERY package is being rebuilt in ubuntu on buildds, including arch: all packages. The output of apt-cache shows the field 'Origin' to indicate that this is not a package built on debian systems. Good grief, and Matt Zimmerman said the exact opposite recently, saying that Ubuntu does not rebuild every package. I have no idea which is correct, but your statement matches what I have been told before Matt said this recently. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Wouter Verhelst [EMAIL PROTECTED] writes: On Tue, Jan 17, 2006 at 04:54:36PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: Besides which, do you honestly know which packages other Debian derivatives rebuild? As a rule, they are far less communicative about their practices than Ubuntu. How does the behavior of other Debian derivatives matter? How does it not matter? Because tu quoque is a fallacy, and is quoque is even more one. The fact that many people do a bad thing does not make the badness of John Doe's doing it any better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
On Wed, Jan 18, 2006 at 06:44:32PM +0100, Josselin Mouette wrote: Raphaël has also harmed the project by implicitly linking it to Ubuntu. Don't be ridiculous. Ubuntu explicitly acknowledge that they build on Debian - see http://www.ubuntulinux.org/ubuntu/relationship - and Debian positively encourages derivative distributions - so where's the harm? Can we stop this time-wasting flame war already, please? Dave signature.asc Description: Digital signature
Re: For those who care about debian-devel-announce
On 10538 March 1977, Martin Schulze wrote: The charter for this list says: Announcements for developers. The charter for -private reads Private discussions among developers: only for issues that may not be discussed on public lists. Anything sent there should be treated as sensitive and not to be spread to other lists; Ever read that? Since this mail also mentions Andrews sarcastic posting http://lists.debian.org/debian-devel-announce/2006/01/msg9.htmlI may lose posting permissions as well. You should lose -private rights, as you clearly cant follow its rule to not leak. -- bye Joerg 4. If you are using the Program in someone else's bedroom at any Monday 3:05 PM, you are not allowed to modify the Program for ten minutes. [This clause provided by Inphernic; every licence should contain at least one clause, the reasoning behind which is far from obvious.] -- libdumb 1:0.9.3-1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Wed, 2006-01-18 at 11:21 +0100, Thomas Hood wrote: Steve Langasek wrote: Given that python-minimal is Essential: yes in Ubuntu, the *only* use for this package in Debian (given that there would be no packages in the wild that depend on it -- the definition of Essential is that you don't need to depend on it) is if we make it Essential: yes as well. I don't see why. If python-minimal were included in Debian then some packages that currently Depend on python could (if their needs are minimal) Depend on python-minimal instead. This would be an improvement, and obtaining this benefit does not require that python-minimal be Essential: yes in Debian. This depends entirely on what's in python-minimal. At 2MB, I have my doubts that most Python programs/modules in Debian will work. I agree with Steve. Unless we're going to make this package Essential, it's kind of pointless (unless compatibility with Ubuntu is a primary goal -- maybe it should be, but then someone needs to explain why, because it's not obviosu to me). And I don't see a need to make it Essential. -- Joe Wreschnig [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: For those who care about their packages in Ubuntu
Paul Johnson [EMAIL PROTECTED] writes: On Tuesday 17 January 2006 16:54, Matt Zimmerman wrote: You have not ever shown a serious interest in what Debian would like. This is, again, insulting, and nonsensical in the face of the repeated dialogues I have initiated and participated in with Debian developers regarding Ubuntu practices. Debian deserves better than to be represented by this kind of behavior. What BSG writes is the feeling I'm getting from you as well. This is not Planet Ubuntu, Debian doesn't exist purely to source Ubuntu. I'm personally tired of the attitude from Ubuntu users and developers alike that this is Planet Ubuntu. My name is Thomas, not BSG. Sorry for the confusion. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
Raphael Hertzog [EMAIL PROTECTED] writes: I'm in line with David. Thomas, if you care about the topic, you must be interested in convincing the one who can make a change on Ubuntu's policy. And the person in question is Matt. If you scare your only interlocutor with Ubuntu, then you can be sure that you won't get what you want. I would be happy with either of two alternatives: * Ubuntu changes its practices to actually start cooperating with Debian. * Ubuntu stops claiming it is cooperating with Debian. What Matt wants to do, as judged by his actual behavior, is to claim he is cooperating with Debian, and then disregard what Debian has actually said, repeatedly, would constitution cooperation. The most important things are: * Proper use of the BTS to file bug reports and patches back. * Proper use of the Maintainer field to indicate the individual responsible for the package and able to make changes. And now, a third has entered my radar screen because it never occurred to me that Ubuntu was so seriously screwing this one up: * Proper changing of package version numbers when Ubuntu rebuilds packages. Matt has argued that some people disagree with the exact parameters of the second of these three. And, on the basis of that disagreement, he does nothing about it at all, and ignores the first and third. If he wanted to demonstrate good faith, he would have required Debian-relevant Ubuntu changes to be reported to the BTS long ago. There has never been disagreement within Debian about this, and if he actually meant I want to do the right thing, but you all can't agree, then he would do the right thing *now* for the cases where there is straightforward agreement. The fact that he has not done so convinces me that he is not really interested in cooperating with Debian. But he *is* interested in appearing to cooperate with Debian. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
On Wed, Jan 18, 2006 at 06:25:07PM +, Dave Holland wrote: On Wed, Jan 18, 2006 at 06:44:32PM +0100, Josselin Mouette wrote: Raphaël has also harmed the project by implicitly linking it to Ubuntu. Don't be ridiculous. Ubuntu explicitly acknowledge that they build on Debian - see http://www.ubuntulinux.org/ubuntu/relationship - and Debian positively encourages derivative distributions - so where's the harm? Can we stop this time-wasting flame war already, please? That's not the right way to stop flame wars: 1. Wrong list, please discuss this on -project if you must. 2. Do not add opinions to it if you think you want a thread to end. cheers, Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
Joerg Jaspert writes: On 10538 March 1977, Martin Schulze wrote: The charter for this list says: Announcements for developers. The charter for -private reads Private discussions among developers: only for issues that may not be discussed on public lists. Anything sent there should be treated as sensitive and not to be spread to other lists; Ever read that? Since this mail also mentions Andrews sarcastic posting http://lists.debian.org/debian-devel-announce/2006/01/msg9.htmlI may lose posting permissions as well. You should lose -private rights, as you clearly cant follow its rule to not leak. I don't understand. Martin's email did not mention -private. Do you mean to say that this decision was made as the result of discussion on -private? Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On 1/18/06, Mike Bird [EMAIL PROTECTED] wrote: On Wed, 2006-01-18 at 05:29, Reinhard Tartler wrote: Oh. There might be a misunderstanding: No binary package is taken from debian, only source packages. This means that EVERY package is being rebuilt in ubuntu on buildds, including arch: all packages. The output of apt-cache shows the field 'Origin' to indicate that this is not a package built on debian systems. Ubuntu does NOT set the origin in its packages: # dpkg -s dpkg | egrep -i '(origin|version):' Origin: debian Version: 1.13.10ubuntu4 # apt can be a useful tool but it tells you where it knows a package can be found, not the actual origin of an installed package: # dpkg -i --force-all xli_1.17.0-18sarge1_i386.deb (snip) # apt-cache show xli | grep -i origin: Origin: Ubuntu # I think this is something we can work on or have changed. I only checked the output of apt-cache. I think apt-cache however, is the most common case for user who want to know about a package, but anyhow.. If I understand your proposal correctly, you propose to introduce binNMU like versioning on ALL nondiverged packages (again, the source package is identical!). This seem not feasible because of practical problems. What practical problems? DDs can increment the two-dot version on a binary NMU. Why can't Ubuntu's copy-sources-from-debian script do the same? requesting binNMUs requires access to wanna-build, AFAIK. Humble ubuntu developers do not have access to that, just uploads. We can talk about uploading policy. I ask to be corrected if I'm wrong on this point. btw, the 'buildX' packages do change the source package, but by policy, only debian/changelog is touched, to increase the version number of the package. What please is the difference between a buildX package and all the other packages that were rebuilt without the buildX annotation? It is quite similar to what debian calls a binary NMU, but developers do not need wanna-build access to that. Instead, they upload a new .dsc and .diff.gz, which gets accepted by katie as new package upload. These kind of uploads are necessary during transitions, e.g. when a package has been built against an older library but needs to be rebuilt with an newer one. -- regards, Reinhard
Re: Debian derivatives and the Maintainer: field (again)
Andreas Tille [EMAIL PROTECTED] writes: On Wed, 18 Jan 2006, Otavio Salvador wrote: Debian-EDU is available in Debian but also outside of it since they Well, that's a temporary hack until we have implemented solutions which makes this superfluous. But exist! -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Hello!
martin f krafft [EMAIL PROTECTED] writes:
also sprach Emilio Jesús Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for 2.4 kernels only these days. udev
As it has been pointed by Tomas Hood, udev is the same hack that
ifrename of a custom nameif script and it is not race free. Indeed,
some of the DEV_NET events are special-cased in half of udev due to
not having a device file associated.
A netif name is given in the kernel, udev only tries to rename it (as
the other tools do):
udev_add.c:287
} else if (udev-type == DEV_NET) {
/* look if we want to change the name of the netif */
if (strcmp(udev-name, udev-kernel_name) != 0) {
retval = rename_net_if(udev);
if (retval != 0)
goto exit;
info(renamed netif to '%s', udev-name);
/* we've changed the name, now fake the devpath, cause
the
* original kernel name sleeps with the fishes and we
don't
* get an event from the kernel with the new name
*/
pos = strrchr(udev-devpath, '/');
if (pos != NULL) {
pos[1] = '\0';
strlcat(udev-devpath, udev-name,
sizeof(udev-devpath));
strlcpy(udev-kernel_name, udev-name,
sizeof(udev-kernel_name));
setenv(DEVPATH, udev-devpath, 1);
setenv(INTERFACE, udev-name, 1);
}
}
With the current situation, upstream (kernel) support is needed to do
the rename in a successfully way. You could retry the rename, but then
you'd get into liveliness issues (you want eth0-eth1 and eth1-eth0,
etc...).
So I think that using other tools for the job is equally appropriate.
I'll stop now as I really have no clue about udev and this has nothing
to do with the original post.
Regards, sorry for the noise and keep up the good work with Debian,
Emilio
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
Michael Poole [EMAIL PROTECTED] writes: Joerg Jaspert writes: On 10538 March 1977, Martin Schulze wrote: Since this mail also mentions Andrews sarcastic posting http://lists.debian.org/debian-devel-announce/2006/01/msg9.html I may lose posting permissions as well. You should lose -private rights, as you clearly cant follow its rule to not leak. I don't understand. Martin's email did not mention -private. Do you mean to say that this decision was made as the result of discussion on -private? No, but the decision was only published in a posting to -private. The whole point of Joey's mail was to make the act of revoking posting permissions public (which I support, though I'm not too happy about the way it was done) Marc -- Fachbegriffe der Informatik - Einfach erklärt 1: Multimedia funktioniert mit elektrischem Strom (Kristian Köhntopp) pgpMQXLZGZMzm.pgp Description: PGP signature
make-kpkg fails, Bug?
Hi,
I just did an upgrade on Sid and an upgrade on Linus tree. Since
then, I can't create a kernel-image.
gcc version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)
Package: kernel-package
Version: 10.032
I just would love to know if we should set a bug on kernel-package
(AFAIK, that is the one in charge?) or if it's Linus tree.
I run:
. getkernelupdate
git checkout -f
make oldconfig
make-kpkg clean
make-kpkg --revision=T42.v3.1 kernel_image
...
make[1]: Leaving directory `/root/linux-2.6'
/usr/bin/makeARCH=i386 prepare
make[1]: Entering directory `/root/linux-2.6'
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `set -e; echo ' CHK include/linux/version.h';
mkdir -p include/linux/;if [ `echo -n 2.6.16-rc1 .file null
.ident GCC:(GNU)4.0.320060115(prerelease)(Debian4.0.2-7) .section
.note.GNU-stack,,@progbits | wc -c ` -gt 64 ]; then echo '2.6.16-rc1
.file null .ident GCC:(GNU)4.0.320060115(prerelease)(Debian4.0.2-7)
.section .note.GNU-stack,,@progbits exceeds 64 characters' 2; exit 1;
fi; (echo \#define UTS_RELEASE \2.6.16-rc1 .file null .ident
GCC:(GNU)4.0.320060115(prerelease)(Debian4.0.2-7) .section
.note.GNU-stack,,@progbits\; echo \#define LINUX_VERSION_CODE `expr 2
\\* 65536 + 6 \\* 256 + 16`; echo '#define KERNEL_VERSION(a,b,c) (((a)
16) + ((b) 8) + (c))'; ) /root/linux-2.6/Makefile
include/linux/version.h.tmp; if [ -r include/linux/version.h ] cmp -s
include/linux/version.h include/linux/version.h.tmp; then rm -f
include/linux/version.h.tmp; else echo ' UPD
include/linux/version.h'; mv -f include/linux/version.h.tmp
include/linux/version.h; fi'
make[1]: *** [include/linux/version.h] Error 2
make[1]: Leaving directory `/root/linux-2.6'
make: *** [debian/stamp-kernel-conf] Error 2
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
* Marc 'HE' Brockschmidt [EMAIL PROTECTED] [2006:01:18 20:23 +0100]: Michael Poole [EMAIL PROTECTED] writes: Joerg Jaspert writes: On 10538 March 1977, Martin Schulze wrote: Since this mail also mentions Andrews sarcastic posting http://lists.debian.org/debian-devel-announce/2006/01/msg9.html I may lose posting permissions as well. You should lose -private rights, as you clearly cant follow its rule to not leak. I don't understand. Martin's email did not mention -private. Do you mean to say that this decision was made as the result of discussion on -private? No, but the decision was only published in a posting to -private. The whole point of Joey's mail was to make the act of revoking posting permissions public (which I support, though I'm not too happy about the way it was done) It's not possible for those of us not on -private to figure out what's going on, really, but is it possible that it wasn't made public in an effort to protect Andrew's privacy? Were I a listmaster, that would've been one of my considerations, regardless of what he'd done to justify the ban. I think it's potentially important that the rest of us know some disciplinary action has been taken, but I can't say that it's relevant to, say, his future employers. (M-F-T: set to -project, *please* reply there.) -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#348728: ITP: php-net-imap -- PHP PEAR module implementing IMAP protocol
* Package name: php-net-imap Version : 1.0.3 Upstream Author : Damian Alejandro Fernandez Sosa [EMAIL PROTECTED] * URL : http://pear.php.net/package/Net_IMAP * License : php license You should be aware that per the current REJECT_FAQ [1] your package will be automatically rejected because it uses the PHP License. Several weeks ago I emailed the FTP Masters[2], requesting that they accept the PHP Licence for all PHP Group software, backed up by extensive debian-legal discussion. They were explicitely invited to either modify their rejection criteria, or continue the debian-legal debate, both of which they have failed to do. I am now re-extending that invitation. Charles 1. http://ftp-master.debian.org/REJECT-FAQ.html 2. http://lists.debian.org/debian-legal/2006/01/msg00066.html -- A guy Who wants To middle-aisle it Must never scratch His little violet Burma-Shave http://burma-shave.org/jingles/1947/a_guy signature.asc Description: Digital signature
Re: Bug#348728: ITP: php-net-imap -- PHP PEAR module implementing IMAP protocol
You should be aware that per the current REJECT_FAQ [1] your package will be automatically rejected because it uses the PHP License. Several weeks ago I emailed the FTP Masters[2], requesting that they accept the PHP Licence for all PHP Group software, backed up by extensive debian-legal discussion. They were explicitely invited to either modify their rejection criteria, or continue the debian-legal debate, both of which they have failed to do. I am now re-extending that invitation. Charles 1. http://ftp-master.debian.org/REJECT-FAQ.html 2. http://lists.debian.org/debian-legal/2006/01/msg00066.html Hi Thanks for the information. I haven't noticed it before because I saw various packages in Debian using the PHP license. I told my sponsor to wait with the upload. I will ask him for upload when PHP license is DFSG compatible or tell him to drop it if the project disagree with the PHP license. Nevertheless i think the project should make a decision. Waiting for it now ... Greetings and thanks for info Steffen pgpCoMxH7JJpb.pgp Description: PGP signature
Re: For those who care about debian-devel-announce
* Brendan [EMAIL PROTECTED] [2006:01:18 14:54 -0500]: This thread is a huge waste of bandwidth. Can't you boys compare pickles somewhere else? This gets, (what's the expression?) a big ole fat PLONK. Sorry sweetie, I'm not a boy and have no pickle to compare. -- off the chain like a rebellious guanine nucleotide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Wed, 2006-01-18 at 11:04, Reinhard Tartler wrote: On 1/18/06, Mike Bird [EMAIL PROTECTED] wrote: What please is the difference between a buildX package and all the other packages that were rebuilt without the buildX annotation? It is quite similar to what debian calls a binary NMU, but developers do not need wanna-build access to that. Instead, they upload a new .dsc and .diff.gz, which gets accepted by katie as new package upload. These kind of uploads are necessary during transitions, e.g. when a package has been built against an older library but needs to be rebuilt with an newer one. Not sure what your first It refers to. When there's a library transition, does the package get a new version in Ubuntu like it would in Debian? If yes, why do some Ubuntu packages have the same version as Debian when Ubuntu is using different libraries than Debian? --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make-kpkg fails, Bug?
On Wed, 18 Jan 2006, Alejandro Bonilla Beeche wrote:
Hi,
I just did an upgrade on Sid and an upgrade on Linus tree. Since
then, I can't create a kernel-image.
gcc version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)
Package: kernel-package
Version: 10.032
I just would love to know if we should set a bug on kernel-package
(AFAIK, that is the one in charge?) or if it's Linus tree.
I run:
. getkernelupdate
git checkout -f
make oldconfig
make-kpkg clean
make-kpkg --revision=T42.v3.1 kernel_image
...
make[1]: Leaving directory `/root/linux-2.6'
/usr/bin/makeARCH=i386 prepare
make[1]: Entering directory `/root/linux-2.6'
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `set -e; echo ' CHK include/linux/version.h';
What does /bin/sh point to?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about debian-devel-announce
This thread is a huge waste of bandwidth. Can't you boys compare pickles somewhere else? This gets, (what's the expression?) a big ole fat PLONK. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: On Tue, Jan 17, 2006 at 04:09:50PM -0800, Thomas Bushnell BSG wrote: Notice that what you say, in response to what has been asked over and over, is my opinion is that changing the Maintainer field on otherwise-unmodified source packages is too costly for derivatives in general. But you say nothing about why. You already have suitable automated tools. I don't think you can speak to what tools we do or do not have. The fact is, we import most Debian source packages unmodified, and do not have any such tool for modifying them. Don't you run wanna-build, buildd and sbuild? It is easy enough to change the maintainer field with that. Since you are rebuilding the package, you *must* change the version number *anyway*. It is not correct to recompile, and leave the version number alone. I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. They obviously do. The version is bumped and a new changelog entry is added. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Mike Bird [EMAIL PROTECTED] writes: On Tue, 2006-01-17 at 17:29, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. Actually, binary-only NMUs, after the first compilation, *do* get new version numbers. In Debian yes. Ubuntu recompiles the Debian source, in a different environment and with different dependencies, then uploads with exactly the same version as Debian. Having two different package files with the exactly the same name and different content and dependencies drove me crazy for a while until we made our migration scripts smarter. --Mike Bird Andreas Barth has some patches for the debian policy and packaging manual from me under review that also include this situation. In short it adds (explains the existing) an optional fourth (sub)part to the debian version: [epoch:]upstream_version[-debian_revision[+branch]] The debian_revision may contain an additional branch suffix denoting a fork in the debian version number. I suggest 4 types of branches [abcs]: - 1.2-3+a0.ubuntu.1 - recompile of a package without changes - 1.2-3+b1 - debian binary only recompile - 1.2-3+c0.ubuntu.1 - patched source based on the debian version - 1.2-3+s1.sarge.1 - debian security upload If that gets accepted into policy I suggest asking all debian based distributions to use the 'a' or 'c' branch to correctly flag recompiles and patching. Using the distribution name in the branch should give an unique enough version to avoid any confusion about the origin. An unbranched version should always mean the binary is unmodified (the md5sum matches debians). MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Andrew Suffield
On Sun, Jan 15, 2006 at 05:09:03PM -0600, Joe Wreschnig wrote: On Sun, 2006-01-15 at 06:28 -0500, sean finney wrote: On Sun, Jan 15, 2006 at 11:58:51AM +0100, Adrian von Bidder wrote: Do you think your constant bitching is funny? Do you think it achieves anything? There are other DDs who are also involved in intense debates and flamewars very often, but you're the only one where I constantly get the impression that you're just being childish, insulting and annoying for the sake of it. ...says someone who just publicly ostracized a fellow dd on a public mailing list. personal opinions of the matter aside, debian-devel is not the place for ridiculing other developers, no matter how justified you feel you may be. please post follow-ups to -private. I said this on -private, and I'll say it here -- why is it appropriate to be an ass on -private, but not on -devel? It's not appropriate anywhere. That goes for Adrian, and Andrew, and everyone. It also leads to situations like the present, where it looks like we're doing nothing to reprimand offensive behavior, because most conversation is happening on -private, while the original, offensive message is sitting on d-d-a. If you are upset by how Andrew acted, talk to him rationally, regardless of whether it's public or private. If you are *very* upset by how Andrew acted, there is an appropriate and agreed-to policy for expelling developers. Roger Leigh has mentioned his interest in seeing this through; contact him. -- Joe Wreschnig [EMAIL PROTECTED] I imagine that the ubuntu people, which include those on canonicals payroll that are posting to this list, are really finding this kind of discord within the Debian community quite comical and amusing. Regards, Dallam -- Revenge is an integral part of forgiving and forgetting. -- The BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, 18 Jan 2006, Otavio Salvador wrote: Well, that's a temporary hack until we have implemented solutions which makes this superfluous. But exist! Sure they exist, but the statement you made about the maintainer field was simply wrong, because it makes no sense to change the maintainer field of Debian internal packages. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Andrew Suffield
On 1/18/06, Dallam Wych [EMAIL PROTECTED] wrote: On Sun, Jan 15, 2006 at 05:09:03PM -0600, Joe Wreschnig wrote: On Sun, 2006-01-15 at 06:28 -0500, sean finney wrote: On Sun, Jan 15, 2006 at 11:58:51AM +0100, Adrian von Bidder wrote: Do you think your constant bitching is funny? Do you think it achieves anything? There are other DDs who are also involved in intense debates and flamewars very often, but you're the only one where I constantly get the impression that you're just being childish, insulting and annoying for the sake of it. ...says someone who just publicly ostracized a fellow dd on a public mailing list. personal opinions of the matter aside, debian-devel is not the place for ridiculing other developers, no matter how justified you feel you may be. please post follow-ups to -private. I said this on -private, and I'll say it here -- why is it appropriate to be an ass on -private, but not on -devel? It's not appropriate anywhere. That goes for Adrian, and Andrew, and everyone. It also leads to situations like the present, where it looks like we're doing nothing to reprimand offensive behavior, because most conversation is happening on -private, while the original, offensive message is sitting on d-d-a. If you are upset by how Andrew acted, talk to him rationally, regardless of whether it's public or private. If you are *very* upset by how Andrew acted, there is an appropriate and agreed-to policy for expelling developers. Roger Leigh has mentioned his interest in seeing this through; contact him. -- Joe Wreschnig [EMAIL PROTECTED] I imagine that the ubuntu people, which include those on canonicals payroll that are posting to this list, are really finding this kind of discord within the Debian community quite comical and amusing. You ignore that a lot of them are part of the Debian community. This project would be better if people like you applied part of the imagination to contribute (at least) with useful comments. -- Gustavo Franco -- [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wed, Jan 18, 2006 at 09:41:58AM +0100, cobaco (aka Bart Cornelis) wrote: On Tuesday 17 January 2006 00:39, Matt Zimmerman wrote: The full quote is We sync our packages to Debian regularly, because that introduces the latest work, the latest upstream code, and the newest packaging efforts from a huge and competent open source community. Without Debian, Ubuntu would not be possible. It should be obvious from the remainder of the sentence that it is talking about propagation of changes *from* Debian *to* Ubuntu. syncinc _to_ debian implies that changes are _pushed_ to Debian regularly, whereas in actuallity they're simply made available for pull by Debian (in most cases) I am pleased to report to all who were confused or offended by the ambiguities in these quotations that Mark has clarified them both in the wiki already. Considere the following: - right now there are no Ubuntu changes to my package - if Ubuntu suddenly does change my package for whatever reason, there's absolutely no way I'll suddenly know to go check the patch page. The PTS already contains this information; if you want asynchronous notification, that should be easy to arrange within the PTS. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Andrew Suffield
On Wed, Jan 18, 2006 at 06:57:13PM -0200, Gustavo Franco wrote: You ignore that a lot of them are part of the Debian community. This project would be better if people like you applied part of the imagination to contribute (at least) with useful comments. Rather, I think *you* missed my point...I tend to be a bit dimissive of people who change sides for a dollar/pound/whatever. As for applying my imagination, I contribute to Debian by way of local install fests, helping steer new users in my community towards Debian, etc. Note all us aren't whiz-bang programmers hence one *can* help Debian without being a DD. I have been a Debian user for about four years now, a linux user since '95...so don't do the glib disrespectful bit on me. Kind Regards, Dallam -- Revenge is an integral part of forgiving and forgetting. -- The BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Tue, Jan 17, 2006 at 05:29:40PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. Actually, binary-only NMUs, after the first compilation, *do* get new version numbers. The source packages don't. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wed, Jan 18, 2006 at 10:01:31AM +0100, Gerfried Fuchs wrote: * Matt Zimmerman [EMAIL PROTECTED] [2006-01-17 11:36]: I'm saying that you should pause and consider that you're looking at a world-writable resource before treating its contents as a position statement on behalf of the project, and that malicious intent is far from the only (or even the most common) reason for errors. It could very well be that Mark or someone else originally wrote from Debian and the quote was transcribed incorrectly. Then pretty please fix it. You surely understand that it isn't appropriate for me to change a quote which is attributed to someone else. However, I did ask Mark to clarify it, and he has done so, so hopefully you can rest easy and this subthread can die. I haven't a clue what you're talking about here. What press release, and how does d-d-a enter into it? You do read d-d-a, don't you? I am refering to buxy's mail, which stirred this all up. I did, but I have no idea what you meant to say by a press release so you can add d-d-a to your announce lists, or how this relates to the mail that you cite. Perhaps you could rephrase it more clearly? The grammar in the original is difficult to parse. Do you not read debian-devel-announce? Yes, I do. Again, I cite myself: I wonder why I never received any bugreport about my stupid and wrong C++ transition here... Do you imply with this message that Ubuntu doesn't care about quality in their upstreams but rather keep their stuff to themselfes? Please, be reasonable. You were notified about the existence of the patch in an announcement on a mailing list that Debian developers are required to read. Don't blame Ubuntu because you didn't use this information. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Andrew Suffield
On 1/18/06, Dallam Wych [EMAIL PROTECTED] wrote: On Wed, Jan 18, 2006 at 06:57:13PM -0200, Gustavo Franco wrote: You ignore that a lot of them are part of the Debian community. This project would be better if people like you applied part of the imagination to contribute (at least) with useful comments. Rather, I think *you* missed my point...I tend to be a bit dimissive of people who change sides for a dollar/pound/whatever. As for applying my imagination, I contribute to Debian by way of local install fests, helping steer new users in my community towards Debian, etc. Note all us aren't whiz-bang programmers hence one *can* help Debian without being a DD. I have been a Debian user for about four years now, a linux user since '95...so don't do the glib disrespectful bit on me. I'm glad that you contribute to Debian, you're part of the Debian community as some people that you're pointing that changed sides for a dollar. I'm sure that you don't know none of them, to say for sure. Please, stop the troll here. If you really believe in what you're saying go in the right ubuntu list and complain. See, i haven't excluded you in my previous message, i don't even knew if you were a DD, before replying. I don't care, i used the term 'community' and not 'whiz-bang programmers' or whatever. -- Gustavo Franco - [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't think you can speak to what tools we do or do not have. The fact is, we import most Debian source packages unmodified, and do not have any such tool for modifying them. Don't you run wanna-build, buildd and sbuild? It is easy enough to change the maintainer field with that. Not in the source package, which is what was being discussed in that context. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Wed, Jan 18, 2006 at 11:21:32AM +0100, Thomas Hood wrote: Steve Langasek wrote: Given that python-minimal is Essential: yes in Ubuntu, the *only* use for this package in Debian (given that there would be no packages in the wild that depend on it -- the definition of Essential is that you don't need to depend on it) is if we make it Essential: yes as well. I don't see why. If python-minimal were included in Debian then some packages that currently Depend on python could (if their needs are minimal) Depend on python-minimal instead. This would be an improvement, This is something that Python upstream explicitly does not want; the only reason for creating python-minimal was so that it could be Essential: yes, not to support stripped-down Python installations. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: On Tue, Jan 17, 2006 at 05:29:40PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. Actually, binary-only NMUs, after the first compilation, *do* get new version numbers. The source packages don't. What are you talking about? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't think you can speak to what tools we do or do not have. The fact is, we import most Debian source packages unmodified, and do not have any such tool for modifying them. Don't you run wanna-build, buildd and sbuild? It is easy enough to change the maintainer field with that. Not in the source package, which is what was being discussed in that context. Huh? Actually, you'll find, they do! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Wed, Jan 18, 2006 at 10:18:22AM -0800, Thomas Bushnell BSG wrote: Reinhard Tartler [EMAIL PROTECTED] writes: Oh. There might be a misunderstanding: No binary package is taken from debian, only source packages. This means that EVERY package is being rebuilt in ubuntu on buildds, including arch: all packages. The output of apt-cache shows the field 'Origin' to indicate that this is not a package built on debian systems. Good grief, and Matt Zimmerman said the exact opposite recently, saying that Ubuntu does not rebuild every package. I said no such thing, and would appreciate your retraction on this point. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. They obviously do. The version is bumped and a new changelog entry is added. Yes. And then the source used to build that binNMU is thrown away. It's a *binary* NMU, you don't see a sourceful upload with that. -- .../ -/ ---/ .--./ / .--/ .-/ .../ -/ ../ -./ --./ / -.--/ ---/ ..-/ .-./ / -/ ../ --/ ./ / .--/ ../ -/ / / -../ ./ -.-./ ---/ -../ ../ -./ --./ / --/ -.--/ / .../ ../ --./ -./ .-/ -/ ..-/ .-./ ./ .-.-.-/ / --/ ---/ .-./ .../ ./ / ../ .../ / ---/ ..-/ -/ -../ .-/ -/ ./ -../ / -/ ./ -.-./ / -./ ---/ .-../ ---/ --./ -.--/ / .-/ -./ -.--/ .--/ .-/ -.--/ .-.-.-/ / ...-.-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, Jan 18, 2006 at 11:21:32AM +0100, Thomas Hood wrote: Steve Langasek wrote: Given that python-minimal is Essential: yes in Ubuntu, the *only* use for this package in Debian (given that there would be no packages in the wild that depend on it -- the definition of Essential is that you don't need to depend on it) is if we make it Essential: yes as well. I don't see why. If python-minimal were included in Debian then some packages that currently Depend on python could (if their needs are minimal) Depend on python-minimal instead. This would be an improvement, This is something that Python upstream explicitly does not want; the only reason for creating python-minimal was so that it could be Essential: yes, not to support stripped-down Python installations. Ah, the law of unintended consequences. You can't stop that; you can't say here's the package, but nobody should use it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
On Wed, Jan 18, 2006 at 01:28:17PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't think you can speak to what tools we do or do not have. The fact is, we import most Debian source packages unmodified, and do not have any such tool for modifying them. Don't you run wanna-build, buildd and sbuild? It is easy enough to change the maintainer field with that. Not in the source package, which is what was being discussed in that context. Huh? Actually, you'll find, they do! Please show me which part of wanna-build or sbuild modifies a source package. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Andrew Suffield
On Wed, Jan 18, 2006 at 07:19:55PM -0200, Gustavo Franco wrote: I'm glad that you contribute to Debian, you're part of the Debian community as some people that you're pointing that changed sides for a dollar. I'm sure that you don't know none of them, to say for sure. Please, stop the troll here. If you really believe in what you're saying go in the right ubuntu list and complain. I find it quite interesting that you refer me to the right ubuntu list to complain. It also seems to be quite fashionable to label someone as a troll who disagrees with with anothers opinion. As I see it, the ubuntu people are posting to *this* list. Perhaps you should refer *them* to the ubuntu list? As to knowing any of them, I'm assuming that you mean on a personal basis and if so then indeed you are correct though I don't know what that has to do with anything. I didn't know Richard Nixon or Margaret Thatcher on a personal basis either, but I do know they made some bad errors in judgement. Excuse me if I don't see the relevance of your comment. See, i haven't excluded you in my previous message, i don't even knew if you were a DD, before replying. I don't care, i used the term 'community' and not 'whiz-bang programmers' or whatever. Right. My whiz-bang programmer comment probably is indictative of an inner frustration in that I wish I had better programing skills so that I could contribute to Debian more. It wasn't intended as a slight to anyone else. Really. Honestly, I don't want to have an argument with you or anyone else about ubuntu. I think it really would be better to discuss ubuntu on ubuntu lists. Kind Regards, Dallam -- Revenge is an integral part of forgiving and forgetting. -- The BOFH -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
On Wed, Jan 18, 2006 at 01:43:53PM -0800, Thomas Bushnell BSG wrote: Matt Zimmerman [EMAIL PROTECTED] writes: This is something that Python upstream explicitly does not want; the only reason for creating python-minimal was so that it could be Essential: yes, not to support stripped-down Python installations. Ah, the law of unintended consequences. You can't stop that; you can't say here's the package, but nobody should use it. Fortunately, no one attempted to do that. What we did do was discuss our plan with Python upstream and ensure that our treatment of the package satisfied their concerns. It's amazing what can be accomplished when both parties actually want to come to an agreement. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [ad-hominem construct deleted]
On Wed, Jan 18, 2006 at 12:30:22PM +0200, Riku Voipio wrote: On Wednesday 18 January 2006 11:01, Gerfried Fuchs wrote: So you are saying it's the Debian Developer's job to pull changes from ubuntu back? If that is an official statement, then that would be useful for a d-d-a mail so we are aware of it. This is what also wonder about ubuntu-haters. Somehow it is OK for Debian to have different opinions and preferences (Tell me about changes vs don't spam me or You don't Attribute my work vs Don't put my name there). But at the same time you require a explict policy from ubuntu and anytime a ubuntu developer says something about it is considered a official position statetement.. Until we can do a official statement of debian derivate policy ourselfs, we can hardly require it from them.. We don't have to require an official position statement from Ubuntu -- it's already been published. The other difference is that Ubuntu has a Dictator For Life, who runs the show, while Debian is just a loose collection of people who elect someone annually to keep them out of mischief. grin Also, other Debian derivatives and Gentoo/Fedora/OpenSUSE don't make a habit of touting their contributions to Debian, and that's been the main complaint that I've seen in this thread -- that Ubuntu *talks* about contributing back to Debian, but isn't *seen* to be doing so, on a systematic basis. Do you imply with this message that Ubuntu doesn't care about quality in their upstreams but rather keep their stuff to themselfes? The same can be claimed about about Debian and our upstreams. Not all maintainers submit their patches upstream, and sometimes our lack of co-operation have made our upstreams really unhappy (Remember micq?). The micq debacle wasn't about Debian not sending patches upstream, it was about Debian not being able to keep up-to-date with the intentional breakages of the ICQ protocol by Miribilis, and consequently making micq (and hence, it's author) look bad. And I like to point out that there isn't any correspondence between the ubuntu developers and the debian developers in respect to getting sensible patches they do back into debian, which very much disappoints me, if not does get me a bad opinion on the intentions of ubuntu. Ubuntu (and other derivates) are using the same freedoms Debian is built upon. We would not accept a licence that required us to submit our patches upstream (dissident and desert island tests), so howcome it is OK to require such behaviour from our downstreams? We're not requiring any particular behaviour from our downstreams beyond licence compliance and keeping their promises. - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: when and why did python(-minimal) become essential?
Matt Zimmerman [EMAIL PROTECTED] writes: You can't stop that; you can't say here's the package, but nobody should use it. Fortunately, no one attempted to do that. What we did do was discuss our plan with Python upstream and ensure that our treatment of the package satisfied their concerns. What I mean is that this doesn't stop people from starting to use and depend on the package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
D-I team January meeting MOVES AGAIN: Saturday January 28th 17:00UTC
The monthly Debian Installer team meeting which was initially scheduled for January 14th is reported to January 21st, as several D-I developers will attend the Extremadura session about the graphical installer development (http://wiki.debian.org/WorkSessionsExtremadura). And, sorry, the above was completely wrong and the Extremadura session is being held from today up to next Sunday. My mistake. So, The Debien Installer team meeting is AGAIN reported to Saturday January 28th, 17:00UTC. Please accept my apologies as the original date of Jan 14th would have perfectly fit, but for some strange reasons I was figuring out that the Extremadura meeting was happening at that moment. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
Matt Zimmerman [EMAIL PROTECTED] writes: On Wed, Jan 18, 2006 at 10:18:22AM -0800, Thomas Bushnell BSG wrote: Reinhard Tartler [EMAIL PROTECTED] writes: Oh. There might be a misunderstanding: No binary package is taken from debian, only source packages. This means that EVERY package is being rebuilt in ubuntu on buildds, including arch: all packages. The output of apt-cache shows the field 'Origin' to indicate that this is not a package built on debian systems. Good grief, and Matt Zimmerman said the exact opposite recently, saying that Ubuntu does not rebuild every package. I said no such thing, and would appreciate your retraction on this point. Ok, then I must have misunderstood something. So it is clear then that Ubuntu does recompile every package. Now, can you do the following, which I don't think there is any diversity of opinion about: When you recompile packages, change their version number just as Debian does for binary-NMUs? That is, the first binary compile for an arch gets the same version number as the original source, but all future recompilations, which would include those done by Ubuntu or anyone else, should get a modified version number. Will you establish an Ubuntu policy that all bugs found, whether patched or not, which might exist in the upstread Debian package, should always be reported to the BTS? I believe there has been no disagreement about these points from the Debian perspective. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Wouter Verhelst [EMAIL PROTECTED] writes: On Wed, Jan 18, 2006 at 08:57:51PM +0100, Goswin von Brederlow wrote: Matt Zimmerman [EMAIL PROTECTED] writes: I don't agree. This isn't even the case within Debian. Binary-only NMUs don't modify the source package, even though the binaries are recompiled. They obviously do. The version is bumped and a new changelog entry is added. Yes. And then the source used to build that binNMU is thrown away. It's a *binary* NMU, you don't see a sourceful upload with that. And yet the version number is changed, and the recorded changelog is altered too (which does land in the binary package as a rule). So this is the point: these are crucial things that allow tracking of different binary version of the same source, and it is these things which we would like to see. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian derivatives and the Maintainer: field (again)
Matt Zimmerman [EMAIL PROTECTED] writes: Don't you run wanna-build, buildd and sbuild? It is easy enough to change the maintainer field with that. Not in the source package, which is what was being discussed in that context. Huh? Actually, you'll find, they do! Please show me which part of wanna-build or sbuild modifies a source package. The binary NMU process does this for *rebuilt* binaries, after the first. I refer to the end effect of Debian's normal procedures, not the particular tools used to effect these results. I do not recall which tool does it, and I'm sorry if it sounded like I was saying that wanna-build and/or sbuild was the tool in question. Debian's normal procedure is that the first build of a package for an arch gets a version number copied from the source, but all future builds that are installed into the archive have an altered version number. All Ubuntu rebuilds are future builds in this way, and so they should all get an altered version number. It would be particularly pleasant and helpful if they contained a version number that was labelled ubuntu in some respect. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make-kpkg fails, Bug?
Adam Heath wrote:
On Wed, 18 Jan 2006, Alejandro Bonilla Beeche wrote:
Hi,
I just did an upgrade on Sid and an upgrade on Linus tree. Since
then, I can't create a kernel-image.
gcc version 4.0.3 20060115 (prerelease) (Debian 4.0.2-7)
Package: kernel-package
Version: 10.032
I just would love to know if we should set a bug on kernel-package
(AFAIK, that is the one in charge?) or if it's Linus tree.
I run:
. getkernelupdate
git checkout -f
make oldconfig
make-kpkg clean
make-kpkg --revision=T42.v3.1 kernel_image
...
make[1]: Leaving directory `/root/linux-2.6'
/usr/bin/makeARCH=i386 prepare
make[1]: Entering directory `/root/linux-2.6'
/bin/sh: -c: line 0: syntax error near unexpected token `('
/bin/sh: -c: line 0: `set -e; echo ' CHK include/linux/version.h';
What does /bin/sh point to?
Could you please explain what is exactly what you need to check?
.Alejandro
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#348775: general: terminal emulators' alternatives settings' priorities annoy users
Package: general Severity: normal -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, The problem at hand is the proposed (and implemented) solution for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=332223 . I'm unconvinced that bumping the priority on the other terminal emulators is an adequate solution, hence I'm opening this general bug for discussion on how to reflect individual users' choices properly. It has been suggested on #debian-devel that maybe creating a per-user ~/bin with its own alternatives links might be an option, however there needs to be a fallback mechanism in case the currently selected option goes away. Perhaps it might be an idea to have a wrapper binary that will fall back on the highest precedence alternative in this case, or optionally show a menu (gee, there may be multiple wrapper programs, so there needs to be a mechanism to select them...NOT!). This message shall serve as a starting point for discussion. Please CC the bug in replies. Simon - -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (50, 'experimental') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-powerpc Locale: LANG=de_DE.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iQCVAwUBQ87HPVYr4CN7gCINAQJRxwP9ErXin3cuJ3ZRjTPqJTSTXYUWKZk/cOm1 bPdktUtLUcdRpbRDDB37LEzkkhaUjSfN2JTdGzzSOUkGgJJw4kZ7N10aU6oSLrrd JAAolW3jIr8d+kH7kI3SF478X3J2mEiS4t21maY8N0Yz8fo2vj/YMsHeP0dRG0ck k0FVwyE4J3E= =eOr6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On Wed, Jan 18, 2006 at 02:47:05PM -0800, Thomas Bushnell BSG wrote:
Ok, then I must have misunderstood something. So it is clear then
that Ubuntu does recompile every package.
To clarify explicitly:
- Ubuntu does not use any binary packages from Debian
- Most Ubuntu source packages are identical copies from Debian, while some are
modified for Ubuntu
- All Ubuntu binary packages are built for Ubuntu in Ubuntu chroots
When you recompile packages, change their version number just as
Debian does for binary-NMUs? That is, the first binary compile for
an arch gets the same version number as the original source, but all
future recompilations, which would include those done by Ubuntu or
anyone else, should get a modified version number.
I believe there are still packages which break when bin-NMU'd (e.g.,
Depends: = ${Source-Version}), and there are parts of our infrastructure
which do not support them (Ubuntu doesn't do bin-NMUs). If it were
essential to version the packages differently, I would say that the source
package versions should be changed as well. Bin-NMUs are more trouble than
they are worth.
Why is it now important to you that the version numbers be changed, though?
This is only an issue when mixing packages between different derivatives,
which already breaks in other subtle ways, so I'm not very much inclined to
try to un-break it in this particular way, given that it's non-trivial.
Will you establish an Ubuntu policy that all bugs found, whether
patched or not, which might exist in the upstread Debian package,
should always be reported to the BTS?
The might here is a problem. It is considered to be in poor taste to
report bugs to bugs.debian.org which have not been verified on Debian, and
attempting to confirm every bug is not feasible for us (we can't even come
close to confirming every bug on Ubuntu).
--
- mdz
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
Philipp Matthias Hahn wrote:
udevd uses ioctl(SIOCSIFNAME) to rename the devices. If you drivers are
compiled in, the get assigned eth[01] during init, but udev is called
much later. Renaming eth0 to eth1 will fail, because there already is an
eth1 and vis versa. Consider using another name system for your network
interfaces, like lan and man.
(be advised, that renaming will break Debian's VLAN scripts, because they
expect your device names to be eth[0-9]*.[0-9]*)
Emilio JesÃs GallegoArias wrote:
martin f krafft [EMAIL PROTECTED] writes:
also sprach Emilio JesÃs Gallego Arias [EMAIL PROTECTED] [2006.01.18.1254
+0100]:
As far as I can tell, network interface names are given by the
kernel and they've nothing to do with udev.
To get a stable naming you should use some package like ifrename.
ifrename is a hack and needed for 2.4 kernels only these days. udev
As it has been pointed by Tomas Hood, udev is the same hack that
ifrename of a custom nameif script and it is not race free. Indeed,
some of the DEV_NET events are special-cased in half of udev due to
not having a device file associated.
...
With the current situation, upstream (kernel) support is needed to do
the rename in a successfully way. You could retry the rename, but then
you'd get into liveliness issues (you want eth0-eth1 and eth1-eth0,
etc...).
Md wrote:
my /etc/udev/rules.d/000local.rules looks like this:
Renaming must happen after the WAIT_FOR_SYSFS, which is in
permissions.rules.
...
SYSFS{address}==00:50:70:e3:16:c2, NAME=eth0, RUN+=/bin/echo 1
/root/udev.log
This RUN action will never work because /root is not writeable when the
rule is processed. You should use something like:
RUN+=/bin/touch /dev/flag-eth0-1
Marco, this is useful indeed, but the problem remains: in the debian
standard kernel the 8138too and 3c59x drivers are both modules, and both
are present in the initramfs.
If they are loaded and get the kernel name before udev starts I have no
chances in renaming them, because the names are both token.
I can imagine many hacks for solving the situation, but none of them is
clean nor standard.
renaming the interfaces to something like net*, for what I can see,
means that I have to reconfigure some packages by hand, and probably I
will have to do the same during the next upgrade.
surely I can set up a script that removes the two modules, modprobe them
in the right order and restart the networking stuff, but that's not
really clean.
or I could remove the 3c59x module from the initramfs, etc...
maybe modifying mkinitramfs script to include udev in the initramfs
could help?
is there any plan to do so?
I did so with wy firewall, and now it can load the firmware for the usb
modem from within the initramfs, but I don't know if this could solve
this situation.
thanks
davide
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev naming problems for eth*
On Jan 19, Davide Natalini [EMAIL PROTECTED] wrote: maybe modifying mkinitramfs script to include udev in the initramfs could help? udev is already part of the initramfs, but its presence is not relevant. The options are: - use names which cannot be used by the kernel, or - help me cleaning up and adapting to Debian the SuSE scripts which provide persistent names for network interfaces I did so with wy firewall, and now it can load the firmware for the usb modem from within the initramfs, but I don't know if this could solve this situation. This reminds me that there should be a list of modules which MUST NOT be added to the initramfs because loading them too early is both useless and as in this case actively harmful. -- ciao, Marco signature.asc Description: Digital signature
Re: udev naming problems for eth*
Op do, 19-01-2006 te 00:11 +0100, schreef Davide Natalini: Marco, this is useful indeed, but the problem remains: in the debian standard kernel the 8138too and 3c59x drivers are both modules, and both are present in the initramfs. If they are loaded and get the kernel name before udev starts I have no chances in renaming them, because the names are both token. I can imagine many hacks for solving the situation, but none of them is clean nor standard. renaming the interfaces to something like net*, for what I can see, means that I have to reconfigure some packages by hand, and probably I will have to do the same during the next upgrade. surely I can set up a script that removes the two modules, modprobe them in the right order and restart the networking stuff, but that's not really clean. or I could remove the 3c59x module from the initramfs, etc... maybe modifying mkinitramfs script to include udev in the initramfs could help? IIRC mkinitramfs already includes udev and copies your udev configuration into the into to initramfs. Greetings Arjan Oosting signature.asc Description: This is a digitally signed message part
Re: For those who care about their packages in Ubuntu
mdz writes: It is considered to be in poor taste to report bugs to bugs.debian.org which have not been verified on Debian... I should think that in most cases by the time you've produced a patch that fixes a bug in an Ubuntu package you would be able to tell whether or not the bug is likely to be present in the corresponding Debian package. If you are wrong once in a while it's hardly the end of the world. -- John Hasler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: make-kpkg fails, Bug?
On Wed, 18 Jan 2006, Alejandro Bonilla Beeche wrote: What does /bin/sh point to? Could you please explain what is exactly what you need to check? ls -l /bin/sh In other words, what does /bin/sh point to? What shell is /bin/sh? bash? zsh(gods no)? posh? dash? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: For those who care about their packages in Ubuntu
On 1/18/06, Mike Bird [EMAIL PROTECTED] wrote: On Wed, 2006-01-18 at 11:04, Reinhard Tartler wrote: On 1/18/06, Mike Bird [EMAIL PROTECTED] wrote: What please is the difference between a buildX package and all the other packages that were rebuilt without the buildX annotation? It is quite similar to what debian calls a binary NMU, but developers do not need wanna-build access to that. Instead, they upload a new .dsc and .diff.gz, which gets accepted by katie as new package upload. These kind of uploads are necessary during transitions, e.g. when a package has been built against an older library but needs to be rebuilt with an newer one. Not sure what your first It refers to. When there's a library transition, does the package get a new version in Ubuntu like it would in Debian? That depends. If there are any changes outside from debian/changelog needed to get the package built on the buildds, then we have to introduce the 'ubuntuX' suffix in the version string. The point of this is to prevent autosyncs when the next version in debian appears. If no changes are necessary, then a 'buildX' suffix is appended if and only if there is no 'ubuntuX' suffix yet. The advantage in this case is that the package will be autosynced on the next debian upload. (if there already is an 'ubuntu' suffix, it is just increased, in that case, we don't want autosyncs anyway). If yes, why do some Ubuntu packages have the same version as Debian when Ubuntu is using different libraries than Debian? Ubuntu source packages which have the same version number as the debian sourcepackage are identical (i.e. have the same md5 sums) [0]. Since every ubuntu binary package is built in ubuntu chroots it does happen that the binary package ends with different binary dependencies than it would have in a debian chroot. Does this answer your question? [0] There is a cornercase when ubuntu introduced a new upstream version before debian did and the debian maintainer uploads an orig.tar.gz with an different md5 sum. This is a situation which really should be avoided wherever possible (and is very seldom anyway). -- regards, Reinhard
