Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: Maybe the installer kernel would have the release version on the package name and then it wouldn't be remove from the suite until the next version. e.g: - linux-image-d-i-4.0-rc1 So you prefer ugly hacked solution over cleant and neat ones ? It would make sure that all udebs would be available until we move the: - linux-image-d-i-4.0-rc2 or - linux-image-d-i-4.0-release Yeah. You know we stopped doing this kind of stuff for the kernel package over a year ago, and probably for a reason, don't you think ? We stopped doing that for kernel packages. The problem here is that, without doing that the binaries will stay but without source code... that will be a GPL violation AFAIK. Or I didn't understand what you're proposing or I don't think your problem will source the GPL violation of lack of source code of binaries. That's what I don't think it'll solve. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Mon, Nov 06, 2006 at 09:05:24AM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Maybe the installer kernel would have the release version on the package name and then it wouldn't be remove from the suite until the next version. e.g: - linux-image-d-i-4.0-rc1 So you prefer ugly hacked solution over cleant and neat ones ? It would make sure that all udebs would be available until we move the: - linux-image-d-i-4.0-rc2 or - linux-image-d-i-4.0-release Yeah. You know we stopped doing this kind of stuff for the kernel package over a year ago, and probably for a reason, don't you think ? We stopped doing that for kernel packages. The problem here is that, without doing that the binaries will stay but without source code... that will be a GPL violation AFAIK. Indeedm which is why the .udebs should be built from the kernel packages directly, but then i will be lapidated for suggesting this again. :) Or I didn't understand what you're proposing or I don't think your problem will source the GPL violation of lack of source code of binaries. That's what I don't think it'll solve. No, to the contrary, it will solve the problem. Since for every kernel abi number, we will store both the .debs and the .udebs into a separate archive, instead of the current situation, so all .debs will always be together with their source. The only problem would be for .udeb package not being rebuilt with the latest kernel of an abi-serie, but this could easily be fixed, and like said, building the .udebs from the kernel package will solve that. We will only advertize some of those kernels as officially supported, and the rest will act a bit like the snapshot.debian.net stuff, and would not even need to be available on all mirrors or something. Like said, a clean and neat, complete solution, which just need a bit of work to make happen. Friendly, Sven Luther -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- 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]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: Yeah. You know we stopped doing this kind of stuff for the kernel package over a year ago, and probably for a reason, don't you think ? We stopped doing that for kernel packages. The problem here is that, without doing that the binaries will stay but without source code... that will be a GPL violation AFAIK. Indeedm which is why the .udebs should be built from the kernel packages directly, but then i will be lapidated for suggesting this again. :) Or I didn't understand what you're proposing or I don't think your problem will source the GPL violation of lack of source code of binaries. That's what I don't think it'll solve. No, to the contrary, it will solve the problem. Since for every kernel abi number, we will store both the .debs and the .udebs into a separate archive, instead of the current situation, so all .debs will always be together with their source. The only problem would be for .udeb package not being rebuilt with the latest kernel of an abi-serie, but this could easily be fixed, and like said, building the .udebs from the kernel package will solve that. We will only advertize some of those kernels as officially supported, and the rest will act a bit like the snapshot.debian.net stuff, and would not even need to be available on all mirrors or something. Like said, a clean and neat, complete solution, which just need a bit of work to make happen. I like the idea while I keep in my mind that Joey had some reasons to dislike the udeb building from kernel source. I don't remember which was the reasons but would be good if you review his posts and check if those problems will still happen if we implement your proposal. Other problem that I see is how we'll say: version X is supported version Y isn't supported, use at your own risk that can stay to be messy. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Mon, Nov 06, 2006 at 09:27:10AM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Yeah. You know we stopped doing this kind of stuff for the kernel package over a year ago, and probably for a reason, don't you think ? We stopped doing that for kernel packages. The problem here is that, without doing that the binaries will stay but without source code... that will be a GPL violation AFAIK. Indeedm which is why the .udebs should be built from the kernel packages directly, but then i will be lapidated for suggesting this again. :) Or I didn't understand what you're proposing or I don't think your problem will source the GPL violation of lack of source code of binaries. That's what I don't think it'll solve. No, to the contrary, it will solve the problem. Since for every kernel abi number, we will store both the .debs and the .udebs into a separate archive, instead of the current situation, so all .debs will always be together with their source. The only problem would be for .udeb package not being rebuilt with the latest kernel of an abi-serie, but this could easily be fixed, and like said, building the .udebs from the kernel package will solve that. We will only advertize some of those kernels as officially supported, and the rest will act a bit like the snapshot.debian.net stuff, and would not even need to be available on all mirrors or something. Like said, a clean and neat, complete solution, which just need a bit of work to make happen. I like the idea while I keep in my mind that Joey had some reasons to dislike the udeb building from kernel source. I don't remember which He dislikes it, because he then will have less control over the .udeb content. But the one archive-per-kernel-abi idea is not dependent on building the .udebs from the linux-2.6 source package, so this doesn't apply here. was the reasons but would be good if you review his posts and check if those problems will still happen if we implement your proposal. I will expose these ideas at fosdem, during a conference, and we can have a chat afterward. It is etch+1 material anyway. And then we can retalk about them at debconf'07. Other problem that I see is how we'll say: version X is supported version Y isn't supported, use at your own risk Well, the supported versions may be pulled in into the sarge/etch/sid relese files, the per-version only being around for development cycles. The d-i image, could even go as far as noticing that you are using a kernel which is not in the main releases, informing the user that he may be using an out-dated image, and then looking at the per-abi archives that can stay to be messy. Not if done right, and as said, this plan has the potential to be a clean and neat implementation, where everyone will say afterward, how did we ever manage it before. The real interogation are on the ftp-master side. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: I like the idea while I keep in my mind that Joey had some reasons to dislike the udeb building from kernel source. I don't remember which He dislikes it, because he then will have less control over the .udeb content. But the one archive-per-kernel-abi idea is not dependent on building the .udebs from the linux-2.6 source package, so this doesn't apply here. Well, since it doesn't depend, so let's we skip it for now. was the reasons but would be good if you review his posts and check if those problems will still happen if we implement your proposal. I will expose these ideas at fosdem, during a conference, and we can have a chat afterward. It is etch+1 material anyway. And then we can retalk about them at debconf'07. Right. Would be nice to meet you there :-D Other problem that I see is how we'll say: version X is supported version Y isn't supported, use at your own risk Well, the supported versions may be pulled in into the sarge/etch/sid relese files, the per-version only being around for development cycles. The d-i image, could even go as far as noticing that you are using a kernel which is not in the main releases, informing the user that he may be using an out-dated image, and then looking at the per-abi archives Yes. That would be nice to have. That would make the user life easier so he will be informated what's going on instead of just fail to install. that can stay to be messy. Not if done right, and as said, this plan has the potential to be a clean and neat implementation, where everyone will say afterward, how did we ever manage it before. The real interogation are on the ftp-master side. heheh. Let's hope they like the idea ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Sat, Nov 04, 2006 at 08:37:51PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: The biggest problem here is that will looks like we'll support all those combinations regarting security and also bug fixing and this won't be true... that can be used if it stay just as a sid resource... Since the problem of moving versions only appears during the development phase of a release, not once it is released, this is indeed no problem at all. Please go ahead and try to do a beta3 netboot install right now, it will have trouble since we can't have 2.6.15 or whatever it was, and 2.6.17 kernel modules in the archive at the same time. Not easily anyway. Yes. I know it'll fail. I see the problem you're trying to address ... I just not sure if it's the right way to solve it. Do you see another way ? I mean, sure doing nothing and ignoring the issue is another way to address the issue, but somehow that is not very satisfying. Maybe the installer kernel would have the release version on the package name and then it wouldn't be remove from the suite until the next version. e.g: - linux-image-d-i-4.0-rc1 So you prefer ugly hacked solution over cleant and neat ones ? It would make sure that all udebs would be available until we move the: - linux-image-d-i-4.0-rc2 or - linux-image-d-i-4.0-release Yeah. You know we stopped doing this kind of stuff for the kernel package over a year ago, and probably for a reason, don't you think ? In that way we don't need to support a lot of images but just the current and the next one while doing the development on sid. Keep on mind that we don't have two major kernel versions anymore and then it would be easy to do. It would work basically as other core components like GCC or XEN. Yeah, like the 3-4 gcc versions we keep around. This doesn't solve the problem of older d-i images though. But we will see. Friendly, Sven Luther -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- 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]
Regarding: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Op 03-11-2006 om 03:03 schreef Frans Pop: On Thursday 02 November 2006 22:38, Otavio Salvador wrote: There's no need to _ask_ you before to open a bug report. We're a comunity and as one we all want the best for the project. I did not say that _I_ needed to be asked, I said it needed to be discussed on the debian-boot list first, Yes and also judged As such, this is an unauthorized request. The full quote I did not say that _I_ needed to be asked, I said it needed to be discussed on the debian-boot list first, especially when they are general purpose architecture all/any udebs as in this case. Adding an architecture specific udeb is much less problematic. Please keep d-i same for all architectures. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: Another alternative can be use something like edeb for embeed devices. That would be a clear option then use udeb for both. Using another group of packages would make both worlds happy and make both team lives easier. One wouldn't affect the other with their respective decisions. My belief is that, once post etch we have support for multiple udeb sources, we should split the archive thus : - the libraries and support package (like parted) in a generic archive. - the debian-installer packages in a debian-installer archive. Agree on that. While those (libraries) will still need coordination since they will directly affect d-i. - the kernel modules in a separate archive, of which there would be one by kernel version (upstream+abi), so as to keep d-i images alive even when new kernel versions are pushed in the archive. Further separation into flavours may help low memory systems on arches with a lot of flavours. The biggest problem here is that will looks like we'll support all those combinations regarting security and also bug fixing and this won't be true... that can be used if it stay just as a sid resource... But let's discuss this post etch. I am thinking of doing a fosdem presentation of my ideas, preferably with proof of concept, which should satisfy all the need for discussion and implementation details, and this happening at the start of the etch+1 devel cycle will make sure we can think about it without being in a rush. Indeed. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Sat, Nov 04, 2006 at 08:34:02AM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: - the kernel modules in a separate archive, of which there would be one by kernel version (upstream+abi), so as to keep d-i images alive even when new kernel versions are pushed in the archive. Further separation into flavours may help low memory systems on arches with a lot of flavours. The biggest problem here is that will looks like we'll support all those combinations regarting security and also bug fixing and this won't be true... that can be used if it stay just as a sid resource... Since the problem of moving versions only appears during the development phase of a release, not once it is released, this is indeed no problem at all. Please go ahead and try to do a beta3 netboot install right now, it will have trouble since we can't have 2.6.15 or whatever it was, and 2.6.17 kernel modules in the archive at the same time. Not easily anyway. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: On Sat, Nov 04, 2006 at 08:34:02AM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: - the kernel modules in a separate archive, of which there would be one by kernel version (upstream+abi), so as to keep d-i images alive even when new kernel versions are pushed in the archive. Further separation into flavours may help low memory systems on arches with a lot of flavours. The biggest problem here is that will looks like we'll support all those combinations regarting security and also bug fixing and this won't be true... that can be used if it stay just as a sid resource... Since the problem of moving versions only appears during the development phase of a release, not once it is released, this is indeed no problem at all. Please go ahead and try to do a beta3 netboot install right now, it will have trouble since we can't have 2.6.15 or whatever it was, and 2.6.17 kernel modules in the archive at the same time. Not easily anyway. Yes. I know it'll fail. I see the problem you're trying to address ... I just not sure if it's the right way to solve it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Sat, Nov 04, 2006 at 03:11:08PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: On Sat, Nov 04, 2006 at 08:34:02AM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: - the kernel modules in a separate archive, of which there would be one by kernel version (upstream+abi), so as to keep d-i images alive even when new kernel versions are pushed in the archive. Further separation into flavours may help low memory systems on arches with a lot of flavours. The biggest problem here is that will looks like we'll support all those combinations regarting security and also bug fixing and this won't be true... that can be used if it stay just as a sid resource... Since the problem of moving versions only appears during the development phase of a release, not once it is released, this is indeed no problem at all. Please go ahead and try to do a beta3 netboot install right now, it will have trouble since we can't have 2.6.15 or whatever it was, and 2.6.17 kernel modules in the archive at the same time. Not easily anyway. Yes. I know it'll fail. I see the problem you're trying to address ... I just not sure if it's the right way to solve it. Do you see another way ? I mean, sure doing nothing and ignoring the issue is another way to address the issue, but somehow that is not very satisfying. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: The biggest problem here is that will looks like we'll support all those combinations regarting security and also bug fixing and this won't be true... that can be used if it stay just as a sid resource... Since the problem of moving versions only appears during the development phase of a release, not once it is released, this is indeed no problem at all. Please go ahead and try to do a beta3 netboot install right now, it will have trouble since we can't have 2.6.15 or whatever it was, and 2.6.17 kernel modules in the archive at the same time. Not easily anyway. Yes. I know it'll fail. I see the problem you're trying to address ... I just not sure if it's the right way to solve it. Do you see another way ? I mean, sure doing nothing and ignoring the issue is another way to address the issue, but somehow that is not very satisfying. Maybe the installer kernel would have the release version on the package name and then it wouldn't be remove from the suite until the next version. e.g: - linux-image-d-i-4.0-rc1 It would make sure that all udebs would be available until we move the: - linux-image-d-i-4.0-rc2 or - linux-image-d-i-4.0-release In that way we don't need to support a lot of images but just the current and the next one while doing the development on sid. Keep on mind that we don't have two major kernel versions anymore and then it would be easy to do. It would work basically as other core components like GCC or XEN. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Friday 03 November 2006 08:29, Sven Luther wrote: I tagged the bug d-i, i think, which should have been enough to attract your attention. At least this is how i understood the issue. No, it is not. I don't get some kind of automatic notification by email for bugs tagged d-i. Or don't you monitor d-i tagged bugs anymore ? It's probably something I do too little. pgpS0RHaecWrK.pgp Description: PGP signature
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Fri, Nov 03, 2006 at 11:18:09AM +0100, Frans Pop wrote: On Friday 03 November 2006 08:29, Sven Luther wrote: I tagged the bug d-i, i think, which should have been enough to attract your attention. At least this is how i understood the issue. No, it is not. I don't get some kind of automatic notification by email for bugs tagged d-i. Or don't you monitor d-i tagged bugs anymore ? It's probably something I do too little. Ah, i thought there was some automatic tool, or whatever, so much for me, next time i will make sure to CC debian-boot or something, that said i was kill-filled by most of you guys, so i was not sure how useful it is. Now, apparently you are not kill-filling me anymore :) BTW, i still don't understand the problem with non-di-image low priority additional .udebs. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Friday 03 November 2006 11:33, Sven Luther wrote: Ah, i thought there was some automatic tool, or whatever, so much for me, next time i will make sure to CC debian-boot or something, that Please discuss it on the list _before_ you file a bug report. said i was kill-filled by most of you guys, so i was not sure how useful it is. Now, apparently you are not kill-filling me anymore :) I have _never_ kill-filed you for listmail. BTW, i still don't understand the problem with non-di-image low priority additional .udebs. Read again my answer to Otavio. It is in there. The udeb section was created specifically for Debian Installer. IMO that means that the d-i team has veto rights over anything that goes in there. The logical consequence of that is that new udebs should be discussed on the debian-boot list before they are requested or created. Again, possibly with the exception of architecture specific things (which should be discussed with/between the d-i porters). However, even for these discussing, or at least announcing, them on the list would be welcome. pgpaMZJqa08XG.pgp Description: PGP signature
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Fri, Nov 03, 2006 at 11:54:39AM +0100, Frans Pop wrote: On Friday 03 November 2006 11:33, Sven Luther wrote: Ah, i thought there was some automatic tool, or whatever, so much for me, next time i will make sure to CC debian-boot or something, that Please discuss it on the list _before_ you file a bug report. said i was kill-filled by most of you guys, so i was not sure how useful it is. Now, apparently you are not kill-filling me anymore :) I have _never_ kill-filed you for listmail. BTW, i still don't understand the problem with non-di-image low priority additional .udebs. Read again my answer to Otavio. It is in there. The udeb section was created specifically for Debian Installer. IMO that means that the d-i team has veto rights over anything that goes in there. Ok, fine and all. But that gives absolutely no hint on why you would veto it, which is what i am asking. It is not easy to discuss things, if you get non-reply, and that is the way it is and accept it kind of replies, nor if you need to make 2-3 exchanges of emails in order to even get the question to get noticed. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: On Fri, Nov 03, 2006 at 03:03:49AM +0100, Frans Pop wrote: On Thursday 02 November 2006 22:38, Otavio Salvador wrote: There's no need to _ask_ you before to open a bug report. We're a comunity and as one we all want the best for the project. I did not say that _I_ needed to be asked, I said it needed to be discussed on the debian-boot list first, especially when they are general purpose architecture all/any udebs as in this case. Adding an architecture specific udeb is much less problematic. Frans, ... I really would like to understand what is the rationale behind this. Adding a .udeb into the archive, if it is not part of the image, and not loaded by d-i, can hardly have any influence on d-i. Not exactly. When we're building the cdimage we need to blacklist the useless udebs to make CD images smaller and like. So there're some consequencies with d-i, yes. We now only found out by accident that a request was made at all and that is _not_ the way adding new udebs to the archive should happen. I tagged the bug d-i, i think, which should have been enough to attract your attention. At least this is how i understood the issue. Or don't you monitor d-i tagged bugs anymore ? I disagreed that we need to coordenate the feature requesting with the d-i team but I agree that usually it should be done by the mailing list. I personally avoid to open bugs when I can contact the team directly and leave the bug reporting resource for people that doesn't know the team. But I don't see anything wrong about opening a bug for check if there's something that might be useful to have in. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Fri, Nov 03, 2006 at 03:34:53PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: On Fri, Nov 03, 2006 at 03:03:49AM +0100, Frans Pop wrote: On Thursday 02 November 2006 22:38, Otavio Salvador wrote: There's no need to _ask_ you before to open a bug report. We're a comunity and as one we all want the best for the project. I did not say that _I_ needed to be asked, I said it needed to be discussed on the debian-boot list first, especially when they are general purpose architecture all/any udebs as in this case. Adding an architecture specific udeb is much less problematic. Frans, ... I really would like to understand what is the rationale behind this. Adding a .udeb into the archive, if it is not part of the image, and not loaded by d-i, can hardly have any influence on d-i. Not exactly. When we're building the cdimage we need to blacklist the useless udebs to make CD images smaller and like. So there're some consequencies with d-i, yes. This is a debian-cd issue though, and not a d-i one. And well, adding more .udebs to the blacklist seems trivial enough. Especialy for a single .udeb like in this case, but it is good to know. We now only found out by accident that a request was made at all and that is _not_ the way adding new udebs to the archive should happen. I tagged the bug d-i, i think, which should have been enough to attract your attention. At least this is how i understood the issue. Or don't you monitor d-i tagged bugs anymore ? I disagreed that we need to coordenate the feature requesting with the d-i team but I agree that usually it should be done by the mailing list. I personally avoid to open bugs when I can contact the team directly and leave the bug reporting resource for people that doesn't know the team. Well, since communincation between me and the d-i team have not been so great lately, and i really thought that the d-i tags would be enough, i thought this the best way. But I don't see anything wrong about opening a bug for check if there's something that might be useful to have in. I can understand frans's point on this though, he fears that people will believe i represent the d-i team in this, and add the .udeb on my request. A bit like Andreas Jochens asking for the ppc64 ports, while his stuff is not even in debian and he has no relationship or even tried to work together, with the rest of the powerpc porter team. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: I really would like to understand what is the rationale behind this. Adding a .udeb into the archive, if it is not part of the image, and not loaded by d-i, can hardly have any influence on d-i. Not exactly. When we're building the cdimage we need to blacklist the useless udebs to make CD images smaller and like. So there're some consequencies with d-i, yes. This is a debian-cd issue though, and not a d-i one. And well, adding more .udebs to the blacklist seems trivial enough. Especialy for a single .udeb like in this case, but it is good to know. Well, it's trivial but the team need to be aware of those modifications otherwise it can take a while to discover useless udebs that are being include on the image. Currently there's no automatic CD testing tool to try to figure those mistakes out as fast as we would like to. I personally avoid to open bugs when I can contact the team directly and leave the bug reporting resource for people that doesn't know the team. Well, since communincation between me and the d-i team have not been so great lately, and i really thought that the d-i tags would be enough, i thought this the best way. That's the main reason why I replied the Frans message. I understood why you reported the bug and on this case I think you did right. But I don't see anything wrong about opening a bug for check if there's something that might be useful to have in. I can understand frans's point on this though, he fears that people will believe i represent the d-i team in this, and add the .udeb on my request. A bit like Andreas Jochens asking for the ppc64 ports, while his stuff is not even in debian and he has no relationship or even tried to work together, with the rest of the powerpc porter team. I understand both sides (your and Frans') and I also agree with him in some part. Besides, I agree with Joey Hess point that there's no need to add this udeb since we can add external binaries trivially on the built image. See you! :-D -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Fri, Nov 03, 2006 at 07:04:03PM -0300, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: I really would like to understand what is the rationale behind this. Adding a .udeb into the archive, if it is not part of the image, and not loaded by d-i, can hardly have any influence on d-i. Not exactly. When we're building the cdimage we need to blacklist the useless udebs to make CD images smaller and like. So there're some consequencies with d-i, yes. This is a debian-cd issue though, and not a d-i one. And well, adding more .udebs to the blacklist seems trivial enough. Especialy for a single .udeb like in this case, but it is good to know. Well, it's trivial but the team need to be aware of those modifications otherwise it can take a while to discover useless udebs that are being include on the image. Currently there's no automatic CD testing tool to try to figure those mistakes out as fast as we would like to. Bah, i can commit to debian-cd, and now that i know about this fact, if ever a .udeb i asked is out there, i will naturally add it to the blacklist. I personally avoid to open bugs when I can contact the team directly and leave the bug reporting resource for people that doesn't know the team. Well, since communincation between me and the d-i team have not been so great lately, and i really thought that the d-i tags would be enough, i thought this the best way. That's the main reason why I replied the Frans message. I understood why you reported the bug and on this case I think you did right. But I don't see anything wrong about opening a bug for check if there's something that might be useful to have in. I can understand frans's point on this though, he fears that people will believe i represent the d-i team in this, and add the .udeb on my request. A bit like Andreas Jochens asking for the ppc64 ports, while his stuff is not even in debian and he has no relationship or even tried to work together, with the rest of the powerpc porter team. I understand both sides (your and Frans') and I also agree with him in some part. Besides, I agree with Joey Hess point that there's no need to add this udeb since we can add external binaries trivially on the built image. Yeah, but adding them to the image is not always the best solution, loading afterward may be a better way. Also, there may be another future for .udebs out there than just for d-i use, altough i know the d-i folk doesn't like this :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Friday 03 November 2006 23:51, Sven Luther wrote: Bah, i can commit to debian-cd, and now that i know about this fact, if ever a .udeb i asked is out there, i will naturally add it to the blacklist. No, sorry that was not the intention. Having everybody committing uncoordinated changes to debian-cd is also not the answer. Why do you think there is someone like a release manager for d-i? It is because interactions are complex and changes often need coordinating and correct timing. I'm perfectly happy to make the changes. I just need to know that there are things that need changes. And the way I know that is by people discussing and announcing things on the list. Also, there may be another future for .udebs out there than just for d-i use, altough i know the d-i folk doesn't like this :) For now, and until it is decided differently by the d-i team and ftp-masters, the debian-installer section is for exclusive use by debian-installer and the d-i team has complete control and veto power over what goes in there. I've seen the smiley, but I don't think that is appropriate. Please don't joke about such matters, just accept the facts and act in accordance with them. If there is a serious other use for udebs, we need to discuss that and discuss how to implement it in the archive first. I've seen some suggestions, but so far no serious plans. Basic message: we do _not_ want rogue udebs out there. My earlier request stands: do not request new udebs without discussing them on the list first; not for d-i and not for any other usage. I think we've discussed this three or four times now. Why is it so difficult to simply accept such facts? pgpfWVCa14FL2.pgp Description: PGP signature
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Sven Luther [EMAIL PROTECTED] writes: Well, it's trivial but the team need to be aware of those modifications otherwise it can take a while to discover useless udebs that are being include on the image. Currently there's no automatic CD testing tool to try to figure those mistakes out as fast as we would like to. Bah, i can commit to debian-cd, and now that i know about this fact, if ever a .udeb i asked is out there, i will naturally add it to the blacklist. It need to be coordenated since there's a lot of people doing daily/week and final builds for d-i and then those people need to be I understand both sides (your and Frans') and I also agree with him in some part. Besides, I agree with Joey Hess point that there's no need to add this udeb since we can add external binaries trivially on the built image. Yeah, but adding them to the image is not always the best solution, loading afterward may be a better way. Also, there may be another future for .udebs out there than just for d-i use, altough i know the d-i folk doesn't like this :) You mean for embeed systems? Yes. I agree with you. But for we start to allow more widly use of udebs there're some issues that need to be in better shape like: - debian-cd - bridney - d-i itself otherwise can be a lot harder to make a d-i release to happen. Another alternative can be use something like edeb for embeed devices. That would be a clear option then use udeb for both. Using another group of packages would make both worlds happy and make both team lives easier. One wouldn't affect the other with their respective decisions. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Saturday 04 November 2006 01:24, Otavio Salvador wrote: Another alternative can be use something like edeb for embeed devices. That would be a clear option then use udeb for both. Using another group of packages would make both worlds happy and make both team lives easier. One wouldn't affect the other with their respective decisions. It would still require coordination for migrations to testing and releases, especially for source packages that would produce both a udeb and an edeb... pgpQzq8N1AV9R.pgp Description: PGP signature
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Frans Pop [EMAIL PROTECTED] writes: On Saturday 04 November 2006 01:24, Otavio Salvador wrote: Another alternative can be use something like edeb for embeed devices. That would be a clear option then use udeb for both. Using another group of packages would make both worlds happy and make both team lives easier. One wouldn't affect the other with their respective decisions. It would still require coordination for migrations to testing and releases, especially for source packages that would produce both a udeb and an edeb... Yes... and coordination for each group of packages. That would be nice to see working :-D -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Sat, Nov 04, 2006 at 12:39:50AM +0100, Frans Pop wrote: On Friday 03 November 2006 23:51, Sven Luther wrote: Bah, i can commit to debian-cd, and now that i know about this fact, if ever a .udeb i asked is out there, i will naturally add it to the blacklist. No, sorry that was not the intention. Having everybody committing uncoordinated changes to debian-cd is also not the answer. Frans, If a .udeb is added to the archive, and immediately blacklisted, which makes sense for a debug-only udeb like strace or gdb, then the net effect on the debian-cd images is null, and nothing, absolutely nothing will be impacted by it, except the slight increase in the packages file. So ... Why do you think there is someone like a release manager for d-i? It is because interactions are complex and changes often need coordinating and correct timing. ... there is not really any need for coordination and stuff like that. Coordination is needed if you guys decide to add the .udeb in question to the image or CDs. I'm perfectly happy to make the changes. I just need to know that there are things that need changes. And the way I know that is by people discussing and announcing things on the list. As said, i thought that the d-i tag would do this. Maybe we could ask the bug-masters (or whatever they are named) to have some script automatically sending d-i tagged bugs to debian-boot ? Also, there may be another future for .udebs out there than just for d-i use, altough i know the d-i folk doesn't like this :) For now, and until it is decided differently by the d-i team and ftp-masters, the debian-installer section is for exclusive use by debian-installer and the d-i team has complete control and veto power over what goes in there. Yeah, the issue is that you are not particularly receptive to discussion about it, but then this may just have been the old dispute. On the other hand, trying to discuss things like this is what got me in this mess in the first place. Let's have this discussion at a later time, after the etch release preferably. I've seen the smiley, but I don't think that is appropriate. Please don't joke about such matters, just accept the facts and act in accordance with them. You know, you are not fun at all, you should losen up a bit, and accept that if you have such rigid stances on stuff, then you deserve to be gently poked about it. If there is a serious other use for udebs, we need to discuss that and discuss how to implement it in the archive first. I've seen some suggestions, but so far no serious plans. Let's have this discussion post-etch, ok ? Basic message: we do _not_ want rogue udebs out there. My earlier request stands: do not request new udebs without discussing them on the list first; not for d-i and not for any other usage. Please be a bit more open though. This kind of stuff, diabolizing new proposals like you are doing, is absolutely not helpful. I think we've discussed this three or four times now. Why is it so difficult to simply accept such facts? Because it is no reasoned fact, but simply you trying to get people to think like you based on your authority ? Face it, you cannot stiffle people thinking, or discussing issues, or trying to push for what they think best. If nothing else, this is called free speach, and if you really don't get that, maybe you are in the wrong line of business. Please don't take offense of this, i will not go further into this, but i think this one is a major issue which led us into the mess we are in, so it is right it goes up in the open. I know i had my part in this too, because i didn't know how to best discuss this, and was insistent while other ways may have server better, but be aware that responses such as those are those who make me have fits. Remember, Free Software, Free as in Free speach. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Fri, Nov 03, 2006 at 09:24:28PM -0300, Otavio Salvador wrote: Yeah, but adding them to the image is not always the best solution, loading afterward may be a better way. Also, there may be another future for .udebs out there than just for d-i use, altough i know the d-i folk doesn't like this :) You mean for embeed systems? Yes. I agree with you. Embedded systems, and stuff like the ghost-like image which Xavier should have been working on, based on gparted and partimage, which got lost because he ended up having to rewrite gparted in C. But for we start to allow more widly use of udebs there're some issues that need to be in better shape like: - debian-cd - bridney - d-i itself otherwise can be a lot harder to make a d-i release to happen. Another alternative can be use something like edeb for embeed devices. That would be a clear option then use udeb for both. Using another group of packages would make both worlds happy and make both team lives easier. One wouldn't affect the other with their respective decisions. My belief is that, once post etch we have support for multiple udeb sources, we should split the archive thus : - the libraries and support package (like parted) in a generic archive. - the debian-installer packages in a debian-installer archive. - the kernel modules in a separate archive, of which there would be one by kernel version (upstream+abi), so as to keep d-i images alive even when new kernel versions are pushed in the archive. Further separation into flavours may help low memory systems on arches with a lot of flavours. Then alternative projects can add to the geenric package they need, and implement their own archive for their own project, without influencing d-i, and everyone is happy. Hard-core embedded guys will want to use their own stuff, but semi-embedded folk with less need for fine-tuned builds will be able to take huge profit from this. But let's discuss this post etch. I am thinking of doing a fosdem presentation of my ideas, preferably with proof of concept, which should satisfy all the need for discussion and implementation details, and this happening at the start of the etch+1 devel cycle will make sure we can think about it without being in a rush. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Eddy Petrișor wrote: No, is not luck, just that all udebs which could be used are added to the pool of binaries which need symbols, AFAICT: No, the code you qouted is specific to building floppy disk images. As I said before, once d-i has access to the installation media, it loads the full libc from it. -- see shy jo signature.asc Description: Digital signature
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Thu, Nov 02, 2006 at 01:54:25PM -0500, Joey Hess wrote: Eddy Petrișor wrote: No, is not luck, just that all udebs which could be used are added to the pool of binaries which need symbols, AFAICT: No, the code you qouted is specific to building floppy disk images. As I said before, once d-i has access to the installation media, it loads the full libc from it. What about other non-libc library packages ? Or are they not usually included in libc ? In particular what about the gtk+dfb packages, and eventual ad-on packages, like the graphical installer Xavier was working on. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Frans Pop [EMAIL PROTECTED] writes: Hello Daniel, I am glad you took this to the debian-boot mailing list as Sven Luther, who currently is not even a member of the Debian Installer team, filed this request without discussing it on the debian-boot list first. As such, this is an unauthorized request. Frans, please... There's no need to _ask_ you before to open a bug report. We're a comunity and as one we all want the best for the project. I agree with Joey POV and don't see a specific need for an extra udeb. Besides, it would demand extra work about migrations and like. But again, it's not a reason to avoid someone to open a bug report or a feature request. No body need _autorization_ to request something. If you'll follow or not this request, it's a different thing... -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Thursday 02 November 2006 22:38, Otavio Salvador wrote: There's no need to _ask_ you before to open a bug report. We're a comunity and as one we all want the best for the project. I did not say that _I_ needed to be asked, I said it needed to be discussed on the debian-boot list first, especially when they are general purpose architecture all/any udebs as in this case. Adding an architecture specific udeb is much less problematic. We now only found out by accident that a request was made at all and that is _not_ the way adding new udebs to the archive should happen. However, it is a fact that adding a udeb to the archive _always_ has consequences that the release manager will at some point have to deal with, even if it is only managing migrations to testing or excluding unneeded udebs from being included on CD images. Also, if udebs are uploaded with the wrong priority, they could affect default installations. If such things are not discussed on the list, we (_the team_) may not know anything about them until it is already in the archive. That is just not the way to do things when you (want to) work as part of a team. Also, if this had been discussed on the list first, we, as a team, could have decided that there were already other ways available to have gdb available within d-i and that there was no need for the udeb, which would have saved troubling the maintainer of gdb with the bug report. Cheers, FJP P.S. Please, next time do not change without discussing it on the debian-boot list to without asking Frans Pop for permission so easily. I'm getting rather tired of people attributing things to me that I've never said. I could understand if you had objections to the who currently is not even a member of the Debian Installer team phrase, but there was nothing wrong with the rest of the para you quoted. pgp0gbEPGQGek.pgp Description: PGP signature
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Fri, Nov 03, 2006 at 03:03:49AM +0100, Frans Pop wrote: On Thursday 02 November 2006 22:38, Otavio Salvador wrote: There's no need to _ask_ you before to open a bug report. We're a comunity and as one we all want the best for the project. I did not say that _I_ needed to be asked, I said it needed to be discussed on the debian-boot list first, especially when they are general purpose architecture all/any udebs as in this case. Adding an architecture specific udeb is much less problematic. Frans, ... I really would like to understand what is the rationale behind this. Adding a .udeb into the archive, if it is not part of the image, and not loaded by d-i, can hardly have any influence on d-i. As far as i understand the only ones who will affect d-i are those in the image, as well as those who are who are of a certain priority. What would be the problem in having more .udebs in the archive ? a slight increase of the Packages file, but i can't see any other harm. We now only found out by accident that a request was made at all and that is _not_ the way adding new udebs to the archive should happen. I tagged the bug d-i, i think, which should have been enough to attract your attention. At least this is how i understood the issue. Or don't you monitor d-i tagged bugs anymore ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Tue, Oct 31, 2006 at 09:36:54AM -0500, Daniel Jacobowitz wrote: On Tue, Oct 31, 2006 at 03:30:23PM +0100, Sven Luther wrote: So, i am not entirely sure how d-i handles the case at hand here, where libraries are part of the actual image, but symbols are removed during reduction, because they are not needed by the .udebs in the image, but they are needed by .udebs loaded later on. My impression is that d-i loads the full libraries later on, or something such. If they did that, you could just wget a full GDB binary. It doesn't Mmm. need anything else in the package besides the executable. But I don't think d-i does what you describe (since I tried to use this approach for strace recently, and there were missing symbols in libc.so.6). I really don't see how reduction could work if it has to take into account all .udebs which can possibly or not be loaded into d-i. I also have not noticed the d-i build process loading not-in-the-ramdisk .udebs, but i have missed them. Also, i don't see how such a process could survive for example a package which was added after the build of the image, or modified or whatever. What did you do with strace ? Create a .udeb out of it and include this one ? or just load in the binary ? Or did you include the strace.udeb into the ramdisk image ? If someone more familiar with d-i than I am can confirm that the udeb will be useful, I can try to get GDB to build one, but it seems like a very strange package to have a udeb. Well, gdb and strace would be two great packages to have as .udeb. Also, .udebs can be useful even outside of d-i, at least those not having any menu item thingy, like libraries, and utility packages (like ssh or parted or whatever for example). Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Tue, Oct 31, 2006 at 03:30:23PM +0100, Sven Luther wrote: So, i am not entirely sure how d-i handles the case at hand here, where libraries are part of the actual image, but symbols are removed during reduction, because they are not needed by the .udebs in the image, but they are needed by .udebs loaded later on. My impression is that d-i loads the full libraries later on, or something such. If they did that, you could just wget a full GDB binary. It doesn't need anything else in the package besides the executable. But I don't think d-i does what you describe (since I tried to use this approach for strace recently, and there were missing symbols in libc.so.6). If someone more familiar with d-i than I am can confirm that the udeb will be useful, I can try to get GDB to build one, but it seems like a very strange package to have a udeb. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Tue, Oct 31, 2006 at 01:06:12PM +0100, Sven Luther wrote: A version of gdb as .udeb, which could easily be loaded inside the d-i would be very useful for developers. This would come in handy to debug various bugs which are otherwise hard to track, like crashes in the graphical installer, or problems like i am having right now, in parted/libparted, which only are apparent inside the d-i environment. Is this really a good idea? It seems like the wrong way round; you could manually load a full GDB and associated libraries, if you need it for debugging, but having it as part of a d-i image would e.g. change the required bits of libraries. Hoping for feedback. -- Daniel Jacobowitz CodeSourcery -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Tue, Oct 31, 2006 at 05:09:46PM +0200, Eddy Petrișor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: My impression is that d-i loads the full libraries later on, or something such. AFAIK, this never happens. The reduction is done mainly for the thing not to be too big in the memory while running. Hi Eddy, I wonder how the current situation works for .udebs not in the image ? How do you find out whose symbols are used by them and know not to strip them ? Is this just luck ? I sincerely doubt that. No, is not luck, just that all udebs which could be used are added to the pool of binaries which need symbols, AFAICT: from build/Makefile : - 8-- ifdef EXTRADRIVERS # Unpack the udebs of additional driver disks, so mklibs runs on them too. dpkg $(DPKG_UNPACK_OPTIONS) --log=/dev/null --root=$(EXTRAUDEBSDIR) - --unpack \ $(wildcard $(foreach dir,$(EXTRADRIVERS),$(dir)/*.udeb)) endif ifdef EXTRAUDEBS # Get and unpack extra udebs too. get-packages udeb $(EXTRAUDEBS) dpkg $(DPKG_UNPACK_OPTIONS) --log=/dev/null --root=$(EXTRAUDEBSDIR) - --unpack \ $(foreach udeb,$(EXTRAUDEBS),$(UDEBDIR)/$(udeb).udeb) endif - 8-- If you'd want a udeb for gdb, then the library reduction should take into account its dependencies (symbols). This would mean: - - either you make a custom image which uses mklibs-copy (no reduction) and you can use a regular binary or a gdb udeb which contains just the gdb binary (dynamically linked) - - build a custom image with gdb's needed symbols not stripped - but this means that gdb could not be used for regulaly built images. We need a custom image anyway, since we need a -debug version of the binaries we want to debug. Indeed - -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFR3EaY8Chqv3NRNoRAgObAKCwmdyQ3e8UFZL5tp3IScBRND07PQCfZQCc r2NSmb15+Bte4FU8COUOIiA= =Y5+O -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Tue, Oct 31, 2006 at 05:09:46PM +0200, Eddy Petrișor wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: My impression is that d-i loads the full libraries later on, or something such. AFAIK, this never happens. The reduction is done mainly for the thing not to be too big in the memory while running. Hi Eddy, I wonder how the current situation works for .udebs not in the image ? How do you find out whose symbols are used by them and know not to strip them ? Is this just luck ? I sincerely doubt that. In any case if you have a better idea on how to do this, maybe having a statically built gdb, it would be welcome too. A statically built gdb is he way to go, IMHO. If you'd want a udeb for gdb, then the library reduction should take into account its dependencies (symbols). This would mean: - - either you make a custom image which uses mklibs-copy (no reduction) and you can use a regular binary or a gdb udeb which contains just the gdb binary (dynamically linked) - - build a custom image with gdb's needed symbols not stripped - but this means that gdb could not be used for regulaly built images. We need a custom image anyway, since we need a -debug version of the binaries we want to debug. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sven Luther wrote: On Tue, Oct 31, 2006 at 09:05:26AM -0500, Daniel Jacobowitz wrote: On Tue, Oct 31, 2006 at 01:06:12PM +0100, Sven Luther wrote: A version of gdb as .udeb, which could easily be loaded inside the d-i would be very useful for developers. This would come in handy to debug various bugs which are otherwise hard to track, like crashes in the graphical installer, or problems like i am having right now, in parted/libparted, which only are apparent inside the d-i environment. Is this really a good idea? It seems like the wrong way round; you could manually load a full GDB and associated libraries, if you need it for debugging, but having it as part of a d-i image would e.g. change the required bits of libraries. Mmm, you mean the mklibs'ed library in the standard image, i hadn't thought of that. My idea was not to include it by default, but to be able to load it in the ramdisk, if needed, so as a .udeb in the archive, but *NOT* as part of the d-i image. So, i am not entirely sure how d-i handles the case at hand here, where libraries are part of the actual image, but symbols are removed during reduction, because they are not needed by the .udebs in the image, but they are needed by .udebs loaded later on. My impression is that d-i loads the full libraries later on, or something such. AFAIK, this never happens. The reduction is done mainly for the thing not to be too big in the memory while running. In any case if you have a better idea on how to do this, maybe having a statically built gdb, it would be welcome too. A statically built gdb is he way to go, IMHO. If you'd want a udeb for gdb, then the library reduction should take into account its dependencies (symbols). This would mean: - - either you make a custom image which uses mklibs-copy (no reduction) and you can use a regular binary or a gdb udeb which contains just the gdb binary (dynamically linked) - - build a custom image with gdb's needed symbols not stripped - but this means that gdb could not be used for regulaly built images. - -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFR2c5Y8Chqv3NRNoRAhv0AJ9lmihF3fyS3OHr38zd4Hw7qeyPZwCg1l2q EaEljSty/gxAEMg7QTz7xFw= =Lowy -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
On Tue, Oct 31, 2006 at 09:05:26AM -0500, Daniel Jacobowitz wrote: On Tue, Oct 31, 2006 at 01:06:12PM +0100, Sven Luther wrote: A version of gdb as .udeb, which could easily be loaded inside the d-i would be very useful for developers. This would come in handy to debug various bugs which are otherwise hard to track, like crashes in the graphical installer, or problems like i am having right now, in parted/libparted, which only are apparent inside the d-i environment. Is this really a good idea? It seems like the wrong way round; you could manually load a full GDB and associated libraries, if you need it for debugging, but having it as part of a d-i image would e.g. change the required bits of libraries. Mmm, you mean the mklibs'ed library in the standard image, i hadn't thought of that. My idea was not to include it by default, but to be able to load it in the ramdisk, if needed, so as a .udeb in the archive, but *NOT* as part of the d-i image. So, i am not entirely sure how d-i handles the case at hand here, where libraries are part of the actual image, but symbols are removed during reduction, because they are not needed by the .udebs in the image, but they are needed by .udebs loaded later on. My impression is that d-i loads the full libraries later on, or something such. In any case if you have a better idea on how to do this, maybe having a statically built gdb, it would be welcome too. Hoping for feedback. Hope this helps. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Jacobowitz wrote: On Tue, Oct 31, 2006 at 03:30:23PM +0100, Sven Luther wrote: So, i am not entirely sure how d-i handles the case at hand here, where libraries are part of the actual image, but symbols are removed during reduction, because they are not needed by the .udebs in the image, but they are needed by .udebs loaded later on. My impression is that d-i loads the full libraries later on, or something such. If they did that, you could just wget a full GDB binary. It doesn't Note that networking might not be enabled at the point gdb is needed. placing the udeb/gdb statically linked binary on the CD might be helpful. If someone more familiar with d-i than I am can confirm that the udeb will be useful, I can try to get GDB to build one, but it seems like a very strange package to have a udeb. Probably a udeb with a statically linked binary would be a package that might be somewhat useful. - -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFR2geY8Chqv3NRNoRAuPUAKDVSUQMISFCrro1pCGMIrjTIsYV3wCglUZ6 HRC7vZiu1qkHDz60qBSsUTs= =7EjR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Daniel Jacobowitz wrote: If they did that, you could just wget a full GDB binary. It doesn't need anything else in the package besides the executable. But I don't think d-i does what you describe (since I tried to use this approach for strace recently, and there were missing symbols in libc.so.6). d-i reduces libc for the boot image, but then loads a full one from install media/network. So if you want to debug something before the full libc is available, you're SOL. However, d-i also already offers a way to include a strace, gdb, or whatever you want onto the boot image, without a udeb, and including any dependant symbols and other libraries: # This variable can be used to copy in additional files from the system # that is doing the build. Useful if you need to include strace, or gdb, # etc. #EXTRAFILES = /usr/bin/strace If someone more familiar with d-i than I am can confirm that the udeb will be useful, I can try to get GDB to build one, but it seems like a very strange package to have a udeb. I don't see any benefit to having a udeb, beyond being able to load the udeb in anna. -- see shy jo signature.asc Description: Digital signature
Re: Bug#396365: please add a gdb .udeb, for easier debugging inside d-i
Hello Daniel, I am glad you took this to the debian-boot mailing list as Sven Luther, who currently is not even a member of the Debian Installer team, filed this request without discussing it on the debian-boot list first. As such, this is an unauthorized request. On Tuesday 31 October 2006 20:44, Joey Hess wrote: Daniel Jacobowitz wrote: If they did that, you could just wget a full GDB binary. It doesn't need anything else in the package besides the executable. But I don't think d-i does what you describe (since I tried to use this approach for strace recently, and there were missing symbols in libc.so.6). I don't see any benefit to having a udeb, beyond being able to load the udeb in anna. Please take this conclusion from Joey Hess as the final statement on this request. It would have limited benefits, but not enough to warrant the creation and the maintenance of the udeb. Feel free to either close this BR or mark it wontfix. Cheers, Frans Pop Debian Installer Release Manager pgpPliMFlu0bS.pgp Description: PGP signature
