Re: [D-I] Call for translation update for next Beta release
Quoting Frans Pop ([EMAIL PROTECTED]): This will be the last Beta release. The next release will be a release candidate (RC) for Etch. For RC releases we _will_ have formal string freeze periods for translation updates and it is also more important that you have your translations updated to 100% because otherwise you run the risk that the installer will be actually released with an incomplete translation! And, translators believe me, you will have someone who will nitpick you very loudly for you to update your translations:-) Hopefully, for the RC releases, I will have achieved the D-I levels reorganization which will give you better priorities. Actually, please focus on levels 1, 2 and 5. signature.asc Description: Digital signature
Re: Status of debian-installer for the native ppc64 port
Hi, On Monday 19 June 2006 22:56, Sven Luther wrote: In the end I gave up and stopped working on that approach. A few month later I started again to work on the installer, but this time I tried to create a separate native ppc64 d-i port. This turned out to be pretty easy and the resulting installer almost worked out of the box. So I did not return to the cross-installation idea. I feel that it is the best solution for this, which should satisfy everyone, so if at least Frans agrees on this plan too, we can try to work in that direction. which solution do you think is better? the cross-installer (isnt there one for amd64 already?) or the native installer? regards, Holger pgpokjuiZPDwY.pgp Description: PGP signature
Re: stagger forced fsck on reboot
On Mon, Jun 19, 2006 at 04:40:05PM +1000, Drew Parsons wrote: The inconvenience could be ameliorated if the force-fsck mount counter could be staggered for each partition. For instance, the first partition on every 20 mounts, the second on every 21, and so on. Then on a given reboot, on average you'd only have to put up with one forced fsck, not all of them together. as far as i know it's also possible to set the counter to a specific value, which might be better. so make them all be checked after 20 maounts, but set the counters to 0, 1, 2, 3 and so on after the isntallation. cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Bug#374228: installation-reports: Installation failed with base-installer/no_codename on AMD64
On Tuesday 20 June 2006 04:40, Anthony Juckel wrote: FYI, the 2006-06-20 amd64 netinst image is still using a 2.6.15 kernel, so I still get the same module load error. I've got a vested interest in testing the nightlies until I get a version that works for me, so I'll keep relating my experience until I get the system up and running. I've subscribe to debian-boot for the time being as well. I saw on IRC that there was a script error that prevented mirror synchronization again, which has been fixed. However, I also see there have been no new AMD64 d-i images built the last 2 days... I've contacted the relevant people. If you want to check for yourself, check this page that new d-i images for AMD64 have been built: http://people.debian.org/~joeyh/d-i/build-logs.html The first CD images built after that should be OK (I hope). Would it be better to send my feedback to that forum, or keep a thread running on this bug? This is fine as it ends up on the d-boot list anyway. Cheers, FJP pgpGICl6FgzOX.pgp Description: PGP signature
Bug#69153: my chance
Do anot ignore me bplease,b I found your email somewhere and nobwb decided to write you. I am coming to your place in few weeks abnd bthought wae can meaet each other. Let me know ifa you do not mind. I am a nice pretty girl. Don't reply to this email. Email me direclty at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Status of debian-installer for the native ppc64 port
Hello, Holger Levsen wrote: which solution do you think is better? the cross-installer (isnt there one for amd64 already?) or the native installer? There is currently no cross-installer for amd64 as far as I know. There is not even a 64-bit kernel flavor in the i386 repository. There was one some time ago but it has been discontinued. I do not think that there is a 'better' solution. Both solutions have their place. The amd64 native 64-bit installer should not be dropped just because the i386 32-bit installer can be used to cross-install amd64. The same is true for the ppc64 case in my opinion. Anyway, at the moment the native 64-bit installer is the only one that works for the ppc64 installation. But it would certainly be helpful to get the cross-installation option also implemented. Regards Andreas Jochens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
I have been fighting the whole Sunday to make a patch to the debian package gtk+2.0 so that it produces also a library with the directfb backend. why? The Gnome team will support the D-I team in producing the gtk+-directfb packages. Until now I have maneged to make a separate set of targets in the debian/rules. Still there are some problems because in the Debian package it seems that the configure* files have also some .orig counterparts and I haven't figured yet what is the flow of the things during the build for these files. (directfb gdk-target is still not visible, because the configure* files are rewritten - this is the most recent info I have, but I had to blindly try to compile the package and went on a wrong track for some time causing me to waste about 4-5 hours). I am still unsure about the way I should tell the build system to use the cairo.so file provided by the libcairo2-directfb-dev package (Dave, I fear that symlinks will be necessary for this file, too). Also I am not sure if the so file should not be called something like cairo-directfb.so, but am so unsure of these things that i think nothing should be done until this issue is calrified. Cairo is fine and, apart from the couple of things pointed out by Frans, package can be used for compiling gtk+: why should we delay things? why should the library be renamed? there's no such an issue and things have been handled properly via .pc file. have you checked the packages? (yes, I have) Would you please double check before sendig such messages to package maintainers and Multiple MLs? Now I think I got the general idea behind the build process of gtk+2.0 Debian package and I hope I will manage to get tonight the direcfb library to build. The library builds fine already (see [2] and [3]). Are you familiar with rebuilding all the libraries, the needed udebs and the mini.iso (I know you've rebuilt from source Dave's package)? have you managed to rebuild the new libraries and to create a g-i image based on those? if so, can you please provide a link to a ppc mini.iso based on the new libs? From one of your messages on d-boot ([1]) you say that current ppc g-i is broken, so shouldn't the crash be fixed before trying to use the new libraries or do you blindly assume that everythings will be magically ok with the new libs? your help is of course _very_ welcome, but to me it looks like you're doing the wrong thing at the wrong time: rebuilding the libs from scratch was very useful a while back (before and soon after Extremadura), when Mike needed the support for putting the dfb backend into cvs and at the time Attilio and myself spent alot of time and effort on doing this (see wikis). now what is needed is testing the packages produced by the official maintainers and not duplicating their work or delaying other people' work. regards, Davide [1] http://lists.debian.org/debian-boot/2006/06/msg00667.html [2] http://lists.debian.org/debian-boot/2006/06/msg00687.html [3] http://lists.debian.org/debian-boot/2006/06/msg00902.html
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On 6/20/06, Viti Davide [EMAIL PROTECTED] wrote: I have been fighting the whole Sunday to make a patch to the debian package gtk+2.0 so that it produces also a library with the directfb backend. why? The Gnome team will support the D-I team in producing the gtk+-directfb packages. I wanted to do so... and if I do it right, their work will be less. Until now I have maneged to make a separate set of targets in the debian/rules. I am still unsure about the way I should tell the build system to use the cairo.so file provided by the libcairo2-directfb-dev package (Dave, I fear that symlinks will be necessary for this file, too). Also I am not sure if the so file should not be called something like cairo-directfb.so, but am so unsure of these things that i think nothing should be done until this issue is calrified. Cairo is fine and, apart from the couple of things pointed out by Frans, package can be used for compiling gtk+: why should we delay things? why should the library be renamed? there's no such an issue and things have been handled properly via .pc file. have you checked the packages? (yes, I have) Would you please double check before sendig such messages to package maintainers and Multiple MLs? Now I think I got the general idea behind the build process of gtk+2.0 Debian package and I hope I will manage to get tonight the direcfb library to build. The library builds fine already (see [2] and [3]). The impression that the above messages left me is that the library used for the image was simply built from sources and added in the image via a tarball, not via a package. Am I not correct about this? Are you familiar with rebuilding all the libraries, the needed udebs and the mini.iso (I know you've rebuilt from source Dave's package)? have you managed to rebuild the new libraries and to create a g-i image based on those? if so, can you please provide a link to a ppc mini.iso based on the new libs? From one of your messages on d-boot ([1]) you say that current ppc g-i is broken, so shouldn't the crash be fixed before trying to use the new libraries or do you blindly assume that everythings will be magically ok with the new libs? Note: I feel much anger in your writing... I don't consider it my responasbility to fix those images, as I have said some time ago, I just have time for testing. In spite of that I wanted to see gtk+2.0 packages prepared to build directfb packages, too and hoped (not blindly) that the colour issues will disappear. your help is of course _very_ welcome, but to me it looks like you're doing the wrong thing at the wrong time: rebuilding the libs from scratch was very useful a while back (before and soon after Extremadura), when Mike needed the support for putting the dfb backend into cvs and at the time Attilio and myself spent alot of time and effort on doing this (see wikis). now what is needed is testing the packages produced by the official maintainers and not duplicating their work or delaying other people' work. Have they done this? Judging from what I know and seen in unstable, directfb gtk packages are still unsupported. Do such experimental packages exist? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: cross-installer
On Tue, Jun 20, 2006 at 11:45:00AM +0200, Andreas Jochens wrote: Hello, Holger Levsen wrote: which solution do you think is better? the cross-installer (isnt there one for amd64 already?) or the native installer? There is currently no cross-installer for amd64 as far as I know. There is not even a 64-bit kernel flavor in the i386 repository. There was one some time ago but it has been discontinued. I do not think that there is a 'better' solution. Both solutions have their place. The amd64 native 64-bit installer should not be dropped just because the i386 32-bit installer can be used to cross-install amd64. The same is true for the ppc64 case in my opinion. Anyway, at the moment the native 64-bit installer is the only one that works for the ppc64 installation. But it would certainly be helpful to get the cross-installation option also implemented. Another question regarding cross-installation: Would the cross-installer allow installation across architectures? Examples Given: * On a recent Macintosh (powerpc) doing the install and take the SCSI-disk to an old Mac (m68k) * On an AMD64 computer doing the install and serve the network-disk to a ARM system. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
request for samogitian
Hello, I'd like to translate boot of instalation to Samogitian language. Arns Udovīčė
Preseeding dictionaries selection
I'm playing with preseeding d-i and i'm wondering how to preseed dictionaries selection. I tried with dictionaries-common dictionaries-common/default-ispell select italiano (Italian) dictionaries-common dictionaries-common/default-wordlistselect italiano (Italian) but i've got no success. Any suggestion? -- Thanks IS Iacopo Spalletti i dot spalletti at iast dot it PGP key block: http://www.nephila.it/pgp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: request for samogitian language
On Tue, Jun 20, 2006 at 02:52:59PM +0300, Zordsdavini iz Litvy wrote: Hello, I'd like to translate boot of instalation to Samogitian language. As far as I known is it documented at http://people.debian.org/~bubulle/d-i/i18n-doc/ Feel free to ask here, this mailinglist, further questions. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preseeding dictionaries selection
Iacopo Spalletti wrote: I'm playing with preseeding d-i and i'm wondering how to preseed dictionaries selection. I tried with dictionaries-common dictionaries-common/default-ispell select italiano (Italian) dictionaries-common dictionaries-common/default-wordlistselect italiano (Italian) but i've got no success. Any suggestion? Hi Iacopo, do a manual install, do then install debconf-utils with 'apt-get install debconf-utils' and then run 'debconf-get-selections \ result.txt ; debconf-get-selections --installler result.txt'. Check out the values in result.txt and use thos in your preseed file. Sincerely, Jan. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: request for samogitian language
What to do if for now there is no SO-639 code of the Samogitian language. We use bat-smg in wikipedia. May be here we have use the same. Arns Udovīčė 2006/6/20, Geert Stappers [EMAIL PROTECTED]: On Tue, Jun 20, 2006 at 02:52:59PM +0300, Zordsdavini iz Litvy wrote: Hello, I'd like to translate boot of instalation to Samogitian language. As far as I known is it documented at http://people.debian.org/~bubulle/d-i/i18n-doc/ Feel free to ask here, this mailinglist, further questions. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Ok^ ek^ besla ikv Olmok Vzauep^evk :)
Re: cross-installer
[EMAIL PROTECTED] (Geert Stappers) writes:
On Tue, Jun 20, 2006 at 11:45:00AM +0200, Andreas Jochens wrote:
Hello,
Holger Levsen wrote:
which solution do you think is better? the cross-installer (isnt there
one for amd64 already?) or the native installer?
There is currently no cross-installer for amd64 as far as I know.
There is not even a 64-bit kernel flavor in the i386 repository.
There was one some time ago but it has been discontinued.
I do not think that there is a 'better' solution. Both solutions
have their place. The amd64 native 64-bit installer should not be
dropped just because the i386 32-bit installer can be used to
cross-install amd64. The same is true for the ppc64 case in my opinion.
Anyway, at the moment the native 64-bit installer is the only one
that works for the ppc64 installation. But it would certainly be
helpful to get the cross-installation option also implemented.
Another question regarding cross-installation:
Would the cross-installer allow installation across architectures?
Examples Given:
* On a recent Macintosh (powerpc) doing the install
and take the SCSI-disk to an old Mac (m68k)
* On an AMD64 computer doing the install
and serve the network-disk to a ARM system.
You can always run (c)debootstrap -aarch untill it fails when it
chroots into the target. Then go to the actual target system and boot
with init=/bin/sh and then
- dpkg --force-depends -i /var/cache/apt/archives/{libc6,dpkg}*.deb
- maybe force some more packages to get dpkg/libc6 depends satisfied
- dpkg -iGROEB /var/cache/apt/archives/
- repeat till there are no more errors
- fix fstab, create user, setup sources.list, ...
- reboot
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
why? The Gnome team will support the D-I team in producing the gtk+-directfb packages. I wanted to do so... and if I do it right, their work will be less. I'm not sure they need help on packaging; I might be wrong but I don't think the gtk is not ready because of technical problems. The library builds fine already (see [2] and [3]). The impression that the above messages left me is that the library used for the image was simply built from sources and added in the image via a tarball, not via a package. Am I not correct about this? You are right, but why do you need a debian package to test the patch? And again: have you tried to build a mini.iso based on the new set of Libraries? Wouldn't it make sense to get confident with it before concentrating On making an udeb you would not know how to use and test? Note: I feel much anger in your writing... Yes, your message did piss me off very much indeed. You would delay things by saying i think nothing should be done until this issue is clarified because you have not clear how the libraries work. Note that it's perfectly ok having doubts, but before telling that in name of The d-I team to the package maintainer, you could discuss it on irc/ml and make Sure there are some problems. IMO it just confuses things. I don't consider it my responasbility to fix those images, as I have said some time ago, I just have time for testing. Huh? What do you expect then? You write on d-boot hey, g-I is fucked on ppc as you did with Cyrillic fonts, And then you expect within a couple of hours to find a hundred messages on your Mailbox asking for details or providing a fix? Why don't you just try to provide proper reports so that the problems can be fixed? You lately reported that the crash on ppc happens because of the touchpad fix, but you Did not even try to revert the patch and see if that is the real problem... If that's your idea of testing things I'd say is not very effective and as a consequence it Takes a long time before problems get fixed. In spite of that I wanted to see gtk+2.0 packages prepared to build directfb packages, too and hoped (not blindly) that the colour issues will disappear. The colour problem disappears: it's one of the first things we did In Extremadura. Sven built the libraries and a test image and, apart For a problem with some buttons (not used inside g-i), everything looks Beautiful. I don't think you need a deb to see thet. now what is needed is testing the packages produced by the official maintainers and not duplicating their work or delaying other people' work. Have they done this? Judging from what I know and seen in unstable, directfb gtk packages are still unsupported. Do such experimental packages exist? No, it does not exist yet; cairo is a requirement. Unofficial cairo Could be used, true, but we'll need it officially anyway. I think the gnome team have all the skills needed to package gtk+-directfb, So IMO it's not a technical problem and of course you can try to do it Yourself, but I don't know how useful that would be. Regards, D.
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On 6/20/06, Viti Davide [EMAIL PROTECTED] wrote: why? The Gnome team will support the D-I team in producing the gtk+-directfb packages. I wanted to do so... and if I do it right, their work will be less. I'm not sure they need help on packaging; I might be wrong but I don't think the gtk is not ready because of technical problems. my feeling on the #gnome-debian channel ws that they were busy with other stuff ATM and nobody had time for this. The library builds fine already (see [2] and [3]). The impression that the above messages left me is that the library used for the image was simply built from sources and added in the image via a tarball, not via a package. Am I not correct about this? You are right, but why do you need a debian package to test the patch? And again: have you tried to build a mini.iso based on the new set of Libraries? Wouldn't it make sense to get confident with it before concentrating On making an udeb you would not know how to use and test? Err, i thought your i386 tests made that. If I am doing the patching against the source package, then you could test it on i386, too. Is not like they are hacked udebs like Attilio was doing, so you can't use it. Note: I feel much anger in your writing... Yes, your message did piss me off very much indeed. You would delay things by saying i think nothing should be done until this issue is clarified because you have not clear how the libraries work. Note that it's perfectly ok having doubts, but before telling that in name of The d-I team to the package maintainer, you could discuss it on irc/ml and make Sure there are some problems. IMO it just confuses things. I got no clear response on that matter from gtk/gnome people on the debian channel, and also I have faced some issues that made me believe that having two cairo.so files in two different places could be problematic; indeed I might have been wrong by not carifying that I was talking about _my_ effort. I don't consider it my responasbility to fix those images, as I have said some time ago, I just have time for testing. Huh? What do you expect then? I said clearly I don't have time for hacking[1], just testing. I am not the ppc porter, nor a helper porter and I don't have the knowledge to claim any of those positions. Also, somebody else is the powerpc porter, AFAIK. You write on d-boot hey, g-I is fucked on ppc as you did with Cyrillic fonts, And then you expect within a couple of hours to find a hundred messages on your Mailbox asking for details or providing a fix? Err, the problem was observed on the 18th of May, and I was expecting, since then somebody to try to investigate and fix this since I clearly said I couldn't do it. I have said something about this on the list on the 30th of May. I know the wiki.d.o/D-I/GUI is not BTS, but I have been told that it would not be proper to add this issue to D-I/Today and since the builds were not integrated, IIRC in trunk for PPC, I thought BTS was not the proper place to report them. The dailies were not official, thus BTS seemd wrong to me. You lately reported that the crash on ppc happens because of the touchpad fix, but you Did not even try to revert the patch and see if that is the real problem... Are you sure[2]? snipped from wiki.d.o: [2006-06-14] ppc: the debconf interface crashes (the fix for [WWW] #372773 is working here) If that's your idea of testing things I'd say is not very effective and as a consequence it Takes a long time before problems get fixed. What part of [1] didn't you understand? In spite of that I wanted to see gtk+2.0 packages prepared to build directfb packages, too and hoped (not blindly) that the colour issues will disappear. The colour problem disappears: it's one of the first things we did In Extremadura. Sven built the libraries and a test image and, apart For a problem with some buttons (not used inside g-i), everything looks Beautiful. I don't think you need a deb to see thet. But the packages are needed nonetheless. now what is needed is testing the packages produced by the official maintainers and not duplicating their work or delaying other people' work. Have they done this? Judging from what I know and seen in unstable, directfb gtk packages are still unsupported. Do such experimental packages exist? No, it does not exist yet; cairo is a requirement. Unofficial cairo Could be used, true, but we'll need it officially anyway. That's what I am working on. I think the gnome team have all the skills needed to package gtk+-directfb, No doubt, but the time is pressing us; if we want a G-I for etch every day counts, even the energy spent now could have been spent a lot better. So IMO it's not a technical problem and of course you can try to do it Yourself, but I don't know how useful that would be. Dave announced the availablity of the cairo packages for quite a while and I haven't seen any move from the gtk/gnome team. The most
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Tue, Jun 20, 2006 at 03:31:14PM +0200, Frans Pop wrote: Joey applied this patch yesterday and today I've built cdebconf for the new version and after that a mini.iso including that. When pkgsel is run, the debconf database is still being trashed... /me is confused Ouch, that's not good. The simplest test for this is to open debconf-copydb.c, remove the setenv() call and see if you still get the warnings about unknown field names. That's what used to happen, at least, so you can see if there really is a change or if something else has happened... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
Just to throw my two cents in. It's my understanding that the official packages upped the Directfb build to 0.9.24 which is fine for testing. If your comfortable using newer versions to see if problems have been fixed feel free but it was just a suggestion. Since the directfb/gdk/cairo software is still under heavy development understanding the state of the latest software by periodically testing cvs builds is not a bad thing if done by someone who could quickly do the builds and produce the images. If there are useful improvements fixes can be backported. I just wanted to clarify my position so its not lost in all the other issues. Mike On 6/20/06, Viti Davide [EMAIL PROTECTED] wrote: why? The Gnome team will support the D-I team in producing the gtk+-directfb packages. I wanted to do so... and if I do it right, their work will be less. I'm not sure they need help on packaging; I might be wrong but I don't think the gtk is not ready because of technical problems. The library builds fine already (see [2] and [3]). The impression that the above messages left me is that the library used for the image was simply built from sources and added in the image via a tarball, not via a package. Am I not correct about this? You are right, but why do you need a debian package to test the patch? And again: have you tried to build a mini.iso based on the new set of Libraries? Wouldn't it make sense to get confident with it before concentrating On making an udeb you would not know how to use and test? Note: I feel much anger in your writing... Yes, your message did piss me off very much indeed. You would delay things by saying i think nothing should be done until this issue is clarified because you have not clear how the libraries work. Note that it's perfectly ok having doubts, but before telling that in name of The d-I team to the package maintainer, you could discuss it on irc/ml and make Sure there are some problems. IMO it just confuses things. I don't consider it my responasbility to fix those images, as I have said some time ago, I just have time for testing. Huh? What do you expect then? You write on d-boot hey, g-I is fucked on ppc as you did with Cyrillic fonts, And then you expect within a couple of hours to find a hundred messages on your Mailbox asking for details or providing a fix? Why don't you just try to provide proper reports so that the problems can be fixed? You lately reported that the crash on ppc happens because of the touchpad fix, but you Did not even try to revert the patch and see if that is the real problem... If that's your idea of testing things I'd say is not very effective and as a consequence it Takes a long time before problems get fixed. In spite of that I wanted to see gtk+2.0 packages prepared to build directfb packages, too and hoped (not blindly) that the colour issues will disappear. The colour problem disappears: it's one of the first things we did In Extremadura. Sven built the libraries and a test image and, apart For a problem with some buttons (not used inside g-i), everything looks Beautiful. I don't think you need a deb to see thet. now what is needed is testing the packages produced by the official maintainers and not duplicating their work or delaying other people' work. Have they done this? Judging from what I know and seen in unstable, directfb gtk packages are still unsupported. Do such experimental packages exist? No, it does not exist yet; cairo is a requirement. Unofficial cairo Could be used, true, but we'll need it officially anyway. I think the gnome team have all the skills needed to package gtk+-directfb, So IMO it's not a technical problem and of course you can try to do it Yourself, but I don't know how useful that would be. Regards, D. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On Tuesday 20 June 2006 16:50, Eddy Petrişor wrote: Dave announced the availablity of the cairo packages for quite a while and I haven't seen any move from the gtk/gnome team. The most important thing I learen in OSS is that you (yourself) are the best o scratch your own itch. That's what I think I am doing here. There is still some discussion about those packages and I reported at least one important needed change a few days ago. AFAIK we have not yet asked the Gnome people to do anything and that seems the smart thing to do until we _know_ the cairo packages are actually good. pgp0XGUk79MSv.pgp Description: PGP signature
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On 6/20/06, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 20 June 2006 16:50, Eddy Petrişor wrote: Dave announced the availablity of the cairo packages for quite a while and I haven't seen any move from the gtk/gnome team. The most important thing I learen in OSS is that you (yourself) are the best o scratch your own itch. That's what I think I am doing here. There is still some discussion about those packages and I reported at least one important needed change a few days ago. AFAIK we have not yet asked the Gnome people to do anything and that seems the smart thing to do until we _know_ the cairo packages are actually good. Probably the best to say that is actually someone who tries to use them or someone with enough library packaging experience. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Monday 19 June 2006 20:57, Steinar H. Gunderson wrote: After some discussion on IRC, here's the updated patch. Joey applied this patch yesterday and today I've built cdebconf for the new version and after that a mini.iso including that. When pkgsel is run, the debconf database is still being trashed... /me is confused pgptHNA8LHsW7.pgp Description: PGP signature
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On Tue, Jun 20, 2006 at 05:50:31PM +0300, Eddy Petrişor wrote: Err, i thought your i386 tests made that. If I am doing the patching against the source package, then you could test it on i386, too. Is not like they are hacked udebs like Attilio was doing, so you can't use it. following the wiki or using the build script committed in extremadura you should be able to build any of the g-i libs and that is what Sven, Attilio and myself did. Packaging the libraries, requires alot more; I just got the impression you are not confident with none of those (and I really do not mean to offend you anyhow by saying that) I got no clear response on that matter from gtk/gnome people on the debian channel, and also I have faced some issues that made me believe that having two cairo.so files in two different places could be problematic; indeed I might have been wrong by not carifying that I was talking about _my_ effort. I think it was not appropriate to involve two MLs and Dave to sort out your doubt: cairo has been successfully used to produce working images and that is enough to say it is working. I don't consider it my responasbility to fix those images, as I have said some time ago, I just have time for testing. Huh? What do you expect then? I said clearly I don't have time for hacking[1], just testing. I am not the ppc porter, nor a helper porter and I don't have the knowledge to claim any of those positions. Also, somebody else is the powerpc porter, AFAIK. You write on d-boot hey, g-I is fucked on ppc as you did with Cyrillic fonts, And then you expect within a couple of hours to find a hundred messages on your Mailbox asking for details or providing a fix? Err, the problem was observed on the 18th of May, and I was expecting, since then somebody to try to investigate and fix this since I clearly said I couldn't do it. I have said something about this on the list on the 30th of May. you reported the pb in [1] and the very same day I replied asking for infos you did not provide until the IRC discussion when you unfairly accused Colin. I asked you again to provide the infos and within 12 hours Colin merged ppc stuff from Frans' branch into trunk. You said the problem was still present [2] (and I had to ask you the very same questions again [3]), and at the end it was you using the wrong image. That did piss me off even more and I think such failure reports are all but useful. Are you sure[2]? right, my fault (i'm sure some posts you bamed it on that patch though) If that's your idea of testing things I'd say is not very effective and as a consequence it Takes a long time before problems get fixed. What part of [1] didn't you understand? it's crystal clear. reporting problems the way you did, especially when many ppl are on different arches, does not help at all IMO, but go on that way if you think I'm wrong. I hope your mail does not hide other feelings than your concern for G-I, because I feel that I am not wanted to be doing G-I work. that's your own way of reading my message. I think you did wrong and I told you the reason why I think so without hiding anything; feel free to do whatever you want the way you want. D. [1] http://lists.debian.org/debian-boot/2006/05/msg00906.html [2] http://lists.debian.org/debian-boot/2006/05/msg01290.html [3] http://lists.debian.org/debian-boot/2006/06/msg00048.html signature.asc Description: Digital signature
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On Tue, Jun 20, 2006 at 05:05:39PM +0200, Frans Pop wrote: There is still some discussion about those packages and I reported at least one important needed change a few days ago. yes, we want everything done the right way, so [1] needs to be sorted out AFAIK we have not yet asked the Gnome people to do anything and that seems the smart thing to do until we _know_ the cairo packages are actually good. actually I CCed gnome ppl in [2] but that's definitely not an official call for help. Ciao, Davide [1] http://lists.debian.org/debian-boot/2006/06/msg01036.html [2] http://lists.debian.org/debian-boot/2006/06/msg00687.html signature.asc Description: Digital signature
Bug#361872: debconf-copydb: Trashes debconf database in /target
On Mon, Jun 19, 2006 at 08:57:02PM +0200, Steinar H. Gunderson wrote: After some discussion on IRC, here's the updated patch. One change is needed yet; the current code in debconf-copydb simply turns off i18n support (since the old code couldn't handle that properly, it seems, or perhaps it's even older). Just nuke the setenv() line from debconf-copydb.c and we should be okay. BTW, Joey: There _are_ lots of non-UTF-8 strings out there, it seems -- it's unfortunate, but we can't nuke the support from debconf just yet. :-/ /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#361872: debconf-copydb: Trashes debconf database in /target
(Keeping Steinar in To: in the hope he'll want to try this one as well ;-) On Tuesday 20 June 2006 16:40, you wrote: One change is needed yet; the current code in debconf-copydb simply turns off i18n support (since the old code couldn't handle that properly, it seems, or perhaps it's even older). Just nuke the setenv() line from debconf-copydb.c and we should be okay. Works much better with that removed. You were right though that the database is completely reorganized... After some sed and sort magic, I could verify the contents. The only remaining issue is that after the debconf-copydb all Owners: fields from the original templates.dat in target are lost. Only three templates were added: Name: debian-installer/country Name: debian-installer/keymap Name: debian-installer/language The config.dat looks good too, with the three templates added and a value for passwd/username merged. pgpuCP0to85BE.pgp Description: PGP signature
Re: confirm_changes
On Mon, Jun 19, 2006 at 11:15:54PM +0200, Frans Pop wrote:
On Monday 19 June 2006 22:56, David Härdeman wrote:
currently at least partman-lvm, partman-crypto and partman-md seem to
contain copies of confirm_changes() from partman-base/partman.
They are at least different in that they use some differently named
templates at some points.
I've done a manual pen-and-paper comparison of the four implementations
in partman-{base,md,lvm,crypto}. The results are at
http://www.hardeman.nu/~david/files/patches/debian/confirm_changes_diff.html
Would it perhaps be an idea to move confirm_changes into
/lib/partman/definitions.sh or is there a reason for the duplication?
If that is the only difference though, it should be possible to generalize
that and pass the template (or even only the component name) as a
parameter.
Looking at the above mentioned comparison, there are three differences:
1) The templates used
This can be taken care of with a parameter as you mentioned
2) Additional comments in partman-base
Not relevant
3) Additional detection of previously formatted partitions
Looking at this difference, it seems like a feature that should
be made available in a general version of the function.
I've attached a patch which merges the four implementations into one
while taking the above comments into consideration. The result is a net
reduction of a bit less than 300 lines of code.
diffstat:
partman-base/definitions.sh | 108 +++
partman-base/partman | 107 --
partman-crypto/choose_partition/crypto/do_option | 96
partman-lvm/choose_partition/lvm/do_option | 94
partman-md/choose_partition/md/do_option | 94
5 files changed, 112 insertions(+), 387 deletions(-)
I've done a build and some testing, and it seems to work.
Any objections to committing it?
Regards,
David
Index: partman-base/definitions.sh
===
--- partman-base/definitions.sh (revision 38213)
+++ partman-base/definitions.sh (working copy)
@@ -927,6 +927,114 @@
done
}
+# List the changes that are about to be committed and let the user confirm
first
+confirm_changes () {
+ local template dev x part partitions num id size type fs path name
filesystem partitems items formatted_previously
+ template=$1
+
+ # Compute the changes we are going to do
+ partitems=''
+ items=''
+ for dev in $DEVICES/*; do
+ [ -d $dev ] || continue
+ cd $dev
+
+ open_dialog IS_CHANGED
+ read_line x
+ close_dialog
+ if [ $x = yes ]; then
+ partitems=${partitems} $(humandev $(cat device))
+
+ fi
+
+ partitions=
+ open_dialog PARTITIONS
+ while { read_line num id size type fs path name; [ $id ]; };
do
+ [ $fs != free ] || continue
+ partitions=$partitions $id,$num
+ done
+ close_dialog
+
+ formatted_previously=no
+ for part in $partitions; do
+ id=${part%,*}
+ num=${part#*,}
+ [ -f $id/method -a -f $id/format \
+ -a -f $id/visual_filesystem ] || continue
+ # if no filesystem (e.g. swap) should either be not
+ # formatted or formatted before the method is specified
+ [ -f $id/filesystem -o ! -f $id/formatted \
+ -o $id/formatted -ot $id/method ] || continue
+ # if it is already formatted filesystem it must be
formatted
+ # before the method or filesystem is specified
+ [ ! -f $id/filesystem -o ! -f $id/formatted \
+ -o $id/formatted -ot $id/method \
+ -o $id/formatted -ot $id/filesystem ] ||
+ {
+ formatted_previously=yes
+ continue
+ }
+ filesystem=$(cat $id/visual_filesystem)
+ db_subst partman/text/confirm_item TYPE $filesystem
+ db_subst partman/text/confirm_item PARTITION $num
+ db_subst partman/text/confirm_item DEVICE $(humandev
$(cat device))
+ db_metaget partman/text/confirm_item description
+
+ items=${items} ${RET}
+
+ done
+ done
+
+ if [ $items ]; then
+ db_metaget partman/text/confirm_item_header description
+ items=$RET
+$items
+ fi
+
+ if [ $partitems ]; then
+
Bug#373586: PMac install - probs w/ finish install
I can confirm this problem (finish install doesn't finish the install - just flashes the screen and returns to the main menu) when installing on a PowerMac G4. I saw it when installing directly from the June 12 jigdo DVD. I haven't had a chance to try the June 19th jigdo DVD just yet. Rick On Jun 14, 2006, at 8:06 AM, Jeffrey B. Green wrote: Package: installation-reports INSTALL REPORT Debian-installer-version: 12 Jun 06 - testing (etch) jigdo cd(#1) uname -a: Linux naro 2.6.15-1-powerpc #2 Mon Mar 6 12:39:17 CET 2006 ppc GNU/Linux Date: 13 Jun 06 Method: How did you install? What did you boot off? If network install, from where? Proxied? Booted from the install cd into expert mode; did standard install with manual partitioning of the hard drive. Machine: Apple G4 PowerMac with AGP Processor: 7400, altivec supported Memory: 640MB Root Device: IDE Hard drive (/proc/.../model WDC WD1200BB-00CAA0) Root Size/partition table: Feel free to paste the full partition table, with notes on which partitions are mounted where. Filesystem 1M-blocks Used Available Use% Mounted on /dev/hda7 480 207 248 46% / tmpfs 315 1 315 1% /dev/shm /dev/hda10 20159 16861 2274 89% /home /dev/hda11 40610 27866 10681 73% /nfs /dev/hda8 5040 1886 2899 40% /usr /dev/hda940318 31202 7069 82% /usr/local tmpfs 315 1 315 1% /dev Output of lspci and lspci -n: :00:0b.0 Host bridge: Apple Computer Inc. UniNorth AGP :00:10.0 VGA compatible controller: ATI Technologies Inc Rage 128 PF/PRO AGP 4x TMDS 0001:10:0b.0 Host bridge: Apple Computer Inc. UniNorth PCI 0001:10:0d.0 PCI bridge: Digital Equipment Corporation DECchip 21154 (rev 05) 0001:11:02.0 SCSI storage controller: Adaptec AHA-7850 (rev 03) 0001:11:04.0 VGA compatible controller: ATI Technologies Inc Rage 128 RE/SG 0001:11:07.0 ff00: Apple Computer Inc. KeyLargo Mac I/O (rev 02) 0001:11:08.0 USB Controller: Apple Computer Inc. KeyLargo USB 0001:11:09.0 USB Controller: Apple Computer Inc. KeyLargo USB 0001:11:0a.0 FireWire (IEEE 1394): Texas Instruments TSB12LV23 IEEE-1394 Controller 0002:21:0b.0 Host bridge: Apple Computer Inc. UniNorth Internal PCI 0002:21:0f.0 Ethernet controller: Apple Computer Inc. UniNorth GMAC (Sun GEM) :00:0b.0 0600: 106b:0020 :00:10.0 0300: 1002:5046 0001:10:0b.0 0600: 106b:001f 0001:10:0d.0 0604: 1011:0026 (rev 05) 0001:11:02.0 0100: 9004:5078 (rev 03) 0001:11:04.0 0300: 1002:5245 0001:11:07.0 ff00: 106b:0022 (rev 02) 0001:11:08.0 0c03: 106b:0019 0001:11:09.0 0c03: 106b:0019 0001:11:0a.0 0c00: 104c:8019 0002:21:0b.0 0600: 106b:001e 0002:21:0f.0 0200: 106b:0021 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Create file systems:[O] Mount partitions: [O] Install base system:[O] Install boot loader:[ ] - kept config since I have a sarge install on that machine too Reboot: [E] - The finish installation step just flash a window coming up and then return to the install menu. I had to finish via the abort installation. Comments/Problems: As above, a standard install though I skipped the Debian mirror part since I install packages from loop mounted DVD images (however even when I did specify a mirror, it didn't work...found the Release file but (the installer) tasksel couldn't seem to connect with the mirror). As a sidenote when I later tried to run tasksel after booting into the new system, that failed when it complained about answering yes to some questions when --force-yes wasn't given as an option. The main problem happened at the end with the finish install step. As above it just flashed a window and returned to the menu. (Package related issues) Although I specified shadow passwords, they were not set, probably because of the finish prob above. I did a shadowconf on to get it going. Also the timezone wasn't set...as above. I installed kdm,kde,xorg via dselect. They didn't set a useable video mode for the machine (640x480 I believe). I needed to go in and set the HSync and VRefresh explicitly in the xorg.conf to get a useable display. Also KDE would not initialize sessions. In both a new user and an established user, it would start to initialize the session but then eventually return to the login screen. To get into something I could use, I escaped from the login screen into console mode, logged in root, killed kdm, and then did a startx. However, I
Bug#373594: installation-report: daily snapshot on compaq armada m700
On Wed, 14 Jun 2006 15:13:26 +0200 Marc Haber wrote: Kudos. That installer job is very well done. Thank you, always nice to hear :-) Comments/Problems: Germany is still not present in the list of countries offered in the initial dialog. A lot more obscure countries are. If you select English as language the installer only shows countries that have English as an official language, same for other languages. Before starting the partitioner, system halts for like two minutes on a blank blue screen with the floppy light on That must be during driver loading. Strange that it takes so long. That probably coincided with: Jun 14 12:12:59 kernel: end_request: I/O error, dev fd0, sector 0 Jun 14 12:13:33 kernel: end_request: I/O error, dev fd0, sector 0 Jun 14 12:13:35 main-menu[2115]: DEBUG: resolver (libtextwrap1): package doesn't exist (ignored) Jun 14 12:13:35 main-menu[2115]: INFO: Menu item 'partman-base' selected Jun 14 12:13:36 kernel: JFS: nTxBlock = 4543, nTxLock = 36350 Jun 14 12:13:36 kernel: SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled Jun 14 12:13:36 kernel: SGI XFS Quota Management subsystem Jun 14 12:14:11 kernel: end_request: I/O error, dev fd0, sector 0 Jun 14 12:14:45 kernel: end_request: I/O error, dev fd0, sector 0 Not sure why this is, especially as you actually do have a floppy drive. On most systems this goes quite smoothly. Erase entire disk and use LVM does not make any changes to the partitioning table Was due to an error in new lvm2 package; already fixed. Why is /tmp not a tmpfs on a separate /home, /usr, /var, /tmp layout? Not sure. D-I team: any reactions to that? popcon seems to install even if answer was no, but popularity-contest is purged on the final system. It is being installed when the question is shown as the question is part of the popcon package; it is purged based on the answer. That's a choice made by Joey when he (re)implemented popcon support. IIRC Woody used to leave popcon installed after answering no, but both solutions can be argued. x11-common shows an upgrade warning even if we are not updating but installing anew. That irritates us too: http://bugs.debian.org/372077 After installation, quite a few mailboxes, including Debian-exim, identd and the user created during installation, are created in /var/mail, but with zero size and owned by root, inhibiting mail delivery. That is serious. Looks like a bug in add-user. I get the following myself: -- 1 root mail 0 2006-06-20 13:41 Debian-exim -- 1 root mail 0 2006-06-20 13:55 fjp -- 1 root mail 0 2006-06-20 13:41 identd -- 1 root mail 0 2006-06-20 13:41 statd Note also the lack of permissions on the files... Thanks for your report. pgpgOwYuzD9f9.pgp Description: PGP signature
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On Jun 20, 2006, at 10:06 AM, Viti Davide wrote: Note: I feel much anger in your writing... Yes, your message did piss me off very much indeed. Is it just me? It sure seems like there's a lot of this going around. Chill out folks! We're all in this because we think it's *fun*. If it makes us angry, it's *not* fun. Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confirm_changes
On Tuesday 20 June 2006 20:14, David Härdeman wrote: 2) Additional comments in partman-base Not relevant I'd suggest to keep the comments in the new common version though. Any objections to committing it? No, looks good. The only thing is upload/release timing. Probably the best thing to do is after committing the changes, first upload only partman-base and only after that's been built for all architectures upload the other components (with updated versioned dependency on partman-base and a needs ... comment in the changelog). I've checked that when there is a function in both definitions.sh and the script itself, the version in the script itself will be executed, so having both with the same name temporarily should not be a problem. Thanks. pgp4emJjFdpPx.pgp Description: PGP signature
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On 6/20/06, Davide Viti [EMAIL PROTECTED] wrote: On Tue, Jun 20, 2006 at 05:50:31PM +0300, Eddy Petrişor wrote: following the wiki or using the build script committed in extremadura you should be able to build any of the g-i libs and that is what Sven, Attilio and myself did. Packaging the libraries, requires alot more; I just got the impression you are not confident with none of those (and I really do not mean to offend you anyhow by saying that) On the contrary, I have trust in your, Attilio's and Sven's work. I just want to take this to the next level. I don't think it helps a lot if I do something which has been done before, does it ;-) ? I got no clear response on that matter from gtk/gnome people on the debian channel, and also I have faced some issues that made me believe that having two cairo.so files in two different places could be problematic; indeed I might have been wrong by not carifying that I was talking about _my_ effort. I think it was not appropriate to involve two MLs and Dave to sort out your doubt: cairo has been successfully used to produce working images and that is enough to say it is working. Err, your are missing the point, you and everybody else used only one library the cairo.so which is build against -directfb. I am not sure that in the context of packaging gtk this is fesable because you have to specify the library used for linking ( -lcairo ), and that is provided for the single source package gtk+2.0 by two -dev packages which both have such a library. What I am NOT sure (and that was one of the points of my initial mail) is if this can be done for a package depending on both. You write on d-boot hey, g-I is fucked on ppc as you did with Cyrillic fonts, And then you expect within a couple of hours to find a hundred messages on your Mailbox asking for details or providing a fix? Err, the problem was observed on the 18th of May, and I was expecting, [cut, me saying wrongly that I have reported this the first time on the list on] the 30th of May. you reported the pb in [1] and the very same day I replied asking for infos Yes, you are right I didn't report it first time on the 30th, but still since the 22nd until the 25th still there are not a couple of hours. Read further. you did not provide until the IRC discussion when you unfairly accused Colin. Get your act together, read [1] which was sent on the 23rd. I CC-ed Colin on that in the hope I'll rasie his attention. you asked if I could reproduce [2] and obviousely that was reproducible since the fix came on the 26th. I have done that [3] on the 25th and also provided some screenshots. I asked you again to provide the infos and within 12 hours Colin merged ppc stuff from Frans' branch into trunk. On the 25th @ 21:06+3 when I said that Collin didn't cared about the issue. He himself has acknowledged that he didn't looked at the problem. He moved the build to the trunk on the 26th @ 14:05+1 And he didn't provided an explicit link to the images nor did he updated the links on the wiki. I am not acusing him, is just the information was missing. You said the problem was still present [2] (and I had to ask you the very same At the second round of images when I actually tested a wrong (old) image because of a wrongly setup cron job which couldn't overwrite a file made by the root user. Indeed that was my mistake and I have said that publicly. If I remember correctly I had dowloaded the wrong image by hand because of this lack of info. questions again [3]), and at the end it was you using the wrong image. That did piss me off even more and I think such failure reports are all but useful. Flashnews, nobody's perfect. I acknowldged that was my mistake. I hope you don't have to near somebody digging up dirt from your past to pour it in your head. Especially when you have acknowledged publicly you were wrong. Still I fail to see what does this have to do with my work on the gtk packages. Are you sure[2]? right, my fault (i'm sure some posts you bamed it on that patch though) Can you backup that afirmation? taking into account the omissions before I suspect your memory is cheating on you. I don't remember saying anything about any patch. The touchpad issue was reported by someone else while I had said that the G-I didn't started on ppc suspecting some input problems because of the messages I could see between the crashes. If that's your idea of testing things I'd say is not very effective and as a consequence it Takes a long time before problems get fixed. What part of [1] didn't you understand? it's crystal clear. reporting problems the way you did, especially when many ppl are on different arches, does not help at all IMO, but A lot of hand waving... I said PPC, what does diffrent arches has anything to do this? go on that way if you think I'm wrong. I have said I will try to test the images weekly. I expected somebody else (maybe the officail porter) to do
Re: confirm_changes
Frans Pop [EMAIL PROTECTED] writes: Probably the best thing to do is after committing the changes, first upload only partman-base and only after that's been built for all architectures upload the other components (with updated versioned dependency on partman-base and a needs ... comment in the changelog). If the other components can work with the previous partman-base we don't need to enforce the version, right? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: add patch tag for the submitted patch
Processing commands for [EMAIL PROTECTED]: tags 373629 patch Bug#373629: failed to do autopartitioning completely (tries the cd device :( ) There were no tags set. Tags added: patch thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373629: add patch for get rid of cd device
Hi
I tried to get rid of the cd device to make sure that autopartkit doesn't try
to do partitioning on this read-only device.
I am using the ped_device_destroy() function from libparted, please have a
look and comment, I guess this is a good workaround to exclude the cd device
from the list.
Greetings
Steffen
--- autopartkit.c.orig 2006-06-20 20:53:45.0 +0200
+++ autopartkit.c 2006-06-20 20:57:03.0 +0200
@@ -335,6 +335,12 @@
dev = ped_device_get_next(NULL);
+/* We delete the cd device from the list */
+if (strstr(dev-path, /cd))
+{
+ ped_device_destroy(dev);
+}
+
if (dev == NULL)
{
/* No devices detected */
--- distribute.c.orig 2006-06-20 20:51:16.0 +0200
+++ distribute.c 2006-06-20 20:53:10.0 +0200
@@ -257,6 +257,13 @@
{
assert(dev);
+ /* We delete the cd device from the list */
+ if (strstr(dev-path, /cd))
+ {
+ ped_device_destroy(dev);
+ continue;
+ }
+
autopartkit_log(2, checking dev: %s, sector_size=%d\n,
dev-path,
dev-sector_size /* in bytes */);
pgpxDYxvbrN3n.pgp
Description: PGP signature
Re: [directfb-dev] [g-i]GTK 2.8.18 with directfb support packages [was:Re: [g-i] Graphical installer and PPC systems]
On Tuesday 20 June 2006 21:39, Eddy Petrişor wrote: And he didn't provided an explicit link to the images nor did he updated the links on the wiki. I am not acusing him, is just the information was missing. I think that is reasonable. Colin has not been involved so far and so could not be expected to know to update such things. That is up to the g-i team when they see his message on d-boot announcing that he did the integration. IIRC I at least checked and possibly fixed some of the references later. About an explicit link: as they're part of the daily builds you're kind of expected to know where to find them... pgpo69Aw7EDWF.pgp Description: PGP signature
Re: confirm_changes
On Tuesday 20 June 2006 21:45, Otavio Salvador wrote: If the other components can work with the previous partman-base we don't need to enforce the version, right? The _current_ versions can. But the new versions of the other components cannot work with an old version of partman-base, so we do need to enforce the version. pgp4z9fvTogus.pgp Description: PGP signature
autopartkit vs. partman-auto
Hi As most of you might know the Debian-Edu people are working a bit on the autopartitioning. Therefore we have two ways which we can go. First one would be to choose autopartkit and bring it back into a shape where we can use it for etch. This includes updating the code so that it fits with the new libparted API and works nice. (We don't have a maintainer for it, it just means trying to make it working) Second one would be to go for partman-auto. This way was suggested by most of the d-i people I guess (please feel free to correct me if i am wrong). After the small talk on debian-boot I had a small talk to Petter Reinholdtsen and there I want to quote one or two points (with his agreement): 22:00 pere white: if partman-auto can be fixed to do the things we need, I do not have any reason to keep autopartkit. But that include LVM support, creating ext3 fs with resize_inode option and scaling the partition sizes with the disk size. 22:13 pere adding resize_inode to ext3 file systems seem to require a rewrite of partman-ext3, as it now uses libparted to create ext2, and then tune2fs -j to convert it to ext3. there is no safe way to add the resize_inode option after the file system is created, so the parman module will need to be rewritten to use mke2fs. 22:13 pere there is an unsafe way to add the resize_inode option, using ext2prepare from the ext2resize package. Can you please comment on that? Will partman-auto have the required features? Shall we drop autopartkit from Debian and integrate/implement features into partman-auto or shall we have both and keep autopartkit alive and fix it as good as we can? I am sorry to bother you again with that, but I guess a clear answer to this mail and a discussion via mail thread is in this case better than several IRC discussions. Greetings and thanks in advance Steffen pgp5gV9GtiG4f.pgp Description: PGP signature
Re: confirm_changes
Hi all, On Tue, Jun 20, 2006 at 08:14:09PM +0200, David Härdeman wrote: Looking at the above mentioned comparison, there are three differences: 1) The templates used This can be taken care of with a parameter as you mentioned 1.5) The priorities at which some templates are asked (high vs. critical). One example is $package/confirm_nochanges - it is high in partman-base and -md but critical in -crypto and -lvm. I'm not sure this difference is intentional/meaningful though? 2) Additional comments in partman-base Not relevant 3) Additional detection of previously formatted partitions Looking at this difference, it seems like a feature that should be made available in a general version of the function. I've attached a patch which merges the four implementations into one while taking the above comments into consideration. The result is a net reduction of a bit less than 300 lines of code. Very nice improvement, IMHO. I looked into doing this consolidation some time back and came to the same conclusion with regard to the differences, so you may consider this a +1 on your findings and the patch :-) cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: debconf-copydb troubles mostly resolved; cloning for remaining issue
Processing commands for [EMAIL PROTECTED]: clone 361872 -1 Bug#361872: debconf-copydb: Trashes debconf database in /target Bug 361872 cloned as bug 374710. tag 361872 pending Bug#361872: debconf-copydb: Trashes debconf database in /target Tags were: patch Tags added: pending severity -1 important Bug#374710: debconf-copydb: Trashes debconf database in /target Severity set to `important' from `serious' retitle -1 debconf-copydb: removes Owners: lines from templates.dat in target Bug#374710: debconf-copydb: Trashes debconf database in /target Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374704: marked as done (installation-reports)
Your message dated Tue, 20 Jun 2006 22:12:58 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#374704: installation-reports has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: installation-reports Boot method: Boot from netinst CD Image version: downloaded from the debian-installer page, daily build for amd64 of june 20th, 2006 Date: june 20th, 2006, 21:22 CET Machine: regular PC compatible with MSI K8T Neo motherboard Processor: AMD64 Memory: 512M Partitions: Disk /dev/hda: 20.0 GB, 20020396032 bytes 255 heads, 63 sectors/track, 2434 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/hda1 1 13 1043916 FAT16 /dev/hda2 14243419446682+ f W95 Ext'd (LBA) /dev/hda5 * 14 268 2048256 83 Linux /dev/hda6 269 280 96358+ 83 Linux /dev/hda7 281 311 248976 82 Linux swap / Solaris /dev/hda8 537 566 240943+ 83 Linux /dev/hda9 5671218 5237158+ 8e Linux LVM /dev/hda10 12192434 9767488+ fd Linux raid autodetect Disk /dev/sda: 81.9 GB, 81964302336 bytes 255 heads, 63 sectors/track, 9964 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System /dev/sda1 1 122 979933+ 83 Linux /dev/sda22670996458597087+ 5 Extended /dev/sda526703885 9767488+ 8e Linux LVM /dev/sda63886753229294496 8e Linux LVM /dev/sda775338748 9767488+ 8e Linux LVM /dev/sda887499964 9767488+ fd Linux raid autodetect Output of lspci and lspci -n: :00:00.0 Host bridge: VIA Technologies, Inc. VT8385 [K8T800 AGP] Host Bridge (rev 01) :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] :00:08.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11) :00:08.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11) :00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10) :00:0d.0 RAID bus controller: Promise Technology, Inc. PDC20378 (FastTrak 378/SATA 378) (rev 02) :00:0e.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) :00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration :00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller :00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control :01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) :01:00.1 Display controller: ATI Technologies Inc: Unknown device 5940 (rev 01) :00:00.0 0600: 1106:3188 (rev 01) :00:01.0 0604: 1106:b188 :00:08.0 0400: 109e:036e (rev 11) :00:08.1 0480: 109e:0878 (rev 11) :00:0b.0 0200: 10ec:8169 (rev 10) :00:0d.0 0104: 105a:3373 (rev 02) :00:0e.0 0c00: 1106:3044 (rev 80) :00:0f.0 0104: 1106:3149 (rev 80) :00:0f.1 0101: 1106:0571 (rev 06) :00:10.0 0c03: 1106:3038 (rev 81) :00:10.1 0c03: 1106:3038 (rev 81) :00:10.2 0c03: 1106:3038 (rev 81) :00:10.3 0c03: 1106:3038 (rev 81) :00:10.4 0c03: 1106:3104 (rev 86)
gtk+-directfb packages: call for help
Hi Josselin, Dave Beckett has worked on producing the libcairo packages (with and without directfb backend enabled) and an experimental version is available in [1]. We've tested it and used it for testing a patch which adds the directfb backend to gtk+ 2.8.17/18 (you can get the patch from [2]). There are still a couple of minor issues which need to be sorted out before cairo is ready to be uploaded to the archives (see [3]) and what we still are unsure about is if a libcairo-directfb-dev.deb package should be produced along with the other (u)debs. We think there's everything you need to produce gtk+-directfb packages; it's not officially available yet, but packaging could be done anyway and would help the d-i team to start working on migrating from old libraries to new ones. Your help is thoroughly appreciated, TIA, Davide [1] http://download.dajobe.org/debian/experimental/ [2] http://www.webalice.it/zinosat/gtk+-directfb_2.8.17.patch.gz [3] http://lists.debian.org/debian-boot/2006/06/msg01036.html [4] http://lists.debian.org/debian-boot/2006/06/msg01036.html signature.asc Description: Digital signature
Processed: debconf-copydb troubles mostly resolved; cloning for remaining issue
Processing commands for [EMAIL PROTECTED]: tag 374710 - patch Bug#374710: debconf-copydb: removes Owners: lines from templates.dat in target Tags were: patch Tags removed: patch target Unknown command or malformed arguments to command. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autopartkit vs. partman-auto
Steffen Joeris [EMAIL PROTECTED] writes: 22:13 pere adding resize_inode to ext3 file systems seem to require a rewrite of partman-ext3, as it now uses libparted to create ext2, and then tune2fs -j to convert it to ext3. there is no safe way to add the resize_inode option after the file system is created, so the parman module will need to be rewritten to use mke2fs. 22:13 pere there is an unsafe way to add the resize_inode option, using ext2prepare from the ext2resize package. Unfortunatelly that's true. We started to work on ext3 support for parted and then we won't have this problem anymore but I'm not sure we'll be able to make it in time for etch. 'cause of that I offer my help to fix autopartkit for new parted library and help someone to maintain it while we can't drop it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#131553: is it me you looking for?
Do not ignore me please, I found your email somewhere and now decided to wraite you. I am coming to byour place in few weeks and thought we acan meet each other. Let me bknow if you do not mind. aI am ab naice prebtty girl. Don't reply to this email. Email me direclty at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confirm_changes
On Tue, Jun 20, 2006 at 10:18:37PM +0200, Max Vozeler wrote: On Tue, Jun 20, 2006 at 08:14:09PM +0200, David Härdeman wrote: Looking at the above mentioned comparison, there are three differences: 1) The templates used This can be taken care of with a parameter as you mentioned 1.5) The priorities at which some templates are asked (high vs. critical). One example is $package/confirm_nochanges - it is high in partman-base and -md but critical in -crypto and -lvm. I'm not sure this difference is intentional/meaningful though? Oh yes, good catch. I'm fairly certain that all templates should be asked at the same level, but I'm not sure which level is best. I'll go with what's currently in partman-base/partman unless someone objects. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373594: installation-report: daily snapshot on compaq armada m700
On Tue, Jun 20, 2006 at 08:19:10PM +0200, Frans Pop wrote: On Wed, 14 Jun 2006 15:13:26 +0200 Marc Haber wrote: Before starting the partitioner, system halts for like two minutes on a blank blue screen with the floppy light on That must be during driver loading. Strange that it takes so long. That probably coincided with: Jun 14 12:12:59 kernel: end_request: I/O error, dev fd0, sector 0 Jun 14 12:13:33 kernel: end_request: I/O error, dev fd0, sector 0 Jun 14 12:13:35 main-menu[2115]: DEBUG: resolver (libtextwrap1): package doesn't exist (ignored) Jun 14 12:13:35 main-menu[2115]: INFO: Menu item 'partman-base' selected Jun 14 12:13:36 kernel: JFS: nTxBlock = 4543, nTxLock = 36350 Jun 14 12:13:36 kernel: SGI XFS with ACLs, security attributes, realtime, large block numbers, no debug enabled Jun 14 12:13:36 kernel: SGI XFS Quota Management subsystem Jun 14 12:14:11 kernel: end_request: I/O error, dev fd0, sector 0 Jun 14 12:14:45 kernel: end_request: I/O error, dev fd0, sector 0 Not sure why this is, especially as you actually do have a floppy drive. No, the notebook does not have a floppy drive. It has a floppy LED though. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 72739835 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: confirm_changes
On Tuesday 20 June 2006 23:34, David Härdeman wrote: Oh yes, good catch. I'm fairly certain that all templates should be asked at the same level, but I'm not sure which level is best. I'll go with what's currently in partman-base/partman unless someone objects. confirm_nochanges should probably be critical (especially as it's default is false). pgpQ1usrZ8HsV.pgp Description: PGP signature
Bug#373594: installation-report: daily snapshot on compaq armada m700
On Tuesday 20 June 2006 23:32, Marc Haber wrote: No, the notebook does not have a floppy drive. It has a floppy LED though. Huh? Then how the hell does the kernel manage to make the floppy light light up? I suspect that your hardware does support a floppy device to some extend and that that confuses the kernel, causing it to retry and thus the delay. Probably the laptop supports a floppy unit in the cdrom/2nd_battery bay? I'd say this is a kernel bug. Anyway, something we cannot solve in the installer so if you want to follow up on this, I suggest you do so separately (probably with upstream kernel people). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: notfound 163501 in 1:0.60.4-1.1
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.19 notfound 163501 1:0.60.4-1.1 Bug#163501: busybox: cp -a doesn't copy symlinks Bug marked as not found in version 1:0.60.4-1.1. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: autopartkit vs. partman-auto
On Tuesday 20 June 2006 22:32, Steffen Joeris wrote: 22:00 pere white: if partman-auto can be fixed to do the things we need, I do not have any reason to keep autopartkit. But that include LVM support, creating ext3 fs with resize_inode option and scaling the partition sizes with the disk size. LVM support is production ready, although of course I don't know if the implementation meets with your requirements. The main limitation of partman-auto is that it only works on a single harddisk and thus is not really useable to set up multi-disk systems. For the rest it is quite flexible and can be customized by adding the recipes you need. As for the resize_inode option, Otavio has given you the answer as to libparted status. Realizing an alternative solution in partman would probably mean someone from debian-edu will have to do the work (or find someone) as we don't really have a lead partman maintainer. If you can provide a patch that does not result in important regressions, that would be fine. But I seem to remember from an earlier thread that pere's proposed solution would mean losing the progress bar for ext3 formatting. Cheers, FJP pgp5T9noUV1k6.pgp Description: PGP signature
Bug#153296: hi family
It's a beautiful day today Dear Family, Just wanted to write you, and let you know, how the degree program I tried out went. Well, six weeks later, I graduated, finished received my Ma_sters Degr_ee with no study required and 100 percent verifiable. Yeah mom, I know you and Dad doubted it at first, but this turned out to be totally legit. This opportunity was given to me because of the professional experience and previous course work I had accumulated. I'm so excited mom and dad, this was a life altering opportunity for once in my life I took advantage of it. I already have jobs, that wouldn't have given me a chance before, now they are calling off the hook! This really is a godsend. Tell Susan and Cousin Joey that they better hurry up and call that # I gave them the other day. It's 1_2_0_6-984-4433 in case you forgot. Again these are the %DEGs they offer,B_achelors, Master_s, MBA and/or Doct_orate (PhD) , and the number to call is 1_2_0_6-984-4433 , tell them to leave a brief message with their name, the degree they are interested in and their day and evening phone numbers. They will contact you soon after. Anyway, much love, and tell the rest of the family I said hello! Love, Fuller family Sincerely -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#201252: chris said he is pissed at you
How are you, If you are like most people, you are more than qual.ified with your experience, but you are lacking that prest.igious piece of paper known as a D.IPLOMA that is often the passport to success.. Call us today. 1.2.0.6-984-4433 24 hours a day, 7 days a week including Sundays and Holidays Look Foward to Hearing From You Were those science teachers missing walking a few days ago?. Don't those singers dislike playing carelessly?. That photographer isn't enjoying fighting.. Did those bus drivers regret singing?. Donna's daughter hasn't practiced playing yet.. Mr. Hanson isn't practicing working.. I was missing jumping.. Doesn't Kate's granddaughter miss shaving for a few months?. 1. 6. Have you missed reading recently?. I am enjoying eating in the river.. THE PARENT arrived back on the scene. She gave me a tape by Dr. Laura Meyers from UCLA. I listened to that tape eight times. I listened over and over and heard the same thing again and again. Ms. Meyers said, 'These kids may need to hear a word many times (perhaps 72 times) before they ever say a word. A computer can be patient and say it the same way every time.' Now I understood. I was not patient enough. I did not allow the student to hear the words over and over. I was interrupting their learning by interjecting, when they were totally engrossed in what they were doing. I was asking questions they were not ready to answer. They were just learning language. They didn't have the answers yet.. 8. I don't practice reading once a week.. Did Roy love working on the top of the mountain?. Thank you, Josef Boyer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
