Re: Meeting Minutes, FTPMaster meeting March 2011
On Tue, Mar 29, 2011 at 10:50:31AM -0300, Henrique de Moraes Holschuh wrote: > At that point, exactly why should you not upload the entire thing? In most parts of the world you actually have to pay for data transfer. So why transfer something that is not going to be used at all? Bastian -- Superior ability breeds superior ambition. -- Spock, "Space Seed", stardate 3141.9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110330095421.ga7...@wavehammer.waldi.eu.org
Re: Best practice for cleaning autotools-generated files?
On Tue, Mar 15, 2011 at 10:29:57PM +, Marcin Owsiany wrote: > The current best practice for dealing with packages using GNU autotools > (as described in /usr/share/doc/autotools-dev/README.Debian.gz) is to > run autoreconf in a prerequisite of a build target, and to remove its > results in the clean target. You should be able to use diff-ignore in debian/source/options and just exclude them from the diff generation. Bastian -- Either one of us, by himself, is expendable. Both of us are not. -- Kirk, "The Devil in the Dark", stardate 3196.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110316153825.ga18...@wavehammer.waldi.eu.org
Re: Speeding up dpkg, a proposal
On Wed, Mar 02, 2011 at 08:13:06PM +, Roger Leigh wrote: > Btrfs is quite simply awful in chroots at present, and it seems > --force-unsafe-io doesn't really seem to help massively either. > It's dog slow--it's quicker to untar a chroot onto ext3 than to > bother with Btrfs. Because unsafe-io does not apply to the handling of the info directory. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110302231220.ga31...@wavehammer.waldi.eu.org
Re: symbol patterns in .symbols files prior to dpkg-1.15.6
On Mon, Jan 24, 2011 at 03:02:17PM +0100, Christian Kastner wrote: > I was > wondering though if anybody had a better approach to recommend? Simply remove them. They are not needed for proper operation, as the shlibs file works as fallback. Bastian -- Virtue is a relative term. -- Spock, "Friday's Child", stardate 3499.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110124174737.ga18...@wavehammer.waldi.eu.org
Re: binNMU for Arch: all packages.
On Sat, Jan 15, 2011 at 10:29:46AM +, Philipp Kern wrote: > Arch:all binNMUing will only work if you keep the invariant of > version(arch:all) = version(source) in some way. This invariant comes from where? From my knowledge neither w-b nor dak cares about it. Bastian -- Deflector shields just came on, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110115125334.gb19...@wavehammer.waldi.eu.org
Re: binNMU for Arch: all packages.
On Sat, Jan 15, 2011 at 01:23:01PM +0100, Julien Cristau wrote:
> On Sat, Jan 15, 2011 at 12:21:52 +0100, Stéphane Glondu wrote:
> > Le 15/01/2011 11:29, Philipp Kern a écrit :
> > > Arch:all binNMUing will only work if you keep the invariant of
> > > version(arch:all) = version(source) in some way.
> > Why is this needed?
> If ${source:Version} is not version(arch:all) you've got yourself an
> uninstallable package. If ${source:Version} is not version(source)
> things become slightly confusing.
Only if it is used. However the packages in question _don't_ have
versioned relations at all:
| Package: libghc6-zip-archive-doc
| Priority: extra
| Section: doc
| Installed-Size: 252
| Maintainer: Debian Haskell Group
| Architecture: all
| Recommends: ghc6-doc
| Suggests: libghc6-zip-archive-dev
>Again. We've had enough of that with
> ${Source-Version}. And it'll probably break some other stuff as well.
Well. Who spoke about a change of source:Version at all?
Bastian
--
Killing is wrong.
-- Losira, "That Which Survives", stardate unknown
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110115125206.ga19...@wavehammer.waldi.eu.org
Re: Collecting data
On Fri, Dec 24, 2010 at 05:41:12PM +0200, derleader __ wrote: > The kernel module will check the status of the OS every 5 minutes. What is > the most efficient way to collect these data? apt-get install munin-node Bastian -- Star Trek Lives! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101224163914.ga27...@wavehammer.waldi.eu.org
Re: Bug#605009: serious performance regression with ext4
On Tue, Nov 30, 2010 at 10:35:11AM +0100, Samuel Thibault wrote: > Mike Hommey, le Tue 30 Nov 2010 10:07:55 +0100, a écrit : > > On Mon, Nov 29, 2010 at 07:18:17AM +0100, Guillem Jover wrote: > > > Hmm, ok so what about posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED) > > > instead, skimming over the kernel source seems to indicate it might > > > end up doing more or less the same thing but in a portable way? > > On the other hand, there is no guarantee that other kernels do the same, > Err, that's posix. What is POSIX? What exactly is written in the standard? Please quote. Okay, here is the quote[1]: | POSIX_FADV_DONTNEED | Specifies that the application expects that it will not access the | specified data in the near future. sync_file_range is Linux-specific and documented to do exactly what we want[2]. posix_fadvise with POSIX_FADV_DONTNEED is not documented to do what we want but only does it as a side-effect (and may hurt others because it evicts anything of the cache). Bastian [1]: http://www.opengroup.org/onlinepubs/9699919799/functions/posix_fadvise.html [2]: fs/sync.c -- "That unit is a woman." "A mass of conflicting impulses." -- Spock and Nomad, "The Changeling", stardate 3541.9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101130102602.ga22...@wavehammer.waldi.eu.org
Re: Bug#605009: serious performance regression with ext4
On Mon, Nov 29, 2010 at 01:22:25PM +, Ian Jackson wrote:
> Olaf van der Spek writes ("Re: Bug#605009: serious performance regression
> with ext4"):
> > Are there any plans to provide an API for atomic (non-durable) file
> > updates, not involving fsync?
> Yes. Such an API has already been defined by POSIX, SuSv3, et al.
> It's called "rename".
Please quote the appropriate standards. "rename" is atomic, aka there is
no time both the old and the new name exists.
> I'm told that the Linux fs maintainers have now accepted that
>open("file.new",O_CREAT);
>write();
>close();
>rename("file.new","file");
> should not result, even after a crash, in "file" containing garbage.
It does not contain gargabe. It is empty.
> If this is the case then all the fsyncs can be taken out again.
Again: Please quote the standard instead of crying. Your view of things
disallows many of the recent improvements in filesystems, so you have to
show evidence. All the databases and other reliable data handing tools
uses fsync since a long time, because the writes may or may not hit the
disk otherwise.
Bastian
--
Even historians fail to learn from history -- they repeat the same mistakes.
-- John Gill, "Patterns of Force", stardate 2534.7
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101129135647.ga24...@wavehammer.waldi.eu.org
Re: How to add dependencies that exist in another repository
On Thu, Nov 11, 2010 at 12:03:30PM +0100, Andreas Tille wrote: > On Thu, Nov 11, 2010 at 10:35:34AM +0100, Goswin von Brederlow wrote: > > I have a package my-apt-config that installs the gpg key for the local > > repository, a /etc/apt/sources.list.d/ file, /etc/apt/apt.conf.d/ file > > and /etc/apt/preferences.d/ file with all the right settings for me. > I completely agree but did not managed to get /etc/apt/preferences.d/ > working as expected. Did I missed a piece of documentation or can you > provide any working example. Your apt is too old. Upgrade to Squeeze. Bastian -- There is an order of things in this universe. -- Apollo, "Who Mourns for Adonais?" stardate 3468.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2010115703.gb22...@wavehammer.waldi.eu.org
Re: Accepted postgresql-9.0 9.0.0-1 (source all amd64)
On Mon, Sep 20, 2010 at 06:11:31PM +0200, Rene Engelhard wrote: > $ cat /var/lib/dpkg/info/libpq5.shlibs > libpq 5 libpq5 (>= 9.0~) > And how are packages linking against libpq5 now aupposed to go into squeeze > with fixes? A preliminary analysis shows that the addition of a symbols file should be enough for the client library in libpq5. There are five new exported functions and no tricky define stuff. Not sure about the other lib. For the record, -release asked to NMU this fast. No further warning will be given if this seems to be working and I see no response from the maintainer. Bastian -- Klingon phaser attack from front! 100% Damage to life support -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100920171039.gb9...@wavehammer.waldi.eu.org
Re: RFC: Policy 10.1 and appropriateness of package conflicts
On Sat, Aug 14, 2010 at 09:29:52AM -0700, Wouter Verhelst wrote: > wou...@celtic:~$ ls -l /usr/bin/gcc > lrwxrwxrwx 1 root root 7 jun 6 07:23 /usr/bin/gcc -> gcc-4.4 > wou...@celtic:~$ dpkg -S /usr/bin/gcc > gcc: /usr/bin/gcc > wou...@celtic:~$ dpkg -S /usr/bin/gcc-4.1 > gcc-4.1: /usr/bin/gcc-4.1 > How is that any different? The name gcc is fixed. Bastian -- The heart is not a logical organ. -- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814165502.ga8...@wavehammer.waldi.eu.org
Re: RFC: Policy 10.1 and appropriateness of package conflicts
On Fri, Aug 13, 2010 at 09:20:17AM -0400, Michael Hanke wrote: > I'm trying to figure out a solution for RC bug #592242. The short > summary of this bug is a package A that conflicts with a package B due > to a name clash in /usr/bin. The programs in question do not provide the > same functionality, hence the alternatives systems cannot be used. > Debian policy 10.1 states: > > Two different packages _must not_ install programs with different > functionality but with the same filenames. (The case of two programs > having the same functionality but different implementations is handled > via "alternatives" or the "Conflicts" mechanism...) > > Since renaming is not an option due to large side-effects in the > packages in question, I declared a package conflict between A and B and > uploaded a new version. However, various parties expressed their > concerns with this "solution". You forgot the rest of the paragraph: | If this case happens, one of the programs must be renamed. The maintainers | should report this to the debian-devel mailing list and try to find a consensus | about which program will have to be renamed. If a consensus cannot be reached, | both programs must be renamed. > However, the situation of #592242 is different. The package (fsl) that > conflicts with other packages (e.g. cyrus-clients-2.2) only installs a > number of symlinks to tools of a large analysis suite into /usr/bin. The > actual suite is installed by another package (fsl-4.1) that does not > conflict with other packages. Hence users will always be able to > install this suite in combination with any other package. The only > purpose of the conflicting package is to allow for a more convenient > out-of-the-box setup for people who run this analysis suite as the > primary software in their research labs. If, for some reason, they happen > to run any of the conflicting packages they can still use the suite with no > drawbacks other than reduced initial setup convenience. I would consider the names of the binaries to generic anyway. > Is there something that is intended by policy 10.1 that I am missing? Yes, at least one package have to rename, and this is a must clause. Bastian -- Captain's Log, star date 21:34.5... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100814111245.ga3...@wavehammer.waldi.eu.org
Re: Moving ACL utilities to /bin?
On Thu, Jul 22, 2010 at 12:30:40PM +0200, Julien BLACHE wrote: > This makes it impossible to use them during the early boot sequence > before /usr is mounted, so they're unusable in udev rules for instance. Care to explain what you try to do? We have groups for access control to devices and you can't rely on the availability of acl support in /dev. BAstian -- ... bacteriological warfare ... hard to believe we were once foolish enough to play around with that. -- McCoy, "The Omega Glory", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100723074254.ga20...@wavehammer.waldi.eu.org
Re: Bindv6only once again
On Sat, Jun 12, 2010 at 01:58:30AM +0200, Juliusz Chroboczek wrote: > In netbase 4.38, Marco d'Itri has unilaterally decided to change the > value of the net.ipv6.bindv6only sysctl to 1. This change has the > following effects: > > (1) it violates POSIX 2008, Volume 2, Section 2.10.20; > (2) it violates RFC 3493, Section 5.3; > (3) it breaks software that is written to comply to POSIX, most notably > Sun's Java. Please start with "fixing" the FreeBSD kernel. It only supports this mode of operation. Bastian -- Men will always be men -- no matter where they are. -- Harry Mudd, "Mudd's Women", stardate 1329.8 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100612090150.ga8...@wavehammer.waldi.eu.org
[RESENT] Re: Xen for Squeeze, 3.4 or 4.0
Whoops, wrong recipient. On Thu, Jun 10, 2010 at 05:54:28PM +0200, Bastian Blank wrote: > I'm currently thinking about which version of Xen supporting in Squeeze. > There are two possibilities: 3.4 and 4.0. 3.4 is currently in testing > and unstable, 4.0 is in experimental. > > Xen 3.4 > === > Pros > - Proofed to be stable > Cons > - NUMA-mode only opt-in, no infos about stability > - Fails on several modern machines because of IO-APIC problems > > Xen 4.0 > === > Pros > - NUMA > - More tested with the Kernel in Squeeze > Cons > - Quite new > > My personal preference would be to go with 4.0. > > Bastian > > Cc debian-devel, as there was quite a few discussions about this matter > in the last months. -- Vulcans worship peace above all. -- McCoy, "Return to Tomorrow", stardate 4768.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100610155858.ga13...@wavehammer.waldi.eu.org
Xen for Squeeze, 3.4 or 4.0
Hi folks I'm currently thinking about which version of Xen supporting in Squeeze. There are two possibilities: 3.4 and 4.0. 3.4 is currently in testing and unstable, 4.0 is in experimental. Xen 3.4 === Pros - Proofed to be stable Cons - NUMA-mode only opt-in, no infos about stability - Fails on several modern machines because of IO-APIC problems Xen 4.0 === Pros - NUMA - More tested with the Kernel in Squeeze Cons - Quite new My personal preference would be to go with 4.0. Bastian Cc debian-devel, as there was quite a few discussions about this matter in the last months. -- Peace was the way. -- Kirk, "The City on the Edge of Forever", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100610155428.ga12...@wavehammer.waldi.eu.org
Re: setgid umask override versus global umask change
On Sun, May 30, 2010 at 09:44:49AM -0700, Mike Bird wrote: > What, I wonder, would be the consequences of setgid directories > overring umask, rather than a system wide umask change? Use POSIX ACLs for this. Bastian -- "We have the right to survive!" "Not by killing others." -- Deela and Kirk, "Wink of An Eye", stardate 5710.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100530185249.ga13...@wavehammer.waldi.eu.org
Re: Recent changes in dpkg
On Thu, May 27, 2010 at 12:00:47PM +0200, Mike Hommey wrote: > > Why they want it unfortunately is a wrong reasoning - the actual > > pending and still unanswered question is "why it is needed". They > > want people to switch to 3.0. By forcing to put something into > > debian/source/format people start putting 1.0 in there for no gain. I > > still fail to have received any real answer why debian/source/format > > "1.0" containing is better than no debian/source directory at all. > There is one possible benefit: impossibility to create a native package > when the .orig.tar.gz is missing, which happens much too often. Now you need to be more verbose. The dpkg-source manpage still lists 1.0 as supporting both patched and native. Bastian -- Either one of us, by himself, is expendable. Both of us are not. -- Kirk, "The Devil in the Dark", stardate 3196.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100527102740.ga26...@wavehammer.waldi.eu.org
Re: RFH: bashisms in configure script
On Tue, May 25, 2010 at 11:55:58PM +0200, Frans Pop wrote: > For example, almost all udebs are listed. Why? Because udebs execute > busybox shell as /bin/sh, which happens to be fairly compatible with bash. The busybox /bin/sh is also a dash, but a different version than the dash package. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100526091546.ga14...@wavehammer.waldi.eu.org
Re: Xen not booting in Unstable
On Wed, Apr 07, 2010 at 10:36:41PM +1000, Russell Coker wrote: > What is the best way of tracking down Xen fail to boot bugs? By providing all information the relevant packages (xen and linux) requests and reporting to the maintainers of this packages instead of the general public. However the symtoms looks like it may have been fixed in -11. Bastian -- Another dream that failed. There's nothing sadder. -- Kirk, "This side of Paradise", stardate 3417.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100407144718.ga22...@wavehammer.waldi.eu.org
Re: Xen, Squeeze, and Beyond
On Wed, Mar 24, 2010 at 10:25:14PM +0100, Matthias Klose wrote: > I did speak with Christian Motschke, who did test the package. I'll look > at the package this weekend, and sponsor it if nobody else did sponsor it > until then. Please don't. He did not come back to the Xen team after the discussion. There are too many questions open. Bastian -- Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324225030.gb29...@wavehammer.waldi.eu.org
Re: Xen, Squeeze, and Beyond
On Thu, Mar 25, 2010 at 03:22:16AM +0800, Thomas Goirand wrote: > It's been 3 months that I am searching for a sponsor for this one: Well, the mails don't looked like you wanted that. > http://ftparchive.gplhost.com/debian/pool/lenny/main/x/xen-qemu-dm-3.4/xen-qemu-dm-3.4_3.4.2-1.dsc > Which is tested and working. Please explain the differences to my packages described in 20091216212224.ga22...@wavehammer.waldi.eu.org>. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324224910.ga29...@wavehammer.waldi.eu.org
Re: linux-image-*-dbg for squeeze?
On Fri, Mar 05, 2010 at 09:07:50AM +0100, Lucas Nussbaum wrote: > I wonder what we (as Debian) could do about it. Would it make sense to > sponsor a very fast machine that the kernel team could use to build the > kernels and upload from, replacing kernel-archive.buildserver.net ? The easiest fix is the official blessing by the ftp team to upload only the architecture independant packages and build all architectures on the buildds. Bastian -- Time is fluid ... like a river with currents, eddies, backwash. -- Spock, "The City on the Edge of Forever", stardate 3134.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100305183417.ga6...@wavehammer.waldi.eu.org
Re: Xen, Squeeze, and Beyond
On Thu, Feb 25, 2010 at 04:53:56PM -0600, John Goerzen wrote: > "Xen - Provides para-virtualization and full-virtualization. Mostly used > on servers. Will be abandoned after squeeze." > The Xen page on the wiki makes no mention of this. Well, I don't know where this conclusion comes from. But usually the maintainers are responsible for such decisions. > 1) Will a squeeze system be able to run the Xen hypervisor? Why not? I see packages laying around. > 1) A Xen dom0? Most likely yes. I'm currently ironing out the obvious bugs. > 2) Will a squeeze system be able to be installed as a Xen domU with a > lenny dom0? What about squeeze+1? Yes. It should even run on RHEL 5. > 3) What will be our preferred Linux server virtualization option after > squeeze? Are we confident enough in the stability and performance of > KVM to call it such? (Last I checked, its paravirt support was of > rather iffy stability and performance, but I could be off.) Did we ever had something "preferred"? Bastian -- Humans do claim a great deal for that particular emotion (love). -- Spock, "The Lights of Zetar", stardate 5725.6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100226095726.ga12...@wavehammer.waldi.eu.org
Re: Status of systemtap in Debian
On Thu, Feb 18, 2010 at 02:01:19PM +0100, Lucas Nussbaum wrote: > On 18/02/10 at 00:18 +0100, Frank Lin PIAT wrote: > > On Tue, 2010-02-16 at 22:47 +0100, Lucas Nussbaum wrote: > > > Why couldn't it be done using a normal deb? It is just a matter of taste. > I's only a few hundreds of megabytes per kernel image. Its around half a GiB per image. >Some games or > debug packages require more space than that. I don't think it's worth > deploying an infrastructure just for that. Did you actually check that? In unstable I found 2 packages larger than 500MiB and less then 10 over 200MiB. None of them is contains debugging information. And for the data packages there is something planned. Bastian -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100218133145.ga29...@wavehammer.waldi.eu.org
Re: Debian Mobile -- Debian GNU/Linux for mobile devices
On Wed, Feb 17, 2010 at 03:53:32PM +0100, Julian Andres Klode wrote: > Is anyone interested in starting a Debian Mobile project, probably as a > Debian Pure Blend? You want to start with em-debian. > - Provide an environment for handheld and netbook devices > + example: the Nokia N900 Well, I would like to have something working for my N770. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, "The Omega Glory", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217151313.ga1...@wavehammer.waldi.eu.org
Re: Status of systemtap in Debian
On Tue, Feb 16, 2010 at 10:17:27PM +0100, Kurt Roeckx wrote: > On Tue, Feb 16, 2010 at 09:13:06PM +0100, Lucas Nussbaum wrote: > > > > - disk space on buildds: at least 2 GiB are required to build a kernel > > with debuginfo. (that doesn't sound too hard to satisfy) > There currently are packages that require more diskspace than > that, for instance the linux-2.6 package on i386 uses 4.7 GB, > while it uses 2.6 GB on amd64. This is a misinterpretation of my data. The effective space requirement is raised by factor 10 with debugging information. > Do you know if there is any cost in cpu time for this? For the build it is marginal. Until the size themself produces cpu usage, e.g. with ccache, which at least I use often to shorten the build time. On runtime it also seems negligible, at least on powerpc, s390 and x86, it adds a hook into the fault handler for kernel addresses. Bastian -- A father doesn't destroy his children. -- Lt. Carolyn Palamas, "Who Mourns for Adonais?", stardate 3468.1. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100217085847.ga17...@wavehammer.waldi.eu.org
Re: Status of systemtap in Debian
On Tue, Feb 16, 2010 at 09:13:06PM +0100, Lucas Nussbaum wrote: > - disk space on buildds: at least 2 GiB are required to build a kernel > with debuginfo. (that doesn't sound too hard to satisfy) A typical build includes between 2 and 10 of them. > - mirror space: each debug .deb would use ~ 450 MB (see > http://ddebs.ubuntu.com/pool/main/l/linux/) Our archive does not support ddebs. Bastian -- Deflector shields just came on, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100216212730.ga15...@wavehammer.waldi.eu.org
Re: TCP SYN cookies and Bug #520668
On Sun, Feb 14, 2010 at 12:42:09AM +1100, Craig Small wrote: > Before I make this change, I am emailling debian-devel for comments. I > am looking in particular for information about why it could be harmful > (if it is). You forgot to mail the maintainer of the package you change the configuration for. There are several packages now who applies various changes and this are all global parameters. Also you forget to mention my "no" as kernel maintainer. Bastian -- Warp 7 -- It's a law we can live with. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lxc linux image flavour
On Sun, Jan 24, 2010 at 06:19:02PM +0100, Suno Ano wrote: > As you can see from http://sunoano.pastebin.com/m4b5380dc , line 29, > Cgroup memory controller is not. This setting is mandatory if you want > to control the available memory per containers and the like. It is not mandantory for the system. > Bastian> The description reads like it is possible to enable/disable > Bastian> the overhead on boot time. Please elaborate. > Nope, it has to be enabled at build-time. http://lxc.teegra.net Please show this on the source. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, "The Omega Glory", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lxc linux image flavour
On Mon, Jan 25, 2010 at 12:26:42AM +, Marco d'Itri wrote: > Actually I meant "vzctl exec" so this is not even close: I need to > change the context of a running process. Hu? "vzctl exec" does a fork and an exec. Please enlighten me where the support you want is actually implemented. Bastian -- ... The prejudices people feel about each other disappear when they get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: lxc linux image flavour
On Sun, Jan 24, 2010 at 01:37:26PM +0100, maximilian attems wrote: > I thus propose to enable an lxc (linux containers) [1] flavour: Please describe the _kernel_ improvements over the normal images. Most of it is already enabled in the default images and does not warrant for an extra image. > * lxc is merged in linux-2.6 and continuously improved > (the maintenance of it should be thus much lower then >it was for openvz) lxc is the userspace part. > * RESOURCE_COUNTERS and CGROUP_MEM_RES_CTLR enabled > (has overhead that is not acceptable, for general purpose images) The description reads like it is possible to enable/disable the overhead on boot time. Please elaborate. Bastian -- The sight of death frightens them [Earthers]. -- Kras the Klingon, "Friday's Child", stardate 3497.2 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen support on Squeeze
On Sun, Jan 03, 2010 at 04:55:27PM +1100, Brian May wrote: > On Sun, Jan 03, 2010 at 01:21:55AM +, Ben Hutchings wrote: > > I believe we will have Xen hypervisor and Linux dom0 packages, but they > > will not be supported to the degree that ordinary kernel packages are. > I can't see any Xen kernel in Squeeze with support for Xen. Am I blind? Yes, you are. | Package: linux-image-2.6.32-trunk-686-bigmem | [...] | Description: Linux 2.6.32 for PCs with 4GB+ RAM | [...] | This kernel also runs on a Xen hypervisor. It supports only unprivileged | (domU) operation. > I don't see the hypervisor either, the only packages with xen in are: | Package: xen-hypervisor-3.4-i386 | [...] | Description: The Xen Hypervisor on i386 Bastian -- "Get back to your stations!" "We're beaming down to the planet, sir." -- Kirk and Mr. Leslie, "This Side of Paradise", stardate 3417.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen support on Squeeze
On Sun, Jan 03, 2010 at 01:21:55AM +, Ben Hutchings wrote: > I believe we will have Xen hypervisor and Linux dom0 packages, The hypervisor works well, but the Linux Dom0 packages are not available yet, upstream is again fading behind. Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, "Metamorphosis", stardate 3219.8 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sat, Dec 26, 2009 at 01:29:48AM +0100, Kurt Roeckx wrote: > On Tue, Oct 27, 2009 at 11:51:35PM +0100, Bastian Blank wrote: > > What would be a step forward: > > - Make any code PIC, including binaries (PIE) and static libs. > static libs would need to be PIE, not PIC. The differences between PIC and PIE are small. For all relevant architectures the only difference is to enable the shared libs assumptions for fPIC. > This is something that's not properly supported on all our arches. > Some people will also say it's too big a performance impact. I would only change this setting on a per-arch basis. It needs an additional register, but on most arches that should make no visible difference. Bastian -- You're dead, Jim. -- McCoy, "Amok Time", stardate 3372.7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Linux image packages going to depend on python
Hi folks The Linux image packages needs to do some modifications to core configuration files like fstab in the future to allow newer kernels to work. To do this and the planned further extension I intend to make all linux image packages depend on python. The python package is already part of the standard system via the priority, so for most people this will not make any difference. However there was concerns about the size from the embedded people, so I consider to restrict that to python-minimal. Bastian -- Live long and prosper. -- Spock, "Amok Time", stardate 3372.7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: New source package formats now available
On Sat, Nov 21, 2009 at 04:54:36PM +0100, Raphael Hertzog wrote: > since a few weeks the Debian archive accepts source package using the new > formats "3.0 (quilt)" and "3.0 (native)". I tried "3.0 (quilt)" with several packages today and none worked properly, so several large packages will be stuck with "3.0 (native)". Bugs as of today. * Packages with different patch systems like linux-2.6. In this case dpkg-source ignores failures to register a patch and produces sources without the changes. (#557618) * The "3.0 (quilt)" format is incompatible with "quilt" by using different patch directories and features. (#557619) * Fuzzy patches leads to silent ignore of the complete patchset. (#557664) * Different behaviour between quilt installed/not installed. Several others against quilt themself are missing. The whole thing is super fragile. It is mostly impossible to use both "3.0 (quilt)" and quilt themself because you use it to develop. > The last step for us (dpkg > maintainers) in this project is to change dpkg-source to use those new > formats by default. I will propose a GR to stop you if you go on until it works properly. And yes, this includes packages like linux-2.6, which have to use a more sophisticated patch system than quilt. Or you start and propose a different format that can be mostly like 3.0 (quilt) for the result (multiple tars) but without the implicit quilt constraints. > However, before we do this we want to ensure that > no packages (in sid) will be broken due to this switch and there are > quite a few packages left to fix: You have to add the bugs above. Bastian -- Lots of people drink from the wrong bottle sometimes. -- Edith Keeler, "The City on the Edge of Forever", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#555944: ITP: fast-md5 -- fast implementation of the MD5 algorithm written in Java
On Fri, Nov 13, 2009 at 12:42:17AM +0530, Onkar Shinde wrote: > * Package name: fast-md5 MD5 is broken. Why do you start with a package that supports exactly this one hash? > * URL : http://www.twmacinta.com/myjava/fast_md5.php The supplied tarball includes binaries, are you handling this properly? > fast-md5 is faster than the build-in MD5 support in java standard toolkit. What about contributing this back to the different implementations? There is no standard one. Bastian -- Power is danger. -- The Centurion, "Balance of Terror", stardate 1709.2 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Minimal kernel version raised to 2.6.27
On Wed, Nov 11, 2009 at 04:51:49PM +0100, Marco d'Itri wrote: > On Nov 11, Goswin von Brederlow wrote: > > >O_CLOEXEC (Since Linux 2.6.23) > > So why does using this flag require 2.6.27? Who is wrong here? > I understand that it is needed for inotify_init1(2). That makes more send. The syscall was introduced, not the flag. Bastian -- Worlds are conquered, galaxies destroyed -- but a woman is always a woman. -- Kirk, "The Conscience of the King", stardate 2818.9 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Minimal kernel version raised to 2.6.27
On Tue, Nov 10, 2009 at 06:08:08PM +0100, Marco d'Itri wrote: > Due to changes in udev 147, squeeze will not support kernels earlier > than 2.6.27. What are these changes? > If your packages have code needed to support old kernels, this is the > right time to clean it up. No. > This means that lenny->squeeze upgrades will use the same lockstep > kernel/udev upgrade method used for etch->lenny upgrades. Please explain. Bastian -- She won' go Warp 7, Cap'n! The batteries are dead! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sun, Nov 01, 2009 at 08:10:44PM +0100, Samuel Thibault wrote: > Ben Hutchings, le Sun 01 Nov 2009 19:06:59 +, a écrit : > > On Sun, 2009-11-01 at 19:53 +0100, Matthias Klose wrote: > > > there are some functions in glibc which are questionably declared with > > > the "warn > > > about unused result" attribute (fwrite*). This seems to force a > > > programming > > > style which not everybody agrees with (having to check the return value > > > after > > > each operation instead of checking errno later). > > In general you cannot rely on checking errno because it is not defined > > whether a successful operation clears it. > But you can clear it by hand before calling them. No, you can't. The value of errno is only defined after a failed call. It is undefined after a sucessfull call. You can see it as a special return value. Bastian -- It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, "The Trouble with Tribbles", stardate 4525.6 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Mon, Oct 26, 2009 at 09:41:59PM +0100, Christoph Anton Mitterer wrote: > Ever thought about integrating PaX [0] per default in Debian? What features does the grsecurity patch provide currently? I know that several of the mentioned PaX features are supported in vanilla kernel in the meantime: - Non-executable memory on x86-32 with PAE. - Randomized stack and heap bases. - /dev/mem is highly restricted now, /dev/kmem removed. What would be a step forward: - Move all newer x86 32bit machines to PAE to support non-executable pages. - Make any code PIC, including binaries (PIE) and static libs. > I'm however not sure how much this actually breaks ;) It takes to much compile time configuration, so don't even think about it. Bastian -- Phasers locked on target, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Lintian based autorejects
On Tue, Oct 27, 2009 at 06:06:12PM +0100, Bernhard R. Link wrote: > * Joerg Jaspert [091027 15:06]: > > Those automated rejects will only be done on sourceful uploads to > > unstable and experimental. > Are there any plans to extend this on binary-only uploads? First there needs to be proper handling of REJECT of binary-only uploads. Currently the mails (if it all) go to the buildd, not to the maintainer. Bastian -- Captain's Log, star date 21:34.5... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 01:28:33PM -0500, Manoj Srivastava wrote: > On Mon, Oct 26 2009, Bastian Blank wrote: > > Policy is not coupled with init or the libs. This is a problem between > > the kernel and the policy tools. > This is not totally true: init loads the initial policy, and > that means that linking with new versions of selinux libs makes a > difference at startup. It is, however, irrelevant for upgrades -- We are currently speaking about upgrades. And I doubt that init have the permission to load the policy again after transiting away from the initial startup role. > Which is why currently, as I have said before, re-execing init > is opportunistic. This may or may not be the case in the future. No. It is not. All the re-exec init calles are only to start it with new libs and there is no change visible for that role. Bastian -- In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, "Wolf in the Fold", stardate 3615.4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 07:23:12AM -0500, Manoj Srivastava wrote: > On Mon, Oct 26 2009, Bastian Blank wrote: > > Oh, and this could be made even easier by defining file-based triggers > > in the package providing init instead of doing it in all the > > dependencies. > In which case it definitely deserves discussion, some > coordination, and perhaps a policy proposal, as well as a more generic > solution. Which files would we be triggering on? The used libs. Bastian -- Landru! Guide us! -- A Beta 3-oid, "The Return of the Archons", stardate 3157.4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 11:22:35AM -0500, Manoj Srivastava wrote: > On Mon, Oct 26 2009, Bastian Blank wrote: > > > On Mon, Oct 26, 2009 at 07:21:31AM -0500, Manoj Srivastava wrote: > >> On Mon, Oct 26 2009, Bastian Blank wrote: > >> > Why are they not able to ignore the errors from telinit? All checked > >> > packages uses this to ask init to reexecute itself and free old library > >> > references. Nothing in this is critical to the usability of the packages > >> > themself or the system. > >> Even if the security system has changed? I dont't think so > >> (better safe than sorry). > > Which security system? Is there a list of packages trying to reexec > > init? The listed bugs only show libsepol and libselinux, both do > > nothing in respect of that. > So far, I hav not needed to. But I can see where there is a > major change in libselinux (we are at the same soname so far, so this > has not happened), and the new libselinux is needed to not have people > bypass init.d's security setup by exploiting a bug in the old system > (perhaps a change is needed in libselinux/libsepol to even load new > policy). If that happens, not being able to re-exec init can be grounds > for a failure to boot (as it is now if you enable selinux and init > can't load policy). Reexec init is only needed to make it change the security domain of itself. Rules reload would be done somewhere else. > > Selinux can only be activated on boot anyway. > What does this have to do with the price of rice in china? The > scenario of interest is a system with selinux enabled and in enforcing, > and a upgrade of security libraries (and policy, perhaps). Policy is not coupled with init or the libs. This is a problem between the kernel and the policy tools. I still don't see what you want to tell me. Bastian -- Witch! Witch! They'll burn ya! -- Hag, "Tomorrow is Yesterday", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 07:21:31AM -0500, Manoj Srivastava wrote: > On Mon, Oct 26 2009, Bastian Blank wrote: > > Why are they not able to ignore the errors from telinit? All checked > > packages uses this to ask init to reexecute itself and free old library > > references. Nothing in this is critical to the usability of the packages > > themself or the system. > Even if the security system has changed? I dont't think so > (better safe than sorry). Which security system? Is there a list of packages trying to reexec init? The listed bugs only show libsepol and libselinux, both do nothing in respect of that. Selinux can only be activated on boot anyway. Bastian -- Intuition, however illogical, is recognized as a command prerogative. -- Kirk, "Obsession", stardate 3620.7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > uses[2]. How do they work? Do they also change the free-standing compiler or only the hosted one? There is a lot of software, which (I would say) missuse the hosted compiler to build non-userspace-code, including the Linux kernel. Bastian -- History tends to exaggerate. -- Col. Green, "The Savage Curtain", stardate 5906.4 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Mon, Oct 26, 2009 at 10:40:56AM +0100, Bastian Blank wrote: > On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote: > > I created a elaborate test case tos ee if we are in a chroot, if > > not if /proc/1 is actually /sbin/init, and that telinit exists (example > > below). > Why are they not able to ignore the errors from telinit? All checked > packages uses this to ask init to reexecute itself and free old library > references. Nothing in this is critical to the usability of the packages > themself or the system. Oh, and this could be made even easier by defining file-based triggers in the package providing init instead of doing it in all the dependencies. Bastian -- Phasers locked on target, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#545691: diverting telinit
On Fri, Oct 23, 2009 at 12:43:18PM -0500, Manoj Srivastava wrote: > I created a elaborate test case tos ee if we are in a chroot, if > not if /proc/1 is actually /sbin/init, and that telinit exists (example > below). Why are they not able to ignore the errors from telinit? All checked packages uses this to ask init to reexecute itself and free old library references. Nothing in this is critical to the usability of the packages themself or the system. > Does this need discussion? Yes, it is highly sysvinit and Linux specific. Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, "Day of the Dove", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Fri, Sep 04, 2009 at 06:58:18PM +0200, Marco d'Itri wrote:
> On Sep 04, Bastian Blank wrote:
>
> > Why do you not extend the current setup to do another step? Currently we
> Even if this were possible at all, it would require (for a start):
> - working out all the possible side effects of synthesizing all/most
> (which ones?) events a second time
This is already the case.
> - having to forward port these changes forever, with the possibility of
> a new architectural change making the exercise useless at any time
Which change? This is an additional init script or so.
> > You could just add another ("change") trigger run after all filesystems
> > are available. (Okay, this extra names must not be used in the fstab at
> > all then.)
> No reason to bother then, persistent names are indispensable for many
> non-trivial systems.
Hu? So you did not even read what I said.
Bastian
--
Madness has no purpose. Or reason. But it may have a goal.
-- Spock, "The Alternative Factor", stardate 3088.7
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DeviceKit and /usr
Package: devicekit-disks Severity: serious On Fri, Sep 04, 2009 at 04:36:52PM +0200, Michael Biebl wrote: > I'd like to add here, that devicekit-disks will install udev helpers > /lib/udev/devkit-disks-* which are called in > /lib/udev/rules.d/95-devkit-disks.rules. > > devkit-disks-part-id and devkit-disks-probe-ata-smart both link against > libraries which are (currently) in /usr/lib, i.e. > devkit-disks-part-id links against libglib-2.0 (784K) > devkit-disks-probe-ata-smart links against (48K) Lets convert that into a bug. What exactly is the use of this tools? > This will mean, that we will need to install those two libs in /lib. > It's not something I'm very keen on to do, but given that almost all of GNOME > has migrated to DeviceKit-*, it's not something that imho can be blocked. Sure it can. Bastian -- It would seem that evil retreats when forcibly confronted. -- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udev and /usr
On Tue, Sep 01, 2009 at 05:24:19AM +0200, Marco d'Itri wrote:
> FYI, udev 146 ships usb-id and pci-id programs which read
> /usr/share/misc/usb.ids and /usr/share/misc/pci.ids .
> udev itself does not care about the results of these programs but other
> programs which used to use HAL may do, leading to subtle breakage.
Why do you not extend the current setup to do another step? Currently we
have two
- in the initramfs with only minimal information and
- during the rcS run with / available.
You could just add another ("change") trigger run after all filesystems
are available. (Okay, this extra names must not be used in the fstab at
all then.)
Bastian
--
Intuition, however illogical, is recognized as a command prerogative.
-- Kirk, "Obsession", stardate 3620.7
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
[ Restricting to debian-devel, as generic development stuff ] On Thu, Sep 03, 2009 at 12:28:27PM +0200, Mike Hommey wrote: > On Thu, Sep 03, 2009 at 12:16:53PM +0200, Bastian Blank > wrote: > > Okay, this also depends on the condition that you don't consider the > > package names themself sensitive. > That could surely grant a wishlist bug for popcon, to allow to, say, only > report package names that are found in the debian archive. This information is not available at the moment. You could use apt to check if the package is _currently_ available in the debian archive up to some degree. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Mon, Aug 31, 2009 at 01:01:24PM -0400, Michael Casadevall wrote: > I think a bigger question is where do you find hardware where you can > get remote root on; I know at least two posibilites - IBM provides access for evaluation purposes and - OSDL provides access for project work. Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
On Thu, Sep 03, 2009 at 11:32:14AM +0200, Martin Grimm wrote: > So as long as there is no easy manual way to provide anonymized figures > without installing software on our production servers we can't deliver > such data :-( Hmm. You could collect the /var/lib/dpkg/status files and do a mass submit with the data out of this files. It would lack the usage data, but at least shows something. Okay, this also depends on the condition that you don't consider the package names themself sensitive. Bastian -- We have phasers, I vote we blast 'em! -- Bailey, "The Corbomite Maneuver", stardate 1514.2 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Future of the s390 port
Hi folks The s390 port was released with Lenny. However it is not in the best condition. There are mainly two problems which needs attention, lack of manpower and a 64 bit userland. The first problem is the worst. Currently only Frans Pop and I do work on it. Frans only does the Debian-Installer part and I simply have not enough time to do the rest. The s390 architecture is quite different to anything else, so it needs several specialized packages to work[1] and they need lasting attention. So if anyone wants to help (especially Debian developers) for the continuity of this port please speak up. The second problem is not that critical. No other distribution still supports a complete 31 bit s390 userland and even Debian dropped the 31 bit kernel support in the meantime[2]. Strategies for an upgrade to a 64 bit userland was discussed lately[3]. I doubt that I would be able to push this port through another release in the current state. The consequence would by that the port dies completely and with it the only free and released distribution for this machines. Bastian [1]: Mainly the kernel, generic tools (s390-tools), hardware support (sysconfig-hardware) and a whole bunch of debian-installer packages. [2]: <20090524185816.ga21...@wavehammer.waldi.eu.org> [3]: <20090818204335.ga6...@droopy.oc.cox.net> -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3 signature.asc Description: Digital signature
Re: default character encoding for everything in debian
On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote: > In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote: > > Not necessarily. Any sane implementation should just use wchar_t > Which could be UTF16 and therefore still has complicatd length semantics. No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like Windows). Bastian -- Phasers locked on target, Captain. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.2 (was Please test eglibc 2.9-23+multiarch.1)
On Mon, Aug 03, 2009 at 11:38:32AM +0200, Aurelien Jarno wrote: > Bastian Blank a écrit : > > What happens if someone install libc-bin without a new libc6 then? > > Forgot about that variant before as it is not forbidden by deps now. > If it is not the same major version, it will probably break, I'll add a > conflict to fix that, but I fear we are going to have the same problem > with apt again... Yep. So I'm also out of options. The question is, how badly will it break the binaries in the package. Bastian -- Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. -- Kirk, "The Squire of Gothos", stardate 2124.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.2 (was Please test eglibc 2.9-23+multiarch.1)
On Mon, Aug 03, 2009 at 02:02:24AM +0200, Aurelien Jarno wrote: > I have finally decided to remove the Depends: line in libc-bin, even if > I don't really like that. My tests show that it works now, but don't > hesitate to test it on your machine. What happens if someone install libc-bin without a new libc6 then? Forgot about that variant before as it is not forbidden by deps now. Bastian -- Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant." -- Kirk, "The Ultimate Computer", stardate 4731.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Please test eglibc 2.9-23+multiarch.1
On Thu, Jul 30, 2009 at 06:02:29PM +0200, Aurelien Jarno wrote: > We have the constraints that we should support upgrades from Lenny, so > we are stuck with apt/aptitude from lenny... Remove the dependency from libc-bin. As long a libc-bin does not have maintainer scripts, this should work. Bastian -- Where there's no emotion, there's no motive for violence. -- Spock, "Dagger of the Mind", stardate 2715.1 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: An introduction to multiarch
On Tue, Jul 28, 2009 at 03:48:24PM +0200, Goswin von Brederlow wrote: > Steve Langasek writes: > > I don't think this configuration belongs to apt, I think it belongs to dpkg. > I disagree, at least to a degree. Me too. >qemu-powerpc (or whatever it would > be called) would add ppc to the list of executable architectures > (however dpkg will allow that) and setup the binfmt-misc stuff needed > to run powerpc binaries in qemu. I don't even need the possibility to execute the binaries. The possibility to compile or link against them exists without. > If the admin runs "dpkg -i > foo_i386_1.2-3.deb" on amd64 then I assume he does want that i386 deb > even if he hasn't configured multiarch for everything. I don't think > dpkg should block that. Yep. dpkg also don't consider several relations, apt considers completely incompatible. Why should it be overly strict on things that don't break anything? Bastian -- You can't evaluate a man by logic alone. -- McCoy, "I, Mudd", stardate 4513.3 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Whence /usr/lib/debug?
On Sun, Jul 26, 2009 at 12:09:11AM +0200, Florian Weimer wrote: > libstdc++6-4.3-dbg does not currently follow this, which prompted me > to write this message: Are this debugging symbols or complete debugging builds? > This is already a bug today because GDB can't find the objects (and my > code can't find them, either). If this are complete libs, they needs to be used with LD_LIBRARY_PATH anyway. Bastian -- Actual war is a very messy business. Very, very messy business. -- Kirk, "A Taste of Armageddon", stardate 3193.0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
On Fri, Jul 03, 2009 at 10:28:24AM +0200, Goswin von Brederlow wrote: > Last I heart s390 planed to drop 31bit support and go fully 64bit. This was the plan. However I don't know if it is the best solution. The fact is: only Debian and SuSE still supports a complete 31bit userland. RHEL is released 64bit only with some 31bit libs and SuSE have both. This also means that many of the commercial software is now released as 64bit binaries. On s390 we have the advantage that we have a lot more operations in 64bit aka zarch mode while using the same opcode format. This includes things like 32bit immediate loads and, for z9 and newer only, unicode conversion[1]. So this code can actually be smaller and faster then the 31bit code. So if we are going to get multiarch support, I would vote for a two stage plan: - Do a full 31 and 64bit release for X. - Reduce the 31bit port to minimal for X+1. I hope that apt e.g. will be able to do such an upgrade. Bastian [1] https://bblank.thinkmo.de/blog/s390-assembler, https://bblank.thinkmo.de/blog/smallest-utf32-to-utf8-converter -- But Captain -- the engines can't take this much longer! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Raising minimum CPU requirement for i386 kernel
Hi folks I would like to raise the minimum CPU requirement for the shipped Linux kernels in the i386 port to i686 (with cmov). For now I will not propose a change of the default machine type setting used by the compiler. This means that Debian will get uninstallable on the following CPUs: - Intel i486, - Intel Pentium (MMX), - AMD K5, - AMD K6(-2, -3), - Cyrix 6x86, - VIA C3 before Nehemiah and - National Semiconductor Geode (GXm, GXLV, GX1 and GX2). Except for the C3 and the Geodes, all of them were released in the last Millenium and the successors will be available for at least 10 years at the release of Squeeze. Bastian -- Killing is stupid; useless! -- McCoy, "A Private Little War", stardate 4211.8 signature.asc Description: Digital signature
Raising minimum CPU requirement for s390 kernel/port
Hi folks I would like to raise the minimum CPU requirement for the s390 port to z900. At the same time the 31-bit kernel (-s390) will be retired because it lacks upstream maintenance. This means that Debian will get unusable on the old 31-bit-only CPUs (G5 and G6), as used for example in the Multiprise 3000. The Hercules[1] emulator supports z/Architecture mode, so it will continue to work. However FLEX-ES, a commercial emulator, will not be able to run Debian anymore. Bastian [1] http://packages.debian.org/hercules -- Love sometimes expresses itself in sacrifice. -- Kirk, "Metamorphosis", stardate 3220.3 signature.asc Description: Digital signature
Bug#521343: Can't repair a lilo+root-on-LVM system
On Thu, Mar 26, 2009 at 10:36:39PM +0200, Eddy Petrișor wrote: > After reboot I was surprised to see the boot process failing and > dropping me in the initrd shell. More investigation and hours later I > realised that inside the initrd /dev/root was created with major > number 253 while the root LVM device > (/dev/mapper/hdapool-rootfilesystem - I know, bad name) had major > number 254. This is #520645. This device numbers are _not_ fixed, and lilo have to stop pretending they are. Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#520765: ITP: fsprotect -- Make filesystems immutable
On Sun, Mar 22, 2009 at 06:17:45PM +0200, Stefanos Harhalakis wrote: > fsprotect ease the pain of protecting a system. By using an init script and > a initramfs script it can make the root and other filesystems immutable. > It uses aufs and tmpfs. Please provide further information. A Debian system without root access does not need a different layer of protection, especially as it brings in another piece of kernel code (aufs). Bastian -- Warp 7 -- It's a law we can live with. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#419209: lvm2: Hangs during snapshot creation
severity 419209 important thanks On Wed, Mar 04, 2009 at 10:44:28AM +0100, Klaus Ethgen wrote: > first of all, I raised the severity of the bug to critical as it makes > the whole system break. lvm2 manages blockdevices via the device-mapper framework, so it manages the system. It is the purpose of this tool and it will not hold you from doing stupid things. And for now I consider taking snapshots of / or /var as stupid, because it is impossible to recover if something goes wrong. And without a working filesystem on this locations, the system will just block. It may work, but it also may break horrible as the kernel interface does not allow to do this change atomic. > Also I add debian-devel to Cc as the bug is very > problematic and I wonder how lvm2 was able to get into lenny with that > big problem! We have many software who only works for most but not for all people. > Also I am willing to help solving the bug. My next step will be to > import the whole version history to git and try to besect the problem. Why do you think this would be a problem of the userspace part? > So this bug is a complete show stopper for lenny If you want to help you can provide the following information when it goes wrong: - "uname -a" - "dmesg" - "dmsetup table" - "cat /proc/mounts" - debug log of the "lvcreate -s" call, using - - your snapshot creation script > Am Sa den 14. Apr 2007 um 12:53 schrieb Jean-Luc Coulon (f5ibh): > > New lvm2 version (2.02.24) hangs during snapshot creation. > > The lvmvreate process is not killeable at this point and the system need to > > be > > reboted. > That is the correct description. There was a bug in older kernels which blocked on devmapper table reload, however I've only seen this with the mirror target during a pvmove call. > But more over the system will be > unbootable at all! I have to run /etc/init.d/reboot stop by hand to hard > reboot the system. A normal shutdown will end in a hanging system with > no remote access at all. The only solution at that point is to > powercycle the machine which is very problematic with remote system. This is the normal behaviour if you lock out either a filesystem or have some parts of the kernel disfunctional after oopses. > Am Fr den 2. Nov 2007 um 16:21 schrieb Stefan Pfetzing: > > did you try to snapshot your /var? Because to me it seemms like the > > current lvm2 configurations tries to use /var/lock/lvm for its locking > > files, and this leads to a deadlock. > This is not really a problem as it is irrelevant if that file is locked > or not in the sapshoot. It is. However I'm currently not sure if it ever tries to write/read this files while it have an operation going. > And I wonder why this should be a problem at all as the lvm1 was working > pretty stable for years now. lvm2 and lvm1 does not have many in common. > Am So den 30. Mär 2008 um 10:52 schrieb Bastian Blank: > > # Automatically generated email from bts, devscripts version 2.9.26 > > severity 419209 important > The severity of this bug is absolute critical and not just important! This is up to the maintainer. I use snapshots often and have not seen such problems recently. Bastian -- We do not colonize. We conquer. We rule. There is no other way for us. -- Rojan, "By Any Other Name", stardate 4657.5 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Section changes in the archive
On Thu, Feb 26, 2009 at 09:07:35PM +0100, Joerg Jaspert wrote: > We plan on changing the current sections in the archive. With the rapid > growth of archive, many of them have become too big to be useful anymore. According to my knowledge of dak, the sections are global. Which means that we don't have to worry about a possible kernel update for lenny+1/2. Am I correct with that? > kernel Kernel and Kernel modules Does this only include the user usable parts or also internal development packages? > linux-support-* > linux-tree-* As you explicitely list this, I assume the later. Bastian -- Captain's Log, star date 21:34.5... signature.asc Description: Digital signature
Whoos with GnuTLS and md5-signed certificates
Hi folks GnuTLS stopped accepting MD5 as a proper signature type for certificates just two weeks before the release. While I don't question the decision themself, MD5 is broken since 4 years, I question the timing. Yesterday several people started to complain that they could not longer connect to their ldap servers, many of them using pam-ldap and nss-ldap. A quick look showed certificates in the chain which was signed with MD5. Even many commercial or non-commercial CAs out there have MD5 signed certs somewhere in the chain and all of them will not longer work now until this intermediate certs will be trusted explicitely. Most of them already switched to SHA1 for their enduser certificates. So now we have a change in Lenny which will break many, many machines. It is neither properly documented in the NEWS file of the package themself nor in the release notes. Bastian -- Too much of anything, even love, isn't necessarily a good thing. -- Kirk, "The Trouble with Tribbles", stardate 4525.6 signature.asc Description: Digital signature
Re: Kernel legacy
On Sun, Feb 01, 2009 at 05:26:30PM +0100, Klaus Ethgen wrote: > With lenny the provided glibc seems to be incompatible to kernel 2.4. The Linux 2.4 support ended with the Etch release. Even for Etch it is only supported for upgrades. > Is there any scenario what happens to such systems when lenny gets > stable? Fix the kernel support in newer versions. Bastian -- Suffocating together ... would create heroic camaraderie. -- Khan Noonian Singh, "Space Seed", stardate 3142.8 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Little endian /usr/share/locale/* files in epiphany-browser-data
On Tue, Jan 20, 2009 at 11:02:46AM +0100, Loïc Minier wrote:
> Perhaps we could have a tool converting .mo files from one endianess to
> the other and ship the two versions in epiphany-browser-data,
Well, either msgfmt should be able to produce both or a special tool is
required. The later would be easier as this tool may fix the location at
the same time.
>then
> patch gettext to loop up files in an endianess specific location first
> e.g. gettext would look in /usr/share/locales/big-endian or
> /little-endian first (depending on endianess), then in
> /usr/share/locales.
It searches in /usr/share/locales/$locale/LC_MESSAGES. I would add
/usr/share/locales/$locale/LC_MESSAGES/{MSB,LSB} to the path.
> I'd rather not implement anything specific in epiphany-browser, it
> would be best to discuss this more widely and come to a generic
> solution for all arch: all packages.
Yeah. And it needs the utils to do this.
Bastian
--
Schshschshchsch.
-- The Gorn, "Arena", stardate 3046.2
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results for General Resolution: Lenny and resolving DFSG violations
On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote: > If there was a GR which chainged the Debian Social contract which > relaxed the first clause to only include __software__ running on the > Host CPU, I would enthusiastically vote for such a measure. I doubt that this a usable definition. Do you think that the provision that a program is pushed into another generic purpose cpu should always make them free? An imaginal system can include several CPU types: - Host CPU (lets say the Power cores of a Cell processor) - Slave CPU (the SPUs of a Cell processor, different instruction set and ABI then the host) - GPU (current NVidia and ATI chips can be filled with rather generic programs to do vector operations) - device driving CPU (e.g. the MIPS cores of a broadcom network chip) Only the last ones are usualy filed by the OS with a firmware and then started. Bastian -- Yes, it is written. Good shall always destroy evil. -- Sirah the Yang, "The Omega Glory", stardate unknown -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DFSG violations in Lenny: Summarizing the choices
On Mon, Nov 10, 2008 at 12:56:26PM +1030, Karl Goetz wrote: > Why are they making hardware that can transmit on *any* frequency? Why > are they not making hardware that transmits in the 2.4GHz ISM band > perhaps with firmware to 'fine tune' it? Seems strange to pour lots of > money into making an all-band radio then locking it to a 500MHz band. As you seem to know about the physics, please provide the specs for a proper hardware-based bandpass-filter for the 2.4GHz ISM band, so you can't leaf this band without hardware modification. Sure, the hardware limits it already, the antenna and sender produce a ressonance circuit. But this can include a bandwidth of several GHz. Bastian -- Vulcans do not approve of violence. -- Spock, "Journey to Babel", stardate 3842.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
On Sat, Nov 01, 2008 at 07:29:16PM -0400, Filipus Klutiero wrote: >> | Package: test >> | Depends: test-modules | test-source >> | >> | Package: test-modules >> | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 >> | >> | Package: test-source >> >> Both apt and aptitude would always try to install test-modules. The >> problem is that neither apt nor aptitude are smart enough to find the >> best solution in the dependency tree, both only evaluate deps of depth 1 >> at one time. > I don't understand why APT would always try to install test-modules. > Suppose you're on lenny and you have speex installed, then APT won't > propose to install vorbis-tools when you request to install abcde, > despite its dependency on vorbis-tools (>= 1.0beta4-1) | lame | flac | > bladeenc | speex > > Are you saying there's a difference in your example? If so, what is it? Yes. You have speex already installed and is therefor prefered to resolve the dependency. My example was for a fresh installation without anything installed yet. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
On Sat, Nov 01, 2008 at 08:41:46PM +0100, Michael Meskes wrote: > On Fri, Oct 31, 2008 at 07:48:41PM +0100, Frans Pop wrote: > > I guess one solution could be to have virtualbox-ose not depend on > > virtualbox-modules, but on virtualbox-ose-modules-$ABI. > Building vbox modules from lme makes no real sense to me because lme is not > supposed to be reupped for each new version of virtualbox. On the other hand > building them with virtualbox-ose makes no sense because vbos is not supposed > to be reupped for each new kernel. You are solving problem 2 before problem 1. > I CCed debian-release to learn whether this is okay for Lenny. You forgot -security. Bastian -- You can't evaluate a man by logic alone. -- McCoy, "I, Mudd", stardate 4513.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Possibility for dependencies against specific kernel modules
On Fri, Oct 31, 2008 at 05:07:44PM +0100, Frans Pop wrote: > Bastian Blank wrote: > > Because of some recent events, I thought about the possibility for > > packages to depend against kernel module packages. As we don't want to > > dictate the usage of Debian provided kernels, we need a last resort > > fallback to the modules source. > Exactly because of the option of using custom built kernels, virtualbox > does not depend on the Debian modules packages, but only recommends them > (which IMO is correct: the Debian module package will be installed by > default, but you can skip/remove it if you don't need it). No, it is not. Recommends are only tried during the first installation, but this relation is version dependant. Bastian -- He's dead, Jim. -- McCoy, "The Devil in the Dark", stardate 3196.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Possibility for dependencies against specific kernel modules
Hi folks Because of some recent events, I thought about the possibility for packages to depend against kernel module packages. As we don't want to dictate the usage of Debian provided kernels, we need a last resort fallback to the modules source. My first solution was something like the following: | Package: test | Depends: test-modules | test-source | | Package: test-modules | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 | | Package: test-source Both apt and aptitude would always try to install test-modules. The problem is that neither apt nor aptitude are smart enough to find the best solution in the dependency tree, both only evaluate deps of depth 1 at one time. I found a variant which seems to work, but produces dependency packages for fun: | Package: test | Depends: test-modules-fallback | | Package: test-modules-fallback | Depends: test-modules | test-source, linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 | test-source | | Package: test-modules | Depends: linux-image-2.6.26-1-powerpc | linux-image-2.6.26-1-powerpc64 | | Package: test-source Now the question is clearly, do we want/need such a possibility? And if yes, how should it work. If the answer is no, I have to refuse to build modules like vbox[1]. Bastian [1]: The virtualbox modules don't define a stable ABI, it actually changes for every release. -- Virtue is a relative term. -- Spock, "Friday's Child", stardate 3499.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Wed, Oct 22, 2008 at 10:54:41AM +0200, Thomas Weber wrote: > Am Mittwoch, den 22.10.2008, 08:36 +0200 schrieb Bastian Blank: > > On Wed, Oct 22, 2008 at 08:07:52AM +0200, Michal Čihař wrote: > > > At least ipw2100 drivers changed firmware name if they required > > > different version, so I guess this is also used by others... > > If they need an incompatible one. Not necessarily if they just need a > > newer one. > I'm not really into hardware, but how often does kernel firmware change > in an incompatible way? The iwl4965 firmware changed 2 times incompatible since the driver exists. > It seems to defeat its purpose (providing a > stable interface a driver can talk to). No. Holding interfaces stable at all cost produces something like Windows. In this case the interface will change, but you still can use the old firmware using the old driver. Bastian -- There are always alternatives. -- Spock, "The Galileo Seven", stardate 2822.3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violations are tagged 'lenny-ignore'?
On Wed, Oct 22, 2008 at 08:07:52AM +0200, Michal Čihař wrote: > At least ipw2100 drivers changed firmware name if they required > different version, so I guess this is also used by others... If they need an incompatible one. Not necessarily if they just need a newer one. Bastian -- Violence in reality is quite different from theory. -- Spock, "The Cloud Minders", stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug reports of DFSG violatio ns are tagged ‘lenny-ignore’?
On Mon, Oct 20, 2008 at 01:32:51PM -0500, Manoj Srivastava wrote: > Seems like there are patches stripping the kernel of these > non-free blobs. So, how much would out hardware support be degraded? > How many people are affected by these non-free drivers? The drm modules: Anything which includes an ATI or Matrox card and runs X. The network modules: Not that much, it is mostly old hardware. We already removed the bnx2x driver for the new Broadcom 10GE interfaces, which in fact is a really new one. Bastian -- You canna change the laws of physics, Captain; I've got to have thirty minutes! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The kernel-img.conf man page
On Fri, Oct 10, 2008 at 10:20:40PM +0100, Stephen Gran wrote: > This one time, at band camp, Manoj Srivastava said: > > I can go either route. Comments? > I'd say a -common package makes the most sense to me. The other way > seems like you could conceivably end up with several roughly identical > manpages installed, which seems like a waste. It would be not that usefull as the kernel team wants to split the complete image maintainer scripts into its own package anyway. And having one package which just a manpage is not nice for the archive. Bastian -- Dismissed. That's a Star Fleet expression for, "Get out." -- Capt. Kathryn Janeway, Star Trek: Voyager, "The Cloud" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Should selinux be standard?
On Tue, Oct 07, 2008 at 06:38:12AM +1000, Russell Coker wrote: > On Tuesday 16 September 2008 04:14, Bastian Blank <[EMAIL PROTECTED]> wrote: > > This > > cost me over one hour as bind lacks proper error messages in this code > > path. > > Has that bug in bind (inadequate error reporting) been fixed? Not according to my inbox. (#490371) Bastian -- Time is fluid ... like a river with currents, eddies, backwash. -- Spock, "The City on the Edge of Forever", stardate 3134.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Sat, Sep 20, 2008 at 10:03:37PM +0200, Bruno Voigt wrote: > Do you have any idea where I might get the package > linux-headers-2.6.26-1-common-xen You need to do a complete build of the linux-2.6 package. Bastian -- Well, Jim, I'm not much of an actor either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Thu, Sep 18, 2008 at 05:43:24PM +0200, Bastian Blank wrote: > This kernel have a critical problem: > > | Bad pte = 11764060, process = vsftpd, vm_flags = 100071, vaddr = b7f85000 > | Pid: 8129, comm: vsftpd Not tainted 2.6.26-1-xen-686 #1 > | [] handle_mm_fault+0x61b/0xe78 > | [] mprotect_fixup+0x6d3/0x735 > | [] do_page_fault+0x684/0xbd6 > | [] sys_mprotect+0x17a/0x1df > | [] sys_mprotect+0x1cc/0x1df > | [] do_page_fault+0x0/0xbd6 > | [] error_code+0x35/0x3c > | === > | VM: killing process vsftpd > > The pte have bit 6 set: PAGE_DIRTY aka PAGE_FILE. But the vm flags lacks > the marker for a nonlinear (file based) mapping. Got a response from Novell, including a workaround. Next try: http://194.39.182.225/debian/xen/try4. | a01d76fa67414fd157c7f50be89525cc1f03dace linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb | 6ed1653d3f8f68026803529bee10dec9e772f706 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | 7d70566bda9719b9e4c1c310150da76768019d9c linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb | 19e1a1d2f2dc085ac38968246fcb0e375c9cd14c linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | e09de4e292cd7f00fc98689ddec3ad7712ec47e1 linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb | 9af0b3015f8d0ea433d06cf2fe9d0055697be485 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | cafb31d7ef45b26b23f1e3c30b0785b4bfc2cd4d xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb | 250d7f2a59603e9203840f465a00dd0e990103d1 xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 signature.asc Description: Digital signature
Re: Xen status in lenny?
On Thu, Sep 18, 2008 at 12:28:53PM +0200, Bastian Blank wrote: > Next try: http://194.39.182.225/debian/xen/try3. > This fixes a warning in the PCI registration and again uses xencons. This kernel have a critical problem: | Bad pte = 11764060, process = vsftpd, vm_flags = 100071, vaddr = b7f85000 | Pid: 8129, comm: vsftpd Not tainted 2.6.26-1-xen-686 #1 | [] handle_mm_fault+0x61b/0xe78 | [] mprotect_fixup+0x6d3/0x735 | [] do_page_fault+0x684/0xbd6 | [] sys_mprotect+0x17a/0x1df | [] sys_mprotect+0x1cc/0x1df | [] do_page_fault+0x0/0xbd6 | [] error_code+0x35/0x3c | === | VM: killing process vsftpd The pte have bit 6 set: PAGE_DIRTY aka PAGE_FILE. But the vm flags lacks the marker for a nonlinear (file based) mapping. Later kswap got killed: | BUG: unable to handle kernel NULL pointer dereference at | IP: [] page_referenced+0x72/0xcd | *pdpt = 5c78f001 *pde = | Oops: [#1] SMP | Modules linked in: rfcomm l2cap bluetooth xt_tcpudp tun xt_physdev ppdev lp video output ac battery ipv6 bridge iptable_nat iptable_filter nf_nat_ftp nf_nat nf_conntrack_ftp nf_conntrack_ipv4 nf_conntrack ip_tablesx_tables fuse sbp2 loop snd_ens1371 gameport snd_ac97_codec ac97_bus snd_pcm_oss snd_pcm snd_mixer_oss snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc serio_raw shpchp parport_pc parport pcspkr pci_hotplug psmouse i2c_i801 iTCO_wdt button i2c_core joydev intel_agp agpgart evdev ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod sg usbhid hid ff_memless sr_mod cdrom sd_mod ata_generic usb_storage ata_piix libata scsi_mod dock tulip ohci1394 ieee1394 ide_pci_generic ide_core ehci_hcd uhci_hcd usbcore e1000e thermal processor fan thermal_sys | | Pid: 216, comm: kswapd0 Not tainted (2.6.26-1-xen-686 #1) | EIP: 0061:[] EFLAGS: 00010293 CPU: 2 | EIP is at page_referenced+0x72/0xcd | EAX: 0001 EBX: c19cdc80 ECX: EDX: | ESI: ffc8 EDI: c49635dc EBP: ESP: ecc39e8c | DS: 007b ES: 007b FS: 00d8 GS: SS: 0069 | Process kswapd0 (pid: 216, ti=ecc38000 task=ed5609c0 task.ti=ecc38000) | Stack: 0001 c19cdc98 c03611c0 c19cdc80 ecc39f74 c0156a34 0006 |000f ecc39f74 0020 0001 04a4 0001ef73 |0001 c18afde0 c1bda360 c1b69460 c1c43160 c19a8620 c1acb2c0 c19d2c60 | Call Trace: | [] shrink_active_list+0x215/0x52f | [] shrink_zone+0x97/0xcd | [] kswapd+0x27b/0x3ed | [] isolate_pages_global+0x0/0x42 | [] autoremove_wake_function+0x0/0x2d | [] kswapd+0x0/0x3ed | [] kthread+0x38/0x5f | [] kthread+0x0/0x5f | [] kernel_thread_helper+0x7/0x10 | === | Code: 74 41 8b 43 08 40 89 44 24 04 8b 77 04 eb 19 8d 4c 24 04 89 f2 89 d8 e8 67 f3 ff ff 01 c5 83 7c 24 04 00 74 17 8b 76 38 83 ee 38 <8b> 46 38 0f 18 00 90 8d 56 38 8d 47 04 39 c2 75 d3 89 f8 e8 bc | EIP: [] page_referenced+0x72/0xcd SS:ESP 0069:ecc39e8c | ---[ end trace c7883867761bd19d ]--- Bastian -- ... The prejudices people feel about each other disappear when they get to know each other. -- Kirk, "Elaan of Troyius", stardate 4372.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
Next try: http://194.39.182.225/debian/xen/try3. Checksums: | 5d551622550b95be67a33711f6691c92df9e6bc5 linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb | 18e74571304130b05b15343b6cca3f428f60c958 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | f623276521dcf23416c12f1923015629e93f246c linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb | 1335b92fcdc20b00eb64c48a652723c850af909d linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | be0791bf7d7497beae230a45b054137d170f624e linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb | d8b785f3aa0192b887dcdc08c107bf30c7581da9 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | e9319c2fe42f79f299de23bd74069afa398e81dc xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb | fab701800db6399405b43ba7ff2425db772f4c90 xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb This fixes a warning in the PCI registration and again uses xencons. Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3 signature.asc Description: Digital signature
Re: [Pkg-xen-devel] Xen status in lenny?
On Thu, Sep 18, 2008 at 11:52:09AM +0200, Paul van der Vlis wrote: > I have it running on my amd64 machine! Okay. > - the VM's do not start automatically, but they start with "xm create". Hmm. Please show the xend log (/var/log/xen/xend.log) from before the manual start. > - I can ping and SSH the VM from the dom0, not from the internet. Please use wireshark/tshark/tcpdump to find the interface where is gets lost. Please make sure that the domains are restarted and not only restored. Also please show the output of xm dmesg and dmesg. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Xen status in lenny?
On Thu, Sep 18, 2008 at 10:20:19AM +0200, Paul van der Vlis wrote: > Bastian Blank schreef: > > On Wed, Sep 17, 2008 at 08:57:40PM -0300, André Luís Lopes wrote: > >> Bastian Blank escreveu: > >>> On Wed, Sep 17, 2008 at 06:52:38PM +0200, Bastian Blank wrote: > > > > Next try: http://194.39.182.225/debian/xen/try2. > Great that there seems to be a amd64 port now! > Do these packages have a dom0 ? That was the reason of that stunt. Bastian -- Bones: "The man's DEAD, Jim!" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Wed, Sep 17, 2008 at 08:57:40PM -0300, André Luís Lopes wrote: > Bastian Blank escreveu: > > On Wed, Sep 17, 2008 at 06:52:38PM +0200, Bastian Blank wrote: Next try: http://194.39.182.225/debian/xen/try2. > >> Checksums: | facc08ef408b745052189d99e971ee0d0c01450c linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb | e819d7a6d849b738f39c4988b1f6c722f81eb5e1 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | 7b8659fd984f8a1711fd5324bed20ad5b3f168bc linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb | 7e01af430254ac90203fcf4c0ba7bf49ca9c7e4d linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | e2b3ea5a57d3dfe89defe57c595a5a7f0025bbbc linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb | 73e9bb968768e2920735f7eb77fd9667f0ffce20 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | 07ef8c3b6c4e2496afd3fc86347f5cf640a644f9 xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb | ddfd7db322b8540cb0f606f974758e883d416a67 xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb >It seems the problem is that xen-linux-system-2.6.26-1-xen-686 > depends on xen-hypervisor-3.2-1-i386-pae | xen-hypervisor-3.1-1-i386-pae > but unstable doesn't have these packages. Unstable has only > xen-hypervisor-3.2-1-i386 and it doesn't provide > xen-hypervisor-3.2-1-i386-pae. Yes. Fixed in the new packages. >Anyway, I tried booting the dom0 provided by your > linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb package and the machine > actually came up. I couldn't install any tool for creating VM later > (xen-tools, virtinst, virt-manager, etc) as the package dependency > systems were all trying to "fix" my system after the problem left by the > error reported earlier on this message when installing these packages. You could have just removed xen-linux-system-* as it is only a meta package without actual functionality. >However, I noticed the Xen kernel giving some WARNINGs when i booted > it and later asking me to install a "xen-friendly" version of > glibc/libc6 or moving my /lib/tls to /lib/tls.disabled unless I wanted > to my system to become slow. Yes. I removed that warning now as it makes more grief than good and is not included in the paravirt_ops implementation. >What I noticed, as the boot message said, was that the system became > really slow after I booted the Xen kernel. Running aptitude took two or > three times more time than running it under a non Xen-enabled kernel, > for example. This is the result of a bug in libc6-xen, set the following in /etc/ld.so.conf.d/lib6-xen.conf | hwcap 1 nosegneg and run ldconfig. See #499366. >I don't know if it was some mistake I did (probably), but it would be > nice if you could tell me if I should have done my testing in any other > way. I'll probably have a QuadCore machine at work which I could test it > in the next two or three days, so I woul be glad to test it there. I would appriciate any possible testing. Bastian -- Knowledge, sir, should be free to all! -- Harry Mudd, "I, Mudd", stardate 4513.3 signature.asc Description: Digital signature
Re: Xen status in lenny?
Should actually sign this. On Wed, Sep 17, 2008 at 06:52:38PM +0200, Bastian Blank wrote: > Checksums: | fdf0c5dd755146ad2b631a60b02e90aa39a20d91 linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb | 90e62bb5548945e19620c6aa0b04b3fc532bc090 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | e4bcee9c5d8f1d23c915e56487f51ecb82f405ac linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb | 414f9d9c31cfaccbf595011c21b860bb33c56232 linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | db1c10f13b4972a9ed6a2d834f3c14c858e162e7 linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb | 57000e8ff722dad5b5dd027f3b6f487ad0a22ea5 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | 5faad1f7e42d8bab766e01a109fd6b50799aa5f5 xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb | b06d9c5373927db34787bddfd9b455dec0bf2a8f xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb -- I'm a soldier, not a diplomat. I can only tell the truth. -- Kirk, "Errand of Mercy", stardate 3198.9 signature.asc Description: Digital signature
Re: Xen status in lenny?
On Wed, Sep 17, 2008 at 03:19:38PM +0200, Jan Wagner wrote: > What about > http://ftp.suse.com/pub/projects/kernel/kotd/HEAD/x86_64/2.6.26/kernel- > source-2.6.26-HEAD_20080808143035.src.rpm ? http://194.39.182.225/debian/xen/ contains packages using most of the xen parts. http://194.39.182.225/linux/git/2.6.26-xen-suse includes the patches. Checksums: | fdf0c5dd755146ad2b631a60b02e90aa39a20d91 linux-headers-2.6.26-1-xen-686_2.6.26-6_i386.deb | 90e62bb5548945e19620c6aa0b04b3fc532bc090 linux-headers-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | e4bcee9c5d8f1d23c915e56487f51ecb82f405ac linux-image-2.6.26-1-xen-686_2.6.26-6_i386.deb | 414f9d9c31cfaccbf595011c21b860bb33c56232 linux-image-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | db1c10f13b4972a9ed6a2d834f3c14c858e162e7 linux-modules-2.6.26-1-xen-686_2.6.26-6_i386.deb | 57000e8ff722dad5b5dd027f3b6f487ad0a22ea5 linux-modules-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb | 5faad1f7e42d8bab766e01a109fd6b50799aa5f5 xen-linux-system-2.6.26-1-xen-686_2.6.26-6_i386.deb | b06d9c5373927db34787bddfd9b455dec0bf2a8f xen-linux-system-2.6.26-1-xen-amd64_2.6.26-6_amd64.deb Bastian -- Conquest is easy. Control is not. -- Kirk, "Mirror, Mirror", stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen status in lenny?
On Tue, Sep 16, 2008 at 10:32:49PM +0200, Jan Wagner wrote: > [Option 1-5] (Option 6 / SLES's 2.6.26 mentioned later in thread by Moritz) Please show it. SLES 11 ships 2.6.25. Bastian -- Men of peace usually are [brave]. -- Spock, "The Savage Curtain", stardate 5906.5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#497236: ITP: libcpuset -- assigns a set of CPUs and Memory Nodes to a set of tasks
On Sun, Aug 31, 2008 at 05:31:32PM +1000, Aníbal Monsalve Salazar wrote: > Description : assigns a set of CPUs and Memory Nodes to a set of tasks Does it work with the cgroup subsystem? As the documentation is 2 years old, I doubt that. Bastian -- Wait! You have not been prepared! -- Mr. Atoz, "Tomorrow is Yesterday", stardate 3113.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: transfering files between *.debian.org hosts (was: people.debian.org to move to ravel)
On Sat, Aug 30, 2008 at 02:32:08PM +0200, Peter Palfrader wrote: > - install sendfile/saft on all machines so you can do > sendfile foo.tar.gz [EMAIL PROTECTED] > > The crypto stuff could be alleviated by using ipsec between all our > servers. But that works even less well than you'd expect. The machines needs to check DNSSEC or the names can be spoofed which makes ipsec mood. > - setup afs > > pros: + AFS is cool Yeah. You can make read-only snapshots for backup purposes. > + once we have a krb realm we could maybe also use it for other > stuff like all those web services that require logins. How > good is krb support in browsers these days? Firefox supports it in a whitelist approach. However I never tested it. > cons: - integrating krb and afs into ud-ldap is a lot of work > - setting up afs will be a lot of work too > - little prior experience with afs > - AFS suffers from the not-a-filesystem syndrome: file access > control is not unix-like and will confuse users. Also other parts are not really POSIX-like. Hardlinks or so. > - might cause problems with existing firewalls. - The needed kernel module still uses rootkit-like behaviour. > What other options did we forget? - Setup Kerberos, allow it as an additional ssh login variant + Ticket forwarding However, only the insecure options allow automatic operation, so lets extend some options (yes, I think about the D-I images which are located in people): - Allow additional principals for automatic usage This can be combined with AFS and SSH-Kerberos Each user can create additional principals $USER/cron/[EMAIL PROTECTED], the keys are put into a keyfile so that a script can create a ticket and use that to do the operations. AFS: Just needs proper ACLs for this principal. SSH: Needs mapping in /etc/krb/krb5.conf or .k5login and there was something else. Bastian -- Extreme feminine beauty is always disturbing. -- Spock, "The Cloud Minders", stardate 5818.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unusual version numbering systems
On Wed, Aug 27, 2008 at 12:51:19PM +0100, Dominic Hargreaves wrote: > I have packaged a piece of software [1] which uses a version number > system which is not compatible with Debian's ordering. > > The version numbers go like > > 4.1 > 4.12 -> 4.1.2 > 4.2rc -> 4.2~rc > 4.2 > 4.21 -> 4.2.1 > (maybe 4.3) > - persuade upstream to change the version numbering Usually the best version, because most of the distributions have some version comparision which will break on that versioning. > - add an epoch each time a new major release comes out (but policy > discourages this - see note at the bottom of 5.6.12) Epochs are to fix errors made in the versioning, not to workaround well-known problems. > - package 4.3, if/when it comes along, as 4.30 instead. - Use your own scheme, you don't need to follow upstream if you have reasons to do so. Bastian -- Vulcans do not approve of violence. -- Spock, "Journey to Babel", stardate 3842.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can a package modify slapd.conf in its maintainer script?
On Wed, Aug 20, 2008 at 10:58:51PM -0700, Steve Langasek wrote: > On Tue, Aug 12, 2008 at 06:07:14PM +0200, Bastian Blank wrote: > > On Tue, Aug 12, 2008 at 12:35:30PM -0300, Steve Langasek wrote: > > > It is possible; I'm currently awaiting feedback from the OpenLDAP > > > comaintainers before we enable it. > > > You know that parts of the config settings are only supported in the > > legacy-format? > > I've been told that there are certain (uncommon) backends that aren't > supported by cn=config, and I'm not surprised to learn that there are some > overlays that are unsupported as well. Do you have a list of these that are > of concern to you? Not currently. I read it somewhere but as the documentation how to configure them via cn=config is completely missing it is not easy to find it again. Can you please first fill the gaps in the documentation before forcing something underdocumented to everybody? > AFAIK the components that have not yet been ported to cn=config are those of > marginal interest, and I don't think they should block us from moving to > only support cn=config in the package; users who prefer to stick with > slapd.conf will be able to switch back after upgrade, at the expense of not > getting automatic config upgrades from the package anymore. So you convert it forth, break it during the step. > > Is there documentation how to import new schemas in the new config tree? > > They need to be provided in LDIF format. All of the schemas included in the > slapd package now also have .ldif versions that can be used as examples of > how to do this. I haven't looked for documentation, per se. Please provide the documentation then. I have several private schemas which I somehow need to port forward. Does slapd support modifications to cn=Schema? > > Also modification are only supported via the ldap > > protocol, who say that root may authenticate at all? > > We prompt for the password to use as the olcRootPW when setting up > cn=config, and can prompt for it again when other packages need to make > schema changes. I don't think this should be any more problematic than > what's currently done for integration with database packages. Who say that there exists a password for the root DN? None of my configs includes one, because I don't need another weak point. Which ACLs applies to the usage of the root DN for authentication? How do you want to reach the daemon? ldapi:///? ldap://127.0.0.1? The admin is free to disable whatever access variant he wants. Some other questions. The cn=config tree is located in /etc/ldap/config.d. What happens if I modify that while the daemon is running with an editor? What happens if I modify it with an editor and per LDAP at the same time? Bastian -- Insufficient facts always invite danger. -- Spock, "Space Seed", stardate 3141.9 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
Why do I see a deja-vue? I think we had this already some years ago.
On Thu, Aug 14, 2008 at 10:25:38PM -0700, Steve Langasek wrote:
> So the current architectures I see wishlist bugs for on ftp.d.o are s390x,
> sh[34]{,eb}, netbsd-i386, and kfreebsd-{i386,amd64}.
The sh* ports are not dead? I've not seen anything from them for years.
Also from the kernel point of view, there are sh2, 3, 4 and 5, the
first three as both little and big endian. And when it goes for the
compiler it only gets worse, it lists 23 multilib variants.
> Doesn't s390x have the same problem as sparc64, where it's not actually
> beneficial to build the whole system for this target?
There is some. IBM likes to add new op-codes to every processor release
and with a higher minimum supported type they can be used. They often
provide a speed benefit. Also the instruction format is identical
between the 31 and 64bit code. I would like to use multiarch, but this
is still not ready.
Bastian
--
History tends to exaggerate.
-- Col. Green, "The Savage Curtain", stardate 5906.4
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
