Re: Proposal for integration of the graphical installer
On Sunday 14 May 2006 11:44, Geert Stappers wrote: Keep the current d-i images as they exist and add extra images for g-i. That would lead to an explosion of the number of images though which is not what we or the debian-cd team wants. The full CD will most likely match the netinst-gui.iso. Will they both allow an 'install' or is it only 'install-gui'? Yes. Updated with a request for the daily-build script. No need. There is nothing image-specific in that script. pgprmwcQf7QUQ.pgp Description: PGP signature
Re: Proposal for integration of the graphical installer
On Sunday 14 May 2006 12:18, Sven Luther wrote: It is usefull to keep those images relatively small, but given their current size, growing from 250 to 300 MB or whatever it is, will probably pass un-noticed. Right. That issue does not really apply to ppc as, as you say, the businesscard and netinst images are a lot bigger anyway than on i386. So, i would vote for always including the g-i images onto the business card, netinst and cd isos, with the same caveat as on i386 concerning the installable tasks of CD 1. DVD medias should be un-problematic though. Well, IIRC for ppc the desktop task did not fit on CD1 when Sarge was released. Not sure if that has changed or not, but I doubt it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On Tue, May 16, 2006 at 07:34:27AM +0200, Frans Pop wrote: On Monday 15 May 2006 23:40, Sven Luther wrote: That said, another important point is, will we be using a separate gtk-dfb 2.9/2.10 package set, or will we be using the main gtk debian package ? In this second case, are the gtk-gnome folk ready to move to gtk 2.10 for etch ? I'd hope we can use the main gtk debian package. Eh, if you want to do gtk-dfb, you can't. The choice between using the DirectFB backend or the X11 backend has to be done at compile time. Or am I missing something? -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for integration of the graphical installer
On Monday 15 May 2006 15:32, Davide Viti wrote: I did one hour ago or so and it booted fine Hmm. I'm guessing that you've tried the mini.iso, and not one of the larger images as they indeed were completely broken. Will hopefully be fixed with the next build. pgpmBoqIwYQSc.pgp Description: PGP signature
Re: Proposal for integration of the graphical installer
On Monday 15 May 2006 14:33, Sven Luther wrote: (and we can't probably change it without another 6+ month flamewar with Ethan Benson), This comment was unnecessary. Please keep old gripes out of mailing list discussions. Especially as everybody is already aware of them. For all those reasons, i would build the netboot g-i images, it costs not much to build them, and since they are not going to be included on the isos ... I will leave the decision on whether or not to include netboot images to Colin. Technically it's not a problem. pgp4qFle3Dy0M.pgp Description: PGP signature
Re: graphics or text as default?
On Tue, May 16, 2006 at 07:34:27AM +0200, Frans Pop wrote: That said, another important point is, will we be using a separate gtk-dfb 2.9/2.10 package set, or will we be using the main gtk debian package ? In this second case, are the gtk-gnome folk ready to move to gtk 2.10 for etch ? I'd hope we can use the main gtk debian package. I have no idea if the Gnome packagers are ready or not or if they are even considering packaging 2.10 for Etch given the release planning and the upcoming freeze. Especially since AFAICT 2.10 has not yet been released... It would be very nice if g-i could use udebs produced along with the main gtk package. AFAIK gtk+ 2.10 should be ready sometimes in May 2006 (see [1]): 2.10 – GTK+ 2.10 is planned to be released around May 2006. Possible features include printing support and better introspection. As said before, the best we can do is try and come up with an unofficial udeb based on some CVS snapshot (maybe working together on an Alioth repository), and see what happens: if 2.10 will be out in time, the udeb can be used to give support to gtk debian packagers (in case they needed any: compilation flags come to my mind); if 2.10 delays too long and we're ready with our udeb, we can decide to use our 2.9.x package (it wouldn't be too different than using the 2.0.9 as far as alignement with upstream is concerned). I don't think Denis or Mike would be disappointed if g-i were still based on 2.0.9 since it's obvious that we've done the best we could, given the weird situation of libraries we are stuck with: OTOH we cannot actively contribute to their work which is now based on the developement of the very latest versions of the libs, and this would be a pity both for them and for us. ciao, Davide [1] http://www.gtk.org/plan/ signature.asc Description: Digital signature
Re: partman-crypto: dm-crypt status update
On Sunday 14 May 2006 21:59, David Härdeman wrote: The only known bug so far is that the /target filesystem isn't cleanly unmounted when it's on an encrypted partition. Any suggestions on where to start looking? Well, the installer just runs 'umount -a' in prebaseconfig's [1] 95umount script. I'd suggest you check that is actually where the error happens by adding a 'set -x' and maybe 'mount 2' before and after the umount to see what's happening. It may be a busybox issue. [1] Just renamed to finish-install in SVN. pgpvDdchgZxvR.pgp Description: PGP signature
Re: powerpc daily sid_d-i CD builds working again
On Tue, May 16, 2006 at 12:17:10AM +0200, Yves-Alexis Perez wrote: On Mon, 2006-05-15 at 23:53 +0200, Sven Luther wrote: On Mon, May 15, 2006 at 04:01:17PM +0200, Yves-Alexis Perez wrote: On Mon, 2006-05-15 at 15:28 +0200, Sven Luther wrote: What framebuffer is used ? atyfb probably ? I don't really know. I used video=ofonly but it doesnt help. I can login on terminal 4, and it seems that there are no fb module (at least find /lib/module/2.6.16-powerpc-1 -name '*fb*' outputs nothing. I have a /dev/fb0 What does dmesg say, and also what is the content of /proc/fb. My powerbook says : $ more /proc/fb 0 ATI Radeon Lf 0 OFfb ATY,264LTP 1 OFfb ATY,264LTP Ok, this is atyfb, and you probably have a rage something chip in there. I wonder about the two fbdevs, but i suppose this is one for the external port, and one for the LCD panel. Do you per chance have an external monitor connected ? I believe that this one is builtin in the kernel, it used to be at least. Can you check that ? Basically, there is two possibilities of it failing : 1) the framebuffer device is not builtin, and cannot be found as module. how can I check I check if framebuffer is builtin ? Read the dmesg output, and see what it says. Check /proc/fb too. Check the .config file. dmesg says nothing about framebuffer. The .config is the one used when generating powerpc gtk installer, don't know where to find it. Ok. Or alternatively give us the lspci output corresponding to your graphic card, and the kernel version used, and i will investigate for you. Linux 2.6.16-1-powerpc lspci isn't very verbose at the moment because there are only unknown devices. Try lspci -n. I'll reinstall a debian on it without the gtk installer to have those informations. Nope, everything should be found with the gtk-installer too. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: PowerPC request for help
On Mon, May 15, 2006 at 07:29:39PM -0400, Daniel Dickinson wrote: On Thu, 11 May 2006 22:28:39 +0200 Frans Pop [EMAIL PROTECTED] wrote: [ ... ] If you would like commit access to the d-i SVN repository, please let us know your alioth account name. alioth is http://alioth.debian.org I don't have an alioth account, and, to be honest, I'd rather vet my patches, at least at first. Either that, or have a separate branch that only gets merged to trunk after confirmation by an actual d-i person. The d-i team has the convention to put branches under 'people', you are welcome to create a branches yourself. See http://svn.debian.org/wsvn/d-i/people/?rev=0sc=0 for allready existing branches. ( I hope this makes you less shy ) Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On Tuesday 16 May 2006 08:11, Wouter Verhelst wrote: Eh, if you want to do gtk-dfb, you can't. The choice between using the DirectFB backend or the X11 backend has to be done at compile time. Or am I missing something? No, you're not. This is an issue and it's going to take some advanced library packaging knowledge to figure it out. However, I do know that it is possible set up the build system to compile the udeb with a different config than the debs. The question is if you can do that based on the regular lib and lib-dev packages. I do not currently have the answers, but hope that the Gnome team or the collective Debian brain will come up with the correct solution. I would prefer to have the Gnome team take the lead in this though as they will hopefully maintain the packages. IMO moment of the upstream release is early enough to start this discussion with them. pgpemrhzIzyHv.pgp Description: PGP signature
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 08:05:08AM +0200, Frans Pop wrote: On Sunday 14 May 2006 11:44, Geert Stappers wrote: Keep the current d-i images as they exist and add extra images for g-i. That would lead to an explosion of the number of images though which is not what we or the debian-cd team wants. I don't know about the i386 situationin detail, but it is probable that there, machines with low-mem situations will need the normal installer over the g-i one. I know i was not able to boot g-i on my PReP box for example, and given yaboot 6MB netbooting limit ... That said, now that yaboot is orphaned, maybe a new maintainer will show up wuth the guts to stand up to Ethan on this. Already the fedora core guys threatened to fork yaboot away from him in order to get development done, so he could be a bit more malleable maybe. Colin, can you comment on this, as you are the most likely candidate for a yaboot takeover. Frioendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for integration of the graphical installer
On 5/16/06, Frans Pop [EMAIL PROTECTED] wrote: For all those reasons, i would build the netboot g-i images, it costs not much to build them, and since they are not going to be included on the isos ... I will leave the decision on whether or not to include netboot images to Colin. Technically it's not a problem. Please keep in mind that the smaller the image is, the higher the chances for an image to be used in case of an expensive connection, or in some cases, a smaller image will be p[refered just because the download is faster. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 08:09:36AM +0200, Frans Pop wrote: On Sunday 14 May 2006 12:18, Sven Luther wrote: It is usefull to keep those images relatively small, but given their current size, growing from 250 to 300 MB or whatever it is, will probably pass un-noticed. Right. That issue does not really apply to ppc as, as you say, the businesscard and netinst images are a lot bigger anyway than on i386. So, i would vote for always including the g-i images onto the business card, netinst and cd isos, with the same caveat as on i386 concerning the installable tasks of CD 1. DVD medias should be un-problematic though. Well, IIRC for ppc the desktop task did not fit on CD1 when Sarge was released. Not sure if that has changed or not, but I doubt it. Well, splitting the desktop task to install only gnome or only KDE, as i remeùber it did, may help here. I imagine we could have all of the gnome stuff on CD1, and all pf the KDE stuff on CD2, with maybe a copy of d-i on CD2, which would default to the KDE desktop. Maybe only the main 32bit image though. powrmacs are much more likely to have DVD drives than PC machines, so maybe a reduced-size DVD iso with all the .debs needed for the main tasks only would be of interest. This one could even include a debianized version of the ubuntu live images. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 01:11:12AM +0300, Eddy Petrişor wrote: So, will you disable them, or should I try to test your images, too ? (it seems to me that there shouldn't be differences, but you'll never know :) There shouldn't be a difference, but if you have time, it doesn't cost anything to try it out. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 08:12:04AM +0200, Frans Pop wrote: On Monday 15 May 2006 15:32, Davide Viti wrote: I did one hour ago or so and it booted fine Hmm. I'm guessing that you've tried the mini.iso, and not one of the larger images as they indeed were completely broken. Will hopefully be fixed with the next build. You're right: sorry. Davide signature.asc Description: Digital signature
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 12:24:55AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 00:11, Eddy Petrişor wrote: So, will you disable them, or should I try to test your images, too ? (it seems to me that there shouldn't be differences, but you'll never know :) They should preferably be disabled. Having images from one source is enough and we'll anyway have the builds integrated into the main build system soon. Seems fine to me, i will disable them once that is done, and maybe start building some gtk 2.9+ or other kind of experimental images then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 08:17:42AM +0200, Frans Pop wrote: On Monday 15 May 2006 14:33, Sven Luther wrote: (and we can't probably change it without another 6+ month flamewar with Ethan Benson), This comment was unnecessary. Please keep old gripes out of mailing list discussions. Especially as everybody is already aware of them. No, it was not. It is a reality, believe me. The interaction with Ethan is problematic, to the point that the fedora core guys threatened to forcibly take over yaboot, and the original yaboot author commented to be disapointed on how Ethan managed yaboot when he took it over from him. And it is not an old gripe, just a fact, that has to be kept in mind if we are going to think about g-i netbooting, which means right now using a patched yaboot. If Colion takes over yaboot, i have hope that we may decide to integrate a couple of the fedora cores patch, and maybe either make the netboot limit bigger, or do something smarter with regard to memory allocation. I have fixed the pegasos firmware to support yaboot (not released yet), so i could provide the necessary upstream-level patch for this, provided the fedora-core guys have not done so already. For all those reasons, i would build the netboot g-i images, it costs not much to build them, and since they are not going to be included on the isos ... I will leave the decision on whether or not to include netboot images to Colin. Technically it's not a problem. They should be built, but not included on the isos, to use clear terms :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 08:33:09AM +0200, Sven Luther wrote: On Tue, May 16, 2006 at 08:05:08AM +0200, Frans Pop wrote: On Sunday 14 May 2006 11:44, Geert Stappers wrote: Keep the current d-i images as they exist and add extra images for g-i. That would lead to an explosion of the number of images though which is not what we or the debian-cd team wants. We all want [1] a graphical installer in addition to the current installer. That means there are additional images. The increase in numbers is less then the double[2] of the current amount. I don't know about the i386 situationin detail, but it is probable that there, machines with low-mem situations will need the normal installer over the g-i one. I know i was not able to boot g-i on my PReP box for example, and given yaboot 6MB netbooting limit ... Fool^WFull switch to g-i will kill serial line and ssh installs. Cheers Geert Stappers [1] Some want g-i more than others want it [2] e.g. lowmem-gui wouldn't make sense, surely not an explosion -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 07:34:27AM +0200, Frans Pop wrote: On Monday 15 May 2006 23:40, Sven Luther wrote: Another aspect not to forget about this too. We have made considerable effort to bring the directfb code to gtk 2.9+. We have involved external folk outside of d-i to help us and make this happen (I am thinking of Dennis and Mike in particular here, but there may be others), and if we are going to end not using it in etch after all, this may not be good for motivation for finding help the next time we need it. I agree, but we cannot really do very much unless upstream actually releases the versions into which directfb was merged and those versions are packaged for Debian. Alternatives have been discussed several times already. This is where release management and planning comes in. It is more important to know, not how the situation is today, but what it will be at freeze time and at release time. But the decision we take today, will influence that. If we decide that 2.9+ and 2.10 is the way to go for etch, then we should be pro-active for this, and start experimenting, and even making them the default NOW. So we can discover any bugs and other problems, and have time to fix them. At this point, and with the freeze a bit over two month away, inaction stands very much aking to deciding on 2.0.x, which is something important members of our g-i team have said is sub-optimal. So, we have to take a decision on which way we want to go, and then make it the default, and push all our forces into making it happen, maybe even going for help wiht upstream again if needed. That said, another important point is, will we be using a separate gtk-dfb 2.9/2.10 package set, or will we be using the main gtk debian package ? In this second case, are the gtk-gnome folk ready to move to gtk 2.10 for etch ? I'd hope we can use the main gtk debian package. I have no idea if the Gnome packagers are ready or not or if they are even considering packaging 2.10 for Etch given the release planning and the upcoming freeze. Especially since AFAICT 2.10 has not yet been released... It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. If they decide to not go with 2.10 for etch, then having a random 2.9 snapshot or a final 2.10 package just for us would be no worse than the current 2.0.x packages that we have today. We have to take a decision now, again, waiting will only default the decision to the status quo, since the time for such changes and good experimenting of it will become more sparse as we near the freeze. Especially as the d-i freeze is maybe unnecessarily early in the freeze schedule. It is no more time for Waiting, but time for Action, so let's decide and act. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On 5/16/06, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 16 May 2006 08:11, Wouter Verhelst wrote: Eh, if you want to do gtk-dfb, you can't. The choice between using the DirectFB backend or the X11 backend has to be done at compile time. Or am I missing something? No, you're not. This is an issue and it's going to take some advanced library packaging knowledge to figure it out. I am not sure if the scale of the changes needed for the backend to be changed is not big enough to make it unreasonably difficult to maintain such a behemoth. It is indeed possible to have different behaviours if one builds an udeb or one builds a regular deb (Marco has done this for the ppp source package), but the rules files will look, IMHO, like a merge of two rules files which have little in common. However, I do know that it is possible set up the build system to compile the udeb with a different config than the debs. If the gtk configuration script is smart enough, it should allow this, but I am not sure if the lib-dev and the lib packagages which are depends are not conflictive, so that would make it impossible for a single source package to generate debs (based on X11) and udebs (based on DFB) I do not currently have the answers, but hope that the Gnome team or the collective Debian brain will come up with the correct solution. I would prefer to have the Gnome team take the lead in this though as they will hopefully maintain the packages. My HO is that is not worth the effort to keep everything in a common package, though the gtk udeb being maintained by the GNOME team + somebody from the d-i team should be the best solution. IMO moment of the upstream release is early enough to start this discussion with them. Why are you hanging always on the idea that we should use released versions? For testing and (in some cases) for the final product a CVS snapshot is more than good. We need testing if we desire the G-I to be ready for etch, I think you agree, don't you? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: kernel installer issues discussion at debconf
On Tue, May 16, 2006 at 06:11:53AM +0200, Andreas Barth wrote: Hi, I just want to point out that we have at Tuesday, 10.05 in the Hacklab the stable release BoF, which will give us a chance to discuss that topic. (Thanks to Frans for pointing out how usefull such a pointer would be. :) At what time will it be, and will there be a life-participation chance for remote folk who where not able to attend debconf ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On Tuesday 16 May 2006 09:40, Eddy Petrişor wrote: Why are you hanging always on the idea that we should use released versions? For testing and (in some cases) for the final product a CVS snapshot is more than good. We need testing if we desire the G-I to be ready for etch, I think you agree, don't you? I have no problem with unofficial builds for testing as Attilio has been doing. I even don't have any problems with creating udebs _outside_ the archive that can be used using localudebs. The only thing I have always objected to (and until now the arguments have always been shared by others) is the suggestion to upload any CVS packages into the Debian archive as they would conflict with official packages. pgpeavugZFKRC.pgp Description: PGP signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tuesday 16 May 2006 09:37, you wrote: I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Thank you for this quick and sane reply. pgpicDYPrUyAW.pgp Description: PGP signature
Re: powerpc daily sid_d-i CD builds working again
On Tue, 2006-05-16 at 08:23 +0200, Sven Luther wrote: On Tue, May 16, 2006 at 12:17:10AM +0200, Yves-Alexis Perez wrote: 0 OFfb ATY,264LTP 1 OFfb ATY,264LTP Ok, this is atyfb, and you probably have a rage something chip in there. I wonder about the two fbdevs, but i suppose this is one for the external port, and one for the LCD panel. Do you per chance have an external monitor connected ? No, but I can connect one if needed. dmesg says nothing about framebuffer. The .config is the one used when generating powerpc gtk installer, don't know where to find it. Ok. But syslog does. See http://heracles.corsac.net/~corsac/hydra/syslog Jan 1 00:02:32 kernel: atyfb: using auxiliary register aperture Jan 1 00:02:32 kernel: atyfb: 3D RAGE LT PRO (Mach64 LI, PCI) [0x4c49 rev 0xdc] Jan 1 00:02:32 kernel: atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK Jan 1 00:02:32 kernel: atyfb: monitor sense=62b, mode 6 Jan 1 00:02:32 kernel: Console: switching to colour frame buffer device 128x48 Jan 1 00:02:32 kernel: atyfb: fb0: ATY Mach64 frame buffer device on PCI Or alternatively give us the lspci output corresponding to your graphic card, and the kernel version used, and i will investigate for you. Linux 2.6.16-1-powerpc lspci isn't very verbose at the moment because there are only unknown devices. Try lspci -n. http://heracles.corsac.net/~corsac/hydra/lspci -- Yves-Alexis Perez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On 5/16/06, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 16 May 2006 09:40, Eddy Petrişor wrote: Why are you hanging always on the idea that we should use released versions? For testing and (in some cases) for the final product a CVS snapshot is more than good. We need testing if we desire the G-I to be ready for etch, I think you agree, don't you? I have no problem with unofficial builds for testing as Attilio has been doing. I even don't have any problems with creating udebs _outside_ the archive that can be used using localudebs. The only thing I have always objected to (and until now the arguments have always been shared by others) is the suggestion to upload any CVS packages into the Debian archive as they would conflict with official packages. I have addressed the concerns regading this point since the minimeeting held some time ago[1] by proposing a solution that would not interfere with the present packages. [1] http://people.debian.org/~bubulle/d-i/irc-meeting-20060405/log -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: powerpc daily sid_d-i CD builds working again
On Tue, May 16, 2006 at 09:53:53AM +0200, Yves-Alexis Perez wrote: On Tue, 2006-05-16 at 08:23 +0200, Sven Luther wrote: On Tue, May 16, 2006 at 12:17:10AM +0200, Yves-Alexis Perez wrote: 0 OFfb ATY,264LTP 1 OFfb ATY,264LTP Ok, this is atyfb, and you probably have a rage something chip in there. I wonder about the two fbdevs, but i suppose this is one for the external port, and one for the LCD panel. Do you per chance have an external monitor connected ? No, but I can connect one if needed. dmesg says nothing about framebuffer. The .config is the one used when generating powerpc gtk installer, don't know where to find it. Ok. But syslog does. See http://heracles.corsac.net/~corsac/hydra/syslog Jan 1 00:02:32 kernel: atyfb: using auxiliary register aperture Jan 1 00:02:32 kernel: atyfb: 3D RAGE LT PRO (Mach64 LI, PCI) [0x4c49 rev 0xdc] Jan 1 00:02:32 kernel: atyfb: 8M SDRAM (1:1), 29.498928 MHz XTAL, 230 MHz PLL, 100 Mhz MCLK, 100 MHz XCLK Jan 1 00:02:32 kernel: atyfb: monitor sense=62b, mode 6 Jan 1 00:02:32 kernel: Console: switching to colour frame buffer device 128x48 Jan 1 00:02:32 kernel: atyfb: fb0: ATY Mach64 frame buffer device on PCI Ok. My diagnostic here, is that g-i makes some assumptions that are wrong on powerpc. Most probably it tries to load the vesafb module, but since the above is builtin in the powerpc kernel, that test fails, obviously. Furthermore, vesafb is a x86-only thingy. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On Tuesday 16 May 2006 09:59, Eddy Petrişor wrote: I have addressed the concerns regading this point since the minimeeting held some time ago[1] by proposing a solution that would not interfere with the present packages. See the reply by the Gnome maintainer for why this is not an option. pgpUptCHnsqCh.pgp Description: PGP signature
Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices
[EMAIL PROTECTED] wrote: Yes. I already explained this multiple times. An IP address is not *needed* on the ethernet interface, but always configuring one is simpler and may prevent problems later. If I am going to do that on the connection from my provider, I will have my contract termitated in a second because I am not allowed to use other IPs in their network than the ones given by thier servers, and believe me, there is NO configuration given for the ethernet card. You are supposed to use a private IP address then. Or ifconfig ethX up with no IP, as in my case, so AFAICT, the postinst should detect if an Ethernet card is up, and if it is, try to probe for a concentrator. If the card is not yet up with an IP, the ppp-udeb.postinst script should just up it, wiithout an IP. At least that's how it seems logical to me. But it's not. I already explained how this should be implemented. You do not *need* an IP address on the interface but *should* have one. And as you noticed, always configuring it is simpler. No, I *have* observed that an ifconfig ethX up which will result in a interface which is up, but has no IP, is enough for the probing to happen correctly. Which is what I wrote. So the question remains, how does one determine which interfaces were brought up by the ppp-udeb script (probably simple, as they might be ones with no IP set) and which are they associated to (more difficult for multiple ppp connections)? Bonus points for the association in subsequent runs of the postinst. I do not understand what you mean. I tested an installation and: 1) the ppp related stuff was not installed by default It is supposed to be. by whom? d-i. 2) the configuration of pppoe on the target system was not the same as the one in the d-i envronment. I do not know what this means, but the d-i configuration will work in the installed system as well. The question is still who will put the configuration there, in the target system?. Yet another script. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tuesday 16 May 2006 09:09, Sven Luther wrote: It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. You have just managed to loose any credit you had started building again by being reasonable in the discussions over the last few days. If this is the way you will behave, I _will_ get you banned from the debian-boot list. I will now officially start ignoring _any_ mails you send unless it threatens to interfere with d-i work. Bye. P.S. Gnome packagers: please ignore the message sent by Sven. pgpKxZJzfgXgS.pgp Description: PGP signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 09:37:36AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 09:09 +0200, Sven Luther a écrit : If we decide that 2.9+ and 2.10 is the way to go for etch, then we should be pro-active for this, and start experimenting, and even making them the default NOW. GTK 2.9 is GNOME 2.16 material, lot of packages Depends on GTK and making a start of unstable cycle version the default is not a good idea Ok, this is what i was afraid of. It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. First tarball are due during may (ie: 2.9.n), not 2.10 Ah, i thought the 2.9 ones where already available. If they decide to not go with 2.10 for etch, then having a random 2.9 snapshot or a final 2.10 package just for us would be no worse than the current 2.0.x packages that we have today. I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Ah, this was in the context of a gtk-dfb only package, and many of the g-i team are arguing that a development 2.9 snapshot is preferable than the unmaintained upstream 2.0.x stuff we are using now. So, basically, this means we will be forced to maintain our own gtk-dfb libs for the etch timeframe, unless there is some serious slip for the etch release, and we have the choice of keeping the 2.0.x gtk-dfb .udebs and using some out of the devel CVS. Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 09:48:30AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 09:09, Sven Luther wrote: It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. Huh ? Whyever not ? Frans, you are backsliding in the bash-sven modus again. You have just managed to loose any credit you had started building again by being reasonable in the discussions over the last few days. If this is the way you will behave, I _will_ get you banned from the debian-boot list. Please tell me what harm i have done. both attilio and davide and eddy seem to be in favour of 2.9+ .udebs, i did nothing but to get firm information outr of the gtk/gnome folk, so we have strong basis for this discussion. How could this ever be seen as hurting d-i or being a problem ? I will now officially start ignoring _any_ mails you send unless it threatens to interfere with d-i work. Well, maybe, but i don't understand why. You are over-reacting in this. Gnome packagers: please ignore the message sent by Sven. More anti-sven vendeta, thanksfully Sebastien already gave the information that was needed. Frans, we are discussing, this is an important issue, can you not put your pride or whatever aside, and let everyone discuss this ? I didn't a single time insult you or use other kind of bad behavior, and i believe my mail was both technically good and interesting to all involved, so what is it you are having a problem with ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On Tue, May 16, 2006 at 10:07:46AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 09:59, Eddy Petrişor wrote: I have addressed the concerns regading this point since the minimeeting held some time ago[1] by proposing a solution that would not interfere with the present packages. See the reply by the Gnome maintainer for why this is not an option. Except that the gnome maintainer spoke about this with regard to having a single 2.10 package in debian, and not a gtk-dfb snapshot. I should have been more clear in my email, probably. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On Tue, May 16, 2006 at 08:36:56AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 08:11, Wouter Verhelst wrote: Eh, if you want to do gtk-dfb, you can't. The choice between using the DirectFB backend or the X11 backend has to be done at compile time. Or am I missing something? No, you're not. This is an issue and it's going to take some advanced library packaging knowledge to figure it out. However, I do know that it is possible set up the build system to compile the udeb with a different config than the debs. The question is if you can do that based on the regular lib and lib-dev packages. My point really was that it's silly to drop the graphical installer as a target for Etch if you need to compile differently for gtk-dfb anyway; so if the regular gtk2 packages aren't at the correct version, having a different gtk2 source package which compiles the .udeb (and nothing more--unless you need some -dev packages to be able to build the installer image) would seem to be the obvious solution. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: The powerpc port should be removed from etch release candidates ...]
Hi Frans, (I am answering this email in the same group, as it also addresses some of the problems of various mailinglists and has its home on debian-powerpc.) On Thu, May 11, 2006 at 06:22:29PM +0200, Frans Pop wrote: On Monday 08 May 2006 11:18, you wrote: it was brought to my attention that you are not reading debian-powerpc, thus I am forwarding my email to you directly. That is correct, mainly as I do not have a powerpc system myself. For being a very important list to powerpc users, it was underinformed about the incident. b) The social and personal side is important. Sven's emails are clearly showing this, but some of the responses by Thomas and others did not reflect this. Yes, but Sven's emails are also only showing one side of the issue. It is only natural that Sven's emails show his side which I have considered before answering. Still others answered with technical arguments only, which stroke me as strange. My point in general is, that this is not a nice way to treat a volunteer and does the organisation no good, no matter how bad a volunteer might have behaved. I have not replied to the various threads because I have no interest in prolonging this discussion. Best to avoid a long discussion is to have a clear and understandable statement you can point people to. To me not having this from the start clearly has prolonged the discussion. The second reason was that there was a mediation going on by the DPL and his second in command and I did not want to interfere in that. This is a good reason to hold communication for a while. I am bit astonished by the result of the mediation, though, as there obviously was no agreement between made between the parties. That is sad. My part is: Writing this comment to help the situation. I am also speaking up to support Sven. I believe that he was bit badly treated in the thread. No matter what he did to contribute to the situation, this list has people which are new to the problem. Well, I'm afraid we disagree there and I don't feel that someone who has not followed all that's happened over the last year on the various lists and IRC channels (mostly d-boot and d-kernel, but elsewhere as well) can really judge the rights and wrongs here. As I have stated earlier: I have only read debian-powerpc and been working from this. As there will be other people doing so, Sven, just like anybody, deserves a fair treatment to this audience, which cannot know what has happened on other channels. Also, this is not really about right or wrong, but about having some fun while working on Debian in general and the installer in particular. Having fun is very important when it comes to a volunteer based project and I'm afraid that Sven was reducing the fun for several core members of the d-i team in a way that has become unacceptable. Giving an understandable examples in a statement for this, would be fair treatment. This would be a step after personal communication to try to improve the situation has failed. Assuming that Sven had the distressing personal situation he wrote about, there should be enough base to make a new attempt and forgive some of the heat. To me it still actually looks like this was used to Sven's disadvantage which I would not have happen to me on a general basis. But that is beside the point, if you and the other core members of the d-i team are not willing to do this, no one can force you. What could have been done better? If Sven's commit rights have been revoked and he got kicked out, it would be very good to give a reasonable explanation that people can be point people to. The usage of the phrase kicked by Sven, seems to indicate that there was no common position why he left the d-i team. Kicking out Sven from the d-i team had already been discussed twice this year. Eventually we did not have to kick him out as Sven himself resigned from the team. If the personal situation Sven write about is true, you cannot really count the resignation. We (I) revoked his commit access mainly because of the broken personal relationships between Sven and other members of the d-i team. IMO it is not good that someone who is not friendly towards a team has commit access to their source repository. In the long run that will only lead to new conflicts. It is much better to have a clean break and maybe resume a normal working relation later on when things have calmed down and people are willing to work together again. I agree with the clean break, if both conflicting parties agree to it. Note that it is just as easy to grant commit access as it is to revoke it and I do not exclude the possibility that Sven will be allowed commit access again in the future. There will have to be major changes in his attitude for that to happen though. I am assuming that Sven knows those criticism of him. And my hope is there is a good
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 16 May 2006 09:37, you wrote: I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Thank you for this quick and sane reply. Please consider that the GNOME guys might have answered in the light of _all_ the features and _all_ the bugs that might be present at this point in the current gtk, BUT the G-I need just a *tiny* piece of functionality of the whole GTK libraries (Attilio can give you a hint on which parts are actually used). (Just to give a scale of what we are talking about, not even the standard OK and cancel buttons are used in G-I.) Taking into account that, IMHO, it would make sense to have a different source package for the G-I suff (mainly because of the DFB backend and packaging issues that may occur), would you, the GNOME team, consider to state your oppinion on such a decision of using a CVS/2.9+ snapshot _just_ for the G-I stuff? I think this is a huge difference and many of the concerns you might have would not apply to this given situation. Attilio could you please summarize what is actualy used in G-I so that the GNOME guys can say what they think for this particular case? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 10:07:45AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 09:50 +0200, Sven Luther a écrit : Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. I don't intend to package GTK 2.9 right now, no. The new version change its ABI version as described by the announcement mail: ... * GtkFileChooser: - Communication with backends is now asynchronous to avoid blocking on filesystem operations. Due to the required interface changes, the GTK+ ABI version has been bumped to 2.10.0. Third-party filesystem backends have to be ported to the new interface, other modules, such as theme engines, input method modules or pixbuf loaders have to be rebuilt so that they are installed in the right place for GTK+ to find them. ... We have enough work with GNOME 2.14 at the moment and the ported to the new interface part means it requires to go with libgnomeui 2.15 anyway I'm not interested to upload a GTK 2.9 variant building only the .udebs to unstable neither Ok, but if someone else would be packaging those to produce .udebs, you have no particular objection to uploading .debs to experimental at the same time ? Or would it make sense to build the gtk-dfb variant from the same cvs/svn repo as the rest of the gtk stuff is done, instead of a standalone snapshot outside of it ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 09:09 +0200, Sven Luther a écrit : If we decide that 2.9+ and 2.10 is the way to go for etch, then we should be pro-active for this, and start experimenting, and even making them the default NOW. GTK 2.9 is GNOME 2.16 material, lot of packages Depends on GTK and making a start of unstable cycle version the default is not a good idea It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. First tarball are due during may (ie: 2.9.n), not 2.10 If they decide to not go with 2.10 for etch, then having a random 2.9 snapshot or a final 2.10 package just for us would be no worse than the current 2.0.x packages that we have today. I disagree, they is a lot of changes and new features for 2.10 and a random 2.9 snapshot is not something we are wanting to ship with a stable Debian Cheers, Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ?
Sebastien Bacher [EMAIL PROTECTED] writes: Le mardi 16 mai 2006 à 09:09 +0200, Sven Luther a écrit : It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. First tarball are due during may (ie: 2.9.n), not 2.10 IIRC the 2.9.0 was releases two weeks ago. Still, it's some time until 2.10 will be released and it *will* be too late for the current freeze plans. Marc -- Fachbegriffe der Informatik - Einfach erklärt 24: Future Computer Whiz Kids Energy Mobilizer Kühlschrank mit Cola und Kartoffelchips drin. (Peter Berlich) pgpITqUaT8uXG.pgp Description: PGP signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 09:50 +0200, Sven Luther a écrit : Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. I don't intend to package GTK 2.9 right now, no. The new version change its ABI version as described by the announcement mail: ... * GtkFileChooser: - Communication with backends is now asynchronous to avoid blocking on filesystem operations. Due to the required interface changes, the GTK+ ABI version has been bumped to 2.10.0. Third-party filesystem backends have to be ported to the new interface, other modules, such as theme engines, input method modules or pixbuf loaders have to be rebuilt so that they are installed in the right place for GTK+ to find them. ... We have enough work with GNOME 2.14 at the moment and the ported to the new interface part means it requires to go with libgnomeui 2.15 anyway I'm not interested to upload a GTK 2.9 variant building only the .udebs to unstable neither Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 10:58:52AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 10:23 +0200, Sven Luther a écrit : Ok, but if someone else would be packaging those to produce .udebs, you have no particular objection to uploading .debs to experimental at the same time ? Are you saying you want to hijack GTK now? Err, no. I am saying, that upto now, the d-i team has been maintaining a set of gtk-dfb 2.0.x package. Since then, we worked with the directfb upstream folk to get gtk-dfb integrated in the main gtk pckages, and this has been happening for the current devel tree. The question at hand is if it would be more meaningfull to keep working with the 2.0.x libraries, knowing we are alone in maintaining them, and they have some known bugs which will not be fixed, or go with the development 2.9+ ones. This is for the d-i .udebs and related development files, not the main gtk packages. Having those gtk-dfb libraries being built from the main gtk packages would be good, which is why i asked you, but as i feared, it will not be in time for etch, but it is definitively something that should be kept in ming for gtk 2.10 and etch+1. So, my (akwardly asked maybe) question was, if it would make sense to share the work on the 2.9+ packages needed for .udebs (if we go that way), with the gtk/gnome team, in order that this work can be more easily reused by the gtk/gnome team once you are ready to go with 2.10, and maybe also benefit from the occasional hiint or advice. I am not familiar with the gtk packaging though, and maybe it is best if Eddy takes over this discussion, given the animosity between Frans and me, but it would be nice to have feedback on these issues. More clearly, there are two points : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? 2) do you have any comment and advice concerning re-use of the gtk packaging infrastructure to build the needed .udebs and -dev libraries, in such a way that they would not conflict with the remaining gtk libraries. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#362633: installation-report: fails to detect hard drive
Hi, sorry, I have not received your reply sent to [EMAIL PROTECTED], should have been sent to [EMAIL PROTECTED] The needed modules should be mptbase and mptscsih, they are present, in /lib/modules... but not loaded, loading them manually and restarting the partman does not help. lspci does not show the hardware. These lines are missing (if debian installer lspci output is compared to redhat- current installation - output): 40:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 40:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) 40:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12) 40:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) 61:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) 61:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI (rev 07) 80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) 80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) dtto for lspci -n -- 40:01.0 Class 0604: 1022:7450 (rev 12) 40:01.1 Class 0800: 1022:7451 (rev 01) 40:02.0 Class 0604: 1022:7450 (rev 12) 40:02.1 Class 0800: 1022:7451 (rev 01) 61:06.0 Class 0100: 1000:0030 (rev 07) 61:06.1 Class 0100: 1000:0030 (rev 07) 80:00.0 Class 0580: 10de:005e (rev a3) 80:01.0 Class 0580: 10de:00d3 (rev a3) -- Thanks Radim Vocka On Friday 14 April 2006 18:38, Radim Vocka wrote: Comments/Problems: Workstation with LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI controler and two SCSI hard drives. Installer does not issue the error message indicating that the hard drive is not found (installer of unofficial Sarge Amd64 distribution does), but no hard drive is detected, as neither the hard drive, nor the partition table is offered for the Partition hard drive step. Do you know which kernel modules are needed for that hardware? Are these modules present when you switch to VT2 and look in /lib/modules/.../kernel/drivers/message/fusion? Are these modules loaded (use 'lsmod | grep mpt')? If not can you load them manually and are the disks then shown when you restart partman? What is the output of 'lspci' and 'lspci -n' for your system (available during installation)? Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 11:45:02AM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no Yeah, but we use only gtk, no gnome components. I don't know how the d-i uses GTK, but does the ABI number change has an impact on it too? Given that right now we are using only gtk 2.0.x, and that there are some features (like the new C-based graphical partitioner Xavier Oswald is working on) which need a newer than gtk 2.6 version. So, no i don't think in the current state of g-i, that the ABI number will be an issue. 2) do you have any comment and advice concerning re-use of the gtk packaging infrastructure to build the needed .udebs and -dev libraries, in such a way that they would not conflict with the remaining gtk libraries. Take the GTK source package, rename it, drop the binary packages you are not interested too, renamed the other ones to no conflict? Then you probably need to make them conflict with the unstable packages or change the location of the files and the .pc, etc according to that. Note that update to GTK 2.9 requires to package pango 1.13 too and a libcairo 1.1 and might have to do similar changes for them too. That's really a non trivial way, do you really need the new version for etch? Well, it is that or 2.0.x. Davide or Attilio already have some experimental packages. We need to rebuild the stuff with the -directfb support, so i guess this will mean building new binary packages, and doing an additional build for it, not sure. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel installer issues discussion at debconf
hello, On Tue, May 16, 2006 at 06:11:53AM +0200, Andreas Barth wrote: I just want to point out that we have at Tuesday, 10.05 in the Hacklab the stable release BoF, which will give us a chance to discuss that topic. (Thanks to Frans for pointing out how usefull such a pointer would be. :) ok, please take into account for remote participants the responses to the thread which kernel version for etch? on d-kernel. regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 10:23 +0200, Sven Luther a écrit : Ok, but if someone else would be packaging those to produce .udebs, you have no particular objection to uploading .debs to experimental at the same time ? Are you saying you want to hijack GTK now? Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
libdebian-installer Packages support proposal
Hi folks I got a request from Colin if it is possible to add udeb selection per frontend. I had to decline this as it will break the ABI. As I have some pending changes which does that also, I hereby propose the following which will make it possible to change the ABI of the Packages reading part of libd-i without affecting all packages. * Split the whole thing into another shared library (adds 8KiB on i386 for the SO startup code). * Either don't change the SONAME of libdebian-installer and provide the old symbols until the next beta as the removal will break existing images, * or change the SONAME once. With this, the following changes can be done easily. * Support for udebs per frontend. * Removal of hashmap usage. Replace them with a binary tree. * Support for more than one version of a package. There are two possible solutions: - The package struct get a list of versions. - The parser is allowed to replace the information of an older version of a package with a newer. * Support for reading more than on Packages files. Bastian -- What kind of love is that? Not to be loved; never to have shown love. -- Commissioner Nancy Hedford, Metamorphosis, stardate 3219.8
Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices
On 5/16/06, Marco d'Itri [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Yes. I already explained this multiple times. An IP address is not *needed* on the ethernet interface, but always configuring one is simpler and may prevent problems later. If I am going to do that on the connection from my provider, I will have my contract termitated in a second because I am not allowed to use other IPs in their network than the ones given by thier servers, and believe me, there is NO configuration given for the ethernet card. You are supposed to use a private IP address then. No, I have told you, I AM NOT ALLOWED TO CONFIGURE THAT ETHERNET INTERFACE WITH ANY IP. The ppp interface is the only one which is allowed to be up with an IP which must be given by their server. I had problems because of this (not exagerating) from day one, when my laptop was put as a router for the internal network and on the used interface it had on private class IP. One guy from the techincal body of the ISP has visited me in the intent to disconnect me _just_ because I had an IP (an IP) other than the one provided by them. Or ifconfig ethX up with no IP, as in my case, so AFAICT, the postinst should detect if an Ethernet card is up, and if it is, try to probe for a concentrator. If the card is not yet up with an IP, the ppp-udeb.postinst script should just up it, wiithout an IP. At least that's how it seems logical to me. But it's not. I already explained how this should be implemented. Please explain non-logic for _my_ particular case. It is not *necessary* to have an IP to search for the concentrator, but it is *sufficient* to have the possibility to probe for concentrators. So, AFAICT, if probing must be done for eth0 then thi should be done according to the following algorithm: - is eth0 up? if yes, probe for concentrators - if eth0 is down, _just_ up the interface (no IP) then probe Any objection to this approach? So the question remains, how does one determine which interfaces were brought up by the ppp-udeb script (probably simple, as they might be ones with no IP set) and which are they associated to (more difficult for multiple ppp connections)? Bonus points for the association in subsequent runs of the postinst. I do not understand what you mean. See debian policy, about the idempotency of the postinst scripts. ppp-udeb's postinst must allow running it an infinite number of times, but the result should be the same. Curently this is not true because for each run of the postinst, another pppoe connection is configured, although it should not. The problem is that this issue must be solved and one will have to know (for multiple netcard system) on which ethX a pppY was configured, so that once the pppY is down, _if_ the associated ethX was upped by ppp-udeb's postinst previousely, it should be downed if no concentrator was found on it. Bringing down every interface on which there is no IP configured is suboptimal, becasue we will assume that PPPoE is the only postinst which brings up interfaces without assigning IPs to them (good for now, but flawed from a design POV and might break other scripts that might up interfaces without IPs, at some point in the future). 1) the ppp related stuff was not installed by default It is supposed to be. by whom? d-i. 2) the configuration of pppoe on the target system was not the same as the one in the d-i envronment. I do not know what this means, but the d-i configuration will work in the installed system as well. The question is still who will put the configuration there, in the target system?. Yet another script. So ppp-udeb should depend on another udeb which should provide a PPP-config-saver udeb which should take care of this copying after the target is installed. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Sebastien Bacher [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 09:50 +0200, Sven Luther a écrit : Sebastien, do you know if the development 2.9 gtk packages will be uploaded to experimental or something such ? If so, would it be meaningful to have those packages also include the build of the .udebs, and upload to unstable a version of those with the main .debs disabled ? PAckaging synergy of this kind is good to reduce workload for all involved. I don't intend to package GTK 2.9 right now, no. The new version change its ABI version as described by the announcement mail: ... * GtkFileChooser: - Communication with backends is now asynchronous to avoid blocking on filesystem operations. Due to the required interface changes, the GTK+ ABI version has been bumped to 2.10.0. Third-party filesystem backends have to be ported to the new interface, other modules, such as theme engines, input method modules or pixbuf loaders have to be rebuilt so that they are installed in the right place for GTK+ to find them. ... I had a quick look over the changes and nothing on that list should affect the G-I, AFAICT. We have enough work with GNOME 2.14 at the moment and the ported to the new interface part means it requires to go with libgnomeui 2.15 anyway I'm not interested to upload a GTK 2.9 variant building only the .udebs to unstable neither Do you object somebody else doing it? As a _distinct_ package, of course, which will be either dropped when you feel you can maintain it, kept as a separate package, or will be given to you, if you like to maintain it. Nobody wants to hijack a package from anybody (although I don't know if one could call the creation of a distict non-interfering package a hijack, taking into account that the GTK team does not maintain a similar package). -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no I don't know how the d-i uses GTK, but does the ABI number change has an impact on it too? 2) do you have any comment and advice concerning re-use of the gtk packaging infrastructure to build the needed .udebs and -dev libraries, in such a way that they would not conflict with the remaining gtk libraries. Take the GTK source package, rename it, drop the binary packages you are not interested too, renamed the other ones to no conflict? Then you probably need to make them conflict with the unstable packages or change the location of the files and the .pc, etc according to that. Note that update to GTK 2.9 requires to package pango 1.13 too and a libcairo 1.1 and might have to do similar changes for them too. That's really a non trivial way, do you really need the new version for etch? Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. I object slightly (but hopefully we'll find time to discuss these issues live). This has not been my reading of Sven's mails in that particular thread. IMHO, the discussion that followed Sven proposals helped to figure out what are the options even though it seems that Sven's initial proposal does not seem possible to use. So, I would say that, here, I see no reason to re-create a conflict. In understand that you may be hurted by the fact that Sven contacting the Gnome team partly in name of the D-I team may be felt as acting like the D-I RM, and I fully understand you have some objections to this. I more see bad effects of our current different schedules. However, imho, this does not need to go to a heated discussion here, at least in public. That discussion is interesting and I think it's valuable for the future release of D-I. So I would just say that it can be probably continued as logn as Sven takes care of not giving the impression that he acts as the D-I team (Sebastien is for isntance not completely aware of our internal organization...and even underlyign conflicts...not everyone reads -project or -devel). Sven, mini message for you, in French because I think it is better suited for what I intend to say: tes efforts sont appréciés et je pense qu'il est possible de trouver un compromis de fonctionnement au sein de D-I qui te permette de continuer à participer, voire même plus tard de participer à nouveau comme cela a été possible par le passé -opinion purement personnelle et qui n'engage en aucun cas l'équipe de D-I-. Je pense que sur ce poitn particulier ton action a été intéressante mais qu'elle a pu malheureusement donner à des personnes extérieures à l'équipe de D-I que tu agissais au nom de l'équipe D-I. Je qualifierais donc cette action de maladroite ce qui explique que je comprenne la réaction épidermique de Frans même si je la trouve un peu exagéréeon peut attribuer cela à la fatigue d'une longue journée. (sorry for our English only speakers. I wanted to say thisI wanted to say this properly and I didn't want to say it in private) signature.asc Description: Digital signature
Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices
On May 16, Eddy Petri??or [EMAIL PROTECTED] wrote: If I am going to do that on the connection from my provider, I will have my contract termitated in a second because I am not allowed to use other IPs in their network than the ones given by thier servers, and believe me, there is NO configuration given for the ethernet card. You are supposed to use a private IP address then. No, I have told you, I AM NOT ALLOWED TO CONFIGURE THAT ETHERNET INTERFACE WITH ANY IP. The ppp interface is the only one which is allowed to be up with an IP which must be given by their server. I had problems because of this (not exagerating) from day one, when my laptop was put as a router for the internal network and on the used interface it had on private class IP. One guy from the techincal body of the ISP has visited me in the intent to disconnect me _just_ because I had an IP (an IP) other than the one provided by them. I do not believe this. Your ISP CANNOT KNOW about IP addresses assigned to your internal interfaces, unless your configuration is broken in some way (e.g. you forwarded packets originated from internal addrsses without NAT'in them). It is not *necessary* to have an IP to search for the concentrator, but it is *sufficient* to have the possibility to probe for concentrators. So, AFAICT, if probing must be done for eth0 then thi should be done according to the following algorithm: - is eth0 up? if yes, probe for concentrators - if eth0 is down, _just_ up the interface (no IP) then probe Any objection to this approach? The case of ethernet interface needs to be up without an IP address must be handled by the code which currently configures ethernet interfaces (if you can persuade the maintainers). This means that when ppp-udeb will start probing the available interfaces they will already be up (with or without an IP address). ppp-udeb's postinst must allow running it an infinite number of times, but the result should be the same. Curently this is not true because for each run of the postinst, another pppoe connection is configured, although it should not. Maybe if a ppp interface exists then it should not try to configure others. The problem is that this issue must be solved and one will have to know (for multiple netcard system) on which ethX a pppY was configured, so that once the pppY is down, _if_ the associated ethX was upped by ppp-udeb's postinst previousely, it should be downed if no concentrator was found on it. ppp-udeb does not support configuring multiple PPP interfaces, and I see no reason why it should. If for some reason you need to know the ethernet interface used by the PPPoE connection you can find it in the /etc/ppp/peers/ config file. (Beware: the name of ethernet interfaces may not match eth[0-9]...) So ppp-udeb should depend on another udeb which should provide a PPP-config-saver udeb which should take care of this copying after the target is installed. No, ppp-udeb should install a script to copy the configuration on the target. -- ciao, Marco signature.asc Description: Digital signature
Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices
On 5/16/06, Marco d'Itri [EMAIL PROTECTED] wrote: On May 16, Eddy Petri??or [EMAIL PROTECTED] wrote: If I am going to do that on the connection from my provider, I will have my contract termitated in a second because I am not allowed to use other IPs in their network than the ones given by thier servers, and believe me, there is NO configuration given for the ethernet card. You are supposed to use a private IP address then. No, I have told you, I AM NOT ALLOWED TO CONFIGURE THAT ETHERNET INTERFACE WITH ANY IP. The ppp interface is the only one which is allowed to be up with an IP which must be given by their server. I had problems because of this (not exagerating) from day one, when my laptop was put as a router for the internal network and on the used interface it had on private class IP. One guy from the techincal body of the ISP has visited me in the intent to disconnect me _just_ because I had an IP (an IP) other than the one provided by them. I do not believe this. Your ISP CANNOT KNOW about IP addresses assigned to your internal interfaces, unless your configuration is broken in some way (e.g. you forwarded packets originated from internal addrsses without NAT'in them). The ISP has a huge wan which covers all the neighbourhood which is in fact a LAN. So if I assign an IP to the interface used for PPPoE, I will expose illegal IPs. I know, this setup is retarded, but I expect that some ISP using PPPoE because of cost reasons would do all kinds of suboptimal configurations and protect themselves with some legalese. Sadly, that's how is happening now for me (/my ISP). The case of ethernet interface needs to be up without an IP address must be handled by the code which currently configures ethernet interfaces (if you can persuade the maintainers). This is where I disagree, because I think there is no reason and no means for the previous steps to allow such a configuration (iirc, leave network interface unconfigured will just do that, no up, no IP), so I guess is the ppp-udeb's duty to do the up, if it needs it for PPPoE. Probably is not the best design, from your POV, but I don't think that the modular architecture of d-i will enforce this. ppp-udeb's postinst must allow running it an infinite number of times, but the result should be the same. Curently this is not true because for each run of the postinst, another pppoe connection is configured, although it should not. Maybe if a ppp interface exists then it should not try to configure others. This will not get the desired effect if: one moves the cable towards the PPPoE server from on nic to another, on a system with two or more nics, in order to configure PPPoE during the installation on another nic for the same connection. The problem is that this issue must be solved and one will have to know (for multiple netcard system) on which ethX a pppY was configured, so that once the pppY is down, _if_ the associated ethX was upped by ppp-udeb's postinst previousely, it should be downed if no concentrator was found on it. ppp-udeb does not support configuring multiple PPP interfaces, and I see no reason why it should. If for some reason you need to know the ethernet interface used by the PPPoE connection you can find it in the /etc/ppp/peers/ config file. Thanks for the info. (Beware: the name of ethernet interfaces may not match eth[0-9]...) I know, pppoeconfig is retarded from this pov. So ppp-udeb should depend on another udeb which should provide a PPP-config-saver udeb which should take care of this copying after the target is installed. No, ppp-udeb should install a script to copy the configuration on the target. In order to have that ran at some point after the syetm is configured, some postinst from the menu, directly or indirectly will have to do the copying. Having another entry in the d-i menu means having another udeb (only one postinst/udeb is possible ;-) ). If somebody tells me a way to link to other post-instal scripts, I will be glad to use those means, but I don't have that knowledge. D-I people, HLP ! :o) -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Some quotes about the issue at hand which should be consensual ... (Was: gtk 2.0.x or 2.9+ for etch g-i ?)
Some thoughts by someone else than me about this issue : Vitality The most important thing that I think would benefit Debian is increasing its tempo. We've been slow in a lot of things, from releasing, to getting updates in, to processing applications from prospective developers, to fixing bugs, to making decisons on policy questions, and all sorts of other things. Even the DPL election process takes longer to go from start to whoa than the last Australian Federal Election, and this year we'll have two state elections run and complete entirely within the election period. There are often good reaons for this, generally of the form it's more important to get it right than to do it fast, but that objection is often used even when there's no actual contradiction between those goals. And sometimes doing it fast *helps* you to do it right, by letting you try out solutions and act on the feedback -- that is, the release early, release often philosophy. Do you all recognize it ? Yes, it is indeed the meat of Anthony's DPL plateform, and we know that the debian project stands behind them, since they voted Anthony as DPL. So, Frans and other of the d-i team, please read them, and think a bit before you get offended because i propose some pro-active thinking for d-i. Especially as it is just thinking, and not non-consensual d-i svn commit as i was accused of doing. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Hi If i'm not wrong, current GTKDFB 2.0.9 libraries (binary .udeb and - dev .deb) are built from a completly different source package than regular GTKX libraries (currently 2.8.xx in unstable, IIRC). Standard GTK libraries used in the Debian are built with the X frontend, while GTK libraries used in the g-i have to be built with the DFB backend (now in GTK 2.9.0 and later ). When i asked on debian-boot to upgrade to more recent GTKDFB libraries for the g-i, i was thinking about replacing ONLY already existing custom source packages and binary (u)debs for GTKDFB, as touching standard GTKX 2.8.x libaries managed by the gnome-team is out of question for me too. Assuming that we keep the scheme of different source packages (and we'll have to, at least until GTK 2.10 is released) for GTKX and GTKDFB, is it possible delegating to the d-i team the management over the GTKDFB package (currently, the DFB backend to GTK is used only by the g-i and was also lately developed to be specifically used in the g- i) ?. Of course, if there is no way to update GTKDFB packages without updating GTKX ones too, the localeudebs solution proposed by Frans is the only way to proceed. The main reason why i think we should switch to GTK 2.9.0 (or later CVS snapshot ) in the g-i is that the DFB backend contained in GTK 2.9. x is much more stable than the one found in GTKDFB 2.0.9 (which was basically a standard GTK 2.0.9 set of libraries patched with the DFB backend taken from from directfb.org CVS repository). GTK 2.9.x introduces a lot of new advanced features, and more recently- written parts of code may still be buggy: luckily, the debian- installer's GTK frontend [1] is a very simple application that makes exclusive use of GTK features that were introduced previously GTK 2.6 was released. Past experiments done with hand-made GTK udebs [2] from CVS 2006-03-26 demonstrated it's stable enough for g-i purposes, while also giving a more stable background for fonts-testing. Attilio [1] http://svn.debian.org/wsvn/d- i/trunk/packages/cdebconf/src/modules/frontend/gtk/gtk.c? op=filerev=0sc=0 [2] http://wiki.debian.org/DebianInstaller/GUIBuild (Building images with more recent GTK+ libraries) Tiscali ADSL 4 Mega Flat Naviga senza limiti a 19,95 Euro al mese con 4 Megabps di velocita'. Attiva subito: hai 2 MESI di canone adsl GRATIS! In piu', se sei raggiunto dalla rete Tiscali, telefoni senza pagare il canone Telecom. Scopri subito come risparmiare! http://abbonati.tiscali.it/prodotti/adsl/tc/4flat/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: powerpc daily sid_d-i CD builds working again
$ more /proc/fb 0 ATI Radeon Lf 0 OFfb ATY,264LTP 1 OFfb ATY,264LTP Might be the LCD is actually on the second one? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367499: installation-reports: Not recognize adaptec aic-9405w sas/sata controller
Package: installation-reports Severity: important -- Package-specific info: Boot method: usb stick Image version: http://cdimage.debian.org/cdimage/etch_di_beta2/i386/iso-cd/debian-testing-i386-businesscard.iso Date: Date and time of the install Machine: IBM xseries 206m Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [0] Detect network card:[0] Configure network: [0] Detect CD: [0] Load installer modules: [0] Detect hard drives: [E] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Installed system ok:[ ] Comments/Problems: The system doesn't recognize the adaptec aic-9405w SATA/SAS controller. I found the gpl drivers at http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-62897 but I'm not able to use them in a useful way other than report to you ... Best regards Michele Bendazzoli -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 11:45 +0200, Sebastien Bacher a écrit : Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no If we are going to ship GNOME 2.16 in etch, we will have to rebuild all modules, theme engines and the like for this new GTK+, and we'd better do it as soon as possible in experimental. Of course there is no way this new GTK+ can enter unstable before it is declared stable upstream. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Bug#367505: Indirect dependency conflict between libgtk+2.0-directfb-dev and libgtk+2.0-directfb0
Package: libgtk+2.0-directfb-dev Version: 2.0.9.2-13 Severity: important *** Please type your report below this line *** The libgtk+2.0-directfb-dev package indirectly conflicts with libgtk+2.0-directfb0. The problem is that libgtk+2.0-directfb0 directly depends on libdirectfb-0.9-22, while libgtk+2.0-directfb-dev depends on libdirectfb-dev which in turn depends on libdirectfb-0.9-24. When compiling the program using libgtk+2.0-directfb-dev, I get the following warning: === gcc e02.c -Wall Pkg-config gtk+-directfb-2.0 --cflags --libsM/usr/bin/ld: warning: libdirectfb-0.9.so.22, needed by /usr/lib/directfb/libgtk- directfb.so, may conflict with libdirectfb-0.9.so.24 /usr/bin/ld: warning: libfusion-0.9.so.22, needed by /usr/lib/directfb/libgtk-di rectfb.so, may conflict with libfusion-0.9.so.24 /usr/bin/ld: warning: libdirect-0.9.so.22, needed by /usr/lib/directfb/libgtk-di rectfb.so, may conflict with libdirect-0.9.so.24 === -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.6 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) Versions of packages libgtk+2.0-directfb-dev depends on: ii libatk1.0-dev 1.11.4-2 Development files for the ATK acce ii libdirectfb-dev 0.9.24-3 frame buffer graphics library, dev ii libgtk+2.0-directfb0 2.0.9.2-13 gtk+2.0 implementation for the fra ii libgtk2.0-dev 2.8.16-1 Development files for the GTK+ lib ii libpango1.0-dev 1.12.1-2 Development files for the Pango ii pkg-config 0.20-1 manage compile and link flags for libgtk+2.0-directfb-dev recommends no packages. -- debconf-show failed
Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices
On Tuesday 16 May 2006 14:33, Eddy Petrişor wrote: In order to have that ran at some point after the syetm is configured, some postinst from the menu, directly or indirectly will have to do the copying. Having another entry in the d-i menu means having another udeb (only one postinst/udeb is possible ;-) ). If somebody tells me a way to link to other post-instal scripts, I will be glad to use those means, but I don't have that knowledge. D-I people, HLP ! :o) Sounds like a prebaseconfig (or finish-install as it is called now) script could be used for that? Just include it in your package and make the rules file drop it into /usr/lib/finish-install.d. There are plenty of examples around. pgprp57MCgGjr.pgp Description: PGP signature
Re: graphics or text as default?
On Tuesday 16 May 2006 10:25, Wouter Verhelst wrote: My point really was that it's silly to drop the graphical installer as a target for Etch if you need to compile differently for gtk-dfb anyway; so if the regular gtk2 packages aren't at the correct version, having a different gtk2 source package which compiles the .udeb (and nothing more--unless you need some -dev packages to be able to build the installer image) would seem to be the obvious solution. Yes, we _do_ need a normal lib package and lib-dev package as we need those to compile the cdebconf-gtk frontend against. Having these packages conflict with the regular ones is not really an option IMO. It would probably work for buildds, but it would make working on the graphical installer on normal systems a pain. pgp5vN9bg6HEM.pgp Description: PGP signature
Re: dhcp3-client and D-I
On Tue, May 16, 2006 at 06:54:55AM +0200, Noèl Köthe wrote: Am Sonntag, den 14.05.2006, 09:10 +1000 schrieb Andrew Pollock: Hello Andrew, we had the D-I BoF here at Debconf6 some hours ago. 1. the D-I will use 2 but 3 will be install on the system which is installed Sounds good. Yes, but the idea was rejected. They want to use the same version which they want to install on the system (like the kernel, too). With the removal of the kernel 2.4 from the bootfloppies there might be more space on them but its not known how much exactly. Joeyh will check this but the only alternative then will be reducing the size with removing unneeded functions/extensions for the dhclient for the udeb (dhcp3-client-tiny;)). If I find out more I will inform you. Okay. I've had a preliminary play with ipconfig over the weekend. Seems relatively straightforward to slot it into netcfg's dhcp.c. What I need to understand is the necessity to set a vendor-class-identifier attribute in with the request, is this a nicety or a need-to-have? ipconfig won't do it. The other thing that ipconfig doesn't currently do is send the hostname with the request, which is an optional feature for some people on cable. That's potentially fixable though, as one of the ways of invoking ipconfig includes a hostname. I've built a udeb from ipconfig, and twiddled with netcfg enough to test it out, I've just been having some problems rebuilding d-i, but I'll try again during the week. regards Andrew -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: powerpc daily sid_d-i CD builds working again
On Tue, 2006-05-16 at 09:58 +0200, Sven Luther wrote: My diagnostic here, is that g-i makes some assumptions that are wrong on powerpc. Most probably it tries to load the vesafb module, but since the above is builtin in the powerpc kernel, that test fails, obviously. Furthermore, vesafb is a x86-only thingy. Ok, I tried with some options (http://people.debian.org/~terpstra/message/20051202.093632.1589458f.en.html ) that people indicate me in #debian-boot. Still nothing. I managed to install strace in the busybox and ran debian-installer trough it. The logs are here: http://heracles.corsac.net/~corsac/hydra/di3.log http://heracles.corsac.net/~corsac/hydra/strace.log Don't really know what's happening... To make myself clear, I don't really *need* to use gtk-installer on this box, it's only my test box, and I wanted to try g-i on this (old) hardware, only to test if it worked. Regards, -- Yves-Alexis Perez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#367499: installation-reports: Not recognize adaptec aic-9405w sas/sata controller
Processing commands for [EMAIL PROTECTED]: severity 367499 normal Bug#367499: installation-reports: Not recognize adaptec aic-9405w sas/sata controller Severity set to `normal' from `important' 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#367499: installation-reports: Not recognize adaptec aic-9405w sas/sata controller
severity 367499 normal thanks The system doesn't recognize the adaptec aic-9405w SATA/SAS controller. I found the gpl drivers at http://www-307.ibm.com/pc/support/site.wss/document.do?lndocid=MIGR-62897 but I'm not able to use them in a useful way other than report to you ... That probably means that the only option is reassigning this issue to the kernel. signature.asc Description: Digital signature
Re: powerpc daily sid_d-i CD builds working again
On Tue, May 16, 2006 at 12:16:38PM +0200, Michael Schmitz wrote:
$ more /proc/fb
0 ATI Radeon Lf
0 OFfb ATY,264LTP
1 OFfb ATY,264LTP
Might be the LCD is actually on the second one?
This might be the reason it fails, if it is so. But i am not sure, since the
dmesg output mentioned fb0.
from the rootskel code we have :
src/lib/debian-installer.d/S35framebuffer-linux
if [ -n $TERM_FRAMEBUFFER_TRY ] \
([ -e /dev/fb/0 ] || [ -e /dev/fb0 ]) \
[ `debconf-get debian-installer/framebuffer` = true ]; then
TERM_FRAMEBUFFER=yes
fi
And :
src/lib/debian-installer.d/S60frontend
...
check_gtk () {
if [ -z $TERM_FRAMEBUFFER ] ; then
echo Framebuffer not available; disabling graphical frontend
2
return 1
fi
...
It needs more investigation, but i think something is happeneing here. atyfb
is correctly builtin for powerpc kernels, i just checked the sid 2.6.16
kernels.
There was an option for running those script in -x mode, and get more verbose
output, can someone remember this ?
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [LONG] ppp-udeb: A succesful installation using it, some ideas and some requests for advices
On 5/16/06, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 16 May 2006 14:33, Eddy Petrişor wrote: In order to have that ran at some point after the syetm is configured, some postinst from the menu, directly or indirectly will have to do the copying. Having another entry in the d-i menu means having another udeb (only one postinst/udeb is possible ;-) ). If somebody tells me a way to link to other post-instal scripts, I will be glad to use those means, but I don't have that knowledge. D-I people, HLP ! :o) Sounds like a prebaseconfig (or finish-install as it is called now) script could be used for that? Just include it in your package and make the rules file drop it into /usr/lib/finish-install.d. There are plenty of examples around. Thanks -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: graphics or text as default?
On 5/16/06, Frans Pop [EMAIL PROTECTED] wrote: On Tuesday 16 May 2006 10:25, Wouter Verhelst wrote: My point really was that it's silly to drop the graphical installer as a target for Etch if you need to compile differently for gtk-dfb anyway; so if the regular gtk2 packages aren't at the correct version, having a different gtk2 source package which compiles the .udeb (and nothing more--unless you need some -dev packages to be able to build the installer image) would seem to be the obvious solution. Yes, we _do_ need a normal lib package and lib-dev package as we need those to compile the cdebconf-gtk frontend against. Having these packages conflict with the regular ones is not really an option IMO. It would probably work for buildds, but it would make working on the graphical installer on normal systems a pain. I'm sorry, but don't you use a chroot environment for such work? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Josselin Mouette [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 11:45 +0200, Sebastien Bacher a écrit : Le mardi 16 mai 2006 à 11:07 +0200, Sven Luther a écrit : 1) you did comment on gtk 2.9+ for etch as the main gtk package, but does this advice also hold in a 2.0.x vs 2.9+ d-i gtk-dfb scenario ? As written previously upstream changed the ABI number so updating to GTK 2.9 would require updating libgnomeui (and probably some other parts of GNOME with it) to 2.15, I don't think that's something we want to do for now no If we are going to ship GNOME 2.16 in etch, we will have to rebuild all modules, theme engines and the like for this new GTK+, and we'd better do it as soon as possible in experimental. Let's stop the non-issues. It is quite clear that from a GNOME POV gtk 2.9+ is not an option at the moment. What everybody should focus on now in this discution is the gtk udebs (the ones with DFB backend which are needed for G-I and G-I only, at least for the moment). So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Again, please understand this is NOT hijacking, these should be distinct packages which have the DFB backend, not the X one, as it is now for the packages maintained by gtk/gnome code. - If teh answer to the previous question is yes, then would you like to assist us in this work ? (as we don't have gtk and general library packaging experience) -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Bug#367515: kernel ABI mismatch message should tell user to look for an updated CD
Package: anna Version: 1.2.3 Severity: wishlist As requested by Frans in the stable BOF @ debconf6, the message displayed to the user when the kernel ABI of the downloaded module udebs doesn't match the running kernel should suggest downloading an updated CD. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: powerpc daily sid_d-i CD builds working again
On Tue, May 16, 2006 at 05:33:24PM +0200, Sven Luther wrote: On Tue, May 16, 2006 at 12:16:38PM +0200, Michael Schmitz wrote: $ more /proc/fb 0 ATI Radeon Lf 0 OFfb ATY,264LTP 1 OFfb ATY,264LTP Might be the LCD is actually on the second one? This might be the reason it fails, if it is so. But i am not sure, since the dmesg output mentioned fb0. 17:37 Corsac but forcing DEBIAN_FRONTEND to gtk seems to run correctly, until it crash with signal 11 So, the DEBIAN_FRONTEND is not correctly set to gtk, for whatever reason, probably because of the image used, and the build setup not being adapted for powerpc after the merge or something. Still, it crashed with signal 11. Could you tell us more about this signal 11, and tell us when it happened. It is possible that we did disable some stuff in the directfb code for radeon, which needs disabling also for atyfb, or in general for powerpc. Some directfb accel i think it was. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: powerpc daily sid_d-i CD builds working again
On Tue, 2006-05-16 at 17:52 +0200, Sven Luther wrote: On Tue, May 16, 2006 at 05:33:24PM +0200, Sven Luther wrote: On Tue, May 16, 2006 at 12:16:38PM +0200, Michael Schmitz wrote: $ more /proc/fb 0 ATI Radeon Lf 0 OFfb ATY,264LTP 1 OFfb ATY,264LTP Might be the LCD is actually on the second one? This might be the reason it fails, if it is so. But i am not sure, since the dmesg output mentioned fb0. 17:37 Corsac but forcing DEBIAN_FRONTEND to gtk seems to run correctly, until it crash with signal 11 So, the DEBIAN_FRONTEND is not correctly set to gtk, for whatever reason, probably because of the image used, and the build setup not being adapted for powerpc after the merge or something. I don't really know. Maybe the framebuffer.. error message is also due to framebuffer crashing. Still, it crashed with signal 11. Could you tell us more about this signal 11, and tell us when it happened. You can see logs of running debian-installer: http://heracles.corsac.net/~corsac/hydra/di3.log When I strace this, this is what I get: http://heracles.corsac.net/~corsac/hydra/strace.log It is possible that we did disable some stuff in the directfb code for radeon, which needs disabling also for atyfb, or in general for powerpc. Some directfb accel i think it was. On advices got on #debian-boot I added on my /etc/directfbrc: debug no-hardware Regards, -- Yves-Alexis Perez -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel installer issues discussion at debconf
* maximilian attems ([EMAIL PROTECTED]) [060516 11:09]: On Tue, May 16, 2006 at 06:11:53AM +0200, Andreas Barth wrote: I just want to point out that we have at Tuesday, 10.05 in the Hacklab the stable release BoF, which will give us a chance to discuss that topic. (Thanks to Frans for pointing out how usefull such a pointer would be. :) ok, please take into account for remote participants the responses to the thread which kernel version for etch? on d-kernel. That is understood - however, that BoF was/is rather about the current stable version, sarge. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
On Tue, May 16, 2006 at 05:06:03PM +0200, Frans Pop wrote: On Tuesday 16 May 2006 10:25, Wouter Verhelst wrote: My point really was that it's silly to drop the graphical installer as a target for Etch if you need to compile differently for gtk-dfb anyway; so if the regular gtk2 packages aren't at the correct version, having a different gtk2 source package which compiles the .udeb (and nothing more--unless you need some -dev packages to be able to build the installer image) would seem to be the obvious solution. Yes, we _do_ need a normal lib package and lib-dev package as we need those to compile the cdebconf-gtk frontend against. Having these packages conflict with the regular ones is not really an option IMO. It would probably work for buildds, but it would make working on the graphical installer on normal systems a pain. Who said they need to conflict? In fact, there already is a package 'libgtk+2.0-directfb-dev' which you can install concurrently with libgtk2.0-dev. There's no reason why another version (which would do what you need it to do) couldn't be installed concurrently with the other two variants. -- Fun will now commence -- Seven Of Nine, Ashes to Ashes, stardate 53679.4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: graphics or text as default?
Hi, Even though I prefer the textual installer or even no installers ;) see http://www.debuntu.org/2006/05/14/51-how-to-installing-debian-etch-from-a-running-debian-based-system/ I reckon graphical as default is best. Why? Just because awared user will instantly look toward FXs menus, but a non-awared user, will simply not know what to do. A good alternative, will be to show a box with: 1.Install In Graph mode 2.Install in Text Mode Stefano Canepa wrote: Hi all, the CD images with both graphical and textual installer will run graphical as default? At my LUG when we explain the installation process to new users we present Mandriva and Debian and many users choise to install Mandriva just for it's graphical installer or better graphical partitioner. I do like the textual installer more but new users like clicking on menus. :) Regards sc -- http://www.debuntu.org http://www.debuntu.org/ Debuntu Debian and Ubuntu Tips and Tricks http://www.debuntu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installing debian without debian-installer
Thank you for your message and the link to the howto; I hope it will be useful to some people. Installing Debian using debootstrap is also documented in the Installation Guide: http://d-i.alioth.debian.org/manual/en.i386/apds03.html Hi, Arf, I could not find that link anymore from the debian frontpage, that's why I went on that quest ;). -- http://www.debuntu.org http://www.debuntu.org/ Debuntu Debian and Ubuntu Tips and Tricks http://www.debuntu.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdebian-installer Packages support proposal
On Tue, May 16, 2006 at 10:52:19AM -0500, Joey Hess wrote: Bastian Blank wrote: * Support for udebs per frontend. Not sure what this means exactly.. | Kamion waldi: how would I go about adding a parameter to di_system_packages_resolve_dependencies_mark_anna without breaking libd-i's ABI? | Kamion I'd like to teach it to check the running cdebconf frontend | Kamion so that cdebconf plugins can do XB-Debconf-Frontend: newt, Provides: cdebconf-blah, and users can do Depends: cdebconf-blah and rely on anna picking the right one * Removal of hashmap usage. Replace them with a binary tree. Does it save back the 8k? That would be nice.. ;-) Nope, the gain is less. * Support for more than one version of a package. There are two possible solutions: - The package struct get a list of versions. - The parser is allowed to replace the information of an older version of a package with a newer. * Support for reading more than on Packages files. Clearly something we want ASAP, thanks for working on it! I'll implement that after the higher priority tasks (aka partman) are sorted out. As there was no response yes, I don't think anyone wants to help. Bastian -- Beam me up, Scotty! signature.asc Description: Digital signature
Re: installing debian without debian-installer
On Tuesday 16 May 2006 19:14, chantra wrote: Arf, I could not find that link anymore from the debian frontpage, that's why I went on that quest ;). From the from page, try the link to Installation manual under the Documentation heading ;-) pgph5OVxx5mdJ.pgp Description: PGP signature
Re: installing debian without debian-installer
From the from page, try the link to Installation manual under the Documentation heading ;-) Arf, I didn't scroll down enough :p . But still, this bit is missing now: C.4.4.4.Configure Timezone, Users, and APT Set your timezone, add a normal user, and choose your apt sources by running # /usr/sbin/base-config new -- http://www.debuntu.org
Bug#367505: marked as done (Indirect dependency conflict between libgtk+2.0-directfb-dev and libgtk+2.0-directfb0)
Your message dated Tue, 16 May 2006 20:13:19 +0200 with message-id [EMAIL PROTECTED] and subject line Bug#367505: Indirect dependency conflict between libgtk+2.0-directfb-dev and libgtk+2.0-directfb0 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: libgtk+2.0-directfb-dev Version: 2.0.9.2-13 Severity: important *** Please type your report below this line *** The libgtk+2.0-directfb-dev package indirectly conflicts with libgtk+2.0-directfb0. The problem is that libgtk+2.0-directfb0 directly depends on libdirectfb-0.9-22, while libgtk+2.0-directfb-dev depends on libdirectfb-dev which in turn depends on libdirectfb-0.9-24. When compiling the program using libgtk+2.0-directfb-dev, I get the following warning: === gcc e02.c -Wall Pkg-config gtk+-directfb-2.0 --cflags --libsM/usr/bin/ld: warning: libdirectfb-0.9.so.22, needed by /usr/lib/directfb/libgtk- directfb.so, may conflict with libdirectfb-0.9.so.24 /usr/bin/ld: warning: libfusion-0.9.so.22, needed by /usr/lib/directfb/libgtk-di rectfb.so, may conflict with libfusion-0.9.so.24 /usr/bin/ld: warning: libdirect-0.9.so.22, needed by /usr/lib/directfb/libgtk-di rectfb.so, may conflict with libdirect-0.9.so.24 === -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.6 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) Versions of packages libgtk+2.0-directfb-dev depends on: ii libatk1.0-dev 1.11.4-2 Development files for the ATK acce ii libdirectfb-dev 0.9.24-3 frame buffer graphics library, dev ii libgtk+2.0-directfb0 2.0.9.2-13 gtk+2.0 implementation for the fra ii libgtk2.0-dev 2.8.16-1 Development files for the GTK+ lib ii libpango1.0-dev 1.12.1-2 Development files for the Pango ii pkg-config 0.20-1 manage compile and link flags for libgtk+2.0-directfb-dev recommends no packages. -- debconf-show failed ---End Message--- ---BeginMessage--- On Tuesday 16 May 2006 15:57, Krzysztof B wrote: The libgtk+2.0-directfb-dev package indirectly conflicts with libgtk+2.0-directfb0. The problem is that libgtk+2.0-directfb0 directly depends on libdirectfb-0.9-22, while libgtk+2.0-directfb-dev depends on libdirectfb-dev which in turn depends on libdirectfb-0.9-24. Could it be that you are using testing? If you look at [1] I think you will find that the version in unstable has the correct dependency. The new version of libgtk+2.0-directfb-dev will probably not migrate to testing for a while yet. I suggest you use unstable anyway when trying to build udebs or the installer. Closing this bug for now, but if I'm mistaken, please reply so it can be reopened. [1] http://packages.debian.org/unstable/libdevel/libgtk+2.0-directfb-dev ---End Message---
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Sebastien Bacher [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that Good. So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Building some udeb is not exactly taking the lead of the GTK packages, right? Well, it is if you look at version numbers ;-) . Also some GTK+DFB specifc libraries will be needed. AFAICT, now there will be no conflict on common ground with gtk, but in case that will happen , we will disscuss the issues with you and we will sort out the problems that might occur. - If teh answer to the previous question is yes, then would you like to assist us in this work ? (as we don't have gtk and general library packaging experience) Sure, feel free to mail the debian-gtk-gnome list about any issue you have on the topic Thanks for the offer. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Building some udeb is not exactly taking the lead of the GTK packages, right? - If teh answer to the previous question is yes, then would you like to assist us in this work ? (as we don't have gtk and general library packaging experience) Sure, feel free to mail the debian-gtk-gnome list about any issue you have on the topic Cheers, Sebastien Bacher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Eddy Petrişor wrote: On 5/16/06, Sebastien Bacher [EMAIL PROTECTED] wrote: Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that Good. So, if i understand correctly, there should be definitely no problems in moving to more recent GTKDFB libraries, right (no conflicts with GTKX pavkages) ? do we all agree about moving to 2.9.0 (needs minor patches) or CVS snapshot dated 2006-03-26 (previous to 2.9.0 but compiles out of repo) ? GTK = 2.9.0 requires the following libraries glib-2.0 = 2.10.1 atk = 1.0.1 pango = 1.9.0 cairo = 1.1.6 We already have correct glib, atk and pango, but we need to repackage a newer cairo compiling it with the DirectFB backend enable against DFB 0.9.24 (the detailed GTKDFB packaging process is described here [1]). Who's going to do this? in the case we can't do this by ourselves, could the debian-gnome team, who nicely offered to help us, support us? friendly Attilio [1] http://www.directfb.org/wiki/index.php/Projects:GTK_on_DirectFB -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367551: No software to net-install over a ppp modem connection
Package: debian-installer Version: Sarge ? The netinst page (http://www.us.debian.org/distrib/netinst) claims: This sort of network installation process requires either an analogue PPP dialup connection to your Internet provider, or Internet access via Ethernet (possibly using a PCMCIA card in your laptop). Unfortunately, it does not support internal ISDN cards. Well, I used a browser to go to: http://http.us.debian.org/debian/dists/sarge/main/installer-i386/current//images/floppy/ and downloaded 3 floppy disk images: boot.img, root.img, and net-drivers.img and copied them onto floppies. Then I got Linux running using the first 2 floppies and then installed the net-drivers from the 3rd floppy. But the drivers seem to only be for ethernet cards. Where are the drivers for a PPP dialup connection to the Internet via an ISP, modem and telephone line? This software should include dialup software such as wvdial. David Lawyer PS: Below is a text copy of the netinst page: http://www.us.debian.org/distrib/netinst [1]Debian Project Select a server near you [United States.] Go [2]Skip Quicknav * [3]About Debian * [4]News * [5]Getting Debian * [6]Support * [7]Developers' Corner * [8]Site map * [9]Search Installing Debian GNU/Linux via the Internet If you have a permanent connection to the Internet, you can install Debian using that. You would initially download only a small portion of Debian required to start the installation process, and then install whatever else you want from within the installation program. This sort of network installation process requires either an analogue PPP dialup connection to your Internet provider, or Internet access via Ethernet (possibly using a PCMCIA card in your laptop). Unfortunately, it does not support internal ISDN cards. There are two options for installs over the network: * [10]Minimal CD: Instead of getting a full 650MB CD image, you just download a CD image file which contains the bare essentials necessary to install the rest. For the moment, it's necessary to have access to a CD recorder in order to use this. * [11]Floppy disks: You download a couple of floppy disk images (files the size of a floppy disk), write them to floppy disks, and then start the installation by booting from the those diskettes. __ Back to the [12]Debian Project homepage. __ This page is also available in the following languages: [13]Blgarski ([EMAIL PROTECTED]) [14]catal`a [15]cesky [16]dansk [17]Deutsch [18]Ellynika' (Ellinika) [19]espanol [20]franc,ais [21]#54620;#44397;#50612; (Hangul) [22]Italiano [23]magyar [24]Nederlands [25]#26085;#26412;#35486; (Nihongo) [26]polski [27]Portugues [28]romana [29]Russkij (Russkij) [30]slovensky [31]suomi [32]svenska [33]Tuerkc,e [34]ukrayins'ka (ukrajins'ka) [35]#20013;#25991;(#31616;) [36]#20013;#25991;(HK) [37]#20013;#25991;(#32321;) How to set [38]the default document language __ To report a problem with the web site, e-mail [EMAIL PROTECTED] For other contact information, see the Debian [40]contact page. Last Modified: Tue, Mar 14 11:20:35 UTC 2006 Copyright (c) 1997-2006 [41]SPI; See [42]license terms Debian is a registered trademark of Software in the Public Interest, Inc. References Visible links 1. http://www.us.debian.org/ 2. http://www.us.debian.org/distrib/netinst#inner 3. http://www.us.debian.org/intro/about 4. http://www.us.debian.org/News/ 5. http://www.us.debian.org/distrib/ 6. http://www.us.debian.org/support 7. http://www.us.debian.org/devel/ 8. http://www.us.debian.org/sitemap 9. http://search.debian.org/ 10. http://www.us.debian.org/CD/netinst/ 11. http://www.us.debian.org/distrib/floppyinst 12. http://www.us.debian.org/ 13. http://www.us.debian.org/distrib/netinst.bg.html 14. http://www.us.debian.org/distrib/netinst.ca.html 15. http://www.us.debian.org/distrib/netinst.cs.html 16. http://www.us.debian.org/distrib/netinst.da.html 17. http://www.us.debian.org/distrib/netinst.de.html 18. http://www.us.debian.org/distrib/netinst.el.html 19. http://www.us.debian.org/distrib/netinst.es.html 20. http://www.us.debian.org/distrib/netinst.fr.html 21. http://www.us.debian.org/distrib/netinst.ko.html 22. http://www.us.debian.org/distrib/netinst.it.html 23. http://www.us.debian.org/distrib/netinst.hu.html 24. http://www.us.debian.org/distrib/netinst.nl.html 25. http://www.us.debian.org/distrib/netinst.ja.html 26. http://www.us.debian.org/distrib/netinst.pl.html 27.
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On 5/16/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: So, if i understand correctly, there should be definitely no problems in moving to more recent GTKDFB libraries, right (no conflicts with GTKX pavkages) ? do we all agree about moving to 2.9.0 (needs minor patches) or CVS snapshot dated 2006-03-26 (previous to 2.9.0 but compiles out of repo) ? GTK = 2.9.0 requires the following libraries I think it does not matter that much to us if it is a snapshot or 2.9.0, but I think that 2.9.0 would help us because we will not be alone on this ground (others might face different problems with 2.9.0, but there are less chances of that happening with a cvs snapshot). As the debian packaging system allows patching before building, I would opt for 2.9.0. glib-2.0 = 2.10.1 atk = 1.0.1 pango = 1.9.0 cairo = 1.1.6 Do these change for 2.9.0? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 07:36:48PM +0200, Sebastien Bacher wrote: Le mardi 16 mai 2006 à 18:42 +0300, Eddy Petrişor a écrit : So the questions are: - Is it OK for the GTK+GNOME team to have D-I people (and maybe with the help of some gtk/gnome people) build some udebs for GTK _with_the_DFB_ backend, as it is now for the 2.0.9 version? Sure, no objection with that So, in English, the main question is if the gtk/gnome people are ok with the fact that now, the lead of developing gtk packages will be taken by d-i people? Building some udeb is not exactly taking the lead of the GTK packages, right? Well, my proposal was to use the same packaging infrastructure for both the official 2.8 gtk and the .udeb producing 2.9+ gtk packages, add the necessary stuff to produce the new -directfb packages, and disable the build of the normal ones. it is indeed not taking the lead, but the experience may benefit the gtk team later on. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal for integration of the graphical installer
On Tue, May 16, 2006 at 09:22:22AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 09:01, Geert Stappers wrote: Fool^WFull switch to g-i will kill serial line and ssh installs. Not so. The installer detects serial line installs and does not enable the framebuffer and thus not the graphical frontend. Similar for ssh installs. Oo. Now I see. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdebian-installer Packages support proposal
On Tuesday 16 May 2006 19:59, Bastian Blank wrote: I'll implement that after the higher priority tasks (aka partman) are sorted out. As there was no response yes, I don't think anyone wants to help. Speaking only for myself of course, I still have your message on my TODO list. However, it is a fairly hard question with no simple answers and both being at Debconf and having to waste lots of time on the issues with Sven have resulted in my not having been able to really sit down for it. The fact that we currently lack an active lead partman maintainer does not help of course. pgpmuoCNrgfMv.pgp Description: PGP signature
tasksel 2.44 MIGRATED to testing
FYI: The status of the tasksel source package in Debian's testing distribution has changed. Previous version: 2.43 Current version: 2.44 -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Le mardi 16 mai 2006 à 21:55 +0200, Attilio Fiandrotti a écrit : So, if i understand correctly, there should be definitely no problems in moving to more recent GTKDFB libraries, right (no conflicts with GTKX pavkages) ? do we all agree about moving to 2.9.0 (needs minor patches) or CVS snapshot dated 2006-03-26 (previous to 2.9.0 but compiles out of repo) ? GTK = 2.9.0 requires the following libraries glib-2.0 = 2.10.1 atk = 1.0.1 pango = 1.9.0 cairo = 1.1.6 Beware that the CVS version now requires pango 1.13. That would mean having to maintain a pango snapshot as well. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Persistent device names
To discuss this subject, I've still wanted to set up a discussion with at least Marco, you, Joey and Colin, but for different reasons have not gotten around to that. As I'll be on holiday for a few weeks after Debconf, let me at least list the issues that I've had in mind and that should be considered when implementing changes for persistent device naming. Please add to the list and comment. - We should like to keep support for devfs and regular device names in the installer; loosing that would mean no support for 2.2/2.4 installs (although those are likely to be dropped anyway) and no support for installs of Sarge and I think may be a problem for debian-edu. However, if it is unavoidable, we could drop this requirement. - Are there likely to be architecture specific issues with persistent device naming? - Or with filesystems other than ext2/ext3? - Persistent device naming is mostly needed to get rid of errors on reboot. Most common case is where a system has multiple disk controllers and the order in which their drivers are loaded is different after the reboot than in d-i leading to a different order in device names. - A special case is for installations from usb-stick in combination with a scsi or SATA harddisk controller. In that case d-i will see the USB stick as the first SCSI controller (sda) and the real SCSI/SATA harddisks will come after that. This also results in errors on reboot as the grub setup and fstab will be incorrect as then the usb stick will not be present and sda will be assigned to the real disk controller. Similar cases for installs to any kind of external disk drive. It seems to me that persistent device naming will probably fix fstab in this case, but possibly not the grub configuration. - Probably unrelated, but worth mentioning. If the user installs to hdb and has BIOS set to boot from hdb, the grub configuration will be incorrect. (Same for hdc, hdd of course.) - The last two issues are somewhat related and could maybe be solved by detecting this situation and asking the user which device the system will boot off. There are a number of bug reports against grub-installer about these two issues. - Identify where changes will be needed. This will be at least partman and will probably include most bootloader installers. Cheers, FJP pgpX1JFOYpjoB.pgp Description: PGP signature
Re: Persistent device names
On May 17, Frans Pop [EMAIL PROTECTED] wrote: - We should like to keep support for devfs and regular device names in the installer; loosing that would mean no support for 2.2/2.4 installs (although those are likely to be dropped anyway) and no support for installs of Sarge and I think may be a problem for debian-edu. However, if it is unavoidable, we could drop this requirement. I would have loved to be able to remove support for devfs names from the udeb, but this is not a big deal. Until now I have no reason to believe that there will be any problem with keeping support for them in etch. I am much more concerned that you are still considering to support kernels older than 2.6. - Are there likely to be architecture specific issues with persistent device naming? - Or with filesystems other than ext2/ext3? Nothing I know about. tree /dev/disk/ should give you some ideas. by-label links are user friendly, but may become ambiguous if users carelessly duplicate file systems using dd. by-uuid links have the same problem *and* need a suitable identifier in the file system metadata. by-id links are more unique but linked to the physical hardware (you can't have it both ways...) and are a bit ugly. by-path links are very descriptive and really unique, but are *really* unique and will change if a disk is moved to a different bus position or something like this. - Persistent device naming is mostly needed to get rid of errors on reboot. Most common case is where a system has multiple disk And is useful anyway to make administration simpler. [SCSI disk + USB storage] It seems to me that persistent device naming will probably fix fstab in Correct. this case, but possibly not the grub configuration. No clue about this. -- ciao, Marco signature.asc Description: Digital signature
Processed: your mail
Processing commands for [EMAIL PROTECTED]: reopen 328498 Bug#328498: switch to cdebconf as default 'reopen' is deprecated when a bug has been closed with a version; use 'found' or 'submitter' as appropriate instead. Bug reopened, originator not changed. -- 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#367402: software raid jfs
using the debian-testing-amd64-netinst.iso from may 13 Wiped disk and tried this one again - Dropped down into shell just before the grub install and chroot /target added backports to sources.list apt-get update apt-get install linux-image-2.6.15-1-amd64-k8 complained about hotplug - and removed it?? went back and did the rest of the install. rebooted and things seemed to work, but no network wanted to install 2.6.16, but then it wouldn't let me log in - as if there was no root user? Karl Schmidt EMail [EMAIL PROTECTED] Transtronics, Inc. WEB http://xtronics.com 3209 West 9th StreetPh (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Any cat would tell you that you can only wash one paw at a time; while we try to do everything at once. -kps -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Eddy Petrişor wrote: On 5/16/06, Attilio Fiandrotti [EMAIL PROTECTED] wrote: So, if i understand correctly, there should be definitely no problems in moving to more recent GTKDFB libraries, right (no conflicts with GTKX pavkages) ? do we all agree about moving to 2.9.0 (needs minor patches) or CVS snapshot dated 2006-03-26 (previous to 2.9.0 but compiles out of repo) ? GTK = 2.9.0 requires the following libraries I think it does not matter that much to us if it is a snapshot or 2.9.0, but I think that 2.9.0 would help us because we will not be alone on this ground (others might face different problems with 2.9.0, but there are less chances of that happening with a cvs snapshot). As the debian packaging system allows patching before building, I would opt for 2.9.0. i'm going to file tomorrow bugs and patches to gnome BTS, so that 2.9.0 can be soon made compile correctly with the DFB backend activated. glib-2.0 = 2.10.1 atk = 1.0.1 pango = 1.9.0 cairo = 1.1.6 Do these change for 2.9.0? The above library requirements apply to both GTK 2.9.0 and 2006-03-26 CVS snapshot (which is older than 2.9.0 ). More recent GTK CVS snapshots require glib 2.11, pango 1.11 ( and DFB 0.9.25 i think). ciao Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdebian-installer Packages support proposal
On Tue, May 16, 2006 at 11:02:43PM +0200, Frans Pop wrote: On Tuesday 16 May 2006 19:59, Bastian Blank wrote: I'll implement that after the higher priority tasks (aka partman) are sorted out. As there was no response yes, I don't think anyone wants to help. Speaking only for myself of course, I still have your message on my TODO list. However, it is a fairly hard question with no simple answers and both being at Debconf and having to waste lots of time on the issues with Sven have resulted in my not having been able to really sit down for it. You are the only one who chose this course of action, that resulted in wasting so much time, for both you, me, the DPL, and i don't know how many innocent onlookers. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
D-I-internals workshop at Debconf
Hi all, I'll be giving a workshop explaining the technical side of the installer on Thursday 18-5 from 20:20 - 22:00 UTC (if my timezone calculations are correct). Main subjects are: - What happens when the installer runs: - installation methods - booting - the menu and running components - Creating udebs - Building installer images If you're interested, you can follow this workshop via streamed video on: http://video:8000/tower.ogg The paper that goes with the workshop is available at: http://people.debian.org/~fjp/talks/debconf6 Cheers, FJP pgphpUxs1xnpH.pgp Description: PGP signature
Daily built images for i386 include graphical installation option
At Debconf Joey Hess and I have integrated support for the graphical installer into the main build system for d-i. For now the support is for i386 only, but amd64 [1] and powerpc will follow very soon. This means that the daily built images [2] of the installer now include an option to boot the graphical (gtk/directfb based) installer as well as the familiar newt based installer. The following types of images support graphical installation: - businesscard CD - netinst CD - hd-media - gtk-miniiso (mini CD image; install is comparable to netboot installs) To boot the graphical version of the installer, type 'installgui' or 'expertgui' at the boot prompt. By default you will get the newt frontend. Thanks to everyone who has helped us with the udeb shlibs/dependency transition which has made the integration possible. Cheers, Frans Pop [1] Images for amd64 will only actually be available when we can resume daily builds for them; these are currently down as a result of the archive integration. [2] http://www.debian.org/devel/debian-installer/ Note: you need the _daily built_ images, not the Etch Beta2 ones pgpo2MOnSJYQX.pgp Description: PGP signature
Re: How can I make mirrors?
Kimberley Crombie [EMAIL PROTECTED] writes: how do imake a mirror aeh, sorry for the last mail. I ment: apt-get install reprepro MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
S/390 and persistent device naming (was: s390 update - partman requirements)
On Monday 08 May 2006 09:16, Bastian Blank wrote:
I fixed the hardware configuration for s390 yesterday. It works
flawless now except that it needs some further indicators that it did
something.
Great.
Now it is time to switch to partman as partconf is completely out of
order.
Yes, it would be nice to be able to use partman for S/390 too.
This leads to a list of requirements in partman:
- Default disk label per disk type. DASD needs ibm disklabels,
fiberchannel disks needs something else, mostly used is msdos.
This is set in default_disk_label in definitions.sh in partman-base.
Sounds like it may need a bit more complex detection than used for other
arches.
- Support for non-default SCSI. It displays any different SCSI types as
SCSI... (...) which is only appropriate for plain old SCSI but not
for new types like libata, fiberchannel or iSCSI.
No idea.
- Templates for dasd.
Probably the simplest item on the list :-)
- Needs to use persistent device names. Is there some progress already
or must I do that myself? s390 requires either /dev/disk/by-path
(usable both for booting and in fstab) or /dev/disk/by-{id,uuid}
(only appropritate in fstab).
I'll come back to that in a separate mail.
- Must save exact informations about the root device or any device
which is needed for them if it is LVM/MD. s390 don't have device
autoconfiguration and therefor must know, which device it needs to be
configured to get the root.
No idea about this.
pgpq3KCrMlQt5.pgp
Description: PGP signature
Re: s390 update - partman requirements
On Monday 15 May 2006 15:01, Bastian Blank wrote:
/dev/disk/by-path (usable both for booting and in fstab) or
/dev/disk/by-{id,uuid} (only appropritate in fstab).
How can I get parted_server to use this paths? Must I issue a CLOSE
with the old device and an OPEN with the correct one? Or may I just
hack parted_devices?
No idea. Sorry.
pgpgUbsCVUI1R.pgp
Description: PGP signature
Re: s390 update - partman requirements
On Monday 15 May 2006 14:45, Bastian Blank wrote: partman-partitioning/storage_device/label/do_option already contains a selection for msdos/gpt. Should I just extend that or push the whole logic out? I would guess extending it for s/390 is best. pgpP8NhdFb0MH.pgp Description: PGP signature
