Re: UUID in fstab for device mapper devices?
Hi Ferenc,
On Sun, Aug 09, 2009 at 09:31:48PM +0200, Ferenc Wagner wrote:
> Guido Günther writes:
>
> > On Sun, Aug 09, 2009 at 04:57:28PM +0200, Ferenc Wagner wrote:
> >
> >> OK, so the problem is identifying multipath devices in d-i. So that
> >> option would be better called d-i_friendly_names, because from the
> >> user PoV losing name persistence -- which this option implies --,
> >> isn't friendly or useful, in my opinion. If only multipath used
> >
> > To avoid we're furhter talking past each other: which device names
> > aren't persistent from your PoV when using user_friendly_names?
>
> I was wrong. The "friendly" mpath names are persistent, because
> /var/lib/multipath/bindings takes care of the persistence. But they
> are arbitrary, and subject to change between machines. (Actually,
> I've never used them, please correct me if I'm wrong again.)
It's correct this way. The names are of course persistent across reboots
since they're stored in a mapping file but not persistent across
machines. Good to have this sorted out.
> > Dropping user_friendly_names won't give you name persistence with and
> > without mp all by itself. You'll either have to use disk/by-id or
> > disk/by-uuid to achive that.
>
> Why not? The WWIDs, which are used to name the devices by default,
> are persistent and also consistent between machines, aren't they?
Yes, these are persistent across machines but they aren't persistent as
to switching multipath on and off (see below).
> I've been using them on this assumption for years, and it seems to
> work out... Please explain why the udev symlinks would be any better
> (given that I'm not interested in using filesystem UUIDs).
We could have the same fstab with and without multipath. This would be
convenient for our users since they'd have easier means of error
recovery (and an easy way to turn multipath on and off):
Without multipath:
/dev/disk/by-uuid/ -> /dev/sdaY
With multipath:
/dev/disk/by-uuid/ -> /dev/mapper/-partY
Udev would handle this transparently. Something similar can possibly be
done by looking at /dev/disk/by-id/scsi--partY (using the WWID
instead of the fs UUID) but I'd have to check the details for that.
> To get really friendly names, I define aliases in multipath.conf, but
> that's mostly sugar, I could do without them. Losing name consistency
> amongst different machines would be a major inconvenience, though.
I wouldn't object getting rid of user_friendly_names in multipath.conf,
but preferably by switching to /dev/disk/by-{uu,}id then.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
unblock freetype, cairo, pango1.0?
Hi, Would it be appropriate to unblock freetype, cairo and pango1.0? All three seem to be frozen due to udebs (debian-boot CCed). -- bye, pabs http://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Team meetings: August 17th
Given our current schedule, a team meetign hould happen on August 17th. As I mentioned on -private (but nothing in this is private), I expected to have a full net connection during my holydays, which would have made such meeting possible for me. As it turns out that I have to move elsewhere in the holidays venue where I'm staying, it makes much complicated to me to guarantee that I can attend. Also because attending an IRC meeting while on holidays (and living with a spanish-like schedule) is fairly impossible to guaranteeI perfer warning that I won't attend that meeting, if one is still going on. If there are enough people around, it would be good to have a meeting, still, as many things happened since the last one (live at Debconf). -- signature.asc Description: Digital signature
Re: Bug#399840: Do we want an ssh-server task?
Quoting Matthew Palmer (mpal...@debian.org): > Out of curiosity, how are people in this situation actually installing their > systems? Are there really that many people out there that are keyboarding When it comes at /me: "aptitude install openssh-server". OTOH, I've already seen the addition of an SSH server being forgotten when a server is manually installed in a hurry, so having this popping up and make it easier to not forget seems to have some added value. > As someone who has preseeded their installs to the point where a new, > fully-configured machine is nothing more than a 10 minute appointment with > the PXE server, I'm having trouble imagining that there's a large market for > this microtask[1], but I've been wrong before. I just think it's a question > worth asking. It's hard to say whether there is a large market or not. The only thing we can say is that this bug's history is quite long (and, from memory, the suggestion pops up from time to time) and, after much much pondering (and live discussion at Debconf), I finally decided to get along with it. An element of the decision was also that Colin mentioned that the task was requested (and added) in Ubuntu which adds something to the "there is some demand for it". I was personnally balanced for adding some other stuff to the task. Actually, the discussion with Colin made me discover the nice utilities he mentioned. Still, because there was a quite strong opposition to a more versatile task, the rough consensus was that we could first try adding the task and then see whether there is a demand for something more complete, or not. signature.asc Description: Digital signature
Bug#540752: reportbug installation-reports
Package: installation-reports Boot method: Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-businesscard.iso Date: 10.08.2009 / 10am Machine: Dell 740 Optiplex Processor: AMD 4850e Memory:4GB Partitions: Output of lspci -knn (or lspci -nn): Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: In general the latest testing versions are unstable on this machine. Especially with KDE. Note: Vanishing mouse cursor. --- Wir forschen für die Zukunft von Morgen!
Re: Install from ISO for Xen guest
On Friday 07 August 2009, Ian Campbell wrote: > On Fri, 2009-08-07 at 07:39 +0100, Ian Campbell wrote: > > I will follow up shortly with[...]a patch to the nightly cron jobs > > which enables this variant for the i386+amd64+powerpc multiarch > > netinst image. > > Here it is. Committed. > Is this sufficient to ensure this variant is enabled in the actual > official images come release time? Or should I be patching somewhere > else as well? AFAIK this should be sufficient. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
Guido Günther writes:
> On Sun, Aug 09, 2009 at 09:31:48PM +0200, Ferenc Wagner wrote:
>
>> Guido Günther writes:
>>
>>> Dropping user_friendly_names won't give you name persistence with
>>> and without mp all by itself. You'll either have to use disk/by-id
>>> or disk/by-uuid to achive that.
>>
>> Why not? The WWIDs, which are used to name the devices by default,
>> are persistent and also consistent between machines, aren't they?
>
> Yes, these are persistent across machines but they aren't persistent
> as to switching multipath on and off (see below).
Hi Guido,
Thanks, I got your point now.
> We could have the same fstab with and without multipath. This would
> be convenient for our users since they'd have easier means of error
> recovery (and an easy way to turn multipath on and off):
And to run without multipath without noticing until the first path
failure.
> Without multipath:
> /dev/disk/by-uuid/ -> /dev/sdaY
>
> With multipath:
> /dev/disk/by-uuid/ -> /dev/mapper/-partY
Multipath is critical enough in my systems that I prefer explicit
control and early failure dealing with it. Others may have different
preferences, of course.
Also, how does this carry over to multipathed root? I'd guess
initramfs needs the real device name after root= anyway, doesn't it?
>> To get really friendly names, I define aliases in multipath.conf,
>> but that's mostly sugar, I could do without them. Losing name
>> consistency amongst different machines would be a major
>> inconvenience, though.
>
> I wouldn't object getting rid of user_friendly_names in
> multipath.conf, but preferably by switching to /dev/disk/by-{uu,}id
> then.
I'd welcome that. It may not be the exact thing I'd want, but good
enough to start from. I may as well get to love it in the end. :)
--
Thanks,
Feri.
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [d-i on kfreebsd] quick status report
On Sun, Aug 09, 2009 at 09:46:07AM +0200, Felix Zielcke wrote:
> Am Samstag, den 08.08.2009, 21:06 +0200 schrieb Robert Millan:
> > On Fri, Aug 07, 2009 at 08:53:06AM +0200, Felix Zielcke wrote:
> > > --- grub-installer(revision 60026)
> > > +++ grub-installer(working copy)
> > > @@ -115,7 +115,7 @@ convert () {
> > > tmp_disk=$(echo "$1" | sed 's%\([sh]d[0-9]*\).*%\1%')
> > > tmp_part=$(echo "$1" | sed "s%$tmp_disk%%")
> > > ;;
> > > - freebsd*)
> > > + freebsd*|gnu/kfreebsd*)
> > > tmp_disk=$(echo "$1" | sed 's%r\{0,1\}\([saw]d[0-9]*\).*$%r\1%'
> > > | \
> > > sed 's%r\{0,1\}\(da[0-9]*\).*$%r\1%')
> > > tmp_part=$(echo "$1" | \
> > > @@ -166,7 +166,7 @@ convert () {
> > > fi
> > > echo "$tmp_drive"
> > > ;;
> > > - freebsd*)
> > > + freebsd*|gnu/kfreebsd*)
> > > if echo $tmp_part | grep "^s" >/dev/null; then
> > > tmp_pc_slice=$(echo $tmp_part | \
> > > sed "s%s\([0-9]*\)[a-h]*$%\1%")
> >
> > I think the convert() function is only used for GRUB Legacy.
>
> Ah I didn't looked it up before.
> convert() gets only used for the os-prober entrys, but there for both
> grub-legacy and grub2.
> grub-probe is still not used.
The GRUB 2 ones don't work, because this routine uses Legacy disk/partition
numbering.
A while ago I sent a patch to fix this problem by switching to grub-probe:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=13;filename=grub-installer.diff;att=1;bug=473401
At this point, keeping the convert() function doesn't provide any benefit,
even for GRUB Legacy. If grub-probe couldn't be used for this conversion,
install would fail anyway.
But it does work. It shipped with Lenny this way.
--
Robert Millan
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [d-i on kfreebsd] quick status report
On Mon, Aug 10, 2009 at 12:58:27PM +0200, Robert Millan wrote: > > A while ago I sent a patch to fix this problem by switching to grub-probe: > > > http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=13;filename=grub-installer.diff;att=1;bug=473401 > > At this point, keeping the convert() function doesn't provide any benefit, > even for GRUB Legacy. If grub-probe couldn't be used for this conversion, > install would fail anyway. > > But it does work. It shipped with Lenny this way. Anyhow, this is not necessary at all to support GNU/kFreeBSD. I was only triing to explain why there's no need to update convert() for the sake of GRUB 2. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Processing of kickseed_0.53_i386.changes
kickseed_0.53_i386.changes uploaded successfully to localhost along with the files: kickseed_0.53.dsc kickseed_0.53.tar.gz kickseed-common_0.53_all.udeb initrd-kickseed_0.53_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
kickseed_0.53_i386.changes ACCEPTED
Accepted: initrd-kickseed_0.53_all.udeb to pool/main/k/kickseed/initrd-kickseed_0.53_all.udeb kickseed-common_0.53_all.udeb to pool/main/k/kickseed/kickseed-common_0.53_all.udeb kickseed_0.53.dsc to pool/main/k/kickseed/kickseed_0.53.dsc kickseed_0.53.tar.gz to pool/main/k/kickseed/kickseed_0.53.tar.gz Override entries for your package: initrd-kickseed_0.53_all.udeb - optional debian-installer kickseed-common_0.53_all.udeb - standard debian-installer kickseed_0.53.dsc - source utils Announcing to debian-devel-chan...@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: broken d-i doc links
Hi, On Mon, Aug 10, 2009 at 05:27:00PM +0200, helix84 wrote: > At http://d-i.debian.org/l10n-stats/ > under Resources > "Debian Installer i18n documentation (HTML version, PDF version, TXT version)" > link to d-i.debian.org but the docs are still at alioth. > I didn't check other links at that page. Thanks for your report, that I forward to the d-i team (whose pages are not under debian-www scope). -- Simon Paillard -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: broken d-i doc links
On Monday 10 August 2009, Simon Paillard wrote: > On Mon, Aug 10, 2009 at 05:27:00PM +0200, helix84 wrote: > > At http://d-i.debian.org/l10n-stats/ > > under Resources > > "Debian Installer i18n documentation (HTML version, PDF version, TXT > > version)" link to d-i.debian.org but the docs are still at alioth. > > I didn't check other links at that page. > > Thanks for your report, that I forward to the d-i team (whose pages are > not under debian-www scope). Already fixed. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: UUID in fstab for device mapper devices?
On Mon, Aug 10, 2009 at 12:20:30PM +0200, Ferenc Wagner wrote:
> Guido Günther writes:
>
> > On Sun, Aug 09, 2009 at 09:31:48PM +0200, Ferenc Wagner wrote:
> >
> >> Guido Günther writes:
> >>
> >>> Dropping user_friendly_names won't give you name persistence with
> >>> and without mp all by itself. You'll either have to use disk/by-id
> >>> or disk/by-uuid to achive that.
> >>
> >> Why not? The WWIDs, which are used to name the devices by default,
> >> are persistent and also consistent between machines, aren't they?
> >
> > Yes, these are persistent across machines but they aren't persistent
> > as to switching multipath on and off (see below).
>
> Hi Guido,
>
> Thanks, I got your point now.
>
> > We could have the same fstab with and without multipath. This would
> > be convenient for our users since they'd have easier means of error
> > recovery (and an easy way to turn multipath on and off):
>
> And to run without multipath without noticing until the first path
> failure.
>
> > Without multipath:
> > /dev/disk/by-uuid/ -> /dev/sdaY
> >
> > With multipath:
> > /dev/disk/by-uuid/ -> /dev/mapper/-partY
>
> Multipath is critical enough in my systems that I prefer explicit
> control and early failure dealing with it. Others may have different
> preferences, of course.
I see your point. Maybe we can even have both /dev/mapper/ as well
as /dev/disk/by-uuid/ support in d-i. This would be even simpler if d-i
would use /dev/disk/by-uuid instead of UUID= by default. Is there any
good reason not to do this? Udevless systems?
> Also, how does this carry over to multipathed root? I'd guess
> initramfs needs the real device name after root= anyway, doesn't it?
Haven't checked but shouldn't a /dev/disk/by-id/ path also work. We have
all the stuff up in the initramfs already.
> >> To get really friendly names, I define aliases in multipath.conf,
> >> but that's mostly sugar, I could do without them. Losing name
> >> consistency amongst different machines would be a major
> >> inconvenience, though.
> >
> > I wouldn't object getting rid of user_friendly_names in
> > multipath.conf, but preferably by switching to /dev/disk/by-{uu,}id
> > then.
>
> I'd welcome that. It may not be the exact thing I'd want, but good
> enough to start from. I may as well get to love it in the end. :)
Now we only need somebody to work on that ;) Seriously: I won't be able
to spend much time working on it in the near future but at least we have
a direction where we should be heading.
Cheers,
-- Guido
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#399840: Do we want an ssh-server task?
Matthew Palmer wrote: On Sun, Aug 09, 2009 at 03:31:10PM +0200, Frans Pop wrote: On Sunday 09 August 2009, Colin Watson wrote: On Wed, Jul 29, 2009 at 01:14:52PM +0200, Frans Pop wrote: On Wednesday 29 July 2009, Christian Perrier wrote: An interesting proposal that Colin made was to converge towards a task named "Login server" or something similar, that would include openssh-server, along with other packages such as denyhosts (or sshguard), rssh (Restricted shell allowing scp, sftp, cvs, svn, rsync or rdist), molly-guard (protects machines from accidental shutdowns/reboots)... Most systems really only want ssh, not any of the rest. Is this assertion really true? My experience has been that quite a lot of people actually want something a bit more, even if they don't know it. I've personally never installed any of the others on any of my systems, while I do have openssh-server installed on all of my systems. The actual request is to make it easier to have openssh-server installed so that users can straight away access the newly installed system over ssh, nothing more and nothing less. So IMO we need a task that does exactly that, and nothing more. Out of curiosity, how are people in this situation actually installing their systems? Are there really that many people out there that are keyboarding their way through an entire install, but can't (won't?) then login to the newly installed system at the console and run "apt-get install openssh-server"? As someone who has preseeded their installs to the point where a new, fully-configured machine is nothing more than a 10 minute appointment with the PXE server, I'm having trouble imagining that there's a large market for this microtask[1], but I've been wrong before. I just think it's a question worth asking. In my case, 99 times out of ten it is a case of "Sit at the console and do the install, when it completes walk back to my desk in another building, try to login and realize 'Damn, I didn't get an ssh server installed' and go back to do so." Good for exercise, not so good for frustration level. Were I dealing exclusively with Debian installs, perhaps my creaky wetware would become conditioned to "the install isn't complete until you apt-get install openssh-server" but I deal with three other distros and at least two other operating systems where this isn't an issue. rick jones -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#507653: installation report: partitioner shows warning: 'The kernel was unable to re-read the partition table on /dev/md0', ext3 format hangs
My setup: (sorry I'm new at this (Linux) so I'm typing this out manually) sda -- 320GB SATA sda1 512M raid container bootable sda2 99% of rest raid container sdb -- 320GB SATA sdb1 512M raid container bootable sdb2 99% of rest raid container md0 RAID1 ext3 boot sda1 sdb1 md1 RAID10 lvm container sda2 sdb2 vg00 in md1 v00 8G swap v01 12G xfs root v02 40G xfs home rest of space unused at the moment At the point where the partitioner needs to format md0, I kept getting the warning "The kernel was unable to re-read the partition table on /dev/md0" and whether I chose back or continue, it would try to format with ext3 and hang. It's a 512MB volume, so it shouldn't take that long. Thing is, I got this exact same setup to work earlier today, but I decided to start over after I messed up with grub2, trying to get a bootloader on sdb so the system can still boot if sda fails. I found a solution: Do NOT select ext3 for md0. Choose xfs. Let it format, then go back and change it to ext3. It will format again, and should finish normally. I'm installing the rest of the system as I type this (on another pc). Hope this helps.
Re: RFC: debhelper 7 conversions
Quoting Colin Watson (cjwat...@debian.org): > Any comments? Other than applause? Not from me..:-) Actually, I eagerly wait for your changes as they will make good self-documented examples about "how to convert to debhelper 7 and properly use overrides" for my own packages..:-) signature.asc Description: Digital signature
Console-setup not installed with the current daily images?
> here is an addition to my first answer: > > a. console-setup is NOT on board after the basic installation performed by > the > current Debian Sid installer, so there can't be any "dpkg-reconfigure console- > setup" performed to readjust my keyboard in order to make it functionable. > > I need to install console-data, otherwise my keyboard layout is unusable - Forking a new thread here May someone thoroughly test whether console-setup is installed on the installed system when the current dailies are used. I'm not in position of doing this as my net connection is too shaky for that. signature.asc Description: Digital signature
Re: Bugs in the latest Debian Sid installer
Quoting Uwe Bugla (uwe.bu...@gmx.de): > This installer does not seem to recognize serial mice. Are you talking about the graphical installer (in such case, the problem is in the installer...though we probably had very few users with serial mice that tested D-I)? Or are you talking about X on the installed system? In such case, the problem pertains to X packages more than the installer...though it wouldn't be a real surprise to me that serial mice are not autoconfigured given the incredibly low number of people still using such old hardware (at least on i386/amd64). signature.asc Description: Digital signature
Re: Bugs in the latest Debian Sid installer
(please avoid quoting the entire discussion) Quoting Uwe Bugla (uwe.bu...@gmx.de): > I have an unusable keyboard layout on the installed system, unfortunately. > After performing "apt-get install console-data" the keyboard layout is > usable, > but without performing that step the usage is a big pain! > > > In any case, "dpkg-reconfigure console-setup" on the installed system > > should help. > > Sounds good, but is only helpful if you know that console-setup has been > installed or not. How can I find that out? You later confirmed that console-setup was not installed on the system. *that* is the entire problem. You're certainly right, that is a bug. But the bug is not having console-setup. That needs investigation which I can't do right now, being on holidays with few timeand using a dialup-style connection. The keymap problem should be solved by installing console-setup on the installed system. That's better than installing console-data as console-setup is the way we intend to go. > Your point of view is fully OK for a standard install, no matter if console- > based or graphical, adressing rookies and beginners. > > My point of view should fit for experienced users using the expert install, > no > matter if graphical or console based. > But simplification in any case, and thus disregarding the different installer > levels with their different sophistication is a point of view or guide line > that I cannot and will not share at all... While I understand that concern, I think that adding the option to configure all NICs would add an extra level of complexity to the installerwhich we can't afford right now. Not to mention of course that nobody apparently felt the deep need to work on this...:-). Patches to the netcfg package are of course very much welcomed but will certainly be investigated thoroughly as we certainly don't want to break the existing installer to add an option which has been requested very very very seldomly in the last 5 years of D-I development. > > Here again, this is much out of scope of the installer. It is left to > > the post-install polishing of the installed machine, when the > > machine's admin is supposed to be skilled enough to know how to do > > this. > > I prefare to avoid the usage of editors. Thus it would make sense to add an > additional point in the installer menu asking the user whether he wants to > perform a Debian Sid installation or rather one based on the testing branch > for which the installer was written: squeeze in this case. That exists and is asked in expert installs. There is no point in showing this in the default install as the installer is meant to install squeeze as it will be the installer used for distributed media when the system is released. > > Installers are here to simplify necessary tasks, NOT to complicate them > > It's quite humble to say "We don't want this and we don't want that" or "We > expect the user to be qualified enough to ..". > > I would not define myself as subqualified. But I would highly prefer an > installer which is a bit more elegant and less buggy and complicated than the > current one. Your contribution in improving the installer will be very much welcomed. Particularly when it comes at the elegant solution for an installer that is both capable to install end users laptops, high-end users machines with encrypted file systems, or cluster nodes of HPC systems Please, again, note that you tested something that's under development and also highly depends on the development of the entire distro. The sid installer is sometimes broken...sometimes even heavily broken. This is what the development branch of Debian is about..:) signature.asc Description: Digital signature
Re: Bugs in the latest Debian Sid installer
Am Montag 10 August 2009 09:14:43 schrieb Christian Perrier: > Quoting Uwe Bugla (uwe.bu...@gmx.de): > > This installer does not seem to recognize serial mice. > > Are you talking about the graphical installer (in such case, the > problem is in the installer...though we probably had very few users > with serial mice that tested D-I)? YEAH! I do talk about ther graphical installer. And if it is only one user, the backwards compatibility should be ensured IMHO! > Or are you talking about X on the installed system? In such case, the > problem pertains to X packages more than the installer...though it > wouldn't be a real surprise to me that serial mice are not > autoconfigured given the incredibly low number of people still using > such old hardware (at least on i386/amd64). Consequently, I cannot talk about X, as I did not come far enough tot test serial mice under X. Regards Uwe -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: udpkg: add a --os option
Hello Aurelien, On Thu, Aug 6, 2009 at 2:34 PM, Aurelien Jarno wrote: > Hi, > > In the kfreebsd branch of the debian-installer we are using at some > places uname to detect if we are running on GNU/Linux on GNU/kFreeBSD, > when the script doesn't differ a lot. > > This is not something really clean, and I think that adding a --os > option to udpkg (similar to the --arch option) could help. > > What do you think? Sorry but I fail to see the difference between calling uname and udpkg. Can you provide an example how it would help? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#539908: partman: libparted says "File system alias linux-swap(new) is deprecated"
Hello, On Tue, Aug 4, 2009 at 7:56 AM, Frans Pop wrote: > Package: partman-base > Version: 132 > > During an installation I get a number of lines like: > main-menu[756]: (process:5108): [0] ../../libparted/filesys.c:147 > (ped_file_system_type_get): File system alias linux-swap(new) is deprecated > > Looks like this will require updates in a number of partman components > (including partman-auto recipes) if we want to be 100% consistent. > > Otavio: what is the correct replacement and could you take care of this > update? Yes; I'll take it. We changed it to use the (new) but after it we, in upstream, has merged a Colin's patch to properly deprecated it and use linux-swap. I'll fix it together with newer parted upload. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#540960: Updating the ttf-cjk-compact Maintainer/Uploaders list
Package: ttf-cjk-compact Version: 1.14 Severity: minor Hidetaka Iwai has not been working on the ttf-cjk-compact package for quite some time. We are tracking their status in the MIA team and would like to ask you to remove them from the Uploaders list of the package so we can close that part of the file. Alternatively, if the person is listed as Maintainer, what we are asking is to please step in as a new maintainer. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#277592: Attention !!!
I am Mrs.Turuer Clarissa Ann.I have a business that will benefit you now and in the future. If you are interested,kindly respond via mr.turuer...@9.cn to enable me forward you further information Regards. Mrs.Turuer Clarissa Ann. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
