Re: cgroup mount point
On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote: > On Mon, Feb 02, 2009 at 09:52:46PM +0100, Mike Hommey wrote: > > On Mon, Feb 02, 2009 at 09:26:11PM +0100, Julien Cristau wrote: > > > On Mon, 2009-02-02 at 18:00 -0200, Thadeu Lima de Souza Cascardo wrote: > > > > Hello, > > > > > > > > Some software I intend to package work with the new cgroup feature in > > > > Linux. I would like to open a discussion about what would be the better > > > > place to mount it and how/when to mount it. > > > > > > What do other distros use? > > > > Even better: what do the kernel folks want to do? > > > > Mike > > From what I've seen, most of them are in the same phases as Debian, or, > perhaps, behind. Fedora seems to plan that for Fedora 11, and they have > some support in libvirt. libvirt is not going to impose any policy for mount points, nor mount anything itself. When we use cgroups, libvirt just looks up the mount table to find out where the admin or distro has put the mount points for each cgroups controller. I've also not done anything in default Fedora install to automatically setup cgroups, since doing that hits the hard-to-answer question of whether to mount all controllers in one, or a separate mount per controller, or a hybrid. > So, we have some more options now: /cgroups, /containers, /dev/cpuset, > /dev/cpuctl, /opt/cgroup, /opt/cpuset. Putting new mount points in / is not really acceptable, so that rules out the first two. /opt is just totally wrong, since that is intended for add on software packages. /dev/ feels a little odd, since it is not really device nodes, but perhaps that doesn't matter. So my pref would be something in /dev/cgroups or /sys/cgroups I also think 'cgroups' is a better name than 'containers', since 'containers' is refering to just one specific use case. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
"Daniel P. Berrange" writes: > On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote: > > So, we have some more options now: /cgroups, /containers, > > /dev/cpuset, /dev/cpuctl, /opt/cgroup, /opt/cpuset. > > Putting new mount points in / is not really acceptable, so that rules > out the first two. /opt is just totally wrong, since that is intended > for add on software packages. /dev/ feels a little odd, since it is > not really device nodes I agree with all that Thadeu Lima says here. I would add that cgroups are nothing to do with device nodes, so definitely don't belong in ‘/dev/’ either. Since they're a filesystem mapping “for browsing and manipulation from user space” of a kernel facility, I think ‘/sys/cgroups/’ is appropriate. -- \ “It's my belief we developed language because of our deep inner | `\ need to complain.” —Jane Wagner, via Lily Tomlin | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Release Update: d-i RC2 and deep freeze; handling of remaining RC bugs; *-reports and release notes
-- # Nicolay DIMITROV . # CRIS - Bât A 2ème étage # Direction des Systèmes d'Information de l'Université Stendhal # Domaine Universitaire 1180 avenue Centrale B.P.25 38040 Grenoble cedex 9 # Tel: 0476827797 Fax: 0476827754 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, Feb 03, 2009 at 10:30:28AM -0200, Thadeu Lima de Souza Cascardo wrote: > Sorry. I didn't mean to imply that libvirt or Fedora did anything in > respect to the mountpoint themselves. But that they are supporting or > planning to support cgroups. And I think that one time we will need to > sort the problem of the mountpoint, either let the applications mount it > (in this case, libvirt) or the system do it (Fedora install, Debian > initscripts, et al). > > I have some experience with lxc tools from http://lxc.sf.net/ and these > tools also look up the mountpoint at /proc/mounts. So it is up to the > system or the user to mount it. That's good. We settled on letting mount points be OS / admin defined in libvirt, because we felt libvirt shouldn't try to impose a mount policy on a resource that will have many users & we are able to work with whatever mount hierarchy the admin / OS decided to setup. > > Putting new mount points in / is not really acceptable, so that rules > > out the first two. /opt is just totally wrong, since that is intended > > for add on software packages. /dev/ feels a little odd, since it is > > not really device nodes, but perhaps that doesn't matter. So my pref > > would be something in /dev/cgroups or /sys/cgroups > > My suggestions were /proc/cgroup, /sys/cgroup, /cgroup or /dev/cgroup. I > sent the problems with the former two, and the rationale for the latter > two in a previous message. > > I agree that /opt/ is not the place for it (and that's the one I called > 'funny'). I've head some people telling that /dev/ is for devices, but I > can't see a problem (/dev/log is a socket and it is there, the FHS > refers to special files). > > /proc/ and /sys/ are two good options if the kernel does not put anything > else there. /proc/cgroups already exist, for example. > > Could you please give your rationale why / is not really acceptable? Just a general preference is to not continually add more ad-hoc top level directories to /, when there are other places in the filesystem hierarchy that are available, such as /sys or /proc. > > I also think 'cgroups' is a better name than 'containers', since > > 'containers' is refering to just one specific use case. > > Agreed on this one, although I still prefer the singular (it is also the > name of the filesystem type). Either singular / plural sounds fine to me Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, Feb 03, 2009 at 10:24:16AM +, Daniel P. Berrange wrote: > Putting new mount points in / is not really acceptable, so that rules > out the first two. /opt is just totally wrong, since that is intended > for add on software packages. /dev/ feels a little odd, since it is > not really device nodes, but perhaps that doesn't matter. So my pref > would be something in /dev/cgroups or /sys/cgroups How about /var/lib/cgroup? There's already precedent (/var/lib/nfs/rpc_pipefs) of mounting virtual file systems under /var/lib. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, 2009-02-03 at 23:44 +1100, Ben Finney wrote: > I agree with all that Thadeu Lima says here. I would add that cgroups > are nothing to do with device nodes, so definitely don't belong in > ‘/dev/’ either. > > Since they're a filesystem mapping “for browsing and manipulation > from user space” of a kernel facility, I think ‘/sys/cgroups/’ is > appropriate. I agree with this point of view. I believe /sys/cgroups is the way to go. Now, of course this has the drawback of shadowing something future versions of Linux would make available at that same path, but I am pretty sure they would be careful not to do that after distributions have settled on a standard path. See you, -- Gustavo Noronha Debian Project -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Рeклама для Вaшего бизнеса
Вы все еще задумываете над имиджем компании, поэтому не обращаетесь к e-mail рассылкам? Хватит! За окном кризис и надо выживать! Это недорого и действительно работает (ведь Вы это письмо прочитали). Звоните, пишите и уже завтра у Вас будут новые клиенты. Тел.:(Ч95)585 62O9 ICQ: 3837 67 114 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, Feb 03, 2009 at 11:44:00PM +1100, Ben Finney wrote: > "Daniel P. Berrange" writes: > > > On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo > > wrote: > > > So, we have some more options now: /cgroups, /containers, > > > /dev/cpuset, /dev/cpuctl, /opt/cgroup, /opt/cpuset. > > > > Putting new mount points in / is not really acceptable, so that rules > > out the first two. /opt is just totally wrong, since that is intended > > for add on software packages. /dev/ feels a little odd, since it is > > not really device nodes > > I agree with all that Thadeu Lima says here. I would add that cgroups > are nothing to do with device nodes, so definitely don't belong in > ‘/dev/’ either. The message you quoted is from Daniel Berrange, not me. Could you also tell your rationale for not agreeing with /? Regards, Cascardo. > Since they're a filesystem mapping “for browsing and manipulation > from user space” of a kernel facility, I think ‘/sys/cgroups/’ is > appropriate. > > -- > \ “It's my belief we developed language because of our deep inner | > `\ need to complain.” —Jane Wagner, via Lily Tomlin | > _o__) | > Ben Finney signature.asc Description: Digital signature
Re: cgroup mount point
Gabor Gombas (gomb...@sztaki.hu) said: > On Tue, Feb 03, 2009 at 10:24:16AM +, Daniel P. Berrange wrote: > > > Putting new mount points in / is not really acceptable, so that rules > > out the first two. /opt is just totally wrong, since that is intended > > for add on software packages. /dev/ feels a little odd, since it is > > not really device nodes, but perhaps that doesn't matter. So my pref > > would be something in /dev/cgroups or /sys/cgroups > > How about /var/lib/cgroup? There's already precedent > (/var/lib/nfs/rpc_pipefs) of mounting virtual file systems under > /var/lib. Depending on when you need the cgroup filesystem to setup your containers, /var may not be there. Bill -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, Feb 3, 2009 at 6:38 AM, Gustavo Noronha wrote: > On Tue, 2009-02-03 at 23:44 +1100, Ben Finney wrote: >> I agree with all that Thadeu Lima says here. I would add that cgroups >> are nothing to do with device nodes, so definitely don't belong in >> '/dev/' either. >> >> Since they're a filesystem mapping "for browsing and manipulation >> from user space" of a kernel facility, I think '/sys/cgroups/' is >> appropriate. > > I agree with this point of view. I believe /sys/cgroups is the way to > go. Now, of course this has the drawback of shadowing something future > versions of Linux would make available at that same path, but I am > pretty sure they would be careful not to do that after distributions > have settled on a standard path. Having one virtual filesystem mounted on top of another virtual filesystem seems like a recipe for problems. /dev/cgroup or /dev/cgroup/ sounds more reasonable to me (although if anyone is still using devfs that would suffer from the same drawbacks) Paul -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#514013: ITP: libconfig-model-openssh-perl -- Graphical editor for OpenSsh sshd_config and ssh_config files
Package: wnpp Severity: wishlist Owner: Dominique Dumont * Package name: libconfig-model-openssh-perl Version : 1.203 Upstream Author : Dominique Dumont * URL : http://search.cpan.org/dist/Config-Model-OpenSsh/ * License : LGPL Programming Lang: Perl Description : Graphical editor for OpenSsh sshd_config and ssh_config files Config::Model::OpenSsh provides a graphical configuration editor for /etc/ssh/sshd_config and /etc/ssh/ssh_config (for root) and ~/.ssh/config for non-root users. Once this module is installed, you can run: # config-edit-sshd Likewise, you can edit your ~/.ssh/config file with: $ config-edit-ssh Or to edit /etc/ssh/ssh_config, run as root: # config-edit-ssh With libconfig-model-cursesui-perl, you can also use a curses interface. With libconfig-model-backend-augeas-perl, you will use Augeas to keep comment and structure of /etc/ssh/sshd_config (not available for ssh config data) Config::Model::OpenSsh include a configuration model that describe the structure and constraints of OpenSsh configuration. This model is used by Config::Model to generate the graphical or curses interfaces. This model can also be used as an example for developers who would like to create their own configuration model for their project. -- System Information: Debian Release: 5.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, Feb 03, 2009 at 10:24:16AM +, Daniel P. Berrange wrote: > On Mon, Feb 02, 2009 at 07:41:53PM -0200, Thadeu Lima de Souza Cascardo wrote: > > From what I've seen, most of them are in the same phases as Debian, or, > > perhaps, behind. Fedora seems to plan that for Fedora 11, and they have > > some support in libvirt. > > libvirt is not going to impose any policy for mount points, nor mount > anything itself. When we use cgroups, libvirt just looks up the mount > table to find out where the admin or distro has put the mount points > for each cgroups controller. > > I've also not done anything in default Fedora install to automatically > setup cgroups, since doing that hits the hard-to-answer question of > whether to mount all controllers in one, or a separate mount per > controller, or a hybrid. Sorry. I didn't mean to imply that libvirt or Fedora did anything in respect to the mountpoint themselves. But that they are supporting or planning to support cgroups. And I think that one time we will need to sort the problem of the mountpoint, either let the applications mount it (in this case, libvirt) or the system do it (Fedora install, Debian initscripts, et al). I have some experience with lxc tools from http://lxc.sf.net/ and these tools also look up the mountpoint at /proc/mounts. So it is up to the system or the user to mount it. > > So, we have some more options now: /cgroups, /containers, /dev/cpuset, > > /dev/cpuctl, /opt/cgroup, /opt/cpuset. > > Putting new mount points in / is not really acceptable, so that rules > out the first two. /opt is just totally wrong, since that is intended > for add on software packages. /dev/ feels a little odd, since it is > not really device nodes, but perhaps that doesn't matter. So my pref > would be something in /dev/cgroups or /sys/cgroups My suggestions were /proc/cgroup, /sys/cgroup, /cgroup or /dev/cgroup. I sent the problems with the former two, and the rationale for the latter two in a previous message. I agree that /opt/ is not the place for it (and that's the one I called 'funny'). I've head some people telling that /dev/ is for devices, but I can't see a problem (/dev/log is a socket and it is there, the FHS refers to special files). /proc/ and /sys/ are two good options if the kernel does not put anything else there. /proc/cgroups already exist, for example. Could you please give your rationale why / is not really acceptable? > I also think 'cgroups' is a better name than 'containers', since > 'containers' is refering to just one specific use case. Agreed on this one, although I still prefer the singular (it is also the name of the filesystem type). > Regards, > Daniel > -- > |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| > |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| Regards, Cascardo. signature.asc Description: Digital signature
Re: cgroup mount point
Paul Menage wrote: > > Having one virtual filesystem mounted on top of another virtual > filesystem seems like a recipe for problems. /dev/cgroup or > /dev/cgroup/ sounds more reasonable to me (although if > anyone is still using devfs that would suffer from the same drawbacks) I was leaning towards /sys/cgroup until this point was brought up. /var/lib does seem like the best default place. If a particular site needs it available before /var is available, then that site is free to mount it on /cgroup or /container or whatever they desire. -- John H. Robinson, IV jaq...@debian.org http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, Feb 03, 2009 at 07:49:15PM +0100, Mike Hommey wrote: > > Having one virtual filesystem mounted on top of another virtual > > filesystem seems like a recipe for problems. > > Like with /sys/fs/fuse/connections ? Come on, there is no problem with a > virtual filesystem mounted on top of another. or /proc/bus/usb or /dev/shm or /dev/pts... :) sean signature.asc Description: Digital signature
Re: cgroup mount point
On Tue, Feb 3, 2009 at 10:51 AM, sean finney wrote: > On Tue, Feb 03, 2009 at 07:49:15PM +0100, Mike Hommey wrote: >> > Having one virtual filesystem mounted on top of another virtual >> > filesystem seems like a recipe for problems. >> >> Like with /sys/fs/fuse/connections ? Come on, there is no problem with a >> virtual filesystem mounted on top of another. > > or /proc/bus/usb or /dev/shm or /dev/pts... :) > /dev is a bit different though - even if it's mounted as a udev fs, you can create a new directory in there to act as a mount point. Cgroups supports multiple hierarchies on different mount points. So if you have two cgroups hierarchies - say one for CPU/network and one for memory isolation, you could create /dev/cgroup/cpunet and /dev/cgroup/memory and mount the two hierarchies. But sysfs doesn't allow you to create new subdirectories to act as mountpoints. If we can have a /sys/cgroups directory which allows you to create arbitrary subdirs to act as mountpoints, that could be OK. Or just fake it by mounting a tmpfs on /sys/cgroups and then create mount points in there, but that seems like a bit of a hack. Paul -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Best practises in team-maintaining packages - summary of the BOFs at DebConf8
Best practises in team-maintaining packages - summary of the BOFs at DebConf8 = Preface --- * First of all please accept my apologies - I promised to write this summary shortly after DebConf but ... * I'm posting this mail to -devel (to reach a broad audience) and to -qa (because I think improving the way teams work is an aspect of QA in Debian), RT and MFT set to -qa. * The following summary can obviously contain my interpretations and might misrepresent some of the discussions; I invite all participants to correct any errors. The BOFs During DebConf 8 in Mar del Plata two BOFs about "Best practises in team-maintaining packages" took place, the first as planned beforehand, and the second at the request of some participants of the first session in order to discuss things further. I'd like to thank again all the participants for the IMO very productive work and especially Tim Retout for taking notes and preparing the minutes of the sessions. The objectives of the BOFs as defined beforehand were: - bring members of different packaging teams together - get an overview of different work flows, tools, and challenges - compile generally useful 'models of good practise' - define possible areas for cooperation / tasks of mutual interest The complete minutes can be found at http://lists.debconf.org/lurker/message/20080815.023943.bf7a5f27.en.html http://lists.debconf.org/lurker/message/20080817.235345.667b162b.en.html The videos of the BOFs are available at http://meetings-archive.debian.net/pub/debian-meetings/2008/debconf8/ (615* - 617* and 823*) The first BOF started with structured mini-presentations by members of several packaging teams (cf. the minutes above). The second half of the first BOF and the entire second BOF then tried to focus on the challenges and open questions that teams face in their work: Tools/work flows/policies - A question was: "Would it be useful to standardise the work flow between packaging teams, or to standardise the documentation for their work flow to make it easier for others to find the relevant information?" Some of the opinions/proposals: * Use the existing mechanisms (e.g. README.source for packages and wiki.d.o/Teams for teams), and spread the word where this information can be found. * Have an "abstraction" package per-team containing team work flow documentation; better than Wiki; can contain cdbs class or README.source files. * Point to the Wiki page(s) in the developers' reference. Maintainers/Uploaders - Question: "Would it be useful to have a common policy for Maintainer/Uploaders?" (i.e. whether Maintainer = team and members in Uploaders or the other way round) Most of the present teams put the team in the Maintainer field. That approach makes dealing with the BTS, with user or maintainer requests and also with retiring people easier. It was also mentioned that it's important not to restrict people helping out on different packages. One team preferred to have a "human maintainer" (and the group in Uploaders) in the past because of bad experiences with people dumping packages in the group's repository and disappearing afterwards, leaving the question of responsibility for the package unanswered. Also discussed where approaches of creating the Uploaders field automatically from debian/changelog; the GNOME team seems to use a tool for that purpose that would be nice to have as an option for other teams to. In the end of the discussion there was a tendency to use the group in the Maintainer field; changing the Developers' reference (5.12), which mentions both possibilities, doesn't seem necessary at the moment, the present teams want to act as models of good practise for the time being. In the long run it might be good to standardise the definitions of the terms "Maintainer" and "Uploaders" for team-maintained packages by policy. Tools --- A large topic was the question of collecting existing and developing new tools that are especially useful for packaging teams. At the moment many teams have their own command-line scripts or web-based tools. As a first step a list of existing tools should be compiled. Some aspects: * Converging existing tools seems desirable; e.g. we now have UDD, PET, buildstat, DEHS, ... * Having a package for command-line tools, cdbs-snippets, ... that are used for working on groups of packages or help in building team-maintained packages (maybe devscripts-team, built from the devscript's source package?) seems useful. * Some of the web-based tools could be made available on Alioth automatically (e.g. PET). Recruiting people - A bit of time was also spent on the question on how to recruit new members for teams and how to integrate them. I seems that none of the present teams has a structured approach for recruitment and induction; some thoughts
urgent RFH: please help test mdadm 2.6.7.2-1
I found a bit of time to package up mdadm 2.6.7.2-1, which fixes two
RC bugs, but I cannot test it. I've built unofficial packages for
i386 and amd64 and put them at
http://debian.madduck.net/repo/pool/main/m/mdadm/
so please try them out if you can, otherwise I won't be able to
upload them soon, which might delay the lenny release.
mdadm (2.6.7.2-1~unreleased.1) unstable; urgency=low
* New upstream release, created for Debian lenny:
- fixes assembly of arrays that are being reshaped (closes: #512475)
- this bug was also responsible for other assembly problems
(closes: #498505, #499643, #496334)
Again, many thanks to Neil Brown for being such an awesome upstream.
* Documentation updates:
- Actually install David Pashley's blog post added in 2.6.7.1-1, and
register it with doc-base.
- Update md.txt to version 2.6.26 (the lenny kernel).
- Add a dump of a website detailing md superblock formats.
- Register FAQ, md.txt, RAID5-vs-RAID10, README.recipes with doc-base
- Cherry-picked UID/UUID typo in mdadm.conf(5) manpage fix (commit
0e69da7) (closes: #506245).
* Added Italian debconf translation; thanks Luca Monducci (closes: #506572).
The upstream changes between 2.6.7.1 and .2 are:
piper:..an/pkg/mdadm/mdadm|build|% git cherry -v mdadm-2.6.7.{1,2}
+ 3b9d24da5bdb88f5668d795f22c93911f55682f6 Fix an error when assembling arrays
that are in the middle of a reshape.
+ a856723ab6baf9423d7c27fd61c795fc59c26f1d Italic/bold fixes in man pages.
+ 5b53734ed8d9648205957b1b555a4e45fdcb510d Add text to man pages suggesting
partition type to use for version 1.x metadata.
+ 15f37068018812e7669e0a1b5da5f53c01eff7e7 Couple more man page fixes
+ 257abe70415427f471ad245f202f153c0aa6d1f5 Describe the HOMEHOST entry in the
mdadm.conf man page.
+ 84ba6910af0bb94d599967bc1f3cc62b62f7e94a Fix confusing usage in md.4 man page.
+ fd53a2c5e58438b923a0a03ea40ea92103c54bac Cosmetic cleanup of some messages.
+ 69b24ddc4ef64c46edff7e10463b8e95665b3434 Remove .UR .UE macros from man page
because the don't do what we want.
+ d305b6e623bed4767f9c97f01ca5db46482c430b Release mdadm-2.6.7.2
Thanks,
--
.''`. martin f. krafft Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"friendships last when each friend thinks he has
a slight superiority over the other."
-- honoré de balzac
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
Re: cgroup mount point
On Tue, 3 Feb 2009 11:14:03 -0800 Paul Menage wrote: > On Tue, Feb 3, 2009 at 10:51 AM, sean finney > wrote: > > or /proc/bus/usb or /dev/shm or /dev/pts... :) > > > > /dev is a bit different though - even if it's mounted as a udev fs, > you can create a new directory in there to act as a mount point. So, what's the problem with /dev/cgroups then? If shm/ and pts/ are allowed under /dev, wouldn't it be discriminating against cgroups/, to not allow it there? Cheers, harry signature.asc Description: PGP signature
Re: cgroup mount point
On Tue, Feb 3, 2009 at 3:38 PM, Harald Braumann wrote: > > So, what's the problem with /dev/cgroups then? If shm/ and pts/ > are allowed under /dev, wouldn't it be discriminating against > cgroups/, to not allow it there? Right, that's what I proposed a couple of emails earlier in this thread. Paul -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: piuparts offline
> "LN" == Lucas Nussbaum writes: LN> - using a local cache/proxy, such as approx, that would have the .debs LN> you need if you first run piuparts online once on the packages you are LN> interested in, before running it offline. I used to run apt-get through WWWOFFLE, but then thought that is a big waste. OK, thanks anyway. I'm wishing piuparts could be enhanced one day with: --local: don't go online at all, and instead attempt to get everything we need from /var/cache/apt/archives and /var/lib/apt/lists. Can be combined with --dry-run to see if everything we need is already in place. Also one can cache the result for faster startup a second time with ... OK, bye. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, Feb 03, 2009 at 08:55:34AM -0800, Paul Menage wrote: > On Tue, Feb 3, 2009 at 6:38 AM, Gustavo Noronha wrote: > > On Tue, 2009-02-03 at 23:44 +1100, Ben Finney wrote: > >> I agree with all that Thadeu Lima says here. I would add that cgroups > >> are nothing to do with device nodes, so definitely don't belong in > >> '/dev/' either. > >> > >> Since they're a filesystem mapping "for browsing and manipulation > >> from user space" of a kernel facility, I think '/sys/cgroups/' is > >> appropriate. > > > > I agree with this point of view. I believe /sys/cgroups is the way to > > go. Now, of course this has the drawback of shadowing something future > > versions of Linux would make available at that same path, but I am > > pretty sure they would be careful not to do that after distributions > > have settled on a standard path. > > Having one virtual filesystem mounted on top of another virtual > filesystem seems like a recipe for problems. Like with /sys/fs/fuse/connections ? Come on, there is no problem with a virtual filesystem mounted on top of another. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: cgroup mount point
On Tue, 3 Feb 2009 15:40:39 -0800 Paul Menage wrote: > On Tue, Feb 3, 2009 at 3:38 PM, Harald Braumann > wrote: > > > > So, what's the problem with /dev/cgroups then? If shm/ and pts/ > > are allowed under /dev, wouldn't it be discriminating against > > cgroups/, to not allow it there? > > Right, that's what I proposed a couple of emails earlier in this > thread. Sorry, I didn't mean to imply that you'd be against it, on the contrary, I took your explanation as another argument for using /dev and against /sys (/cgroups should not even be considered, IMHO). The question was targeted at those, who oppose it. Cheers, harry signature.asc Description: PGP signature
Re: Release Candidate 2 of Debian Installer
On Tue, 3 Feb 2009 12:35:48 +0900 Paul Wise wrote: > How about letting the person doing the installation write the labels > if they want to use LABEL and use UUID by default. > Or as a third option, put everything in LVM, including boot and root, and the problem goes away. GRUB2 would have to be used, though. Cheers, harry signature.asc Description: PGP signature
Re: Release Candidate 2 of Debian Installer
On Tue, 2009-02-03 at 23:43 +0100, Harald Braumann wrote: > On Tue, 3 Feb 2009 12:35:48 +0900 > Paul Wise wrote: > > > How about letting the person doing the installation write the labels > > if they want to use LABEL and use UUID by default. > > > Or as a third option, put everything in LVM, including boot and root, > and the problem goes away. GRUB2 would have to be used, though. I am not sure GRUB2 is ready for a production release of Debian. It will be by squeeze, but not yet for lenny IMHO. Right now for booting off LVM, we use lilo. This is lilo's main use-case in Debian currently[1], excluding hardware configurations where GRUB1 fails to work correctly. A configuration resulting in us using lilo as the default bootloader is probably not a good idea for many reasons, of which I have gone through before, and do not intend to outline here (mostly related to the age of the lilo codebase, and the fact that lilo needs to be refactored if it is to remain relevant for much longer). William [1] debian-installer explicitly installs lilo instead of grub when a LVM is used as the boot partition. signature.asc Description: This is a digitally signed message part
Re: cgroup mount point
Thadeu Lima de Souza Cascardo writes: > The message you quoted is from Daniel Berrange, not me. You're right. I should have read more carefully. > Could you also tell your rationale for not agreeing with /? The bar for adding new required entries to the root directory is now very high. The facility being discussed is far too specific to need a top-level entry, especially when better alternatives have already been suggested that fit it into the existing, more meaningful, directories. -- \ “The optimist thinks this is the best of all possible worlds. | `\ The pessimist fears it is true.” —J. Robert Oppenheimer | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
finally purged debconf items with no owners
I have finally figured out how to remove the items with no owners from the debconf database. It took the fancy Makefile below, created by reverse engineering the extremely complicated debconf system as far as I was able. The big problem is that it is an extreme mystery how to do just # debconf-whatever --purge whatever If anybody knows the answer, please say it. Anyway, here's the Makefile purge:/tmp/base_purge bad_owners set -xe; for i in `cat bad_owners`; do j=/tmp/$$i.postrm; ln $< $$j;\ $$j; done bad_owners:owners good_owners comm -3 $? > $@ owners:/var/cache/debconf/config.dat debconf-show --listowners|sort -u > $@ good_owners:owners dpkg -l $$(cat $?)|perl -alnwe 'print $$F[1] if /^.[ic]/' > $@ /tmp/base_purge: echo . /usr/share/debconf/confmodule \&\& db_purge > $@ && chmod +x $@ By the way, just for the record below are the offending packages that left their configurations upon purge. I do not know if their current versions do the same. Nor do I know if piuparts detects such things. abiword-common alsa-base alsa-modules-2.4.18-k7 alsa-modules-2.4.19-k7 ash cpufreqd docbook-dsssl dpkg-www efax ftpd gnus htdig jpilot kdrill language-env libdvdread3 libpaper-utils libpaperg libpq3 libsensors3 links-ssl linux-image-2.6.16-1-686 php5-gd php5-mysql postgresql-client spamassassin ssh tetex-base tetex-bin txt2pdbdoc x86info xfree86-common xplanet -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
