Re: ia32-libs depends on ia32-apt-get ?
Goswin von Brederlow wrote: > Better add the pinings from /usr/share/doc/ia32-apt-get/NEWS.Debian.gz > as well. Goswin, you should put a "debconf warning" to point the apt pining solution to the user. Yannick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs depends on ia32-apt-get ?
Goswin von Brederlow wrote: > There where 3 options: > > 1) ia32-libs + ia32-libs-gtk (+ ia32-libs-kde + ia32-libs-qt) > ftp-master asked us to clean that up basically and > "it would not pass NEW if it where uploaded now" > > 2) ia32-lib* packages in the same schema as ia32-libs > vetoed by ftp-master for being way to many packages as ugly as > ia32-libs > > 3) ia32-apt-get > > So strike option 1 and 2 and what are you left with? Isn't it possible to have a system similar to apt-build? One would do "ia32-apt-convert ia32-libfoo" that would convert libfoo 32bits package and its dependencies, put it in a local repository. Then the user could install ia32-libfoo with apt-get, aptitude, whatever. Yannick PS: Of course, there would be a ia32-apt-update to update all the ia32-* installed. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Joerg Jaspert wrote: > On 11797 March 1977, Goswin von Brederlow wrote: > >> Will you do security support and regular uploads for it too? Or just a >> one shot upload? Will you stand against ftp-masters whish to remove >> it? > > You are actively working with all you can do to not only let us hate it > but actually consider removing it completly. Good job. Not being a DD, my thoughts may be meaningless here; but as an amd64 Debian user, I think I should speak in defence of Goswin. If I understand well, ia32-libs was not acceptable in its state for ftp- masters. I think that having all the ia32-* packages would not be acceptable either. The right thing would be to have multi-arch, but it will come when it's ready (that's not a bad thing). Waiting for multi-arch, Goswin's system permits me to use wine (and chromium browser) on my 64bits Debian. Of course, Goswin made mistakes as ia32-apt-get does not warn the user about the need of pining i386 packages and try to install converted binary ones. But his propositions to limit the conversion to library packages may solve the issue. Maybe all of this should go to experimental (is there a problem with wine depending on experimental packages for amd64?) but thank you Goswin for your work. Yannick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs transition
Goswin von Brederlow wrote: > The choices where > 1) rewrite the old ia32-libs + ia32-libs-gtk for the new libc6-i386 > or > 2) make ia32-apt-get take over (slightly prematurely in hindsight) If it's possible (according to ftp-masters) to have the old ia32-libs packages adapted to the new libc6-i386; the best thing, for me, would be to have a minimal[1] ia32-libs package in the archive and an ia32-archive tool for those who want other ia32-* packages or wants to keep up to date with library versions. Yannick [1] Minimal in the sense of the required libraries for packages needing i386 in main (only wine?). -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Goswin von Brederlow wrote: > And hey, the "good" reason was "diverting the package management tools > is unacceptable". But, no, we have to do insults instead of arguing. Alas, despite the diversion of the package management tools, I find ia32- apt-get pretty useful. For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript engine). With ia32-apt-get, I could install the 32bit version of my GTK theme engine so that Firefox can look good. Is there a design problem in converting 32bits libraries to ia32-* packages or the sole problem is the diversion of apt-get and co? If there's no design flaw, wouldn't ia32-archive be the correct path? I mean a system to install converted packages which is set apart the package management system (until the actual package installation of course)? Yannick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ia32-libs{-tools}, multiarch, squeeze
Tollef Fog Heen wrote: > ]] Yannick > > | For instance, I wanted to test Firefox 3.5 in 32bits on my amd64 > | Debian (64bit Firefox 3.5 does not have the new tracemonkey javascript > | engine). With ia32-apt-get, I could install the 32bit version of my > | GTK theme engine so that Firefox can look good. > > You could just use a chroot. It's not that hard. Hi Tollef, Of course I could use a chroot (even though I didn't know that schroot could permit me to use my home folder inside a chroot). But then, why do some bother with multiarch implementation? ;-) Correct me if I'm wrong, but doesn't multiarch do the same thing as ia32- apt-get but at the distribution level? Sincerely, Yannick -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ries.debian.org AKA ftp-master.debian.org back
2007-11-12T18:11:11+0100, "Steinar H. Gunderson" <[EMAIL PROTECTED]>: > On Mon, Nov 12, 2007 at 05:10:08PM +0100, Elimar Riesebieter wrote: > > $ lynx http://incoming.debian.org > > > > shows an awfully bad formated directory listing and the dak files as > > well. Is that usual now? > > I don't know about lynx, but in Firefox incoming.d.o looks like it > has always done. You have maybe the page in Fx's cache? I see with Iceweasel the same thing than Elimar. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do not touch l10n files (was Re: DDTP issue)
Dear Debian fellows, In France, we have an expression that says "a storm in a glass of water". I sincerely think we are in such a case. Let me summarise what happened, according to what I read on the debian-l10-french list. Once, there was a description for the Apache package using a long coma-separated list for the apache modules both in the original description and in the French translation. Then, the apache maintainers changed the description only changing the PHP3 in PHP. What bother Fabio Massimo is that the new French translation goes further and also changes the layout of the module list. I'm sure being a package maintainer is like taking care of a baby and, as a good father, you feel very concerned even with the translations of your baby. This honours you but... Fabio Massimo, you say : > Yes we are [unhappy with the new translation since in the first place we > asked nicely to change the layout > back to the original one (as it was before this translation) and then you > jumped in with some fancy reasons and even after 3/4 attempts to explain > to you why the layout has to be changed back you were not able to > understand them, I'm sorry, but you never explained - at least on the french l10n list - why the layout of the translation had to be changed. You only said that the maintainers are responsible of the layout and that you dislike the new one so it has to be changed. Dear maintainers, are the layouts of the translations so important? Maybe sometimes a strange layout can cause technical problems for its displaying, but I don't think coma-separated list vs. itemised list worth the fight. Furthermore, theses mails rise the problem of conflicts between maintainers and translators about translations. I am not a real Debian translator (do I loose all credibility for what I said before? ;-). I'm just a proof-reader. I agree that the English version of a Debian document should be the "official" one, because it's expected to be understood by most people. But when you have to translate a text, you are facing two sorts of problems: the specific requirements of your language (like non-breaking spaces in French) and the "in my language, we'd rather say this in that way". Thus, if we want to make a _good_ translation, and I'm sure everybody wants it here, we often have to make large changes in the translation. I can tell you that we are making big effort to be sure not to pervert the initial sense of the text. Is it a problem? Shouldn't the maintainers be confident in the translators and their work? I'm sure we are here to walk together to make Debian a good (well, in fact a better, it's yet very good) distribution. So lets not make a storms in glass of water. Communautairement, (fellowshiply ?) Yannick
