Re: amd64 porters IRC meeting: preparations for sarge
Thomas Steffen <[EMAIL PROTECTED]> writes: > On 4/26/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> If you have a chroot that is simple: >> >> 'apt-get install foobar' in the chroot >> dpkg --force-architecture -i /chroot/var/cache/apt/foobar*deb > > Yes, that is a start. But I don't think that any --force-* options > should be exposed to the user. Basically, dpkg should not be exposed. > So we would need a wrapper to handle this. > >> The multiarch proposal works without chroot and always works. Having >> the libs in chroots and the binary in / won't work with plugins or >> libs that load other files at runtime. > > I had a closer look at the multiarch proposal, and it does not solve > those problems either. It only states that they should be treated on a > "case to case" basis. Still, it needs to be worked out some way. With multiarch you just say apt-get install openoffice.org and it finds the i386 debs, downloads them, downloads any needed Depends in the right/best bitness and installs it all. 'apt-get install foobar:arch' to force a specific architecture if in doubt. What is there left to handle? >> All this is just bandaid till sarge is out of the way and true >> multiarch can be uploaded to debian. > > Well, I am not sure that multiarch is going to be so much easier, or > so much different in the end. But I agree, once sarge is out of the > way, things will certainly move forward again. > > Thomas Multiarch is completly different. Packages will be build for the right file positions and non overlapping. No need to cludge around with a chroot. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 porters IRC meeting: preparations for sarge
On 4/26/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > If you have a chroot that is simple: > > 'apt-get install foobar' in the chroot > dpkg --force-architecture -i /chroot/var/cache/apt/foobar*deb Yes, that is a start. But I don't think that any --force-* options should be exposed to the user. Basically, dpkg should not be exposed. So we would need a wrapper to handle this. > The multiarch proposal works without chroot and always works. Having > the libs in chroots and the binary in / won't work with plugins or > libs that load other files at runtime. I had a closer look at the multiarch proposal, and it does not solve those problems either. It only states that they should be treated on a "case to case" basis. Still, it needs to be worked out some way. > All this is just bandaid till sarge is out of the way and true > multiarch can be uploaded to debian. Well, I am not sure that multiarch is going to be so much easier, or so much different in the end. But I agree, once sarge is out of the way, things will certainly move forward again. Thomas
Re: amd64 porters IRC meeting: preparations for sarge
Thomas Steffen <[EMAIL PROTECTED]> writes: > On 4/25/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > [openoffice and libraries] > >> It's probably easier to write an installer that fetches and installes >> the i386 debs on the fly. > > Maybe it is just because of my research background, but I am looking > for a solution that can be generalised. So it should work for other > applications, too, including third party binaries if possible (think > alien). > > And I have to admit that an automated installer has its benefits > there. You could just give it an executable, and it checks and updates > the chroot, sets the library pathes etc... and it could interact with > dpkg in both systems, which means that it could bridge the "dependency > divide". If you have a chroot that is simple: 'apt-get install foobar' in the chroot dpkg --force-architecture -i /chroot/var/cache/apt/foobar*deb Thats enough in many cases already. But if foobar needs other binaries that you don't have outside the chroot you have to install them too. > So does it generalise to true multiarch support? Yes, I think it > could. It wouldn't matter which architecture you have, and which you > want to run, the problem is always (mostly) the same. The multiarch proposal works without chroot and always works. Having the libs in chroots and the binary in / won't work with plugins or libs that load other files at runtime. > The only question is how it relates to dpkg/apt-get. Is it like a > generalisation of dpkg, with multiarch support? No, dpkg would still > be used. Maybe like apt-get with multiarch support? Yes, that seems > closer. Or is it more like alien, a stop gap that usually works? In > the beginning, most likely yes. > > And the beauty is that the existing infrastructure does not have to be > changed at all. > > Thomas All this is just bandaid till sarge is out of the way and true multiarch can be uploaded to debian. So support to do anything cludgy for sarge is very limited. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 porters IRC meeting: preparations for sarge
On 4/25/05, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: [openoffice and libraries] > It's probably easier to write an installer that fetches and installes > the i386 debs on the fly. Maybe it is just because of my research background, but I am looking for a solution that can be generalised. So it should work for other applications, too, including third party binaries if possible (think alien). And I have to admit that an automated installer has its benefits there. You could just give it an executable, and it checks and updates the chroot, sets the library pathes etc... and it could interact with dpkg in both systems, which means that it could bridge the "dependency divide". So does it generalise to true multiarch support? Yes, I think it could. It wouldn't matter which architecture you have, and which you want to run, the problem is always (mostly) the same. The only question is how it relates to dpkg/apt-get. Is it like a generalisation of dpkg, with multiarch support? No, dpkg would still be used. Maybe like apt-get with multiarch support? Yes, that seems closer. Or is it more like alien, a stop gap that usually works? In the beginning, most likely yes. And the beauty is that the existing infrastructure does not have to be changed at all. Thomas
Re: amd64 porters IRC meeting: preparations for sarge
Thomas Steffen <[EMAIL PROTECTED]> writes: > On 4/23/05, Martin Zobel-Helas <[EMAIL PROTECTED]> wrote: >> Here we go: >> >> Logfile: http://debian-amd64.alioth.debian.org/irc-log.txt >> Summary: http://debian-amd64.alioth.debian.org/irc-summary.txt > > Thank you very much for the results and the log. The future does > indeed look promissing. > > But I do have a question about openoffice/chroot. As far as I could > figure it out, the prepared solution was to install the openoffice > package with a 32bit binary under /, and tell ld.so to use libraries > from a 32bit chroot to resolve openoffice. At least that works nicely > for me. Actualy ia32-libs and friends should have all OOo needs. > But now I see hints to use dchroot. And while to me as a developer > that seems fine, I think it is not a feasible solution for the "end > user". The chroot environment has so many subtle difference compared > to the normal environment, that it could be very confusing. At the end > of the day, the installation should appear as one system, and not as a > split personality :-) > > So is there any option planned to run openoffice (and other 32bit > apps) directly? It might still be located in /emul/i386, but I would > like to call it directly, without the dchroot wrapper. I think > openoffice can be installed into any directory, so it should be > possible. > > Thomas One possibility is to add an ia32-openoffie.org package that contains the 32bit OOo binaries but is for ia64/amd64. But the package would be huge. OOo source is already 165Mb. Add all the binary debs to that and you get the size of ia32-openoffie.org source. It's probably easier to write an installer that fetches and installes the i386 debs on the fly. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 porters IRC meeting: preparations for sarge
On 4/25/05, Lennart Sorensen <[EMAIL PROTECTED]> wrote: > Well there are plans for openoffice 2.x to be 64bit compatible so it cna > run natively instead. Yes, but the release date for openoffice 2.x has been pushed back, and if we are unlucky, they might drop 64bit support, too :-( At least I have not seen a working version anywhere as of yet. > I thought there were openoffice packages for 64bit that just required > some libs installed in the chroot/emul dir but would otherwise run as if > they were 64bit programs. Yes, and I think using a chroot is ok for the time being. In the long run, we have to simplify this. Maybe the 64bit dpkg can also look after the chroot? Kind of multiarch light? I can see some potential there. The problem I have with the chroot solution is that is it so amazingly ugly. The openoffice package needs special treatement, the user has to set up the chroot and change /etc/ld.so.config, dependencies do not work properly, and the changed /etc/ld.so.config interferes with library upgrades. But I am afraid that any change for the better requires at least a basic multiarch support in dpkg. And that seems a long way off. Thomas
Re: amd64 porters IRC meeting: preparations for sarge
On Sat, Apr 23, 2005 at 11:08:08PM +0200, Thomas Steffen wrote: > Thank you very much for the results and the log. The future does > indeed look promissing. > > But I do have a question about openoffice/chroot. As far as I could > figure it out, the prepared solution was to install the openoffice > package with a 32bit binary under /, and tell ld.so to use libraries > from a 32bit chroot to resolve openoffice. At least that works nicely > for me. > > But now I see hints to use dchroot. And while to me as a developer > that seems fine, I think it is not a feasible solution for the "end > user". The chroot environment has so many subtle difference compared > to the normal environment, that it could be very confusing. At the end > of the day, the installation should appear as one system, and not as a > split personality :-) > > So is there any option planned to run openoffice (and other 32bit > apps) directly? It might still be located in /emul/i386, but I would > like to call it directly, without the dchroot wrapper. I think > openoffice can be installed into any directory, so it should be > possible. Well there are plans for openoffice 2.x to be 64bit compatible so it cna run natively instead. I thought there were openoffice packages for 64bit that just required some libs installed in the chroot/emul dir but would otherwise run as if they were 64bit programs. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 porters IRC meeting: preparations for sarge
On 4/23/05, Martin Zobel-Helas <[EMAIL PROTECTED]> wrote: > Here we go: > > Logfile: http://debian-amd64.alioth.debian.org/irc-log.txt > Summary: http://debian-amd64.alioth.debian.org/irc-summary.txt Thank you very much for the results and the log. The future does indeed look promissing. But I do have a question about openoffice/chroot. As far as I could figure it out, the prepared solution was to install the openoffice package with a 32bit binary under /, and tell ld.so to use libraries from a 32bit chroot to resolve openoffice. At least that works nicely for me. But now I see hints to use dchroot. And while to me as a developer that seems fine, I think it is not a feasible solution for the "end user". The chroot environment has so many subtle difference compared to the normal environment, that it could be very confusing. At the end of the day, the installation should appear as one system, and not as a split personality :-) So is there any option planned to run openoffice (and other 32bit apps) directly? It might still be located in /emul/i386, but I would like to call it directly, without the dchroot wrapper. I think openoffice can be installed into any directory, so it should be possible. Thomas
Re: amd64 porters IRC meeting: preparations for sarge
Hi Kyuu, On Friday, 22 Apr 2005, you wrote: > Frederik Schueler wrote: > > >Hello, > > > >This is a reminder on the IRC meeting taking place on next > >saturday, April 23rd - the scedule was now set for 0700 UTC. > > > > > May I request that someone could perhaps brief on the results on this > list (or at least, post a logfile) after the meeting. I figure there are > others like me, who are interested in the matters but don't have any > useful expertise to bring to the meeting itself. Here we go: Logfile: http://debian-amd64.alioth.debian.org/irc-log.txt Summary: http://debian-amd64.alioth.debian.org/irc-summary.txt Greetings Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 porters IRC meeting: preparations for sarge
Frederik Schueler wrote: Hello, This is a reminder on the IRC meeting taking place on next saturday, April 23rd - the scedule was now set for 0700 UTC. May I request that someone could perhaps brief on the results on this list (or at least, post a logfile) after the meeting. I figure there are others like me, who are interested in the matters but don't have any useful expertise to bring to the meeting itself. /v\ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
amd64 porters IRC meeting: preparations for sarge
Hello, This is a reminder on the IRC meeting taking place on next saturday, April 23rd - the scedule was now set for 0700 UTC. The meeting will take place in #debian-amd64 on irc.oftc.net. The agenda is as follows: - the sarge release of debian-amd64 - patched versions of packages in sarge * patch D-I docs and choose-mirror for amd64? - security updates - CD and DVD installation media * include i386 debs for a chroot on the CD/DVD set? - Which combinations of sarge/testing/sid vs GCC versions ... to continue running buildd's for. - Should debian-amd64 actively push multiarch forward (to merge i386 and amd64)? Should we have packages with matching names that provide amd64 script wrappers for running chrooted i386 binaries ? - future of debian-amd64-gcc-4.0 Last-minute additions will be posted here: http://debian-amd64.alioth.debian.org/irc-meeting.txt Everyone interested is invited to join. Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
amd64 porters IRC meeting: preparations for sarge - second call
Hello, This is a reminder on the IRC meeting taking place on next saturday, April 23rd either 0700 UTC or 1400 UTC. The final scedule is still to be fixed. The initial call can befound here: http://lists.debian.org/debian-amd64/2005/04/msg00307.html the current scedule and topics list is to be found here: http://debian-amd64.alioth.debian.org/irc-meeting.txt Everyone interested is invited to join. Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: amd64 porters IRC meeting: preparations for sarge
Hello, On Tue, Apr 12, 2005 at 09:05:41AM +0100, Daniel James wrote: > Is this intended to be an open meeting? If so, I would like to listen > in. Everyone interested can join, of course :-) We will publish a log on alioth for those who cannot attend. Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: amd64 porters IRC meeting: preparations for sarge
Hello, The current scedule proposal is to meet on saturday 23rd, what allows us to find a timeframe fitting everyone's needs. I think 7:00 UTC is a good idea, alternatively 14:00 UTC. On Mon, Apr 11, 2005 at 02:30:09PM -0700, Alex Perry wrote: > I suspect another relevant agenda item is: Which combinations of > sarge/testing/sid vs GCC versions ... to continue running buildd's for. > > I suggest we segue into an adjacent topic area (once the main topics are > dealt with): Should debian-amd64 actively push multiarch forward (to > merge i386 and amd64) ? Should we have packages with matching names that > provide amd64 script wrappers for running chrooted i386 binaries ? I put a document on alioth listing the topics so far and added these 2. http://debian-amd64.alioth.debian.org/irc-meeting.txt Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: amd64 porters IRC meeting: preparations for sarge
Hi Frederik, > I would like to collect additional topics and scedule proposals for > the IRC meeting about the future of the debian-amd64 sarge > distribution. Is this intended to be an open meeting? If so, I would like to listen in. Cheers Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: amd64 porters IRC meeting: preparations for sarge
Frederik Schueler wrote: Now, what we need to start the meeting is: [...] 18:00 UTC is fine by me. Don't forget we've switched to summer time; it's 11am PDT for example. I'd like to avoid 8:00 UTC because that's 1am PDT but 7:00 UTC would be usable for me. I suspect another relevant agenda item is: Which combinations of sarge/testing/sid vs GCC versions ... to continue running buildd's for. I suggest we segue into an adjacent topic area (once the main topics are dealt with): Should debian-amd64 actively push multiarch forward (to merge i386 and amd64) ? Should we have packages with matching names that provide amd64 script wrappers for running chrooted i386 binaries ? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
amd64 porters IRC meeting: preparations for sarge
Fellow debian-amd64 porters, I would like to collect additional topics and scedule proposals for the IRC meeting about the future of the debian-amd64 sarge distribution. What I would like to discuss, is how we are going to handle: - the sarge release of debian-amd64 - patched versions of packages in sarge - security updates - CD and DVD installation media Additionally, I would like to discuss if we should fork debian-installer and use it with newer kernel versions than 2.6.8, since an increasing number of new amd64 mainboards do ship with hardware not supported by that ancient kernel version (megaraid, sk98lin, sata_nv, sata_sis to name a few). Now, what we need to start the meeting is: 1. a fixed date next week, or at the weekend? suited for everyone who wants to attend, for example April, 19th 18:00 UTC? or better 8:00 UTC? 2. additional items for the agenda. Kind regards Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
