Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
Darren Salt writes: > I've carefully avoided use of initramfs images; I don't plan to start using > them just so that /usr can be mounted early. > > You can call it irrational or whatever else you like; I don't care. [..] > > For me, the presence of an initramfs is a downside when I've been able to do > without without problem for so long. Disliking initramfs for no technical reason is of course something you are free to do. But why should this affect any decision that Debian makes about requiring or not requiring initramfs? Curious, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C -- 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/87txvhqe3a@vostro.rath.org
Re: choice in core infrastructure decisions (Re: Bug#684396: ITP: openrc -- alternative boot mechanism)
+++ Faidon Liambotis [2012-08-11 03:48 +0300]: > On 08/11/12 01:12, Russ Allbery wrote: > > There are choices that we don't support because the process of supporting > > that choice would involve far more work than benefit, and the final goal > > is excellence, not choice for its own sake. For example, we don't allow > > users to replace the system C library with a different one. That's > > something that we *could* do, but the general consensus of the project is > > that investing our effort in that is not the best way to produce > > excellence. > > I kind of disagree with that. I don't think that the fact that we don't > support multiple C libraries is the result of a "consensus decision". > > I think it's just because noone attempted to properly do that and prove > it's viability and usefulness either to a portion of the userbase or the > project as a whole. Not wishing to get into the general argument, but just to clarify that in fact this (enabling an alternative c-library) has been done in the past, showing that it is technically possible. The SLIND project (http://wiki.network-crawler.de/index.php/SLIND_Siemens_Linux_Distribution) rebuilt a reasonable subset of debian against uclibc. dpkg has had support for uclibc- for some years. It's not actually technically very difficult, although proper support would involve some intrusive changes in some places. It would actually be useful to quite a lot of people if a core subset of Debian was easily buildable for use with uclibc and busybox, but so far this work has always been done in forks and derivatives, and not pushed back in, which makes it very hard to maintain. Deciding whether that was still relevant or worth the effort would no doubt require another long thread :-) Steve and Russ have it right. We strive for technical excellence and the widest functional coverage that can sensibly be achieved in the context of a binary distro and the available resources. The implies plenty of choice, but not choice for its own sake. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- 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/20120902024201.gz27...@stoneboat.aleph1.co.uk
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Sep 2, 2012, at 2:36 AM, Darren Salt wrote: > I demand that Thomas Goirand may or may not have written... > > [snip] >> Sure, OpenRC doesn't have (yet) all the features of systemd. But because of >> the above, it might be worth to *at least* give it a chance. > > Should it have all of those features? Should it require support from other > packages? (Are all of those features appropriate?) Well, the socket-based activation which allows true parallelization of the boot process as well as the replacement of the complicated and error-prone bash scripts with unit files are quite compelling in my opinion. I use systemd on my laptop with an SSD and within a kvm and have boot times down to 3 seconds. Also, systemctl and systemd-analyze are really nice. Adrian -- 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/213434cf-8972-4c0b-a8b6-61e01c600...@physik.fu-berlin.de
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
I demand that Steve Langasek may or may not have written... [snip] > The Fedora implementation does not require us to drop support for /usr as a > separate filesystem. It only requires us to ensure /usr is mounted before > init is started. > > - /usr as a separate filesystem mounted from an initramfs: supported > - /usr on the root filesystem: supported Fine... > - /usr on a separate filesystem without the use of an initramfs: not >supported... and no discernable user demand for this. I use exactly that on most computers which I've set up (primary exception being a netbook, due to limited storage), and I don't want an initramfs. There may come a time when I decide to change this in favour of no separate /usr partition, but I very much doubt that it'll be before I need to replace hardware. I've carefully avoided use of initramfs images; I don't plan to start using them just so that /usr can be mounted early. You can call it irrational or whatever else you like; I don't care. > My knee-jerk reaction to the Fedora proposal had been that it was sick and > wrong and would cause unacceptable breakage for users on upgrades if Debian > adopted the same plan. However, I struggled to formulate a concrete > scenario where losing support for that last configuration would actually > make a difference. Upgrade-in-place ‘legacy’, if you like. [snip; not worth maintaining the distinction?] > This, plus the extensive upstream use (IMHO misuse) of software installed > to /usr as part of udev rules, means that in reality an ever increasing > number of libraries need to be shipped in /lib to properly handle > bootstrapping the mount of /usr using only the contents of /. My opinion? Misuse, with the intention of moving away from separate /usr. > In contrast, if we use an initramfs to handle mounting of /usr, we move all > the complexity out of the packaging and instead pull components into the > small initramfs only as needed. As far as I've been able to determine, > there really is no downside to the user from making this switch. For me, the presence of an initramfs is a downside when I've been able to do without without problem for so long. -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ I'm not a complete idiot - some parts are missing. -- 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/52ce18bc8c%lists...@moreofthesa.me.uk
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
I demand that Thomas Goirand may or may not have written... [snip] > Sure, OpenRC doesn't have (yet) all the features of systemd. But because of > the above, it might be worth to *at least* give it a chance. Should it have all of those features? Should it require support from other packages? (Are all of those features appropriate?) -- | _ | Darren Salt, using Debian GNU/Linux (and Android) | ( ) | | X | ASCII Ribbon campaign against HTML e-mail | / \ | http://www.asciiribbon.org/ Become a programmer and never see the world. -- 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/52ce121a1c%lists...@moreofthesa.me.uk
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le Sat, Sep 01, 2012 at 09:02:06PM +0200, Svante Signell a écrit : > > Maybe you, Josselin, should step down from working on Debian. It looks > like your priorities are not in line with the Debian goals and the > Debian contract any longer. Whatever the consequences will be. In general I am for discussing things without taboos, but if Debian had only one, I think it should be about never calling for peoples heads. We have an expulsion procedure for DDs who harm the project, and those who are not willing or not able to start this procedure should not gratuitously invite DDs to leave. And yes, this is one of the cases where it is good to underline loudly that your opinion does not matter because you are not a a member of the Debian project. And please do not answer. -- Charles Plessy Tsurumi, Kanagawa, Japan -- 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/20120901222031.ga11...@falafel.plessy.net
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
Hi Thomas, On Fri, Aug 31, 2012 at 05:39:14PM +0800, Thomas Goirand wrote: > On 08/31/2012 03:39 AM, Steve Langasek wrote: > > - /usr on a separate filesystem without the use of an initramfs: not > >supported... and no discernable user demand for this. > Well, let's say I have a big crash, and I want to recover, and I > need to access /etc/lvm/archive in a single user, with of course > my /usr in a bad state, and I wouldn't be able to mount it for > various reasons. Let's say, an HDD crash, which is very common. > If I need to have /usr mounted before init starts, then I'm more > or less dead, and I'll have to get a recovery CD / USB. > If I don't need /usr, everything is fine, I can boot into single > user mode, and repair. > Guess which situation I prefer? There's no reason that you should be "more or less dead". The proposed design still allows for recovery - it just requires that you use the initramfs as the recovery environment, rather than the rootfs. The difference is about where we put our bootstrapping/recovery environment and how we package it, not about whether we have one. > Now, you tell me: what are the advantage of requiring having > everything in /usr exactly? I really don't get what the advantage is. The advantages have been laid out in the Fedora spec. The only additional advantage not mentioned there is that it saves us from fighting an uphill battle against upstreams - not just those who have adopted the Fedora design and are entangling /usr with things like /lib/udev, but even upstreams like GNU autotools, which really doesn't support the idea of separate heirarchies for boot-critical libraries vs. dev packages. > On 08/31/2012 03:39 AM, Steve Langasek wrote: > > However, I struggled to formulate a concrete > > scenario where losing support for that last configuration would actually > > make a difference. > You must have not read some of my posts then. I don't recall if I did or not. But certainly in this post, you're not presenting anything that can't be supported under the new proposal, just something that has to be supported differently. > Also, please make the point into why having stuff in /usr is > to be preferred. Or is it that the *only* argument that you > have is that we are polluted by RedHat crap? If so, why > shouldn't we consider switching to an alternative of udev > like mdev, if its development goes on the right direction, > for Jessie? This is a profound misunderstanding of the problem. udev is not the issue. udev rules *provided by other desktop packages* are the issue. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- 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/20120901223010.gc22...@virgil.dodds.net
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Svante Signell wrote: >On Fri, 2012-08-31 at 19:34 +0300, Serge wrote: >> 2012/8/31 Josselin Mouette wrote: > >> Linux is still not about choice? Then let's make it be about choice! >> >> > As for Debian not being universal, this is certainly not my saying. >> > But toy ports and toy init systems are part of what makes Debian less >> > universal: being the universal OS doesnât mean accepting every piece >> > of shit, it means being able to answer every user need. >> >> So, if user needs to see something in debian repository then being >> universal means having it in repository. :) > >Maybe you, Josselin, should step down from working on Debian. It looks >like your priorities are not in line with the Debian goals and the >Debian contract any longer. Whatever the consequences will be. Svante, you've been causing trouble for a long time now, using the excuse of being a Hurd porter. I've been tempted to kill-file you for a while. But this particular message from you is so far out of line that I feel it needs a response. Calm down and apologise, or I will ask that the listmasters ban you from Debian lists. -- Steve McIntyre, Cambridge, UK.st...@einval.com Google-bait: http://www.debian.org/CD/free-linux-cd Debian does NOT ship free CDs. Please do NOT contact the mailing lists asking us to send them to you. -- 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/e1t7vji-0005l8...@mail.einval.com
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
Hi Matthew, On Sat, Sep 01, 2012 at 07:25:09PM +0100, Matthew Woodcraft wrote: > Wouter Verhelst wrote: > > Since you're talking of software RAID and LVM, that means you need an > > initramfs to boot your system. Thus, your systems will continue to > > boot with the proposed scenario, which supports booting with /usr on a > > separate filesystem if you have an initramfs. > Using software RAID and LVM does not require an initramfs. > Debian has supported booting from md RAID without using an initramfs for > a very long time. True but misleading. LILO supported it because it hard-coded the block list of the kernel and initrd at install time. GRUB1 never supported any RAID except for RAID1, as far as I'm aware. GRUB2 has supported RAID5 since ~2008, but has only been used as the default boot loader in Debian since 2011; prior to that the installer would select the best bootloader for the chosen disk layout - but grub2 was sufficiently experimental at that point that no one who actually cared about their data would be using it. As for LVM, I'm not aware of any implementation that supports kernel auto-activation of VGs without an initramfs. > GRUB2 can boot from LVM or a separate /boot, but in any case risk-averse > people might choose to avoid root-on-LVM; this is one of the reasons for > putting /usr on a separate filesystem in the first place. I wouldn't call this being risk averse, I would call it being *bad* at risk assessment / risk management. All the interesting data needed for running the system is on a filesystem other than the root filesystem in that case. If you actually think LVM isn't safe, you shouldn't be using it for /usr (and /var). If you think it is safe, you should have / on it as well and, if necessary, allocate a separate /boot partition for the bootloader. > The system I'm sending this email from would fail to boot if separate > /usr without initramfs stops being supported. Can you please elaborate on why that is? Is there something in your configuration that would prevent an initramfs from being automatically used by the bootloader when generated at kernel install time? Are there particular constraints on your environment that would prevent the system from using an initramfs if one was required (e.g., would there be some reason you would have to reinstall to adapt to such new requirements)? > If Debian doesn't want to continue doing the work to support that > configuration, fair enough; I'll change. But I'd like to correct the > impression that such systems don't exist. My assertion isn't that an initramfsless system with /usr as a separate filesystem can't be done; my assertion is, rather, than it is an uninteresting configuration to support and that dropping support for it won't negatively impact our users. If I'm mistaken about this, I'd certainly like to know it. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Bug#684726: ITP: check_v46 -- Icinga / Nagios plugin for dual stacked (IPv4 / IPv6) hosts
On Wed, 2012-08-29 at 14:35 -0700, Don Armstrong wrote: > See Policy §7.2. If the depended-on package is not "required for the > depending package to provide a significant amount of functionality" > but is a package which "would be found together with the [depending > package] in all but unusual installations", it should be a > Recommends:, not a Depends:. Yeah,.. but this is really very vague, isn't it? And AFAICS the consensus on most distributions and also most Debian packages was that depends is the relation that indicates that the package is required for core functionality. Therefor, and this is also in reply to Timo Juhani Lindfors mail before, I personally would say roughly the following: A depends on B if either of the following is true: - without B, A cannot be installed/configured - without B, A fails not gracefully (i.e. corrupts data, segfaults, doesn't work at all without warnings/hints) - without B, using A wouldn't make sense at all (as it looses it's core functionality), even if it would fail gracefully I largely agree with what Russ, wrote below, I like to install only what I really want, and giving information in the package description about the Recommends and Suggests is a good way to help understanding. But apart from all that,... my intention was no to ask for "clarification" of the policy in that matters (even though that wouldn't harm perhaps ;) ) A package like nagios-plugins-contrib is obviously not a meta-package. It's however not a normal package either, as it contains different programs from different upstreams, whose only "connection" is, that all of them are nagios/icinga checks. I call this "compilation packages". IMHO the following is likely true: - For some compilation packages it would be better if they were split up, especially when one considers that Debian would ultimately package "all" (or at least very much) of the available Nagios/Icinga pluings. The compilation package would just get enormous big. - Ask yourself, if you were the maintainer of these plugins and if you'd decided to package them separately, would you have used Depends or Recommends in many of the cases (I talk about e.g. the packages which provide programs absolutely needed by the plugins)? So I'd conclude, that Recommends was chosen in some cases only, to keep the dependencies small (because people typically tend to not use each program of a compilation package anyway),... and therefore this sounds like "wrong" packaging[0] to me. - Those who argue that this is a problem because one gets so many very small packages,... we do this already,... with the font-* packages, for example; and it seems to work. Cheers, Chris. > 0: I wrote the above, not Bernd. Please try to avoid incorrect > attribution when you quote e-mail. Yeah sorry,... was a mistake when cutting out Bernd's comments. [0] Of course this is not meant specifically "againt" "nagios-plugins-contrib" and it's maintainers; so don't feel offended. It's a general issue IMHO in current packaging practise :) smime.p7s Description: S/MIME cryptographic signature
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
On Fri, 2012-08-31 at 19:34 +0300, Serge wrote: > 2012/8/31 Josselin Mouette wrote: > Linux is still not about choice? Then let's make it be about choice! > > > As for Debian not being universal, this is certainly not my saying. > > But toy ports and toy init systems are part of what makes Debian less > > universal: being the universal OS doesn’t mean accepting every piece > > of shit, it means being able to answer every user need. > > So, if user needs to see something in debian repository then being > universal means having it in repository. :) Maybe you, Josselin, should step down from working on Debian. It looks like your priorities are not in line with the Debian goals and the Debian contract any longer. Whatever the consequences will be. -- 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/1346526126.5554.19.camel@x60
Re: Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
On 01/09/12 20:18, John Paul Adrian Glaubitz wrote: > On Sat, Sep 01, 2012 at 08:02:21PM +0200, Carlos Alberto Lopez Perez wrote: > >> This package contains the source code for the native implementation of ZFS >> for the Linux Kernel, which can be used with DKMS, so that local kernel >> modules are automatically built and installed every time the kernel packages >> are upgraded. >> . >> This package also contains the user space utilities needed to manage ZFS. > > Wow, this is actually very nice. I didn't know the implementation of > ZFS has advanced that much. I would really love to see this in Debian > anytime soon. > > Do you know how it compares to the version of zfs available for the > FreeBSD kernels feature-wise? > > Cheers, > > Adrian > > Wikipedia has a nice table comparing the different ports of ZFS [1] According to it, both the FreeBSD port and this Native Linux port (LLNL) are based on zpool version 28, for which the relevant changelog is also detailed on Wikipedia [2]. For the Linux port, the ZFS Posix Layer (ZPL) is available from version 0.6.0-rc1 and is expected to be completely stabilized for version 0.6.0 [3] Regards! [1] https://en.wikipedia.org/wiki/ZFS#Comparisons [2] https://en.wikipedia.org/wiki/ZFS#Release_history [3] https://github.com/zfsonlinux/zfs/issues/7 signature.asc Description: OpenPGP digital signature
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
Wouter Verhelst wrote: > Since you're talking of software RAID and LVM, that means you need an > initramfs to boot your system. Thus, your systems will continue to > boot with the proposed scenario, which supports booting with /usr on a > separate filesystem if you have an initramfs. Using software RAID and LVM does not require an initramfs. Debian has supported booting from md RAID without using an initramfs for a very long time. GRUB2 can boot from LVM or a separate /boot, but in any case risk-averse people might choose to avoid root-on-LVM; this is one of the reasons for putting /usr on a separate filesystem in the first place. The system I'm sending this email from would fail to boot if separate /usr without initramfs stops being supported. If Debian doesn't want to continue doing the work to support that configuration, fair enough; I'll change. But I'd like to correct the impression that such systems don't exist. -M- -- 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/20120901182508.ga21...@golux.woodcraft.me.uk
Re: Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
On 01/09/12 20:36, Arno Töll wrote: > Hi, > > On 01.09.2012 20:02, Carlos Alberto Lopez Perez wrote: >> This package contains the source code for the native implementation >> of ZFS for the Linux Kernel, which can be used with DKMS, so that >> local kernel modules are automatically built and installed every time >> the kernel packages are upgraded. > > Question remains whether the resulting binary packages are distributable > by Debian. You'd basically need to ship source only binary packages > which are built on the installing platform - including utilities, not > only for the kernel driver. > > The user space utilities are not linked against any GPL library so there isn't any license problem distributing them in binary form. The only external dependencies for the user-space utilities are: libselinux1, zlib1g, and of course libc6. signature.asc Description: OpenPGP digital signature
Bug#686453: ITP: spl-dkms -- The Solaris Porting Layer (SPL) for the Linux kernel
Package: wnpp Owner: Carlos Alberto Lopez Perez Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: spl-dkms Version : 0.6.0 Upstream Author : Brian Behlendorf * URL : http://zfsonlinux.org/ * License : GPL-2+ Programming Lang: C Description : The Solaris Porting Layer (SPL) for the Linux kernel. The Solaris Porting Layer (SPL) is a Linux kernel module which provides many of the Solaris kernel APIs. This shim layer makes it possible to run Solaris kernel code in the Linux kernel with relatively minimal modification. . This can be particularly useful when you want to track upstream Solaris development closely and don't want the overhead of maintaining a large patch which converts Solaris primitives to Linux primitives. . This package contains the source code for the SPL Linux kernel module, which can be used with DKMS, so that local kernel modules are automatically built and installed every time the kernel packages are upgraded. signature.asc Description: OpenPGP digital signature
Re: Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
Hi, On 01.09.2012 20:02, Carlos Alberto Lopez Perez wrote: > This package contains the source code for the native implementation > of ZFS for the Linux Kernel, which can be used with DKMS, so that > local kernel modules are automatically built and installed every time > the kernel packages are upgraded. Question remains whether the resulting binary packages are distributable by Debian. You'd basically need to ship source only binary packages which are built on the installing platform - including utilities, not only for the kernel driver. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
On Sat, Sep 01, 2012 at 08:02:21PM +0200, Carlos Alberto Lopez Perez wrote: > This package contains the source code for the native implementation of ZFS > for the Linux Kernel, which can be used with DKMS, so that local kernel > modules are automatically built and installed every time the kernel packages > are upgraded. > . > This package also contains the user space utilities needed to manage ZFS. Wow, this is actually very nice. I didn't know the implementation of ZFS has advanced that much. I would really love to see this in Debian anytime soon. Do you know how it compares to the version of zfs available for the FreeBSD kernels feature-wise? Cheers, Adrian -- 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/20120901181854.gb24...@physik.fu-berlin.de
Bug#686447: ITP: zfs-linux -- The native Linux kernel port of the ZFS filesystem
Package: wnpp Owner: Carlos Alberto Lopez Perez Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org * Package name: zfs-linux Version : 0.6.0 Upstream Author : Brian Behlendorf * URL : http://zfsonlinux.org/ * License : CDDL Programming Lang: C Description : The native Linux kernel port of the ZFS filesystem. ZFS is an advanced file system and volume manager which was originally developed for Solaris. It provides a number of advanced features like snapshots, clones, live integrity checksums, deduplication, compression and much more. The port to the Linux kernel includes a functional and stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL). . This package contains the source code for the native implementation of ZFS for the Linux Kernel, which can be used with DKMS, so that local kernel modules are automatically built and installed every time the kernel packages are upgraded. . This package also contains the user space utilities needed to manage ZFS. signature.asc Description: OpenPGP digital signature
Re: Stuff from /bin, /sbin, /lib depending on /usr/lib libraries
On Fri, Aug 31, 2012 at 10:57:10PM +0800, Thomas Goirand wrote: > On 08/31/2012 06:55 PM, Riku Voipio wrote: > > How is that different from having a botched / or /boot ? Why do you > > think having a separate /usr will make / less prone to HD crashes? > > You have / on RAID5 while /usr isn't? > > > > Typically, I have / on 2 small RAID1 partitions making the array on the > first > 2 HDD (1 or 2 gigs), and /usr on a LVM on a much, much larger RAID array > (I use mostly software RAID1 and RAID10, but in some cases, much bigger > hardware RAID5). So yes, that's my usual server setup. Since you're talking of software RAID and LVM, that means you need an initramfs to boot your system. Thus, your systems will continue to boot with the proposed scenario, which supports booting with /usr on a separate filesystem if you have an initramfs. What exactly is the problem? -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/2012090325.gc18...@grep.be
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
On Fri, Aug 31, 2012 at 09:56:27AM +0200, Josselin Mouette wrote: > Le jeudi 30 août 2012 à 22:19 +0200, Wouter Verhelst a écrit : > > On Fri, Aug 24, 2012 at 10:44:11AM +0200, Andrew Shadura wrote: > > > How do you suppose it's possible to undo arbitrary network > > > configuration done by arbitrary set of tools when there's no central > > > place to hold such information (and can't possibly be)? > > > > Actually, the kernel holds that information. Any tool can just query the > > kernel for information, and decide what to do with what's returned. > > Yes it does, but does it hold it in a meaningful, structured way? Yes. > In complex setups, for example, there might be no certain way to say > which interface is related to which route. wouter@carillon:~$ ip route sh default via 192.168.64.1 dev wlan0 169.254.0.0/16 dev tap0 scope link metric 1000 172.28.119.2 dev tap0 proto kernel scope link src 172.28.119.1 192.168.10.6 dev tap4 proto kernel scope link src 192.168.10.5 192.168.64.0/24 dev wlan0 proto kernel scope link src 192.168.64.184 wouter@carillon:~$ sudo ip route add 192.168.14.0/24 via 192.168.10.6 wouter@carillon:~$ ip route sh default via 192.168.64.1 dev wlan0 169.254.0.0/16 dev tap0 scope link metric 1000 172.28.119.2 dev tap0 proto kernel scope link src 172.28.119.1 192.168.10.6 dev tap4 proto kernel scope link src 192.168.10.5 192.168.14.0/24 via 192.168.10.6 dev tap4 192.168.64.0/24 dev wlan0 proto kernel scope link src 192.168.64.184 As you can see, each and every one of those entries contains a "dev" line saying which interface the route relates to, even when you add a route without specifying an interface. Since you said "complex setup", however, I might miss something. Did you have something specific in mind? > Or to tell which low-level interface another interface depends on > (think tunnels managed by userland tools). That indeed is slightly more complex. However, provided you know what the endpoint of the tunnel is, it's not impossible to figure out: wouter@carillon:~$ ip route get 192.168.14.1 192.168.14.1 via 192.168.10.6 dev tap4 src 192.168.10.5 cache > Actually if there was at least a *standard*, low-level (or in-kernel) > tool to return structured information about the current network > configuration, It's called "netlink", as Ben already pointed out as well. > maybe high-level network tools (such as ifupdown and NM) could be > redesigned in a completely different, much more compatible, way. Really, there's nothing stopping that from happening right now. NM does use netlink; ifupdown does not. Unfortunately that means ifupdown would need to be pretty much rewritten; in addition to rewriting the backend so that it uses netlink, its concepts are way too far away from the dynamicity that would be required to do the kind of stuff I'm describing. Such a rewrite is pretty much what I've started to do with ipcfg, fwiw. -- The volume of a pizza of thickness a and radius z can be described by the following formula: pi zz a -- 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/20120901101747.gb18...@grep.be
Re: Bug#684396: ITP: openrc -- alternative boot mechanism that manages the services, startup and shutdown of a host
Le 31 août 2012 10:06, "Josselin Mouette" a écrit : > > Le vendredi 31 août 2012 à 04:18 +0300, Serge a écrit : > > 2012/8/10 Josselin Mouette wrote: > > > Because being able to choose between alternatives for core features such > > > as the init system only brings more bugs and no added value. > > > > Sorry, I don't understand this point. > > > > If it's about just adding more bugs without bringing anything good > > with it — sure, it's a bad idea. > > It is exactly what init system multiplication is about. > > > But as long as: > > 1. It breaks nothing for existing installations (i.e. does not > > change defaults, > > That is already far-stretched. > > > does not break existing custom scripts, > > This is even more far-stretched. > > > even > > is not installed by default) > > 2. It has something, that is not provided by other packages, > > meaning, it makes someone happy. (!) > > Kitten pictures make me happy. Can we ship them too? I will fill an itp. Can i add you as m'y sponsor? > > 3. There's someone willing to maintain it and fix the bugs. > > That means there is someone who will pester other maintainers to “fix” > their init scripts so that they work with another half-baked init > implementation. > > > PS: IMHO, saying things like "Linux is not about choice" and > > "Debian is not about being universal" just scares maintainers > > and users away from debian, and brings nothing good instead. > > If you’re scared by hearing that Linux is not about choice, let me say > it again: Linux is not about choice. Not about choice. Choice is not > inherently good. Linux is not about choice. Booh. > > As for Debian not being universal, this is certainly not my saying. But > toy ports and toy init systems are part of what makes Debian less > universal: being the universal OS doesn’t mean accepting every piece of > shit, it means being able to answer every user need. Adding more choice > always brings more bugs, but it does not, by far, always answer to more > user needs. > > One good init system can answer all our needs, while four bad ones will > certainly not. > > -- > .''`. Josselin Mouette > : :' : > `. `' > `- > > > -- > 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/1346399420.3479.446.camel@pi0307572 >
Re: can we (fully) fix/integrate NetworkManager (preferred) or release-goal its decommissioning
Serge writes: > 2012/8/30 Wouter Verhelst wrote: > >>> How do you suppose it's possible to undo arbitrary network >>> configuration done by arbitrary set of tools when there's no central >>> place to hold such information (and can't possibly be)? >> >> Actually, the kernel holds that information. Any tool can just query the >> kernel for information, and decide what to do with what's returned. > > Not sure. Will it work for user-space configuration too? I.e. `ifdown` > may have have to stop `dhclient` and `wpa_supplicanf`. Is it possible > to detect such cases automatically? If you start dhclient or wpa_supplicant on ifup, then you naturally need to query and deconfigure those tools on ifdown too. There is a perfect symmetry here: "up" use rtnetlink => "down" queries/deconfigures rtnetlink "up" use wpa_supplicant => "down" queries/deconfigures wpa_supplicant "up" use dhclient => "down" queries/deconfigures dhclient "up" use pppd => "down" queries/deconfigures pppd etc. Layered combinations of the above is of course common and must be supported. But I fail to see the point of this discussion. Post patches for NM and/or ifupdown implementing the features you'd like to see. No need for all the theoretical mumbo-jumbo, implying that someone else should do the job. Bjørn -- 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/878vcu3yhi@nemi.mork.no
Re: [b-d][falla] acl2
Le 31/08/2012 20:29, Julien Cristau a écrit :
> On Thu, Aug 30, 2012 at 15:23:53 -0400, Camm Maguire wrote:
>
>> Greetings!
>>
>> Stephen Gran writes:
>>
>>> Why not add logging to the Makefile, or cat debian/mini-proveall.out or
>>> something? This doesn't look like a dead end to me.
>>>
>>
>> Thanks so much for your suggestion! Can uploads instruct all autobuilders
>> but for a single arch to ignore the package? The build is very intensive.
>
> Upload to experimental, with
[...]
> in debian/rules.
To even avoid the start of the compilation (ie also preparing the chroot),
cannot we use something like:
Build-Depends: {normal stuff...}, maintainer-avoid-build [!foo]
This should prevent autobuilders to try to build the package on all
but foo architectures, no ?
Regards,
Vincent
> Cheers, Julien
--
Vincent Danjean GPG key ID 0x9D025E87 vdanj...@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main
--
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/5041bd96.9040...@ens-lyon.org
Bug#686413: ITP: feedgnuplot -- A pipe-oriented frontend to gnuplot. Allows plotting of standard input, both in realtime and for stored data
Package: wnpp Severity: wishlist Owner: Dima Kogan * Package name: feedgnuplot Version : 1.20 Upstream Author : Dima Kogan * URL : https://github.com/dkogan/feedgnuplot * License : GPL Programming Lang: Perl Description : A pipe-oriented frontend to gnuplot. Allows plotting of standard input, both in realtime and for stored data This is a flexible, command-line-oriented frontend to Gnuplot. It creates plots from data coming in on STDIN or given in a filename passed on the commandline. Various data representations are supported, as is hardcopy output and streaming display of live data. I am the author of this tool. The packaging has been done for a while now, and just awaits a sponsor. -- 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/20120901073652.15301.6893.reportbug@shorty.local
