Re: Saying goodbye as D-I Release Manager, but not to D-I
On Fri, Jun 01, 2007 at 08:32:33PM +0200, Frans Pop wrote: > On Friday 01 June 2007 20:22, Sven Luther wrote: > > Sad to see you go, and sad that debian failed in mediating this in a > > way which allowed us both to have fun. Let this be a lection to the > > future, of the hurt that pride can cause to all involved and > > bystanders. > > I'd like to ask everybody to take this message as it is and to not reply > to it. All arguments and recriminations are already known and nothing new > can be added. Indeed, Frans, but the above was from November, and i asked you to consider a meetiong at FOSDEM around 4 months away. If you had shown any interest in solving this issue, it would have been solved, and this fact won't change even if you tell people to hear only your side of the story. The FUD campaign against me was torough enough that i did stand no chance, and you perfectly know that. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Saying goodbye as D-I Release Manager, but not to D-I
On Fri, Jun 01, 2007 at 07:41:08PM +0200, Frans Pop wrote: > Hello all, > > Yesterday I have retired from Debian. > > I have explained my reasons for that decision in detail on the > debian-private mailing list and I will not repeat them in detail here. > The main, but not the only, reason is that my involvement in the project > was no longer "fun" because of the continued personal abuse I have been > getting on various mailing lists from a certain person. Many of you may > not have seen much of that recently, but if you check the archives for > the debian-project list for the end of last month you will see what I > mean. Notice that the abuse included : An last a personal message to Frans, remember when we where in Extremadura, we had a good time, and we worked side by side. I seriously lament that it all degenerated like it did. I certainly have my part of responsability in this, but i passed though times, as you know. Let's put pride and arrogance and remembrance of past hurts aside, and let's again work on d-i all together, as it should be. And that it was you who twice asked for my expulsion from Debian. It is really sad that you could not grow up and stopd this childish persecution of me, and that when i proposed that we meet at FOSDEM, you chose to ask for my expulsion instead. Imagine what we could all have achieved in all this time if you had not rejected all the conciliation proposal i sent your way, Sad to see you go, and sad that debian failed in mediating this in a way which allowed us both to have fun. Let this be a lection to the future, of the hurt that pride can cause to all involved and bystanders. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: floppies, a radical proposal
On Fri, Jun 01, 2007 at 02:07:45PM -0400, Rick Thomas wrote: > > It would be really great if whatever solution results from this > discussion were also applicable to other architectures than x86. My > personal interest is in PowerPC (especially OldWorld PowerMacs) and > I'm willing to help as much as I can with the testing process (I'm > not a developer) Make sure you grab a copy of the moiboot packages from http://people.debian.org/~luther/miboot, before they get erased. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Powerpc netinst CD when selected install64 installs only powerpc not powerpc64 kernel image!
On Thu, May 24, 2007 at 12:09:12PM +0200, Michal Semler wrote: > > Hi all, > > Today I found serious error in powerpc netinst image, where I selected > install64 to install 64bit kernel. Installation continues and finishes > well, but system is unable to be booted from harddrive. > > After a while checking, I found out, that installer installed > linux-kernel-2.6.18-4-powerpc.deb image instead of > linux-kernel-2.6.18-4-powerpc64.deb which results everytime into > not-booting machine. > > Can anybody help me how to boot with rescue64 to my installed /dev/sda2 > partition? I am not familiar with yaboot. > > It is at > > /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED],0 partition=2 > > when I run only rescue64, rescue mode auto starts which I don't want and > there is also not possible select install any additional packege (kernel > package) I would go into rescue mode, go to a console, and chroot into the installed system, and there hand-install the right kernel (and remove the other one). for yaboot, you can either simply run ybin, which should do the right thing if yaboot-installer did his job correctly, or use the rescue menu item. If the d-i folk had not been so much preocuped with their witch-hunt, this kind of problems would not be happening. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stop. Breathe. Walk away.
On Wed, May 23, 2007 at 05:59:52PM +0200, Robert Millan wrote: > On Sun, May 20, 2007 at 05:20:26PM +0200, Geert Stappers wrote: > > Stop. Breathe. Walk away. > > > > See http://www.donotfeedtheenergybeast.com/ > > for more information. > > Ironicaly, publicly calling someone a demented maniac archieves precisely > the opposite purpose that this site seems to encourage. > > Yet, it seems to contain some wise advice. But I'm afraid you can't really > have wisdom without compassion. Find compassion first. What else is new, if those involved here just even knew the meaning of compasion and plain common sense, we would all happily be coding since over a year now. Sadened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stop. Breathe. Walk away.
On Wed, May 23, 2007 at 06:09:16PM +0200, Robert Millan wrote: > On Tue, May 22, 2007 at 03:31:46AM +0200, Sven Luther wrote: > > > > You are wrong, this is an issue pertaining to the whole of debian, who > > chose to let the DAMs punish me, while knowing this was unfair, while > > everyone with the least sense of decency would notice that people like > > Geert or Holger, or Frans, deserved the same or worse punishment. > > Nobody deserves punishment. Specially not punishment in retaliation for other > punishment. Can't we all just forget and get along? Well, Debian has decided that it didn't want to forget and get along, but rather to punish in a neboulous one-sided way. And furthermore, it chose to side with those who acted in a non-decent way, which refused any tentative of peaceful resolution of this conflict, which chose the camp of hate and rejection. I am all for forgetting and getting along, but the other side didn't want this, and why should they, while they where sure to get the full support of the powerful in debian. Frans still has me banned from the debian-boot irc channel (even making a typo in his ban :), and Geert is still attacking me in a totally unprovoked way. This doesn't sound something which is encouraging to "forgetting and get along". Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stop. Breathe. Walk away.
On Mon, May 21, 2007 at 03:46:57PM -0700, Steve Langasek wrote: > On Mon, May 21, 2007 at 10:47:51PM +0200, Geert Stappers wrote: > > Op 20-05-2007 om 15:36 schreef Steve Langasek: > > > On Sun, May 20, 2007 at 05:20:26PM +0200, Geert Stappers wrote: > > > > Stop. Breathe. Walk away. > > > > > See http://www.donotfeedtheenergybeast.com/ > > > > for more information. > > > > Er, what? Why are you quoting 'dontfeedtheenergybeast', and then > > > *forwarding* potentially inflammatory content to us > > > Because it is a better response then "ignore" > > No, "do something with the potential to suck a development mailing list into > a pointless off-topic discussion" is not better than "ignore". > > > > that wasn't on this mailing list before? > > > Due restricted time: Addressing the whole (d-i) community versus > > addressing just one person. > > AFAICS, this isn't an issue pertaining to "the d-i community", it's an issue > pertaining to "people who edit the wiki"... You are wrong, this is an issue pertaining to the whole of debian, who chose to let the DAMs punish me, while knowing this was unfair, while everyone with the least sense of decency would notice that people like Geert or Holger, or Frans, deserved the same or worse punishment. Shame on Debian, Shame on what you have all done to it, Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stop. Breathe. Walk away.
On Mon, May 21, 2007 at 10:47:51PM +0200, Geert Stappers wrote: > Op 20-05-2007 om 15:36 schreef Steve Langasek: > > On Sun, May 20, 2007 at 05:20:26PM +0200, Geert Stappers wrote: > > > Stop. Breathe. Walk away. > > > > > See http://www.donotfeedtheenergybeast.com/ > > > for more information. > > > > Er, what? Why are you quoting 'dontfeedtheenergybeast', and then > > *forwarding* potentially inflammatory content to us > > Because it is a better response then "ignore" A better answer is to do the (minimal on your part) effort to solve this issue in a human and decent way, but this would ask that you recognize you have been wrong and have been acting like an unfeeling bastard all along, which you are not emotionally equiped to do, so you go on the offensive in the most hurting way. Geert, i really don't understand how you (and the others involved here) can loook themselves in a mirror and not feel ashamed of what they have done to me. And you are all lucky i have a family, and am still, despite your efforts to destroy me, somewhat sane, if you had done to someone else less sane, what you have done to me, in could very well have ended in a blood bath, just look at the kind of things happening in US high schools for example. > > that wasn't on this mailing list before? > > Due restricted time: Addressing the whole (d-i) community versus > addressing just one person. What about being humanly decent, and recognizing what you have done, and asking for apology. Just look at everyone recognizing that Debian has acted unfairly against me in all this, and ask yourself why debian had absolutely to act unfairly. It was because you and holger and frans, and a couple of others could absolutely not live without forcing debian to act fairly in this. See what you have done to debian by your arrogance and stubborness ? You have forced debian to no more be something beautiful to be proud of, but something unfair and ugly, to be ashamed of. Shame on you, shame on the d-i team, Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Stop. Breathe. Walk away.
On Sun, May 20, 2007 at 05:20:26PM +0200, Geert Stappers wrote: > Stop. Breathe. Walk away. > > See http://www.donotfeedtheenergybeast.com/ > for more information. Hey, Geert and all, Why can't you guys not just leave me alone ? You already won all you wanted, and there is really no need to gloat over it, and keep coming at me. For some guys who accused me of all possible evil, and saying i can't forget old grudges, you behave in a real hypocrit way. Geert, i really regret i ever sponsored you into Debian, i guess the NM process should have some check in place to prevent people who like to make their fellow DD suffer to ever become DD, but then what do you want, like Wouter said, behaving as assholes is acceptable, provided the new release goes forward. This makes me sick, you cannot imagine how much, so ... Just go away, and torture someone else somewhere for a while, ok ? Saddened, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Thu, May 17, 2007 at 10:44:41AM -0500, Rolf Brudeseth wrote: > > On Wed, May 16, 2007 at 12:41:18PM -0500, Rolf Brudeseth wrote: > > > > > > > > I tested the script with the console attached to serial port 1 and 2 > (hvsi0 > > > and hvsi1). > > > > > > I had to make some minor changes to the script to get it to work. > > > > > > I don't know, but you may want to implement the changes differently. > > > Regardless, before you submit the final 90console script, I assume I > need > > > to figure out how to detect whether a graphics monitor is used as the > > > console, as well as how the ATX workstation behaves. > > > > Hi Rolf, ... > > > > I have a question here. Is this a safe way to handle this ? The options > > contain the variables of the OF, set by the user, but it is also > > possible to boot directly from the OF command line, bypassing the values > > found in options, or have special values passed from yaboot. On the > > pegasos, but i suppose the same holds true for IBM power boxes, i know > > it is even possible to pass these special values by the DHCP server. > > > > This would typically be done in a d-i install, where you want to > > over-ride the defaults, without changing the real values. I know i have > > done so myself. > > > > So, all in all, it is much better to do the same using the chosen > > properties, which is what should be used on CHRP for this kind of > > things, and is also said to be so in the CHRP spec. > > > > If you don't believe me, or otherwise ignore me, just ask someone with a > > clue on this and they will tell you so. > > I am not ignoring you, just slow at responding. I am getting input from > folks that are not adding their comments to this bug, and I am no Open > Firmware expert so it is taking me some time to wrap my head around this. > > But I am happy to change the script if you think I am not implenting the > changes in the optimum way. > > $ ls -l /proc/device-tree/chosen/ > total 16 > -r--r--r-- 1 root root 19 2007-05-17 10:23 bootargs > -r--r--r-- 1 root root 58 2007-05-17 10:23 bootpath > -r--r--r-- 1 root root 4 2007-05-17 10:23 cpu > -r--r--r-- 1 root root 40 2007-05-17 10:23 ibm,rpa-client-config > -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-end > -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,initrd-start > -r--r--r-- 1 root root 8 2007-05-17 10:23 linux,kernel-end > -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,phandle > -r--r--r-- 1 root root 4 2007-05-17 10:23 linux,stdout-package > -r--r--r-- 1 root root 22 2007-05-17 10:23 linux,stdout-path > -r--r--r-- 1 root root 4 2007-05-17 10:23 memory > -r--r--r-- 1 root root 4 2007-05-17 10:23 mmu > -r--r--r-- 1 root root 7 2007-05-17 10:23 name > -r--r--r-- 1 root root 4 2007-05-17 10:23 nvram > -r--r--r-- 1 root root 4 2007-05-17 10:23 stdin > -r--r--r-- 1 root root 4 2007-05-17 10:23 stdout > > I see that the following two files report the node, so changing the script > to use 'chosen' instead, and testing it on my hardware is no problem. > > $ cat /proc/device-tree/options/output-device > /vdevice/[EMAIL PROTECTED] > > $ cat /proc/device-tree/chosen/linux,stdout-path > /vdevice/[EMAIL PROTECTED] > > But I can not find an equivalent method in 'chosen' to determine whether > the console is mapped to hvsi0 or hvc0. > > $ cat /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible > hvterm-protocol Well once you have seen that chosen/linux,stdout-path points to [EMAIL PROTECTED], then you can revert to using the normal device tree for the compatible function. The main point is to use chosen to know what was done at boot time, since chosen is set either by the OF or thebootloader to inform the client program (in this case linux) about the different choices which where made at boot time. The options entry is no guarantee whatsoeve, just information about what the default option can be, but it can be overriden. Notice also, that stdin and stdout, should be two devices wxhich can be used to actually output and input information, altough i am not sure how this is supposed to work. Normally you could just ignore any of these choices, and simply have the chosen/stdin and cvhosen stdout used. Friendly, Sven Luther > > Let me know what I should use. I can either modify the script myself or if > you prefer you can send me a new one. Either way I can test it. > > > > > Friendly, > > > > Sven Luther > > > > > > > > > --- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Wed, May 16, 2007 at 12:41:18PM -0500, Rolf Brudeseth wrote: > > I tested the script with the console attached to serial port 1 and 2 (hvsi0 > and hvsi1). > > I had to make some minor changes to the script to get it to work. > > I don't know, but you may want to implement the changes differently. > Regardless, before you submit the final 90console script, I assume I need > to figure out how to detect whether a graphics monitor is used as the > console, as well as how the ATX workstation behaves. Hi Rolf, ... I have a question here. Is this a safe way to handle this ? The options contain the variables of the OF, set by the user, but it is also possible to boot directly from the OF command line, bypassing the values found in options, or have special values passed from yaboot. On the pegasos, but i suppose the same holds true for IBM power boxes, i know it is even possible to pass these special values by the DHCP server. This would typically be done in a d-i install, where you want to over-ride the defaults, without changing the real values. I know i have done so myself. So, all in all, it is much better to do the same using the chosen properties, which is what should be used on CHRP for this kind of things, and is also said to be so in the CHRP spec. If you don't believe me, or otherwise ignore me, just ask someone with a clue on this and they will tell you so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: questions regarding debian gui installer cutomization.
On Tue, May 15, 2007 at 06:52:44PM +0100, Luis Matos wrote: > Ter, 2007-05-15 às 20:13 +0530, Anant Shrivastava escreveu: > > hello everyone, > > i am anant shrivastava, a new member of this list, > > my company was working on developing an internal distro derived from RH > > earlier, but with the release of Debian 4.0 i am able to convince the > > administration on using Debian. > > now we are facing with few problems, > > 1) they want some changes in the installation process > > 2) regarding downloads of updates > > > > as far as updates download is concerned i have came to one solution i am > > downloading packages on one PC and then using apt-move created http/ ftp > > repo for updation for internal usage. is there any other option > > also i have to manually add the http and ftp details to each pc, is any > > workaround possible. > > you can use apt-proxy. see p.d.o/apt-proxy Or approx, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394970: /420820: no console set IBM p5 server
On Mon, May 14, 2007 at 12:28:20PM -0500, Rolf Brudeseth wrote: > > Is it understood how one determines which device file (hvsi0, hvsi1 or > hvc0) Open Firmware associates with the console as it pertains to IBM > System p servers? > > This can be determined by looking at properties under /proc/device-tree. > > Please let me know if this is needed and I will find the documentation. I > know how it is accomplished, I just need to make sure that I point to > documentation already released by IBM. ofpath or ofpathname (from yaboot or the ibm-power-utils or whatever that package is named) are the one doing the OF path from linux path mapping. Not sure it supports the other way around, but that would be the right way to handle this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Tue, May 15, 2007 at 08:03:13AM +0200, Frans Pop wrote: > On Monday 14 May 2007 23:55, Rolf Brudeseth wrote: > > > On Monday 14 May 2007 22:29, Rolf Brudeseth wrote: > > > > - Step 1: > > > > $ cat /proc/device-tree/options/output-device > > > > /vdevice/[EMAIL PROTECTED] > > > > ==> hvsi0 or hvc0 > > > > > > > > $ cat /proc/device-tree/options/output-device > > > > /vdevice/[EMAIL PROTECTED] > > > > ==> hvsi1 > > > > > > Do these pseudo files always exist, or just if a serial console is > > > used? > > > > These three device files should always be present in /dev. It is just a > > matter of specifying the correct one in /etc/inittab, regardless of how > > the console is accessed. > > > > > If they do always exist, what is their value if "the other device" is > > > used, or if a regular console is used? > > > > I am not sure I understand the question so let me try to explain it as > > follows. IBM System p5 servers can be configured in two mutually > > exclusive ways as far as consoles are concerned. > > You misunderstand me. I'm not concerned about the device files in /dev, > but about the files in /proc. > > We are going to be using the presence/content of the files > /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED], > /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] and > /proc/device-tree/vdevice/[EMAIL PROTECTED]/compatible to determine which > type > of console is being actually used, right? > > My question is: if hvsi1 is being used, what is the output of > cat /proc/device-tree/options/output-device/vdevice/[EMAIL PROTECTED] > or does that file just not exist in that case? Frans, forget about those existential questions. /proc/device-tree/chosen is what you want. It will contain a copy of all the relevant information used during booting, provided to you by the underlying firmware. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#420820: no console set IBM p5 server
On Mon, May 14, 2007 at 09:38:25PM +0200, Frans Pop wrote: > (No need to CC me. I see your replies on the debian-boot mailing list.) > > On Monday 14 May 2007 21:09, Rolf Brudeseth wrote: > > ~ # /usr/lib/finish-install.d/90console > [...] > > + readlink /proc/1560/fd/0 > > + rawconsole=/dev/console > > Thanks. So the debian-installer process thinks a regular console is being > used. That means that we do indeed need that redirection information you > referred to. > So, how do we determine which device is actually being used as console? The information of which console is used is available from the CHRP device tree. Probably something like : /proc/device-tree/chosen/stdout or /proc/device-tree/chosen/linux,stdout-path (This is from my Apple XServe G5, i don't have the p505 online right now, and cannot access it until next week), so Rolf, if you could share the content of your /proc/device-tree/chosen directory, and the content of those nodes actually of interest ? The stdout seems to be a pointer to a node of some kind, while the linux,stdout-path actually contains the path of the OF device used as stdout. This means that you would need something like ofpath or ofpathname to map it back to the actual /dev/hvc*|hvsi*. Notice also, that later linuces are able to auto-discover the actual output device used, and keep it as console, without the need of specifying console=/dev/*, altough i am not fully sure how this works. This is rather nice, especially as the actual name of the serial devices changes for the same hardware depending on how you use it, and the virtualized ones may even have a phantom /dev/ttyS or /dev/tty somewhere, since adding /dev/hvc0 in addition to both /dev/ttyS and /dev/tty on the kernel command line does desactivate the hvc output. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 05:14:09PM -0300, Otavio Salvador wrote: > Steve Langasek <[EMAIL PROTECTED]> writes: > > > Frans already asked most of the questions that I had. A few others: > > > > Is anybody else using grub2 as a default bootloader today? > > Not yet. Just an entry point, which may or may not be important here. Sun has decided to make grub2 the default for opensolaris, including their powerpc opensolaris port. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 09:59:51AM -0300, Otavio Salvador wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hello, > > We, the GRUB team, want to swtich to GRUB2 due many reasons, basicaly: > > - easier to maintain; > - better codebase; > - multi-arch support; > - active upstream; > > Our current plan is to finish the update-grub2 merging on upstream > side (being handled by Robert) and then upload a new package to > Debian. This package after moving to lenny ought be set as default > boot-loader in grub-installer (while we still offer grub as an option > during the test cicle). > > The upgrade from grub to grub2 will be transparent since menu.list can > be automaticaly converted to the new format and this will be in place > when we start the default boot-loader change. > > After doing it, we intend to drop grub from archive since it's a bunch > of patches difficult to maintain and hard to follow. > > Thoughts? I wonder if we will also move from yaboot-installer to grub2-installer on powerpc, and if you have given any thought to that migration path ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i for ps3
On Fri, Apr 20, 2007 at 01:36:52PM -0300, Otavio Salvador wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Thu, Apr 19, 2007 at 03:09:37PM -0400, Joey Hess wrote: > >> Hi guys. I wonder if you could update us on the current status of d-i > >> for the ps3. Has there been any progress on the kernel? If there are d-i > >> patches that are ready to be merged to trunk now would be a good time to > >> do that. > > > > disclaimer: the below you is a plural you meaning those of the d-i team > > who will without doubt recognize themselve in this. > > > > Well, i have a ps3, and had intentions to actually do some work on them, > > but given how you so vehemently refused to have anything to do with me, > > rejecting all my tentatives to solve this lamentable dispute, rejecting > > even a RL meeting at FOSDEM, responding by an active role in the > > expulsion request, it is probably a bit hypocrit of you to ask about > > this, especially given the further punishing decision of the DAMs about > > this. > > Sorry Sven, > > I personally like you a lot and do not have problems with you but > instead to claim again about it, start a tree with it and then put it > somewhere to someone grab the fixes from it. > > git-svnimport or even git-svn would do it nicely to you. > > I do think you should start to work intead of worry too much about > it. You have done, and do, a great work overall and I do want you keep > this all mess on the past. Do the right thing and forget the > other. That's what you ought to do. I cannot do anymore any debian work without thinking about all the hurt which was done to me, sorry, but it will be a long time until i ever find back any motivation to do work on debian or any other free project. And it is by the hatred and harrasment of the like of frans and joeyh, who are the primary causes of this, so after over a year of witch hunt against me, and pure rejection of the work i used to do on powerpc, i find it shameless and hypocrit of joeyh to write mails like this. And i will not be silenced, whatever debian further does to hurt me. Hurt, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: d-i for ps3
On Thu, Apr 19, 2007 at 03:09:37PM -0400, Joey Hess wrote: > Hi guys. I wonder if you could update us on the current status of d-i > for the ps3. Has there been any progress on the kernel? If there are d-i > patches that are ready to be merged to trunk now would be a good time to > do that. disclaimer: the below you is a plural you meaning those of the d-i team who will without doubt recognize themselve in this. Well, i have a ps3, and had intentions to actually do some work on them, but given how you so vehemently refused to have anything to do with me, rejecting all my tentatives to solve this lamentable dispute, rejecting even a RL meeting at FOSDEM, responding by an active role in the expulsion request, it is probably a bit hypocrit of you to ask about this, especially given the further punishing decision of the DAMs about this. Hurt, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417871: debian-installer: On a system without ide disks and floppy, d-i takes forever in disk discovery.
Package: debian-installer Severity: normal On an x86 system (actually two different boards, and older athlon 1.2Ghz based via board, and a newer tyan nforce based opteron board, when there are no ide disks (except the cdrom drive), nor floppy driver connected, but only scsi or sata disks, the disk discovery phase takes forever (like a couple of minutes in the worst case). -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D-I RC2 images available for testing
On Wed, Mar 14, 2007 at 05:25:50PM +0900, Charles Plessy wrote: > Le Mon, Mar 12, 2007 at 04:05:09PM +0100, Frans Pop a écrit : > > > > For all architectures, except for m68k, installer and CD/DVD images of > > what is going to be D-I RC2 are now available for testing. RC2 is > > scheduled to be the D-I release shipped with Etch. > > > > Netboot, floppy and hd-media images are available from: > > http://ftp.nl.debian.org/debian/dists/etch/main/installer-/rc2/images/ > > > > CD/DVD images are available from: > > http://www.debian.org/devel/debian-installer/ > > Dear D-I team, > > I wanted to give a try to the RC2 installer, and found a gtk image for > powerpc64 in the ftp.nl site. This image does not work (crash of the > graphical interface during startup), but in the end, I am wondering if > it was supposed to work at all, or if it is there because the iso is > built automatically on each platform. What hardware are you using ? I suppose the iMac G5 has nvidia graphics, right ? Can you provide an lspci output of it ? We started an effort last year to get things working on powerpc, but for reasons you can imagine, i was forced to not pursue this, and so ... There was a wiki page somewhere, mayb e Attilio or Eddy can give you the link, it would be good to add your hardware there, and do a followup on those tests, and see why directfb/directfb-gtk is failing on this hardware. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with tyan thunder n3600B board, where are the netboot x86 images ?
On Mon, Mar 12, 2007 at 12:09:29PM -0700, Steve Langasek wrote: > On Mon, Mar 12, 2007 at 05:37:31PM +0100, Sven Luther wrote: > > > for those who care about debian, and not only for their own private feud : > > > 17:19 -!- Irssi: Join to #debian-boot was synced in 1 secs > > 17:19 < svenl> ah, nice, i am no more banned :) > > 17:20 < fjp> Don't think I've ever tested raid or lvm on s/390. > > 17:20 < fjp> svenl: Sorry, but that is a mistake then. > > 17:20 < svenl> fjp: i think i got hand on a newer tyan board, where the > > daily > > image dies somwhere in the SATA drivers, unless > > Surely a kernel problem, anyway? and reported as : 414580 Still, this means this problem is present in rc2, which was asked to be tested. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with tyan thunder n3600B board, where are the netboot x86 images ?
On Mon, Mar 12, 2007 at 12:09:29PM -0700, Steve Langasek wrote: > On Mon, Mar 12, 2007 at 05:37:31PM +0100, Sven Luther wrote: > > > for those who care about debian, and not only for their own private feud : > > > 17:19 -!- Irssi: Join to #debian-boot was synced in 1 secs > > 17:19 < svenl> ah, nice, i am no more banned :) > > 17:20 < fjp> Don't think I've ever tested raid or lvm on s/390. > > 17:20 < fjp> svenl: Sorry, but that is a mistake then. > > 17:20 < svenl> fjp: i think i got hand on a newer tyan board, where the > > daily > > image dies somwhere in the SATA drivers, unless > > Surely a kernel problem, anyway? Probably, i guess i will try to build some 2.6.20 based d-i images or something. > > 17:20 < svenl> unless i have fucked hardware. > > 17:21 < svenl> fjp: where did you guys put the link of the non-iso images on > > the d-i web site ? > > Isn't that the heading 'other images (netboot, usb stick, floppy, etc) > pointing to http://people.debian.org/~joeyh/d-i/images/daily/ ? Yep, my fault, i didn't see them. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: previous unspoken words
On Mon, Mar 12, 2007 at 07:30:41PM +0100, Geert Stappers wrote: > On 12-03-2007 at 17:37 wrote Sven Luther: > under Subject: problems with tyan thunder n3600B board, where are the netboot > x86 images ? > > > Well, > > > > for those who care about debian, and not only for their own private feud : > > > > 17:19 -!- Irssi: Join to #debian-boot was synced in 1 secs > > 17:19 < svenl> ah, nice, i am no more banned :) > > 17:20 < fjp> Don't think I've ever tested raid or lvm on s/390. > > 17:20 < fjp> svenl: Sorry, but that is a mistake then. > > 17:20 < svenl> fjp: i think i got hand on a newer tyan board, where the > > daily > > image dies somwhere in the SATA drivers, unless > > 17:20 < svenl> unless i have fucked hardware. > > 17:21 < svenl> fjp: where did you guys put the link of the non-iso images on > > the d-i web site ? or alternatively, where are the full d-i x86 daily > > builds ? > > 17:21 < svenl> fjp: and since i used the daily netinst builds, i guess this > > applies to RC2 also, i want to try some netboot images. > > 17:22 -!- mode/#debian-boot [+o fjp] by ChanServ > > 17:22 -!- mode/#debian-boot [+b [EMAIL PROTECTED] by fjp > > 17:22 -!- svenl was kicked from #debian-boot by fjp [fjp] > > > > Anyone has any kind of experience with those tyan boards and see this same > > problem ? > > > > And could it be possible to restore the non-iso images links to the web > > site ? > > > > Friendly, > > > > Sven Luther > > > On FOSDEM 2007 saturday I didn't say a word to Sven Luther. > On sundaymornig there was only a small "hi". > > I should have said: > > Sven, We are through. > You go your way, I go my way. Fine, but then, do so without hurting debian, please. And to think that i actually advocated you :/ Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problems with tyan thunder n3600B board, where are the netboot x86 images ?
On Mon, Mar 12, 2007 at 06:32:32PM +0100, Frans Pop wrote: > On Monday 12 March 2007 17:37, Sven Luther wrote: > > 17:19 -!- Irssi: Join to #debian-boot was synced in 1 secs > > 17:19 < svenl> ah, nice, i am no more banned :) > > 17:20 < fjp> svenl: Sorry, but that is a mistake then. > > Note that Sven was banned from #debian-boot today not because of his > questions, but because the ban that was already in place was not working > because Sven changed providers or something. > > Sven has been banned from the #debian-boot channel since the end of > December, and will remain banned from that channel until such time as we > decide the ban should be lifted. Frans, i was banned in october or so, but then later, i was unbanned again, and then you re-banned me without reason or provokation. So, even your earlier ban is unnacceptable, and shows clearly that you are not fit to be a leader of d-i anymore, since you have again and again showed that you are unabled to put your pride and personal vendetta against me aside and try to work together for the greater good of debian, despite my many (innumerable soon :) attempts at reconciliation. Please grow up and forget the past, and think of what debian stands for, and what we are trying to achieve, and how much you have already damaged it by your immature behaviour. /me still wishes that we could have discussed this at FOSDEM, an oportunity lost, and those oportunities to meet in person are few indeed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
problems with tyan thunder n3600B board, where are the netboot x86 images ?
Well, for those who care about debian, and not only for their own private feud : 17:19 -!- Irssi: Join to #debian-boot was synced in 1 secs 17:19 < svenl> ah, nice, i am no more banned :) 17:20 < fjp> Don't think I've ever tested raid or lvm on s/390. 17:20 < fjp> svenl: Sorry, but that is a mistake then. 17:20 < svenl> fjp: i think i got hand on a newer tyan board, where the daily image dies somwhere in the SATA drivers, unless 17:20 < svenl> unless i have fucked hardware. 17:21 < svenl> fjp: where did you guys put the link of the non-iso images on the d-i web site ? or alternatively, where are the full d-i x86 daily builds ? 17:21 < svenl> fjp: and since i used the daily netinst builds, i guess this applies to RC2 also, i want to try some netboot images. 17:22 -!- mode/#debian-boot [+o fjp] by ChanServ 17:22 -!- mode/#debian-boot [+b [EMAIL PROTECTED] by fjp 17:22 -!- svenl was kicked from #debian-boot by fjp [fjp] Anyone has any kind of experience with those tyan boards and see this same problem ? And could it be possible to restore the non-iso images links to the web site ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414574: debian-installer web site is missing links to the non-iso d-i images.
Package: debian-installer Severity: normal I wanted to test a d-i daily build netboot image on this tyan motherboard, which seems to have some sata driver troubles, but was unable to find the netboot images on the web site anymore. Only iso links remain, please fix this. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#411446: installation-reports
On Tue, Feb 20, 2007 at 03:26:33PM +0100, Frans Pop wrote: > reassign 411446 clock-setup 0.13 > retitle 411446 [powerpc] Should not select UTC for iBooks > thanks > > On Monday 19 February 2007 08:12, Todd Partridge wrote: > > Comments/Problems: > > Used both the x86 and PPC Install Guide. The PPC Guide isn't entirely > > updated for PPC. > > Yes, we're aware of that. However, it is up to the Debian PowerPC > community to update that and unfortunately so far nobody has stepped up > to work on that. Frans, There is no wonder of that if you keep insulting the powerpc community, like you did at the start of january, while i was banned and not posting [0]. Please, let's put the past behind us, and put again the debian project as our top priorities, and all work together to make debian the best distribution out there, instead of loosing so much time with hate and in-fighting. I was sad that you chose not to meet with me at FOSDEM, and that when i greeted you in the hall outside the debian room, you chose to ignore me and pass by me looking the other was, as well as the way you chose to refuse to participate in the discussion concerning my ideas for the kernel and d-i, and the possibilities initramfs-tools offers to us. We have done ourself a lot of hurt since last year, where we were both at extremadura and at FOSDEM, and we had a good time together, let us go back to this time, and put aside the dispute which riped us in between. I am sure we will all have a hard time forgetting what happened, but it is a sign of maturity to be able to put it aside for the greater good. I still have faith in you and the others involved in this, that you will be able to grasp this, and that we can all work in harmony and go back to hacking happily ever after. [0] - http://lists.debian.org/debian-powerpc/2007/01/msg00068.html Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412723: yaboot-installer: yaboot sets wrong partition number in LVM/RAID situations.
Package: yaboot-installer Version: 1.1.9 Severity: critical Tags: d-i Justification: breaks the whole system When doing an LVM over RAID install on an apple XServe, we have three partitions : sd[ab]2 -> the yaboot partition, sd[ab]3 -> /boot and sd[ab]4 the LVM partition, which holds the root. But / is on a LVM device, and /boot on a RAID1 device, which yaboot knows how to read, since a RAID1 partition will be seen as a normal partition individually. The problem is due to the fact that our /boot is in /dev/md0, and that we want yaboot to look at the partitions containing this RAID1 partition, namely /dev/sd[ab]3. This leaves the system unbootable on a reboot, thus the severity of this bug report. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397973: Bug still present
tags 397973 + confirmed thanks I just confirmed that this bug is still present in today's d-i (daily built from the SVN, r45447). We booted the Xserve on the serial console, did the installation normally, and in partman created the RAID partition on a mac partition table. This failed to create the RAID flag, and thus partman-md failed to detect the disks, with the error message shown in earlier reports. Going into a shell, setting the flag by hand, and then going back to partitioning and it works fine, so maybe this could be added to the erratas. Notice again that there is absolutely nothing in reproducing this which needs powermac hardware to test, and i am sure that i can even be reproduced in quemu or vmware. You just need to chose a mac partition table, and you will face this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 11:52:12AM +0100, David Härdeman wrote:
> On Fri, Jan 26, 2007 at 10:52:39AM +0100, Sven Luther wrote:
> >Next step would be :
> >
> > 1) write a program writing to stdout and dropping the actual error message
> > somewhere.
>
> How about this:
>
> #include
> #include
> #include
> #include
>
> #define LOGFILE "/stdouttest.log"
> #define TESTMSG "This is a test string\n"
>
> int
> main(int argc, char **argv, char **envp)
> {
> FILE *logfile;
> int printerrno;
> char *printerror;
> int retval = EXIT_FAILURE;
> int result;
>
> /* Setup a log file */
> logfile = fopen(LOGFILE, "a");
> if (!logfile)
> exit(retval);
>
> fprintf(logfile, "Program %s started\n", argv[0]);
>
> /* Print to stdout */
> result = fprintf(stdout, TESTMSG);
>
> /* Log results */
> if (result < 0) {
> printerrno = errno;
> printerror = strerror(printerrno);
> fprintf(logfile, "Printing failed (%i): %s\n",
> printerrno, printerror);
> } else if (result < strlen(TESTMSG)) {
> fprintf(logfile, "Printing was truncated to %i bytes\n",
> result);
> } else {
> fprintf(logfile, "Printing successful\n");
> retval = EXIT_SUCCESS;
> }
>
> /* We're done */
> fclose(logfile);
> exit(retval);
> }
Thanks, i will try, but i won't have time until i am back from solution linux
next thursday.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#403136: XServe G5 has no hardware deffect, so this *IS* a udev bug :/
On Fri, Jan 26, 2007 at 11:11:45AM +0100, Marco d'Itri wrote: > On Jan 26, Sven Luther <[EMAIL PROTECTED]> wrote: > > > 1) write a program writing to stdout and dropping the actual error message > > somewhere. > Just add something like this to the top of the affected scripts: > > exec >> /dev/xxx.log 2>&1 It tells me that the pipe was closed by the other side, not very helpful, the other side being udevd. The idea was to try to find out more about the exact error, but i guess maybe adding explicit debugging to udevd is the only way out here. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
XServe G5 has no hardware deffect, so this *IS* a udev bug :/
tags 403136 + d-i tags 403136 + needhelp thanks Well, After speaking some with various folks, and someone else testing the same d-i which failed here on other XServe's, altough maybe not from the same generation (mine is from september 2005 i was told), i became suspicious, and brang the machine to an apple technical center, for defect testing. The machine came back today, and it was working perfectly, passed all apple hardware diagnostic tests, and ran full tests of mac-os-x during various days without problems. Furthermore, YDL 4.1 installs fine, and also has no problems whatsoever with the (somewhat older) udev installation there, and since this is an issue which surfaced around november rather suddenly (it was in a datacenter a couple of weeks, then upgraded, and at the first reboot, everything broke), i suspect it is indeed some strange udev issue. Let's again summarize the situation : 1) udev does not create the /dev/sd* device nodes, either in initramfs-tools or in d-i. Probably other nodes are affected. 2) the udev d-i scsi-devfs.sh scripts, which is in charge of creating that node, dies when writing to stdout, which is piped to udevd. 3) ubuntu (of late november) exhibited the same problem. 4) yaird did not work, but for some other reason (not recognizing a given node, didn't investigate more). This makes the box fully unusable and unsuported both in d-i and in normal debian, thus the RC status, furthermore something very strange is going on with udev. Next step would be : 1) write a program writing to stdout and dropping the actual error message somewhere. 2) contact udev author and ask for his help, since Marco said he didn't have a further clue, and this may be an upstream problem. 3) fix yaird to work on it, and see if the machine is stable with yaird and without udev. More to this once i have the box back, and am back from the Solution Linux show in paris. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#352914: reopen, until the issues mentioned in the Fri, 8 Sep 2006 11:13:59 +0200 mail have been checked.
reopen 352914 thanks Reopening this bug report. There are a couple of issues mentioned in : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352914;msg=130 Which have not been fully confirmed to be fixed. Not sure if this is the best way, or if opening a new bug report for them would be best. I will investigate this first chance in february, and provide feedback in the bug report. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392764: Can't reproduce on PowerStack, MAC partition issue only?
On Sun, Jan 21, 2007 at 07:58:47PM +0100, Ulrich Teichert wrote: > Hi, > > I tried to reproduce this bug on my Motorola PowerStack II (PPC prep), > but did not succeed. I've used the d-i daily build from 2007-01-19, > netinst iso and booted the netinst kernel over TFTP (yes, I know this > isn't supported, but my bandwith doesn't allow a full netinstall). > > During manual partitioning, I created two RAID partitions: > > [EMAIL PROTECTED]:~$ cat /proc/partitions > major minor #blocks name > >8 08891556 sda >8 1 16033 sda1 >8 2 489982 sda2 >8 34184932 sda3 >8 44192965 sda4 >9 04184832 md0 > > Which is a brain-dead setup with only one disk and a RAID1 on two partitions: > > [EMAIL PROTECTED]:~$ df -h > FilesystemSize Used Avail Use% Mounted on > /dev/md0 4.0G 390M 3.4G 11% / > tmpfs 62M 0 62M 0% /lib/init/rw > udev 10M 44K 10M 1% /dev > tmpfs 62M 0 62M 0% /dev/shm > > I haven't seen any failure, which suggests that the problem only shows up > on MAC partition types (the PowerStack uses PC-style partitions). > > Sorry, but it looks like I don't have the hardware to track this down, yes, it is a mac partition table issue. There where actually two bugs, one which i fixed, and was long fixed in ubuntu but the fix didn't go back to debian until i investigated, and the other which is not in parted, but in partman, and is still open. It is possible to test this on any hardware, but you would need a second disk if your firmware/bios is not able to boot from mac partition tables, like i believe is the case for PReP boxes. This can also be tested on plain x86 boxes with a second disk. My believe is that since mac partitions used to not have the RAID flag, that partman somewhere has some explicit test for x86 partitions, and sets the RAID flag only in those cases, or something. I will try to reproduce his on pegasos and its amiga partition tables, which are in the same case as the mac partitions. partman actually *ERASES* the raid flag set by hand by parted, which is rather strange, and hints strongly at some problem in partman-md (but also possibly mirrored in partman-lvm, which has a similar flag setup). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397973: #397973 [powerpci/mac] partman-md appears to not write back the raid flag to partitions.
On Fri, Jan 12, 2007 at 07:51:40PM +0100, Frans Pop wrote: > This issue may possibly be fixed by partman-base (101). Please test. Well, i have done an d-i install, created the devices by hand, chosen in expert mode unstable, which i suppose will pull in the above version, but haven't really found out a way to test it (please add the version to syslog when they get installed, this would be very helpful), and have to say that the problem still persists. I create two 1GB raid partitions, and try to create a RAID1 device, and find the "No RAID partitions available" dialog. When i go into parted, i notice that the raid flag has gone, replaced with a swap flag, which seems strange. Both of them used to be swap partitions prior to the test though. I set the raid flags back, go back to partman, who mentions me a dialog "please make sure you are happy with the partitions table and commit it" (paraphrased i forgot to copy, but you get the meaning), and the raid flags are gone again. To work around this, you have to go into parted, after the first partman-md dialog, and set the raid flags. The funny thing is that the raid flag is shown in the main partman manual partitioning dialog, so i suppose it is in the database, unless these flags are detected and not taken from the partman datas or something. Without this, i would have thought that partman had the non-raid stored in its data, and when doing the write to disk, did write the non-raid flag (well, erased the flag i guess). It would be really helpful if this could be reproduced on an x86 box, with a mac partition table (expert mode, chose pmac as partition table format for the disk). So, unless i made a mistake, i confirm that this bug is still present. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397973: #397973 [powerpci/mac] partman-md appears to not write back the raid flag to partitions.
On Fri, Jan 12, 2007 at 07:51:40PM +0100, Frans Pop wrote: > This issue may possibly be fixed by partman-base (101). Please test. I will, will need to see if i can manually work around #403136 to reach the partitioning step. If i create the sd* devices by hand it usually works, but dies horribly during base-install, but this should be enough to test this fix. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392764: closed by Frans Pop <[EMAIL PROTECTED]> (#392764 partman: [powerpc] RAID support is broken on powermac hardware (64bit, XServe G5))
On Fri, Jan 12, 2007 at 06:02:06PM +0100, Frans Pop wrote: > On Friday 12 January 2007 17:10, Sven Luther wrote: > > reopen 392764 > > # Clueless closing of this bug, probably due to a confusion with > > another, # separate, but similar bug. > > thanks > > > > Frans, you know that i did open two bugs, because those where two > > separate issues, right ? > > Did you even bother to READ the main reason that I closed this BR: > > > Closing this bug report as the issue was traced to a bug in parted > > > (#392767) which has been solved in the mean time. > > I don't see _any_ evidence in the report that there is still an issue > after #392767 was solved. _You_ identified #392767 as the root cause of > this BR after all. I opened both bugs, didn't i ? I investigated both of them, i found a fix to the previous bug, and applied it, and provided a patch, and tested it and discussed it upstream. The second issue was still there, which is why i opened the second and separate bug report, and mentioned the issue to you and holger and others numerous times, asking for help, since despite me looking into the partman code at some length, i couldn't find any obvious source of this bug. Also, the fact that, as described in the original bug report, and the "installing raid on mac" thread i started on debian-boot/debian-powerpc, using the parted tool allows one to set the raid flag, which is then removed by partman-md again when first invoked. This is definitively an obscure partman bug. Please, don't let your hatred of me, or past disagrement, or whatever you want to call it cloud your judgement, and let's all honestly try together to make debian the best technical distribution out there. I have gladly accepted to stay away from debian lists if it can help this, and i hope that you and others can also learn to put arrogance and remembrance of past hurts aside and all work together. Maybe you should have taken *GOOD* resolutions for new year instead of what you have done, i know i did :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397973: Processed: upping severity, as discussed with Steve ...
severity 397973 serious # 12:18 < vorlon> fjp: I would think that not being able to do a RAID install # should be considered RC these days, do you disagree? thanks On Fri, Jan 12, 2007 at 03:08:21PM +0100, Frans Pop wrote: > > On Friday 12 January 2007 10:33, Debian Bug Tracking System wrote: > > Bug#397973: [powerpci/mac] partman-md appears to not write back the > > raid flag to partitions. Severity set to `serious' from `important' > > I don't agree that this issue is RC. It does not match any of the > criteria. > > 1) This issue does not actually break anything. It just makes it > impossible to make use of an optional feature (software RAID) during > installation. > > 2) The issue affects only a limited group of users as it is architecture > specific: software RAID support in partman works just fine on at least > i386, amd64, sparc and hppa. I'm not sure about other architectures, but > at least we have no reports of breakage there. > > 3) There is no regression, or at least, I do not see how there can be as > software RAID support and general partman code has not been touched at > that level during Etch development. This rather looks like an incomplete > implementation of software RAID support for this particular architecture. > As such, and since there currently (unfortunately) is no lead partman > maintainer, it is primarily the responsibility of the PowerPC community > to provide the missing bits and pieces needed to implement the support. > > So, IMO as D-I RM, this issue does not make partman-md "unsuitable for > release". 12:18 < vorlon> fjp: I would think that not being able to do a RAID install should be considered RC these days, do you disagree? What else is there to say ... > Note for future reference: this BR is possibly related to: > http://bugs.debian.org/392764 Unrelated, this was, to the best of my knowledge, a separate bug, which i investigated and fixed, and colin had already fixed for ubuntu and commented on it later on. It is unrelated to this bug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392764: closed by Frans Pop <[EMAIL PROTECTED]> (#392764 partman: [powerpc] RAID support is broken on powermac hardware (64bit, XServe G5))
reopen 392764 # Clueless closing of this bug, probably due to a confusion with another, # separate, but similar bug. thanks Frans, you know that i did open two bugs, because those where two separate issues, right ? Friendly, Sven Luther On Fri, Jan 12, 2007 at 07:03:46AM -0800, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > #392764: partman: [powerpc] RAID support is broken on powermac hardware > (64bit, XServe G5), > which was filed against the partman package. > > It has been closed by Frans Pop <[EMAIL PROTECTED]>. > > Their explanation is attached below. If this explanation is > unsatisfactory and you have not received a better one in a separate > message then please contact Frans Pop <[EMAIL PROTECTED]> by replying > to this email. > > Debian bug tracking system administrator > (administrator, Debian Bugs database) > > > --- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > Date: Fri, 12 Jan 2007 15:07:58 +0100 > From: Frans Pop <[EMAIL PROTECTED]> > Subject: #392764 partman: [powerpc] RAID support is broken on powermac > hardware > (64bit, XServe G5) > To: [EMAIL PROTECTED] > Message-id: <[EMAIL PROTECTED]> > > Closing this bug report as the issue was traced to a bug in parted > (#392767) which has been solved in the mean time. > > If there is still a remaining issue with RAID flags, that is probably > already covered by #397973, and so this can still be closed as it is a > duplicate. > > Cheers, > FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405705: [powerpc, manual] Booting of PREP machines
On Sat, Jan 06, 2007 at 12:12:25PM +0100, Ulrich Teichert wrote: > Hi, > > >On Friday 05 January 2007 18:17, Ulrich Teichert wrote: > >> Currently, the only &arch-title; subarchitectures that support CD-ROM > >> -booting are PReP and New World PowerMacs. On PowerMacs, hold the > >> +booting are PReP (with the exception of Motorola PowerStack machines) > >> +and New World PowerMacs. > > > >Does this mean that booting from CD is known to work for other PReP > >systems? > > I think that Sven Luther had contact to somebody who booted a RS/6000 140p > that way. But that's only hearsay, my 140p is currently refusing to boot > *at all*, I need to take it apart :-(. Those IBM boxes are such divas, > you don't boot them for a month and pooof, they won't boot anymore for > anybody > > That's why I only excluded the PowerStacks in the above paragraph - I am > sure that this class of machines does not boot from the daily installer > CDs, I've not tested other PReP boxes. Someone indeed mentioned CD booting, but i didn't manage to boot Jens's 43P-140 from CD. There may have been some incompatibilities in the debian-cd options which cause problem when booting a prep box, compared to a newer chrp box, i am not fully sure i remember this correctly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405572: PowerPC, prep flavor: missing root= boot option after install
I can't resist to mail about this, i had every intention of not doing so, but i think that both Ulrich and Frans are missing some important facts, so i will add them here. On Sat, Jan 06, 2007 at 12:32:08PM +0100, Ulrich Teichert wrote: > Hi, > > >On Thursday 04 January 2007 16:54, Ulrich Teichert wrote: > >> After a successful installation > >> on a Motorola PowerStack II, rebooting the fresh installation failed, > >> because the kernel option root=/dev/sda2 (in my case) was missing. > >[...] > >> ROOT=/dev/sda2 should be added to the > >> /etc/initramfs-tools/initramfs.config > > > >Can you test if creating a file /etc/initramfs-tools/conf.d/prep-root with > >such a line works too? If it does, then that is much to be preferred. > > I just checked out the d-i trunk, I'll see what I can do. > > >Also, the following information is required in order to fix this: > >=2D does this need to be added for _all_ PReP systems, and if not what > > algorithm can be used? > > It has to be added for all PReP systems which use the mkvmlinuz boot loader, > so that would be all PRePs, if I am not mistaken. The PReP partition is used to boot on all PReP boxes : The motorola powerstack I and II, the IBM PReP box (43P-140) and the various Bulls system (Estrella and some other such i think, not 100% sure), but also all other IBM PowerPC/Power boxes : RS6K, pseries, modern iseries, etc. These are of the CHRP generation, and yaboot can be used there. Yaboot should be copied to the PReP partition, but there is nothing stopping a chrp box to not do yaboot, but instead use prep-installer to copy the mkvmlinuz generated kernel to the prep partition instead. This should even be possible with the current installer i think, in expert mode, but it has been some time since i tested. > >=2D how can the location of the PReP partition be determined; I doubt it > > will always be /dev/sda2 (use if a regular PATA controller and > > installation to a different harddisk come to mind) > > /dev/sda2 isn't the PReP partition. The PReP boot partition *has to be* > the first primary partition on the boot disk. /dev/sda2 is the root > partition of the fresh install in my case and of course this can and > will be different. We only need to know the boot disk, then we know > the place and the name of the PReP partition. Indeed, what is important is to set the *ROOT* partition, not the prep partition. prep-installer knows how to do this, as does yaboot-installer on more recent IBM Power boxes. The code which does this is : (packages/arch/powerpc/prep-installer/debian/postinst) if ([ "$ARCH" = powerpc/prep ] || [ "$ARCH" = powerpc/chrp_rs6k ] || [ "$ARCH" = powerpc/chrp_ibm ]) && \ db_get partman-prep/boot_partitions && [ "$RET" ]; then for part in $RET; do if [ -z "$PARTITIONS" ]; then DEFAULT="$part" PARTITIONS="$part" else PARTITIONS="$PARTITIONS,$part" fi done info "partman-supplied bootstrap partitions: $PARTITIONS" info "partman-supplied default bootstrap partition: $DEFAULT" if [ "$PARTITIONS" ] && [ "$DEFAULT" = "$PARTITIONS" ]; then # We have explicit information from partman-prep that only one # bootstrap partition is available, so it's safe to bypass this # question. bootdev_priority=medium fi fi if [ -z "$PARTITIONS" ]; then # error: no viable boot partitions found; fall over die prep-installer/nopart 'No prep boot partitions found' fi With partman-prep/boot_partitions being set by partman-prep. I hope this info gives some light in the confusion i have seen in this sub-thread, and i gues sthe conf.d initramfs-tools thingy should also work, i am not really familiar with initramfs-tools, so i may have missed this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403031: proposed patch to clean the finish-install serial console detection.
reopen 403031 severity 403031 wishlist retitle 403031 Serial console detection should happen only once. thanks Sorry, this mail left due to a bad manipulation before i had time to finish it or even review it :/ On Tue, Dec 26, 2006 at 08:24:41AM +0100, Sven Luther wrote: > On Mon, Dec 25, 2006 at 09:36:52PM +0100, Frans Pop wrote: > > On Tuesday 19 December 2006 23:07, Sven Luther wrote: > > The second one will be the one finish-install is run from. This instance > > will have TERM_TYPE=network, and not TERM_TYPE=serial like the original > > one. So, in that case, even though the install was started over serial > > console, the installed system would not be set up to use serial console > > (while this works correctly with the current logic). > > Cool, i knew there was something. I guess the good solution here is to set a > debconf variable in rootskel which would be there to check it. Ok, I re-open this bug as a wishlist. I believe that it is plain wrong to do the check twice, and instead some way needs to be found to circumwent the problem you found above. Possibly by adding an explicit debconf variable in rootskel/detect-console or something. Notice too, that this may play in well (post-etch), with the idea to enable serial consoles even for normal installs, as this may be a useful thing to do. I don't know how to best do this, but a search for serial consoles in the dmesg output may be a solution. This has to be a low-priority interactive process though. > > /me is so glad he is conservative with patches like this and takes the > > time to think them through and really test them instead of applying them > > blindly. > > /me is so glade you took the time to investigate the issue, instead of > dismissing it out of hand as your first reply indicated. > > > Hopefully this will teach you to not dismiss my concerns out of hand in > > the future, though I won't hold my breath. > > Well, please re-read my mails, i posted the patch, asked why this was not > done, and *EXPLICITLY* asked this to be double checked, did i not ? ... Frans, Fabio, Anthony, i think this is symptomatic on how this whole issue degenerated over all this time. Please, all tree look at my original bug report. I noticed a discrepancy between the rootskel and the finish-install list, suggested a solution which would allow in the future to fix this issue with having to change only one place (a most laudable goal for anyone knowledgeable in programming), and explicitly mentioned the 'unless i miss something', which was an invitation to comment from others of the team. The reply from Frans was "has this patch been tested", and saying it should not be applied before etch. This kind of reply from Frans has been of the kind which has set my teeths on edge since a loong time, one tries to work, to do best, to ask for comments, and mostly gets ignored. Now i am serene enough to not snap, but as i was in personal distress in spring, you can imagine how it affected me. Also, continuous repetitions of similar issues are not prone to appeasing such situations. Please think next time before you do such, and learn that team work is also about letting everyone speak, and discuss problems and possible solutions in the open, in order to find the best possible technical solution to a given problem. And with that, happy christmas to you all, and let's hope that next year will bring better understanding patience and goodwill to everyone concerned. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403031: proposed patch to clean the finish-install serial console detection.
On Mon, Dec 25, 2006 at 09:36:52PM +0100, Frans Pop wrote:
> On Tuesday 19 December 2006 23:07, Sven Luther wrote:
> > Err, can you tell me the risk of regression. Please speak the issue
> > with someone else, like Colin and Joey, or Bastian, and weigth the
> > actual risk.
>
> OK. So let me tell you why this patch will BREAK some installations.
>
> finish-install.d/90console has:
>
> inst_pid=$(pidof debian-installer | sed "s/ /\n/g" | sort -n | head -n 1)
> rawconsole=$(readlink /proc/${inst_pid}/fd/0)
>
>
> Why does it take the 'head'?
> Reason is that during installs using network console there are _two_
> debian-installer processes: the original one (possibly started over
> sercon), and the second one started over ssh.
>
> The second one will be the one finish-install is run from. This instance
> will have TERM_TYPE=network, and not TERM_TYPE=serial like the original
> one. So, in that case, even though the install was started over serial
> console, the installed system would not be set up to use serial console
> (while this works correctly with the current logic).
Cool, i knew there was something. I guess the good solution here is to set a
debconf variable in rootskel which would be there to check it.
> /me is so glad he is conservative with patches like this and takes the
> time to think them through and really test them instead of applying them
> blindly.
/me is so glade you took the time to investigate the issue, instead of
dismissing it out of hand as your first reply indicated.
> Hopefully this will teach you to not dismiss my concerns out of hand in
> the future, though I won't hold my breath.
Well, please re-read my mails, i posted the patch, asked why this was not
done, and *EXPLICITLY* asked this to be double checked, did i not ?
What i highly dislike about you, is your way to say : this is too risky, and
won't be considered, instead of saying "let's take the time to invesitgate the
issue", or other more positive things. Don't you see how arrogant and
despreciative your first line of answer is ?
Don't you also see how you are backsliding into ad-hominem attacks in this
reply, and instead of working together to make debian the best technical
distribution, you take the oportunity to bash me
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403778: installation-report: sudo password not specified
On Thu, Dec 21, 2006 at 10:28:45AM -0500, Joey Hess wrote: > Tshepang Lekhonkhobe wrote: > > On 12/19/06, Joey Hess <[EMAIL PROTECTED]> wrote: > > >Max Hyre wrote: > > >> When asked whether to allow root to login, the information specifies > > >> that `sudo' will be used for rootish things, but doesn't mention that > > >> the password is the user's own. > > > > > >I would have thought that this would be obvious, since: > > > > > >* When installing this way, you give the installer only one password. > > > > Not so obvious to a newbie installer... > > >* It's documented on sudo's man page as the default behavior of sudo. > > > > out of question... > > > > This option is only available to people who have booted the installer > with "expert". I have limited patience for people who think they are > experts and are not familiar with man pages. Notice that this option is also easily available by hitting "go back" once or twice at the root password prompt, and then following the installation normally. /me knows, as i discovered this option in exactly this way :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kde/gnome/xfce media other than full CDs
On Wed, Dec 20, 2006 at 03:52:24PM -0500, Joey Hess wrote: > peter green wrote: > > it has recently been announced that there will be seperate CDs for > > kde/gnome/xfce with different desktop tasks and package selections. > > > > but what is the plan for other means of installation > > (buisnesscard/netinst/floppies/netboot)? will there be 3 seperate > > desktop tasks listed? will there be one desktop task that installs all > > three? or will kde and xfce desktops simply not be availible from > > tasksel. > > In all cases you get a choice what desktop environment you want, before > you enter d-i. d-i/tasksel never requires you to make this choice in the > user interface, though. In the case of regular sized CDs, you make the > choice when deciding what CD to get. In the case of all other > installation images, you can make the choice when booting the installer, > by typing "install tasks=kde-desktop" Most people will not know about any such option, and when faced with the normal tasksel selections, will only be proposed a desktop or graphical task, which as far as i know will install only gnome. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft release notes and errata for RC1 - Efika support
On Wed, Dec 20, 2006 at 01:29:02PM -0200, Otavio Salvador wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > The Efika (http://www.genesippc.com/efika.php) needs 2.6.19 based patches, > > so > > will not be supported, altough i have a d-i build using a modified > > base-installer, which will grab the kernel package from a separate repo. > > Nice. > > Are those patches too invasive? Maybe those could be brought to 2.6.18? They are indeed rather invasive, well, maybe not, but they affect some very early levels of the kernel, and so a backport at this stage of the etch development is to risky. (And i don't have time to do it, and others are not interested). > > It would really be friendlier if base-installer would allow pre-configure > > hooks, which would be invoked after debootstrap, but before the whole > > apt-checking stuff. I just added a few lines at the end of configure_apt > > right > > now. > > Why you need it? To change the repository for the kernel grabing? Yep. The somewhat clumsy patch is : --- debian/postinst (révision 43406) +++ debian/postinst (copie de travail) @@ -312,6 +312,17 @@ else echo "deb $APTSOURCE $DISTRIBUTION $COMPONENTS" > /target/etc/apt/sources.list fi + + if [ "`grep '^machine[[:space:]]*:' "/proc/cpuinfo" | head -n1 | cut -d: -f2 | sed 's/^ *//;'`" = "EFIKA5K2 CHRP PowerPC System" ]; then + log "Configuring for an EFIKA5K2 System" + # Disable authentification, let's do this until i know how to add authentification to the efika repo. + # This will be left in place on the installed system. + cat > /target/etc/apt/apt.conf.d/00trustefika <http://people.debian.org/~luther/efika/debian/ ./" >> /target/etc/apt/sources.list + register-module -i pata_mpc52xx + fi } I need to work on a fix of initramfs-tools, and know how to add thrusted sub-repository support, but the main gist is the above. If there were propper hooks for this, this would be easier. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403084: debian-installer: [powerpc] mini-iso images are non-bootable on powerpc/pmac/chrp
On Tue, Dec 19, 2006 at 03:01:50PM +, Colin Watson wrote: > On Thu, Dec 14, 2006 at 03:45:29PM +0100, Sven Luther wrote: > > Since i am going to reinstalll the XServe G5 which went broken last week, i > > investigated why i couldn't boot from CD. > > > > It happens that the generated mini.iso files (powerpc64/netboot), are > > broken, > > and are missing the needed magic to make them autoboot. At least on chrp > > boxes. I am nto fully sure, and i will try booting the image from disk, but > > i > > guess this is the problem. It used to work like a month ago, so i don't know > > what happened here. > > Are you sure it used to work with these particular images? To my > knowledge the images built from the d-i tree have never supported CHRP > systems, only those built from debian-cd. This is indeed the case. I don't know why those images suddenly didn't work anymore on the XServe at the data center, while i was using them just fine a week previous to this. I have the XServe back, and i reseted the PROM, and it should be working fine. That said, due to udev killing the scsi-devfs.sh scripts when they write to the pipe, the whole d-i is totally unusable on this box, and i really don't know why. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: miboot-floppies (powerpc oldworld) for sarge
On Wed, Dec 20, 2006 at 07:05:46AM -0500, Rick Thomas wrote: > Hi Sven, > > > On Dec 20, 2006, at 2:16 AM, Sven Luther wrote: > > >What is really needed is for confirmation with the current kernels > >that : > > > > 1) miboot booting works (or not). > > > > 2) bootx booting works (or not). > > > > 3) quik booting works (or not). > > > >Rick, you have been rather active in this, could i ask you to make > >a survey > >with the current 2.6.18 kernels in both etch and testing, and tell > >us what > >works and what doesn't. And file a bug report against the kernel > >packages > >(linux-2.6, title prefaced [powerpc,oldworld]). > > Items 1 and 2 are on my list. I hope to get to them before Friday. > Item 3 (quik) is more problematical. I also run MacOS-9 on my > OldWorld test machine, and quikis incompatible with that. > > I'll look thru the junk box and see if I can find parts to cobble > together a "quik" test box, but I'm not guaranteeing anything, and I > don't know how long it will take if I do succeed. Well, i think what would be interesting is maybe to have a wiki page, listing a cross table of all tested models, and the different boot methods, and listing the working reports and not working ones, or something. Then give out a call for testers of the last daily-builds. > To make sure I have it right: Bug reports (or success reports!) > should have > Package: linux-2.6 > as the first line, and should have > Subject: [powerpc,oldworld] Yes, apart, that after the [powerpc,oldworld] you can add a short description. Friendlty, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft release notes and errata for RC1 - Efika support
On Tue, Dec 19, 2006 at 04:23:34PM +0100, Holger Levsen wrote: > package: release-notes > severity: wishlist > > On Friday 10 November 2006 17:16, Sven Luther wrote: > > We could also mention architecture support changes : > > > > - PowerPC: dropped support for powerpc/apus. > > - PowerPC: Added support for 64bit PowerPC architectures (IBM pSeries, > > Apple G5 powermacs). > > - PowerPC: not supported : Apple Nubus and IBM pre-power5 Iseries. > > > > Well, to be complete, one could have the list of supported subarches too : > > > > - Apple newworld and G5 powermacs > > - IBM CHRP machines (RS6K, pseries, iseries, ...) > > - Genesi CHRP machines (Pegasos, maybe Efika) The Efika (http://www.genesippc.com/efika.php) needs 2.6.19 based patches, so will not be supported, altough i have a d-i build using a modified base-installer, which will grab the kernel package from a separate repo. It would really be friendlier if base-installer would allow pre-configure hooks, which would be invoked after debootstrap, but before the whole apt-checking stuff. I just added a few lines at the end of configure_apt right now. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: miboot-floppies (powerpc oldworld) for sarge
On Wed, Dec 20, 2006 at 01:43:23AM -0500, Rick Thomas wrote: > Actually, you (and I) *can* boot our oldworld PowerMacs from the 2.4 > miboot floppyset. And we can install Sarge from there. We can even > use it to install a 2.6.8 kernel. > > Not to put words into his mouth, but I think that is what Holger is > saying. For the purpose the Sarge floppyset serves, it's enough to > have just a 2.4 kernel for the installer. > > On the other hand, what Sven is saying seems (again, not to put words > in his mouth) to be that, as long as we're going to encourage the > user to install a 2.6 kernel eventually, it would be cleaner/nicer/ > more-elegant to start them off with a 2.6 kernel from the beginning > in the installer. > > Holger seems to reply "Why bother?" > > My thought (admittedly a bit of a stretch) is that there *may* be > hardware out there (SATA disks?) that a user can plug into an > OldWorld PowerMac PCI slot that is not supported by the 2.4 kernel, > but is supported by the 2.6 kernel, and why should we artificially > limit our user base to exclude such users? > > So I mostly agree with Sven on this one, but I don't think it's worth > a lot of emotion. There are plenty of bigger issues regarding > OldWorld PowerMacs that need looking into. Until recently, just > getting Etch to boot *at-all* on OldWorld was one of them! Notice that with the etch release around the corner, installing sarge is not all that important. I have kind of lost oversight of what is going on in the etch/oldworld arena. There where various bugs for various kernel versions and boot methods, some of them with a fix. What is really needed is for confirmation with the current kernels that : 1) miboot booting works (or not). 2) bootx booting works (or not). 3) quik booting works (or not). Rick, you have been rather active in this, could i ask you to make a survey with the current 2.6.18 kernels in both etch and testing, and tell us what works and what doesn't. And file a bug report against the kernel packages (linux-2.6, title prefaced [powerpc,oldworld]). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403031: proposed patch to clean the finish-install serial console detection.
On Tue, Dec 19, 2006 at 03:21:11PM +0100, Frans Pop wrote: > On Saturday 16 December 2006 00:30, Sven Luther wrote: > > Please find attached a patch which does the finish-install detection of > > a serial console, based on what was done in > > rootskel/detect-linux-console. > > Has this patch been tested? Sure, i used it on the efika. It causes no regresion on the hardware i have, but i agree with you that it is important to test on other hardware. > Even if it has, I'm not sure we should make this change so short before > the release because of the risk of regressions. I'd rather just add the > support for the missing type of devices for now and leave this BR open so > this patch can be applied post-Etch. Err, can you tell me the risk of regression. Please speak the issue with someone else, like Colin and Joey, or Bastian, and weigth the actual risk. The problem would be if there is a legitimate reason why a certain device would be declared as serial console in rootskel, but not in finish-install, i can't myself imagine where this could be, and when i did an audit for ttyS* in the whole d-i packages svn repo, i didn't find any other place which is involved, but this was a couple of months ago already. So, that you apply it now or later, i would be very interested in the reason why this was not done as this patch in the first place, which would seem more logical and intuitive. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403084: closed by Frans Pop <[EMAIL PROTECTED]> (Re: Bug#403084: debian-installer: [powerpc] mini-iso images are non-bootable on powerpc/pmac/chrp)
On Tue, Dec 19, 2006 at 12:33:14PM -0800, Debian Bug Tracking System wrote: > Date: Tue, 19 Dec 2006 20:04:59 +0100 > From: Frans Pop <[EMAIL PROTECTED]> > Subject: Re: Bug#403084: debian-installer: [powerpc] mini-iso images are > non-bootable on powerpc/pmac/chrp > To: [EMAIL PROTECTED] > Message-id: <[EMAIL PROTECTED]> > > Closing as there was no regression. yes, i saw colin's message earlier and would have done this too. That said, even if there is no regression, this is still a wishlist bug, i think. Autobooting on IBM Power boxes is a good feature to have, especially now that apple left the powerpc market. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
further investigation shows the udev scripts are not even started ...
Package: udev Version: 0.103-1 Followup-For: Bug #403136 Hi, ... I have experimented a bit, thanks to Marco's hints. And we narrowed this done to the scsi-devfs.sh script not even being launched. A udevtrigger showed that all those scripts are : Jan 12 22:14:07 udevd[347]: udev_done: seq 2161, pid [7002] exit with 1, 0 seconds old exiting with return status 1. I have checked by adding an echo at the start of scsi-devfs.sh, and adding set -x too, but it seems to me that it doesn't even get called at all, which is rather strange. Marco, can you give me some information about how to further investigate this, i have narrowed the problematic code to udevd.c, and probably to the udev_done/reap_sigchilds/udev_event_process, but i am not sure how to further continue from there. It may be that for some obscure reason, the scripts are being killed, and this triggers the return status of 1, but as said, running those scripts by hand is perfectly fine. Most baffling. Friendly, Sven Luther -- Package-specific info: -- /etc/udev/rules.d/: /etc/udev/rules.d/: total 8 lrwxrwxrwx 1 root root 39 2006-12-09 08:15 020_libgphoto2_generic-ptp_support.rules -> ../libgphoto2_generic_ptp_support.rules lrwxrwxrwx 1 root root 20 2006-02-13 19:26 020_permissions.rules -> ../permissions.rules lrwxrwxrwx 1 root root 19 2006-08-28 16:23 025_libgphoto2.rules -> ../libgphoto2.rules lrwxrwxrwx 1 root root 16 2006-08-28 16:45 025_libsane.rules -> ../libsane.rules lrwxrwxrwx 1 root root 13 2006-02-13 19:26 udev.rules -> ../udev.rules lrwxrwxrwx 1 root root 25 2006-08-28 16:10 z20_persistent-input.rules -> ../persistent-input.rules lrwxrwxrwx 1 root root 19 2006-08-28 16:10 z20_persistent.rules -> ../persistent.rules -rw-r--r-- 1 root root 599 1970-10-03 14:05 z25_persistent-cd.rules -rw-r--r-- 1 root root 602 2006-09-19 08:12 z25_persistent-net.rules lrwxrwxrwx 1 root root 33 2006-08-28 16:10 z45_persistent-net-generator.rules -> ../persistent-net-generator.rules lrwxrwxrwx 1 root root 12 2006-08-28 16:10 z50_run.rules -> ../run.rules lrwxrwxrwx 1 root root 16 2006-08-28 16:10 z55_hotplug.rules -> ../hotplug.rules lrwxrwxrwx 1 root root 19 2005-08-15 17:31 z60_alsa-utils.rules -> ../alsa-utils.rules lrwxrwxrwx 1 root root 15 2006-08-28 00:32 z60_hdparm.rules -> ../hdparm.rules lrwxrwxrwx 1 root root 33 2006-08-28 16:12 z60_xserver-xorg-input-wacom.rules -> ../xserver-xorg-input-wacom.rules lrwxrwxrwx 1 root root 17 2006-08-28 16:10 z70_hotplugd.rules -> ../hotplugd.rules lrwxrwxrwx 1 root root 29 2006-08-28 16:10 z75_cd-aliases-generator.rules -> ../cd-aliases-generator.rules lrwxrwxrwx 1 root root 12 2006-11-23 08:14 z99_hal.rules -> ../hal.rules -- /sys/: /sys/block/hda/dev /sys/block/hda/hda1/dev /sys/block/hda/hda2/dev /sys/block/hda/hda3/dev /sys/block/hda/hda4/dev /sys/block/hda/hda5/dev /sys/block/hda/hda6/dev /sys/block/hdc/dev /sys/block/ram0/dev /sys/block/ram10/dev /sys/block/ram11/dev /sys/block/ram12/dev /sys/block/ram13/dev /sys/block/ram14/dev /sys/block/ram15/dev /sys/block/ram1/dev /sys/block/ram2/dev /sys/block/ram3/dev /sys/block/ram4/dev /sys/block/ram5/dev /sys/block/ram6/dev /sys/block/ram7/dev /sys/block/ram8/dev /sys/block/ram9/dev /sys/block/sda/dev /sys/block/sdb/dev /sys/block/sdc/dev /sys/block/sdd/dev /sys/class/drm/card0/dev /sys/class/graphics/fb0/dev /sys/class/input/input0/event0/dev /sys/class/input/input0/mouse0/dev /sys/class/input/input0/ts0/dev /sys/class/input/input3/event1/dev /sys/class/input/input4/event2/dev /sys/class/input/input4/mouse1/dev /sys/class/input/input4/ts1/dev /sys/class/input/mice/dev /sys/class/misc/device-mapper/dev /sys/class/misc/nvram/dev /sys/class/misc/psaux/dev /sys/class/misc/rtc/dev /sys/class/misc/snapshot/dev /sys/class/printer/lp0/dev /sys/class/sound/audio/dev /sys/class/sound/controlC0/dev /sys/class/sound/dsp/dev /sys/class/sound/mixer/dev /sys/class/sound/pcmC0D0c/dev /sys/class/sound/pcmC0D0p/dev /sys/class/sound/seq/dev /sys/class/sound/sequencer2/dev /sys/class/sound/sequencer/dev /sys/class/sound/timer/dev /sys/class/usb_device/usbdev1.1/dev /sys/class/usb_device/usbdev1.3/dev /sys/class/usb_device/usbdev2.1/dev /sys/class/usb_device/usbdev3.1/dev /sys/class/usb_device/usbdev4.1/dev /sys/class/usb_device/usbdev5.1/dev /sys/class/usb_device/usbdev5.2/dev /sys/devices/pci:00/:00:05.0/usb3/3-0:1.0/usbdev3.1_ep81/dev /sys/devices/pci:00/:00:05.0/usb3/usbdev3.1_ep00/dev /sys/devices/pci:00/:00:05.1/usb4/4-0:1.0/usbdev4.1_ep81/dev /sys/devices/pci:00/:00:05.1/usb4/usbdev4.1_ep00/dev /sys/devices/pci:00/:00:05.2/usb5/5-0:1.0/usbdev5.1_ep81/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/5-2:1.0/usbdev5.2_ep02/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/5-2:1.0/usbdev5.2_ep81/dev /sys/devices/pci:00/:00:05.2/usb5/5-2/usbdev5.2_ep00/dev /sys/devices/pci:00/:00:05.2/usb5/usbdev5.1_ep00/dev /sys/devices/pc
Re: Bug#403136: udev bug ... (d-i fails to create /dev/sd* devices)
On Sun, Dec 17, 2006 at 02:48:24PM +0100, Marco d'Itri wrote: > On Dec 16, Sven Luther <[EMAIL PROTECTED]> wrote: > > > Well, i never dealt with udev, i have not even the faintest idea where to > > start, and the initramfs-tools or d-i environment i have to play with is > > really not all that user friendly, so please help me or give me guidance on > > how to further investigate ? > OTOH looks like you were really quick to blame udev for this. > > > Can you tell me how i can make udev log all received events, or something > > such. Once i get the hand, it is usually already too late, and everything > > happened. > Uncomment the last line of /etc/udev/hotplug.rules . Well, in the d-i context, or probably even the initramfs-tools context, this is probably not going to do us much good. I did build a modified udev-udeb, in which i added a hotplug.rules which includes only the : # Log every event to /dev/hotplug.log (for debugging). RUN+="logger.agent" lines, and i added /lib/udev/logger.agent to it too. I am unsure if this will be enough though, because lot of stuff are missing from the udev-udeb, and possibly also whatever is used to run the hotplug.rules. Would a udev-dbg-udev make sense ? It would make debugging this kind of stuff much easier. Now, i wonder if it is udev related, since the udev-udeb is much more lightweight than the full udev, is d-i using something else to create the devices ? Anyway, thanks for your help. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Scheduling linux-2.6 2.6.18-9
On Sun, Dec 17, 2006 at 01:53:03PM +0100, Max Vozeler wrote: > Hi all, > > On Sun, Dec 17, 2006 at 02:43:57AM -0800, Steve Langasek wrote: > > On Fri, Dec 15, 2006 at 06:08:08PM +0100, Frederik Schueler wrote: > > > This update bears 3 ABI breaking changes. While the vserver patch might > > > be adaptable, the PAE migration of i386 Xen is not. But we need this > > > change as a workaround for #399113, otherwise the i386 Xen kernels will > > > be broken in the release, and require an immediate update. > > > And since we are already planning an ABI bump, we can add the missing > > > changeset of 2.6.18.5, too. > > > > The first two ABI changes are specific to extra kernel flavors that > > aren't relevant to the installer and have few (if any?) extra modules > > built for them. > > Actually, quite a few modules packages are being built for the > vserver and xen flavours : > > main: > spca5xx (linux-modules-extra-2.6) > redhat-cluster (linux-modules-extra-2.6) > squashfs(linux-modules-extra-2.6) > loop-aes(loop-aes) > > contrib: > ipw2100 (linux-modules-contrib-2.6) > ipw2200 (linux-modules-contrib-2.6) > ipw3945 (linux-modules-contrib-2.6) > > non-free: > kqemu (linux-modules-nonfree-2.6) > > Unless I missed some, I think this concerns four source packages. > I'm not sure if it would be possible to binNMU / force rebuild of > those, but since linux-modules-* are maintained by the kernel team > and loop-aes by myself, I think we could react quickly and rebuild > them via normal sourceful uploads as well. Why is loop-aes not part of the official module packages ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403392: debian-installer: etch->sid sources transformation should remove security line ...
Package: debian-installer Severity: normal When building svn debian-installer on an etch system, the /etc/apt/sources.list are taken, and the etch component is changed to sid. This fails when you have etch security sources, since there are no sid security sources, and i guess may be problematic for other non-official repositories too. Please consider removing the security line, which will be present on each etch install, or consider, after the etch->sid replacement, checking and removing each line which is not valid, instead of failing like it happens right now. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403295: closed by Frans Pop <[EMAIL PROTECTED]> (Re: Bug#403295: nobootloader: [powerpc] Please add efika support.)
On Sat, Dec 16, 2006 at 06:18:12AM -0800, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > #403295: nobootloader: [powerpc] Please add efika support., > which was filed against the nobootloader package. > > It has been closed by Frans Pop <[EMAIL PROTECTED]>. > > Their explanation is attached below. If this explanation is > unsatisfactory and you have not received a better one in a separate > message then please contact Frans Pop <[EMAIL PROTECTED]> by replying > to this email. > > Debian bug tracking system administrator > (administrator, Debian Bugs database) > > > --- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > From: Frans Pop <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: Bug#403295: nobootloader: [powerpc] Please add efika support. > Date: Sat, 16 Dec 2006 15:11:26 +0100 > Message-Id: <[EMAIL PROTECTED]> > > On Saturday 16 December 2006 13:28, Sven Luther wrote: > > That said, this patch doesn't conflict, it is just useless. In any case > > it doesn't hurt. > > As the patch is bogus, let's close the BR. Bogus is maybe a bit strong word, don't you think ? But thanks for closing this BR, i was going to do it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403295: nobootloader: [powerpc] Please add efika support.
On Sat, Dec 16, 2006 at 10:05:24AM +0100, Martin Michlmayr wrote: > * Sven Luther <[EMAIL PROTECTED]> [2006-12-16 00:26]: > > - powerpc/chrp_pegasos) > > + powerpc/chrp_pegasos|powerpc/chrp_efika) > > This conflicts with #403295 which defines EFIKA as > powerpc/chrp_pegasos... Oh my, ... Sorry, you are indeed right. I had two conflicting implementation paths, and decided to go the single chrp_pegasos one. But forgot about this while i was investigating the svn diff output yesterday. That said, this patch doesn't conflict, it is just useless. In any case it doesn't hurt. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403293: libdebian-installer: [powerpc] Add efika support.
On Sat, Dec 16, 2006 at 11:51:38AM +0100, Geert Stappers wrote:
> Op 16-12-2006 om 00:21 schreef Sven Luther:
> > --- src/system/subarch-powerpc-linux.c (révision 43393)
> > +++ src/system/subarch-powerpc-linux.c (copie de travail)
> > @@ -21,6 +21,7 @@
> > static struct map map_machine[] = {
> > { "PReP", "prep" },
> > { "CHRP Pegasos", "chrp_pegasos" },
> > + { "EFIKA5K2 CHRP PowerPC System", "chrp_pegasos" },
> > { "CHRP IBM", "chrp_rs6k" },
> > { "CHRP", "chrp" },
> > { "Amiga", "amiga" },
>
> See also #403295 ( http://bugs.debian.org/403295 )
Sure, sorry.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403299: (no subject)
On Sat, Dec 16, 2006 at 09:43:51AM +0100, Frans Pop wrote: > On Saturday 16 December 2006 01:38, Daniel Dent wrote: > > The system comes up fine and correctly configured after it > > has been booted. However, it doesn't shutdown properly. > > Because / is on LVM the volume group refuses to deactivate > > because / is still mounted (even though it is only read only > > by that point). As a result, mdadm won't shut down the raid > > device. When the system is booted back up, the raid > > partition is marked dirty (because it doesn't shutdown > > properly but reboots anyway) and ends up rebuilding. > > I have some doubts about that. / on LVM on RAID is known to work It used to work just fine, I did all my XServe tests in this setup, but recent udev fucked this up severly, by trying to mount LVM and RAID *before* the disks where mounted. This affects both d-i (where the /dev/sd* are not created) and initramfs-tools. Not sure if this is a similar problem or not. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: miboot-floppies (powerpc oldworld) for sarge
On Fri, Dec 15, 2006 at 11:21:53PM +0100, Holger Levsen wrote: > Hi, > > On Friday 15 December 2006 21:37, Sven Luther wrote: > > Notice that the 2.6 sarge d-i image had a bug which was later fixed in the > > etch/sid version. It has to do with calling mkvmlinuz i think, instead of > > simply gzipping it by hand. > > > > Holger, can you backport the little change from the sid branch, this should > > fix it. > > But why? People can install with 2.4 just fine and then later upgrade to 2.6, > so why do the work and backport it? > > The CDs work fine with 2.6, don't they? It's only the miboot floppies, isn't > it? And this time with the patch ... Friendly, Sven Luther Index: config/powerpc/powerpc/floppy.cfg === --- config/powerpc/powerpc/floppy.cfg (révision 30690) +++ config/powerpc/powerpc/floppy.cfg (révision 30691) @@ -6,7 +6,9 @@ WRITE_MEDIA += $(FLAVOUR_SUPPORTED) $(TEMP_KERNEL).gz: $(TEMP_KERNEL) - mkvmlinuz -a miboot -k $(TEMP_KERNEL) -n -d $(TEMP)/lib -o $(TEMP_KERNEL).gz + #mkvmlinuz -a miboot -k $(TEMP_KERNEL) -n -d $(TEMP)/lib -o $(TEMP_KERNEL).gz + # Let's do it the good old fashioned way. + gzip -c -9 $(TEMP_KERNEL) >$(TEMP_KERNEL).gz $(TEMP_BOOT).new: $(TEMP_KERNEL).gz dd if=/dev/zero of=$@ bs=1024 count=$(FLOPPY_SIZE)
Bug#403295: nobootloader: [powerpc] Please add efika support.
Package: nobootloader Version: 1.15 Severity: normal Tags: patch Please add support for the efika board. -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Index: debian/postinst === --- debian/postinst (révision 42839) +++ debian/postinst (copie de travail) @@ -27,7 +27,7 @@ bootfs=$(mapdevfs $bootfs_devfs) case "`archdetect`" in - powerpc/chrp_pegasos) + powerpc/chrp_pegasos|powerpc/chrp_efika) kernel=`ls /target/boot/vmlinuz-2.* | sed -e 's%/target/boot/%%'` partition_offset=1 Index: debian/changelog === --- debian/changelog(révision 42839) +++ debian/changelog(copie de travail) @@ -1,3 +1,10 @@ +nobootloader (1.16) UNRELEASED; urgency=low + + [ Sven Luther ] + * [powerpc] Add support for the Efika board. + + -- Sven Luther <[EMAIL PROTECTED]> Sat, 16 Dec 2006 00:18:54 +0100 + nobootloader (1.15) unstable; urgency=low [ Colin Watson ]
Re: miboot-floppies (powerpc oldworld) for sarge
On Fri, Dec 15, 2006 at 11:21:53PM +0100, Holger Levsen wrote: > Hi, > > On Friday 15 December 2006 21:37, Sven Luther wrote: > > Notice that the 2.6 sarge d-i image had a bug which was later fixed in the > > etch/sid version. It has to do with calling mkvmlinuz i think, instead of > > simply gzipping it by hand. > > > > Holger, can you backport the little change from the sid branch, this should > > fix it. > > But why? People can install with 2.4 just fine and then later upgrade to 2.6, > so why do the work and backport it? Because even when using 2.4 floppies, they will install the 2.6.8 kernels, so it is best to have the same kernel for installation media and reboot kernels. The change is trivial, please try it : File : config/powerpc/powerpc/floppy.cfg $(TEMP_KERNEL).gz: $(TEMP_KERNEL) #mkvmlinuz -a miboot -r $(KERNELVERSION) -k $(TEMP_KERNEL) -n -d $(TEMP)/lib -o $(TEMP_KERNEL).gz # Let's do it the good old fashioned way. gzip -c -9 $(TEMP_KERNEL) >$(TEMP_KERNEL).gz you see, you just need to uncomment the mkvmlinuz call, and add the gzip instead. I attach the proper fix, but you could get it by : svn diff -r30690:30691 Also. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403031: proposed patch to clean the finish-install serial console detection.
Package: finish-install
Version: 2.6
Tags: patch
Followup-For: Bug #403031
Please find attached a patch which does the finish-install detection of a
serial console, based on what was done in rootskel/detect-linux-console.
Friendly,
Sven Luther
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-powerpc
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Index: debian/changelog
===
--- debian/changelog(révision 43358)
+++ debian/changelog(copie de travail)
@@ -1,3 +1,11 @@
+finish-install (2.7) UNRELEASED; urgency=low
+
+ [ Sven Luther ]
+ * Added check for TERM_TYPE instead of explicit console check, since we
+already do this detection in rootskel/detect-console.
+
+ -- Sven Luther <[EMAIL PROTECTED]> Sat, 16 Dec 2006 00:24:44 +0100
+
finish-install (2.6) unstable; urgency=low
* 90console: [powerpc64] Added support for hvc* and hvsi* serial consoles.
Index: finish-install.d/90console
===
--- finish-install.d/90console (révision 43358)
+++ finish-install.d/90console (copie de travail)
@@ -15,8 +15,8 @@
rawconsole=${rawconsole#/dev/}
console=${console#/dev/}
-case "$console" in
-ttyS*|hvc*|hvsi*)
+case "$TERM_TYPE" in
+serial)
log "Configuring /etc/inittab for serial console"
consoletype=${console%%[0-9]*}
ttyline=${console#$consoletype}
Bug#403293: libdebian-installer: [powerpc] Add efika support.
Package: libdebian-installer
Version: 0.47
Severity: normal
Tags: patch
Please add support for the efika board to libdebian-installer.
Friendly,
Sven Luther
-- System Information:
Debian Release: 4.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: powerpc (ppc)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-2-powerpc
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Index: debian/changelog
===
--- debian/changelog (révision 43393)
+++ debian/changelog (copie de travail)
@@ -1,3 +1,9 @@
+libdebian-installer (0.48) UNRELEASED; urgency=low
+
+ * Added support for Efika /proc/cpuinfo machine field.
+
+ -- Sven Luther <[EMAIL PROTECTED]> Thu, 14 Dec 2006 09:48:04 +0100
+
libdebian-installer (0.47) unstable; urgency=low
* Fix FTBFS on mips/mipsel.
Index: src/system/subarch-powerpc-linux.c
===
--- src/system/subarch-powerpc-linux.c (révision 43393)
+++ src/system/subarch-powerpc-linux.c (copie de travail)
@@ -21,6 +21,7 @@
static struct map map_machine[] = {
{ "PReP", "prep" },
{ "CHRP Pegasos", "chrp_pegasos" },
+ { "EFIKA5K2 CHRP PowerPC System", "chrp_pegasos" },
{ "CHRP IBM", "chrp_rs6k" },
{ "CHRP", "chrp" },
{ "Amiga", "amiga" },
Re: miboot-floppies (powerpc oldworld) for sarge
On Fri, Dec 15, 2006 at 01:42:03PM -0200, Lucas Rossi wrote: > > > Citando Holger Levsen <[EMAIL PROTECTED]>: > > >Hi Lucas, > > > >On Friday 15 December 2006 15:32, you wrote: > >> As I said, > > > >you didn't (until now) ;) > > Sorry, you probably didn't read my very fisrt mail, that exposed > the problem... > > > > >> the computer just spits out the disks, > > > >you tried the 2.4 and 2.6 ones? > > Well...good point! I tried the 2.6 again with another disk and > nada...then I tried the 2.4 with the same disk and tadaaa! I'm > installing the basic system now. If anything goes wrong I'll let you > know, but I believe it'll be okay. As soon as it finishes I'm > updating the kernel to the 2.6 and setting up my server. Notice that the 2.6 sarge d-i image had a bug which was later fixed in the etch/sid version. It has to do with calling mkvmlinuz i think, instead of simply gzipping it by hand. Holger, can you backport the little change from the sid branch, this should fix it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newest powerpc install disks not booting
On Thu, Dec 14, 2006 at 03:58:16PM -0700, dann frazier wrote: > On Thu, Dec 14, 2006 at 10:06:52PM +0100, Holger Levsen wrote: > > Hi Dann, > > > > we used to have miboot-floppies for sarge/powerpc somewhere on > > people.debian.org/~luther/ but it seems they are gone. Since these floppies > > in etch are also sometimes not working and older hardware might not be > > supported by newer kernels, too - it would be very good to have them again. > > > > Did you do the sarge 3.1r4 rebuild of d-i for powerpc? Or do you know who > > did? > > It looks like this was autobuilt: > > http://buildd.debian.org/fetch.cgi?&pkg=debian-installer&ver=20050317sarge1&arch=powerpc&stamp=1154814507&file=log > > > I'm asking you to do this, because I guess you have everything set up and > > just > > need to install miboot and repeat the build. (To use the same chroot again > > for official builds, you obviously need to remove the miboot package again.) > > Frans: can we update debian-installer on a single arch, perhaps via > binNMU, like this? No, because miboot is not in main, and thus official d-i packages cannot be done. What is needed is a local build of the miboot floppies, and putting them up somewhere unofficial, and replacing the official sarge miboot floppies by a note pointing to these unofficial images. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403084: debian-installer: [powerpc] mini-iso images are non-bootable on powerpc/pmac/chrp
Package: debian-installer Severity: important Tags: d-i Hi, ... Since i am going to reinstalll the XServe G5 which went broken last week, i investigated why i couldn't boot from CD. It happens that the generated mini.iso files (powerpc64/netboot), are broken, and are missing the needed magic to make them autoboot. At least on chrp boxes. I am nto fully sure, and i will try booting the image from disk, but i guess this is the problem. It used to work like a month ago, so i don't know what happened here. Colin, you are the expert on this, can you investigate ? Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403031: finish-install: serial console detection is not matching what is done in rootskel/console-detect
Package: finish-install Version: 2.6 Severity: normal Well, while working on the efika support, i found out that more problematic serial console setups break finish-install. The efika has ttyPSC0 as console. This is in part due to the fact that rootskel/console-detect uses : /dev/console|/dev/tts/*|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*) TERM_TYPE=serial Which is a lot more complete than the : case "$console" in ttyS*|hvc*|hvsi*) used in finish-install/S90console. Furthermore, this forces us to modify the code in two places for each new kind of serial console, and with the crazy scheme of the linux upstream folk to call each different serial console with its own name, this may happen a lot in the future. I thus suggest that the finish-install/S90console be changed to : case "$TERM_TYPE" in serial ) Which, unless i miss something, would catch all those consoles detected by the rootskel/console-detect code, and thanks to the remaniement of my preceding suggestion by frans/colin, will allow to do the right thing. I think that it would be useful to have some override of the TERM_TYPE detection, in case of some new future serial console kind not catched by the above rootskel/console-detect code, i don't know if this is already possible, but this would be a separate bug report maybe. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: partitioner seems confused
On Wed, Dec 13, 2006 at 11:09:18PM -0500, Dennis Clarke wrote: > > During install onto a PowerPC based EFIKA unit the installer complained : > > This partitioner doesn't have information about the default type of > partition tables on your architecture. Hi Denis, ... The Efika will not be supported by a 2.6.18 kernel, which is what will ship in etch, as thus i doubt there will be any sense of asking for help here. I am actively working on fixing those issues, and will merge whatever patches are mergeable in d-i before the etch release, and have the rest go in afterward. Please have a look at : http://people.debian.org/~luther/efika, where you will find my ongoing work (which among others fixes this issue you are seeing), and which will be the canonical way to find debian-on-efika information and stuff. Please forward any bug report you may have to me personally ([EMAIL PROTECTED] please), so i am early in the loop and can give you advice and fix those issues first which are important to you. I am working on the serial issues you are seeing too, but like said, i have gotten only second hand vague reports upto now. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newest powerpc install disks not booting
On Wed, Dec 13, 2006 at 09:06:30AM -0200, Lucas Rossi wrote: > > > > ftp://ftp.debian.org/debian/dists/stable/main/installer-powerpc/current/images/powerpc/floppy Well, since miboot is not free (yet), it was not included in the sarge official builds. Your best guess is to rebuild the debian-installer package of sarge yourself, after having installed the miboot package (from http://people.debian.org/~luther/miboot if i remember well), which would yield you not-broken miboot floppies for installation on your old world system. On a sarge powerpc system : 1) lftp http://people.debian.org/~luther/miboot 2) mget *.deb 3) dpkg -i *.deb 4) apt-get source debian-installer 5) cd debian-installer- 6) apt-get build-dep debian-installer 7) dpkg-buildpackage -rfakeroot -us -uc Not sure if this will do it, but should be a good start. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Newest powerpc install disks not booting
On Tue, Dec 12, 2006 at 06:31:49AM -0200, Lucas Rossi wrote: > Hi folks! > > I'm trying to install Debian sarge in a Power Macintosh 8500/150 > (Old World). The problem is that the newest floppy disks aren't > booting. When I use the image boot.img the pc doesn't accept the disk > and spit it out. > > So I tried to use a older image, but then I have other > compatibility problems, mostly because of differences between > versions. > > The MacOS is already unninstalled. > > What can I do? Hi Lucas, ... I am rather busy with RL work, so please ask this on debian-boot instead. In general it is best to cross post these questions to debian-powerpc & debian-boot. Wouter, Frans and Holger are those more involved in those matters, and thus make sure they get involved. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Short ppc-prep install report
On Sun, Dec 10, 2006 at 01:56:46AM +0100, Ulrich Teichert wrote: > Hi, > > I've used the netboot iso images from Friday. Netbooting the kernel > on the PowerstackII went well, CD detection was OK, but I ran into > the already reported problem: > > Invalid Release file: no entry for main/binary-powerpc/Packages > > I briefly tested CD-booting instead, but wasn't successful at all. > I've tried: > > `boot cdrom` > `boot cdrom \install\prep\vmlinuz-prep.initrd` > > But nothing worked, I only got the error message: "The attempt to load > a boot image failed". Has this worked for anyone else before on this > kind of hardware? Like said, i was never able to boot from cdrom, but i didn't try much. The netboot vmlinuz-prep works fine, and this is what is the recomended installation method on prep. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#386265 closed by Frans Pop <[EMAIL PROTECTED]> (Bug#386265: fixed in base-installer 1.70)
On Wed, Dec 06, 2006 at 09:12:17AM +0100, Frans Pop wrote: > On Wednesday 06 December 2006 08:30, Sven Luther wrote: > > Frans, notice that yaird is still the prefered option for prep > > machines, as initramfs-tools still is unable to detect the root > > partition per default. > > Setting yaird as default for a subarch is not trivial and IMHO > initramfs-tools is currently much to be preferred over yaird. > > > Another solution would be to set the ROOT= variable in > > /etc/initramfs-tools/initramfs.conf (or whatever the conf file is > > named), to make sure the ramdisk knows about the ROOT to boot from. > > > > This would have to be done after initramfs-tools is installed, but > > before the kernel is installed (or at least configured), so inside > > base-installer. > > If you can create a file /target/etc/mkinitramfs/conf.d/preproot or It would be trivial, it would just have a single line which is ROOT=... And the root partition can be grabbed from debconf already. I guess i can grab code from nobootloader for that. Will do this, not sure if i have time before the WE, but i will try this. > similar instead, this looks trivial. Yep. > base-installer already does similar things starting from line 735. > Creating and testing a patch should be fairly trivial. Cool. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#386265 closed by Frans Pop <[EMAIL PROTECTED]> (Bug#386265: fixed in base-installer 1.70)
On Tue, Dec 05, 2006 at 03:33:30PM -0800, Debian Bug Tracking System wrote: >* Only offer initramfs generator selection at low priority as yaird is no > longer a really logical option. Frans, notice that yaird is still the prefered option for prep machines, as initramfs-tools still is unable to detect the root partition per default. Another solution would be to set the ROOT= variable in /etc/initramfs-tools/initramfs.conf (or whatever the conf file is named), to make sure the ramdisk knows about the ROOT to boot from. This would have to be done after initramfs-tools is installed, but before the kernel is installed (or at least configured), so inside base-installer. Ideally, initramfs-tools should do a ROOT=probe (like on yaird and initrd-tools), and allow a command line override of the root= option, but this is something i see the initramfs-tools guys to be very recalcitrant with. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401264: partman-auto-lvm: [powerpc, prep] On PReP systems, no separate /boot is needed, since we have the prep partition
On Mon, Dec 04, 2006 at 10:51:33PM +0100, David Härdeman wrote: > On Sat, Dec 02, 2006 at 09:37:18AM +0100, Sven Luther wrote: > >Package: partman-auto-lvm > >Version: 18 > >Severity: normal > > > > > >Hello, ... > > > >I am doing a prep install on my motorola powerstack II, and found that > >chosing > >a LVM automated setup, the recipes automatically creates a separate /boot > >partition. > > > >On PReP system, the kernel with builtin initrd and bootwrapper is put > >inside > >the PReP partition, so there is no need for a separate /boot outside the > >LVM. > >This should be valid for other root on RAID and LVM+CRYPTO recipes. > > Note that this requires changes to auto-lvm_tools.sh in partman-auto-lvm > if /boot is excluded since it includes the following lines: > > # Check if the scheme contains a boot partition; if not warn the user > if ! echo "$normalscheme" | grep -q "[[:space:]]/boot[[:space:]]"; then > db_input critical partman-auto-lvm/no_boot || true > db_go || return 30 > db_get partman-auto-lvm/no_boot || true > [ "$RET" = true ] || return 30 > fi Ah, nice catch. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No prep kernels in daily installer images?
On Sun, Dec 03, 2006 at 07:19:55PM +0100, Ulrich Teichert wrote: > Hi, > > >> > > >> > http://people.debian.org/~wouter/d-i/powerpc/daily/prep/netboot/vmlinuz-prep.initrd > >> > >> OK, I'll give 'em a spin on Sunday - I have guests tomorrow (well, rather > >> later today) and won't have time before. > > Tried it some minutes ago. The kernel boots OK on my Powerstack II using > tftp netbooting from a sarge box (I've used the firmware command "boot > net:,,"): > > Dec 3 19:10:06 mosna in.tftpd[6988]: RRQ from 192.168.22.57 filename > vmlinuz-prep.initrd > > and the installer comes up. It's still loading stuff, which will go on > for a while because of my lousy ISDN-line (I am working on it, I swear!), > but it really looks promising so far. Consider using approx on another box of your network, it really speeded my d-i testing turnover (by orders of magnitude, i am quite smitten by it). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No prep kernels in daily installer images?
On Mon, Dec 04, 2006 at 10:37:31AM +, Colin Watson wrote: > On Fri, Dec 01, 2006 at 10:56:36PM +0100, Sven Luther wrote: > > On Fri, Dec 01, 2006 at 09:47:26PM +0100, Frans Pop wrote: > > > So, some patience please. Hopefully this will be sorted out by early next > > > week. > > > > Like i said, netbooting is the prefered installation methods for prep boxes, > > especially powerstack II ones like the one Ulrich or myself has, and the > > daily > > build 2.6.18 based images should work just fine. > > At Frans' request, I've restored prep support in debian-cd, so with any > luck at least people will be able to try out prep CD booting. If it's > fundamentally broken we can always turn it off again like so: > > -for subarch in powerpc powerpc64 prep > +for subarch in powerpc powerpc64 Ok, i will test on both the powerstack II and the IBM 43P-140 i have here. My guess is that it may work on the IBM PReP and not on the powerstack, from older experiments. I think Attilio has the same IBM PReP box. How this works on other PReP systems, like the Bull Estrella, is anyone's guess, and as said, it will not work on Motorola PowerStack I (the hifi like boxed powerstack we played with in oldenbourg two years ago), since it needs the ppcbug zImage, which is not currently supported by mkvmlinuz. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#401271: [powerpc,prep] Motorola Powerstack II installation report.
On Sat, Dec 02, 2006 at 11:52:56AM -0500, Douglas Tutty wrote: > Hello, > > This may be a totally inappropriate comment and if it is please ignore > it and __please__ take no offence as none is inteded at all. None, taken. > It is refreshing to see collegial teamwork on the PPC/PReP front. Thank > you all for working together again peacefully. :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#386265: base-installer patch for prep support.
On Sat, Dec 02, 2006 at 06:33:10PM +0100, Frans Pop wrote: > On Saturday 02 December 2006 18:19, Otavio Salvador wrote: > > Could you comment on that? I agree with Sven here and I would like to > > remove all code specific for 2.4 kernels. I don't think we need to > > change all d-i code for it but when we're doing changes and that has > > code that's specific for 2.4 it could be dropped that time too. > > We've decided to postpone structural 2.4 cleanup until after Etch as > people may still want to create custom installers based on 2.4.27 (and as > that tree is still being maintained). Well, but as far as i know, this makes little sense on powerpc, and more to the point, the 2.4 based powerpc kernel images in question, are non-existent in the archive anymore. If someone makes a custom installer, he will most probably not name the images by the older naming scheme used for sarge, no ? How will base-installer/kernel react if the user uses some random naming scheme for his custom kernels. Furthermore, i also had that understanding, but i remember vaguely having seen random cleanup happening for dropping 2.4 stuff. Has 2.4 compatibility installs been done recently ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#386265: base-installer patch for prep support.
On Sat, Dec 02, 2006 at 03:07:06PM -0200, Otavio Salvador wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > + if [ "$1" = powerpc ] && [ "$SMP" ]; then > > + # 2.4 only has powerpc-smp. > > + echo "kernel-image-$KERNEL_MAJOR-$1$SMP" > > + fi > > + echo "kernel-image-$KERNEL_MAJOR-$1" > > + ;; > > Well this isn't a patch complain but lack of information from my > part. > > I would like to know why we're keeping support to 2.4 kernels since no > architecture is using it right now? We should drop it, i don't remember now if this was a leftover from the generic 2.4 removal i did, or if i had chosen not to touch that part of the patch back then. My vote is to drop all 2.4 memory from those files, especially for powerpc. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401271: [powerpc,prep] Motorola Powerstack II installation report.
On Sat, Dec 02, 2006 at 11:42:08AM +0100, Frans Pop wrote: > reassign 401271 partman-auto > retitle 401271 Separate boot partition not needed for prep systems > tags 401271 + pending > thanks > > On Saturday 02 December 2006 10:47, Sven Luther wrote: > > Comments/Problems: > > 1) PReP machines need 2.6.18 based -prep kernels, as thus, a unstable > > install will do it, and a testing/etch install needs some work. > > Should be solved as soon as 2.6.18 migrates to testing. Yep, hopefully soon, but then Ulrich wanted to make a test install tomorrow, and it is for his benefit that i tried it out. He is rejecting my mails due to my broken ISP setup, so if someone can forward him this installation report, i think he would appreciate. > > 3) /boot separate partition in RAID/LVM/Crypto cases is wasted, since > > the kernel will anyway reside on the PReP partition. > > Reassigning to partman-auto; have deleted definitions for /boot partitions > in powerpc-prep recipes. Cool. > > 4) PReP boxes don't know how to set command line options, so there is > > need to set it inside the ramdisk (not supported by initramfs-tools, > > but supported by yaird), so they need to be given by hand at the kernel > > bootwrapper kenrel args prompt. (This is a initramfs-tools bug, maybe > > RC ?). > > I've seen a sparate bug filed for this. Indeed. > > Now, about the workaround, currently you need to : > > > > 1) as soon as the base system is installed, when you are in the > > tasksel dialog, go to console 2, chroot /target, install lftp or some > > other tool and get the unstable mkvmlinuz and linux-image-2.6.18-3-prep > > kernels. > > Why install lftp? Just use wget... Well, lftp let you navigate the hierarchy and doesn't mean you have to type the exact url to download. But then wget falls under : "or some other tool". Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Regarding: Bug#401271: [powerpc,prep] Motorola Powerstack II installation report.
On Sat, Dec 02, 2006 at 12:45:30PM +0100, Geert Stappers wrote: > Op 02-12-2006 om 11:42 schreef Frans Pop: > > On Saturday 02 December 2006 10:47, Sven Luther wrote: > > > > > Now, about the workaround, currently you need to : > > > > > > 1) as soon as the base system is installed, when you are in the > > > tasksel dialog, go to console 2, chroot /target, install lftp or some > > > other tool and get the unstable mkvmlinuz and linux-image-2.6.18-3-prep > > > kernels. > > > > Why install lftp? Just use wget... > > | $ apt-cache show bash | head -n 3 > | Package: bash > | Essential: yes > | Priority: required > | $ apt-cache show wget | head -n 3 > | Package: wget > | Priority: important > | Section: web > | $ > > I can imagion that "install lftp or some other tool" is indeed needed. > > > I admit that I should have check "who is right". > > The reason for this message is to avoid > another "stop bashing me" message. > > The thing I would like to see are messages with technical content, > E-mail threads that tell why things works (or wouldn't work) Well, no, i think Frans question about why not wget was perfectly valid. I guess i didn't think of wget, or rather i was too lazy to copy such a long path by hand, and just installed lftp to get the stuff, with its nice mget linux-image*prep* syntax. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401271: [powerpc,prep] Motorola Powerstack II installation report.
Package: installation-reports Boot method: netboot image Image version: http://people.debian.org/~wouter/d-i/powerpc/20061201-12:56/prep/netboot/vmlinuz-prep.initrd Date: 2006/12/02 10:27 Machine: Motorola PowerStack II Processor: PPC 604e Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[E] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: Well, there are several issues here : 1) PReP machines need 2.6.18 based -prep kernels, as thus, a unstable install will do it, and a testing/etch install needs some work. Workarounds below. 2) PReP boxes need version 27 of mkvmlinuz, currently only in unstable, but which is scheduled for testing migration today. 3) /boot separate partition in RAID/LVM/Crypto cases is wasted, since the kernel will anyway reside on the PReP partition. 4) PReP boxes don't know how to set command line options, so there is need to set it inside the ramdisk (not supported by initramfs-tools, but supported by yaird), so they need to be given by hand at the kernel bootwrapper kenrel args prompt. (This is a initramfs-tools bug, maybe RC ?). 5) Even when 2.6.18 kernels are moved to etch, or with a sid install, there is still a problem with base-installer, which will install the -powerpc kernel. The patch attached to #386265 (Open since 86 days or so), is needed to fix this. Apart from these issues, the install went fine, i suppose. I didn't note the name of the LVM partition, so i have some trouble getting it by hand, but finally managed, it is /dev//root or /dev/mapper/-root. Now, about the workaround, currently you need to : 1) as soon as the base system is installed, when you are in the tasksel dialog, go to console 2, chroot /target, install lftp or some other tool and get the unstable mkvmlinuz and linux-image-2.6.18-3-prep kernels. 2) remove the already installed 2.6.17-2-powerpc kernels. Make sure no more /boot/vmlinuz* file is left. 3) install mkvmlinuz 27 (probably no more needed starting tomorrow). 4) go into /etc/initramfs-tools/initramfs-tools, and set ROOT=/dev//root. This used to work with yaird at least, and i think i remember this from the early initramfs-tools days, but i see it documented nowhere, so YMMV. 5) install the downloaded linux-image-2.6.18-3-prep with dpkg -i. Reboot. Try simply rebooting, if initramfs-tools fails at the finding root stage, reboot, and at the kernel command line option prompt, add a propper root=/dev/... entry. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386265: base-installer patch for prep support.
tags 386265 + patch
thanks
Hi,
Find attached a patch which chose a -prep kernel on prep boxes, and also
removed apus support, since we currently have no apus kernels.
I would appreciate a review of this one, to see if i didn't make a mistake
that may affect other stuff.
This patch also includes a /proc/cpuinfo output of my powerstack II, for
addition into the kernel choser testing infrastructure.
Friendly,
Sven Luther
Index: powerpc.sh
===
--- powerpc.sh (revision 42783)
+++ powerpc.sh (working copy)
@@ -9,7 +9,8 @@
;;
esac
case "$SUBARCH" in
- powermac*|prep|chrp*) echo "$family" ;;
+ powermac*|chrp*)echo "$family" ;;
+ prep) echo prep ;;
amiga) echo apus ;;
*)
warning "Unknown $ARCH subarchitecture '$SUBARCH'."
@@ -31,34 +32,26 @@
}
arch_get_kernel () {
- # The APUS kernels are in a separate source package, so may
- # sometimes have a different version number.
- apusversion=2.4.27
-
CPUS="$(grep -ci ^processor "$CPUINFO")" || CPUS=1
- if [ "$CPUS" ] && [ "$CPUS" -gt 1 ] && [ "$1" != "powerpc64" ]; then
+ if [ "$CPUS" ] && [ "$CPUS" -gt 1 ] && [ "$1" != "powerpc64" ] && [
"$1" != "prep" ] ; then
SMP=-smp
else
SMP=
fi
- case "$1" in
- apus) echo "kernel-image-$apusversion-apus" ;;
+ case "$KERNEL_MAJOR" in
+ 2.6)
+ if [ "$SMP" ]; then
+ echo "linux-image-$KERNEL_MAJOR-$1$SMP"
+ fi
+ echo "linux-image-$KERNEL_MAJOR-$1"
+ ;;
*)
- case "$KERNEL_MAJOR" in
- 2.6)
- if [ "$SMP" ]; then
- echo
"linux-image-$KERNEL_MAJOR-$1$SMP"
- fi
- echo "linux-image-$KERNEL_MAJOR-$1"
- ;;
- *)
- if [ "$1" = powerpc ] && [ "$SMP" ];
then
- # 2.4 only has powerpc-smp.
- echo
"kernel-image-$KERNEL_MAJOR-$1$SMP"
- fi
- echo "kernel-image-$KERNEL_MAJOR-$1"
- ;;
- esac
+ if [ "$1" = powerpc ] && [ "$SMP" ]; then
+ # 2.4 only has powerpc-smp.
+ echo "kernel-image-$KERNEL_MAJOR-$1$SMP"
+ fi
+ echo "kernel-image-$KERNEL_MAJOR-$1"
+ ;;
esac
}
processor : 0
cpu : 604r
clock : ???
revision: 49.2 (pvr 0009 3102)
bogomips: 299.00
machine : PReP Utah (Powerstack II Pro4000)
l2 cache: 512KiB, parity disabled SRAM:synchronous, pipelined, no parity
Bug#401264: partman-auto-lvm: [powerpc, prep] On PReP systems, no separate /boot is needed, since we have the prep partition
Package: partman-auto-lvm Version: 18 Severity: normal Hello, ... I am doing a prep install on my motorola powerstack II, and found that chosing a LVM automated setup, the recipes automatically creates a separate /boot partition. On PReP system, the kernel with builtin initrd and bootwrapper is put inside the PReP partition, so there is no need for a separate /boot outside the LVM. This should be valid for other root on RAID and LVM+CRYPTO recipes. This may also be true on CHRP systems who use the zImage wrapper and a PReP partition, and not yaboot, but we use yaboot by default on those, and this would cause a time-travel loop, since the choice of bootloader is done after the partitioning step. Friendly, Sven Luther -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-2-powerpc Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No prep kernels in daily installer images?
On Sat, Dec 02, 2006 at 12:18:35AM +0100, Ulrich Teichert wrote: > Hi, > > >Prep support is missing in 2.6.16 and 2.6.17 debian kernels. It is present in > >2.6.18 kernels, with the -prep flavour, thanks to the work i did. I have not > >had time to test them, so feedback on this would be welcome, but at least > >they > >build. > > > >Please try the weekly cd builds (altough i never did manage to boot from cd), > >or better yet the netboot daily builds : > > > > > > http://people.debian.org/~wouter/d-i/powerpc/daily/prep/netboot/vmlinuz-prep.initrd > > OK, I'll give 'em a spin on Sunday - I have guests tomorrow (well, rather > later today) and won't have time before. > > >You do have a powerstack II (in a beige housing) or a powerstack I (in a hifi > >radio like black housing) ? > > It's a powerstack II. I have a powerstack I as well, but it got damaged > during transport and does not boot right now - no idea if I will get this > fixed. Is it even supported upstream? The same kernel supports it, but you need a .ppcbug instead of the .prep boot wrapper. I had access to some such in oldenbourg two years ago, and saw linux boot on it. If you ever bring it to work again, i would be very interested in having you test the .ppcbug (which is currently not built, but which i can enable again easily if there is a need) kernel wrapper, and give us some feedback on how d-i works on it. > >Also, note that you will need the -prep flavour, and no more the powerpc > >flavour, since prep did not yet migrate to ARCH=powerpc (together with apus, > >who is also disabled). > > Yeah, I know, Cool, Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No prep kernels in daily installer images?
On Fri, Dec 01, 2006 at 09:47:26PM +0100, Frans Pop wrote: > On Friday 01 December 2006 20:48, Ulrich Teichert wrote: > > today, I downloaded the latest netinst and business card image daily > > uilds of the debian installer for powerpc. Is it right that there are > > no prep kernels on it? On my recently acquired powerstack I can't boot > > install/powerpc/vmlinux, nor the ppc64 kernel (well, this expected, > > yes). However, there are prep udebs on the CD, so do I miss something > > obvious? > > There have been no recent daily d-i builds for powerpc due to networking > problems with the DD that builds them for us. Hey, if you want, i can reactivate my daily builds, i now also have access to an online XServe G5 which could easily host the daily builder and has good bandwidth and should have permanent uptime. Whatever you reproached to my own daily builds, you have to admit that they never experienced any network or otherwise related trouble. > Only when that is solved we can add support for prep in debian-cd. What > you currently see are only a few random udebs that are copied onto the CD > by default. Real support still needs to be added. But then, as long as we don't have evidence of a prep cd boot, i doubt it make sense to > > So, some patience please. Hopefully this will be sorted out by early next > week. Like i said, netbooting is the prefered installation methods for prep boxes, especially powerstack II ones like the one Ulrich or myself has, and the daily build 2.6.18 based images should work just fine. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No prep kernels in daily installer images?
On Fri, Dec 01, 2006 at 09:47:26PM +0100, Frans Pop wrote: > On Friday 01 December 2006 20:48, Ulrich Teichert wrote: > > today, I downloaded the latest netinst and business card image daily > > uilds of the debian installer for powerpc. Is it right that there are > > no prep kernels on it? On my recently acquired powerstack I can't boot > > install/powerpc/vmlinux, nor the ppc64 kernel (well, this expected, > > yes). However, there are prep udebs on the CD, so do I miss something > > obvious? > > There have been no recent daily d-i builds for powerpc due to networking > problems with the DD that builds them for us. > Only when that is solved we can add support for prep in debian-cd. What > you currently see are only a few random udebs that are copied onto the CD > by default. Real support still needs to be added. > > So, some patience please. Hopefully this will be sorted out by early next > week. Actually, at a quick glance, it seems the daily builds are again present since november 29, and there are nov 30, and two dec 1 builds. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: No prep kernels in daily installer images?
On Fri, Dec 01, 2006 at 08:48:04PM +0100, Ulrich Teichert wrote: > Hi, > > today, I downloaded the latest netinst and business card image daily > uilds of the debian installer for powerpc. Is it right that there are no > prep kernels on it? On my recently acquired powerstack I can't boot > install/powerpc/vmlinux, nor the ppc64 kernel (well, this expected, yes). > However, there are prep udebs on the CD, so do I miss something obvious? Prep support is missing in 2.6.16 and 2.6.17 debian kernels. It is present in 2.6.18 kernels, with the -prep flavour, thanks to the work i did. I have not had time to test them, so feedback on this would be welcome, but at least they build. Please try the weekly cd builds (altough i never did manage to boot from cd), or better yet the netboot daily builds : http://people.debian.org/~wouter/d-i/powerpc/daily/prep/netboot/vmlinuz-prep.initrd You do have a powerstack II (in a beige housing) or a powerstack I (in a hifi radio like black housing) ? Also, note that you will need the -prep flavour, and no more the powerpc flavour, since prep did not yet migrate to ARCH=powerpc (together with apus, who is also disabled). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394970: Please, add credits for patch while closing #394970
On Thu, Nov 30, 2006 at 06:40:16PM +0100, Fabio Tranchitella wrote: > Hi Frans, > > * 2006-11-30 18:33, Frans Pop wrote: > > On Thursday 30 November 2006 18:02, Fabio Tranchitella wrote: > > > do you mind to retroactively modify the changelog for the upload 2.6 > > > of finish-install to credit Sven Luther about the patch he submitted? I > > > do not want to be pedantic, and I know that you modified and fixed his > > > patch, but I think it would be correct considering that in the same > > > changelog entry you already cite the names of the translators who > > > submitted the updates. > > > > No sorry. > > The patch that was applied was not Sven's patch, but a patch I basically > > created myself from scratch. Sven's patch was broken (/etc/inittab would > > not have had the correct line) and had unnecessary code duplication (as > > he indicated himself). > > Fine, thanks for your explanation: I now understand your reasons, and I > accept it. I don't though. > > credit people just for submitting a bug report. > > That's normal. When people sen me bug reports and stuff, or even just push me to solve a bug they can reproduce, i always say : - Special thanks to for helping solve this bug. But then, this is part of Frans continuous trend to discredit my technical work, to lessen my contribution, and to outcast me in general. > > Sven has always been correctly credited for any patches he's submitted or > > work he's contributed. > > Thanks for confirming this, too. This is not the full truth though, but the devil is in the detail. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: g5 noise issue in RC1 - patch for the errata
On Thu, Nov 30, 2006 at 04:42:55PM +0100, Holger Levsen wrote: > Hi, > > I propose to add the following and attached patch to the errata: > > [Issues on powerpc] > > + on G5 imacs the fans are very loud, switch to a different > + console and run href="http://svn.debian.org/wsvn/d-i/trunk/packages/rootskel/src/lib/debian-installer-startup.d/S05fancontrol-linux-powerpc?op=file&sc=1";>these > > commands to make them silent. Holger, ... The issue is not restricted to G5 imacs, but to all G5/64bit powerpc hardware from apple. This means also the G5 powermacs, and the G5 XServers. So, i would use instead : On G5 Apple machines, ... > If you say go ahead, I can commit it myself. Otherwise feel free to reword > it, > but this annoying issue should be documented properly. > > BTW, http://www.debian.org/devel/debian-installer/errata doesn't mention how > to report bugs to the errata - in the bottom it even tells me to report > problems to [EMAIL PROTECTED] What _is_ the correct way? > > BTW2, I also suggest to truncate the comment in S05fancontrol-linux-powerpc > to > the first four words of it - ibook's and other fans dont go to aircraft I don't remember the comment exactly, but notice that : * I think i said something about G5 apple machines, or should have, there are no G5 ibooks or powerbooks. * Most of the modules are only present in the powerpc64 flavour. > levels and the filename suggest it's executed on all powerpc machines.. Ideally, a check for 64bitness could be added, altough i had some user suggest that some of those modules would be useful on ibooks also. I am not fully sure as i didn't investigate at the time. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394970: which serious bugs exactly? (Re: if you care about debian on powerpc, please react ...)
On Thu, Nov 30, 2006 at 12:17:07PM +0100, Holger Levsen wrote: > Hi, > > On Sunday 26 November 2006 15:09, Sven Luther wrote: > > > > currently shiping powerpc hardware are : > > > > IBM pseries : not really supported, patch sitting without comment > > > > since months, early work lost because of svn commit conflicts. > > > raise the bug severity? which bug#, btw? > > > > Outstanding bugs -- Normal bugs; Patch Available (1 bug) > > #394970: finish-install: [powerpc64] Add support for IBM serial consoles > > (hvc and hvsi) > > Package: finish-install (finish-install 2.4); Reported by: Sven Luther > > <[EMAIL PROTECTED]>; Tags: patch; 33 days old > > Sven, the last info on this bug is from you, saying that you would test the > patch Frans corrected the coming (and now past) weekend. You didn't post an > update how the test went, so I'm not surprised the patch isn't commited. I didn't, because 1) the box is not connected now, and i had the XServe G5 in the rack, which was being prepared to be put in production, and due to bugs like : #397973 [powerpci/mac] partman-md appears to not write back the raid flag to partitions. This took longer, and i was able to put it in the datacenter only yesterday, freeing the rack. 2) The p505 i have on lend from IBM now has the VIOS server installed, and i need to read the 150+ pages of documentation to become familiar with the LPAR setup code, before doing the test. 3) Last sunday, we did my 2 year son's birthday party, which didn't leave me time to do the testing, especially given the issues with 1), and other work related issues, which had more priority. So, no, i didn't have time to test it, the day has only so much hours, and you would understand, that family live and RL work takes priority, as so many have been telling me recently. Now, there is no excuse to not commit the patch, especially the one modified by Frans, to the svn, and indeed i expect it to be commited already, just waiting for my test to upload the package. Even then, what really needs testing, is the check for the patch to not break finish-install on other hardware, to make sure there are no regressions, and this would be better served by the patch going in ASAP, rather than waiting longer. This would also allow to setup a call for user to test, rather than relying on only me. > How did the test went? Is the patch now fine? Could you please add this > information to the bugreport?! Thanks. > > As you mention this bug in this thread under the "powerpc should be removed > because arch support is poor" label (which I still think isn't true), I > wonder if the severity "normal" is correct. Well, if i upgrade severity, i am sure to get an immediate backlash, but you are free to do so if you like. In general, i would seriously welcome more people working on the powerpc port, and not people like you leaving all the pressure on me, or like frans said once : "we won't bother fixing powerpc issues, since we know svenl will eventually fix them". This doesn't scale well to me having less time due to RL issues, as you might guess. And may have been one of the cause of the escalation of those problems back in spring, there is such a thing like over-stressing your human ressources, any good leader should know that :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Processing of linux-kernel-di-powerpc-2.6_1.24_powerpc.changes
On Mon, Nov 27, 2006 at 01:08:45PM +, Archive Administrator wrote: > linux-kernel-di-powerpc-2.6_1.24_powerpc.changes uploaded successfully to > localhost > along with the files: > linux-kernel-di-powerpc-2.6_1.24.dsc > linux-kernel-di-powerpc-2.6_1.24.tar.gz Colin, ... I would have appreciated if you had credited me for the abi bump, since i was the one doing it, even though someone called "debian-boot" asked for a REJECT. Give credit where credit is due, please. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer wants to destroy
On Sun, Nov 26, 2006 at 11:00:01PM +0100, Geert Stappers wrote: > Op 26-11-2006 om 21:11 schreef Sven Luther: > > On Sun, Nov 26, 2006 at 04:41:38PM +0100, Geert Stappers wrote: > > > > > > Op 26-11-2006 om 15:44 schreef Sven Luther: > > > > ... it can only end with me being totally destroyed. > > > > > > Fine, just continue with what you are doing. > > > > And you would have played a strong role in this. But Fabio proposed to act > > as > > mediator, and both me and Frans (on behalf of the un-named other guys i > > guess), as well as the DPL agreed to it, so let's see what it brings. > > > > But if you are really honest with yourself, you will be able to see your own > > part in what happened in this. I know my part, and i made ammend, and i > > tried > > to engage conciling discussion, but to absolutely no avail. > > > > Maybe if someone else than me points you to your negative participation in > > this, you will be able to aknowledge it, as well as the positive > > participation > > i know you also had, and we will be able to move forward in this discussion. > > > > Friendly, > > > > Sven Luther > > > I'm still in doubt what is a better aproach, fjp or joeyh. > fjp: I never ignored you on mailinglists > joeyh: I'm ignoring him for various reasons since october 2005 The problem is that frans is only partially truthful about this. He indeed didn't ignore me on the mailing list about technical issue, altough he sometimes (and at moments quite often) resorted to agressive bashing, for the most superficial of reasons. Now, the real problem is not about the technical issue, but about the abysmal social problem, and i almost never got any reply from my conciliation proposals on the mailing list, and on irc, it always ended in the "FUCK YOU" variety. > The mediation is about a personal problem "Frans versus Sven". Well, given that the others chose not to name themselves, it clearly seems a "Frans vs Sven" issue. But what you are missing here is that it is not a "Frans vs Sven" issue or a "Frans and some others vs Sven" issue, but instead it is trying to find a solution to a broken social situation, so that all parties win, and everyone is happy about the outcome. This is what i most fervently wish for, and which i hope a real mediation attempt will bring. I have some doubt the other side of this conflict sees it such, and make it into a to-the-death kind of fight, where they will either lose face, or i will be fully destroyed. This is clearly the impression i get, i may be wrong, and some people tell me i am wrong, but i never got even a hint of the what the other side feelings and position is that would contradict this impression. Frans and the DPL, and others like Raphael Hertzog, clearly stated that a pre-alable of it ever being solved is for me to recognize publicly that all is my fault. I am a honest person, i don't see it such, and despite what you, frans, joeyh, aj, and others want to believe, the fault is shared, and trying to end it by having one side recognize all fault is his, is what i mean when i say that they are out to "destroy" me. You also participated in this. The good way out of this, and the one i started doing in the wiki page, and which you ridiculized in your reply to it, is to not mention past faults, which most probably where not meant, but came out because of anger and suffering, and instead forget about them, analyze the current situation, and then go forward from there, and modify the situation from one where we get a new escalating clash each other week, to one where the situation can smooth itself over time. > The outcome is only relevant for those two. Yeah, right, so, now i am confused, you are saying that it is a personal feud between frans and me, or the contrary ? > I wonder how Sven will bend the personal conflict in a debian-installer > conflict. Because there is also a lot of damage to repair. And you caused a rather important part of that damage. > Anyway: enough food for the energybeast[1] today. You know that this kind of comments is insulting in its own right ? You know how you are de-humanizing me by this, and making me not a man of flesh and blood, with feeling and sentiments, but a thing to be figthed ? Seriously Geert, i am seriously disapointed in you, remember how we meet for the first time in oldenbourg in 98, and then again in linuxtag a couple of years ago, how we spoke together then, and worked together on conglomerate ? Am i really a thing to be fighted ? and energybeast ? Do you think this kind of behaviour can in any way help solve this issue ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Developer wants to destroy
On Sun, Nov 26, 2006 at 04:41:38PM +0100, Geert Stappers wrote: > > Op 26-11-2006 om 15:44 schreef Sven Luther: > > ... it can only end with me being totally destroyed. > > Fine, just continue with what you are doing. And you would have played a strong role in this. But Fabio proposed to act as mediator, and both me and Frans (on behalf of the un-named other guys i guess), as well as the DPL agreed to it, so let's see what it brings. But if you are really honest with yourself, you will be able to see your own part in what happened in this. I know my part, and i made ammend, and i tried to engage conciling discussion, but to absolutely no avail. Maybe if someone else than me points you to your negative participation in this, you will be able to aknowledge it, as well as the positive participation i know you also had, and we will be able to move forward in this discussion. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-di-powerpc-2.6_1.24_powerpc.changes REJECTED
On Sun, Nov 26, 2006 at 03:18:57PM +0100, Geert Stappers wrote: > That does remind me of a person showing scrafs of self inflected wounds. > It took me a few days that she was actually telling "I'm now over it" > > Right now I'm seeing Sven Luther raging in an ineffective way. Well, it seems like others, you are not able to differentiate rage, from pain and desesperation, and a cry for help. > I wonder when he will be able to cope with the current situation. Never, the current situation is setup in such a way, that it is impossible to cope with it, and it can only end with me being totally destroyed. > Currently I only see him shouting "I am unter attack!!". The thing I mis > in his attitude is patience. Patience to take time to write a ask "Why > was the upload rejected?". Patience to wait for the reason why an upload > was rejected. Like i am waiting since april to know exactly what is reproached me ? Patience, like what Frans showed when he noticed the cosmetic bug in my upload ? > The "Sven Luther pattern" says that this message will get a long > follow-up message explain that Sven Luther is right. With some luck > we get over three years an answer saying "I'm now over it" No, you will either get some exterior party intervening and solving the issue, or you will see me leave debian forever. Sven: An last a personal message to Frans, remember when we where in Extremadura, we had a good time, and we worked side by side. I seriously lament that it all degenerated like it did. I certainly have my part of responsability in this, but i passed though times, as you know. Let's put pride and arrogance and remembrance of past hurts aside, and let's again work on d-i all together, as it should be. Frans: My honest opinion of it: the biggest load of self-satisfied and self-centered crap I've ever seen FUCK YOU! I hope you also remember your own response to the my wiki page. Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-di-powerpc-2.6_1.24_powerpc.changes REJECTED
On Sat, Nov 25, 2006 at 07:42:11PM +, Archive Administrator wrote:
> reject as requested by debian-boot
FRANS, CAN YOU PLEASE STOP THIS CONTINUOUS HARRASMENT.
WHAT DO YOU HOPE TO ACHIEVE BYY THIS ?
IF YOUR INTENTION IS TO DRIVE ME CRAZY, AND GET ME TO LEAVE DEBIUAN< WELL< YOU
ARE SUCCEDDING< I HOPE YOU ARE HAPPY BY THIS.
AND ALL OF YOU OTHERS WHO PARTICIPATED IN THIS, Holger, GERt, JOEY H, Steve
lanagsek, i hope you ARe happy about what you did.
As for all other,s i thank the few who supported me, and i hope that all those
others who chose to look the other side, saying this is not my problem, and
hoping i will go away, will know the part they played in this.
In particular this is a message to Christian, you are the third of the d-i
triumvirat, and you should have said something, and not let this happen or at
least said something.
I don't think i care to work anymore with people who chose to see someone
driven crazy, and look the other side.
THIS IS A LAST CALL FOR HELP.
PLEASE PLEASE PLEASE PLEASEPLEASEPLEASE.
SOMEONE SPEAK WITH FRANS ABOUT THIS.
SOMEONE DO SOMETHING.
HEPL ME HELP ME HELP ME HELPE ME.
SOMEONE DO SOMETHING.
HWOP CAN YOU LET SOMEONE YOU KNOW AND WORKED WITH BE DESTROYED LIKE I AM BEING
DESTROYED ?
HELP
hEPL]
HEPL
HEOPL
HEPL
HE{L:
JHEPL
JFEeivn
SVEN:
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: linux-kernel-di-powerpc-2.6_1.24_powerpc.changes REJECTED
Hi fellow debian-powerpc users, Once more, some influent folk in the debian-boot team, who didn't even want to be named, is trying to stop me from working on powerpc d-i. Frans requested uploads of 2.6.18-3 .udeb packages, and so i did it, but the package was rejected. Fellow powerpc debian users, i urge you to speak up, and push for this issue to be sorted. It is clear that nothing i say or do will have any influence on this, and both our DPL, and people of the tech ctte, like ian and steve, are fully letting this happen. Those of you who said they would be willing to mediate in this, can i ask you to do something, this is driving me crazy, and all the time i spent in this childish fight i so often wanted to end, i cannot spend fixing bugs. Please help me stop this witch hunt. Sven: An last a personal message to Frans, remember when we where in Extremadura, we had a good time, and we worked side by side. I seriously lament that it all degenerated like it did. I certainly have my part of responsability in this, but i passed though times, as you know. Let's put pride and arrogance and remembrance of past hurts aside, and let's again work on d-i all together, as it should be. Frans: My honest opinion of it: the biggest load of self-satisfied and self-centered crap I've ever seen FUCK YOU! Friendly, Sven Luther On Sat, Nov 25, 2006 at 07:42:11PM +, Archive Administrator wrote: > reject as requested by debian-boot > > > > === > > If you don't understand why your files were rejected, or if the > override file requires editing, reply to this email. > --- > Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. > Aucun virus connu a ce jour par nos services n'a ete detecte. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
