Re: communication, friendlyness, DDs (Re: Ubuntu-to-Debian packaging)
Hi, On Sun, Dec 02, 2007 at 09:08:54PM +0100, Holger Levsen wrote: On Sunday 02 December 2007 13:19, Patrick Schoenfeld wrote: Really, it may have sounded more rude to you, then it was meant to be. But I was really annoyed by such a statement, That rather implies you were unfriendly, at least I'm often (too) unfriendly, yes, I agree. when I'm really annoyed. Also, in communication it is totally irrelevant how you (the sending end) ment something. What matters in communication is how the receiving end perceives it and what the sending end ment, is almost totaly irrelevant. Well, but its not really possible for the sending end to know before, how the receiving end will perceive something. Besides that I'm feeling hard to express some things properly, because english is just not my native language. Its hard to try to respect feelings of receival ends then. Then let me tell you with my oh-my-god-DD!-status, that most DDs expect You get me wrong. I don't say, nor did I mean that DDs are gods. The problem is just the place were it happens (because of the audience) and the simple fact that the argued thing is easy to look up. friendlyness when interacting with fellow developers (being them DDs or not) :-) Sure, most of us can life with a flame here or a heated argument there, but at least I do expect to be treated friendly. Anytime, everywhere. Well, its not always that easy. What you feel as beeing unfriendly is felt unfriendly by the receiving end. In fact my first thinking when I read the mail about my unfriendlyness was: What?! I don't really understand why my mail has been unfriendly at all. Because I just complained about something that I felt totally wrong. I did not call Jose a moron or anything else insulting. And, DDs don't know everything and don't have to know everything as well. José I agree with this. But the problem is not to know everything, but the simple fact that informations can be looked up. If you argue with someone about elementar questions on how things should be done, its better to be informed. IMHO Debian Developers don't need to know everything, but they should know where to get the information from. In this case Jose knew the information source very well, but instead of looking into it and _then_ answering he indicated that he was to lazy or whatsoever to look into the policy and instead say that he does not know. I should have said that I feel this beeing bad, then it my have sounded different on the receiving end. But i cannot change things I already did. shared his experiences with you and the list and when he was in NM he was told by a DD (! :) that he should remove the old changelog and that he is not sure if there is a policy for this. And he made it through NM with this advice and all his NM communication was read by his AM, FD and DAM. Can't be that wrong. I don't see how this argumentation works. Sorry. He also indicated he might be wrong (as things might have changed) and that his knowledge is limited (doh! just like anybody elses on this planet) - Thats not true. In his first mail (the one that I first critizized) he just stated how it should be. Quiet confident. Sureley anyone who does not (yet) know better would see: Ah, the advise from a DD, additional their is no policy for it and oh not even a documented best practice in the DevRef, so I'll follow his advise. You see what I think is bad? In his second mail he did. But this mail would have never happend if I had not complained to him. what's wrong with that? It's rather good for two reasons: people know that they should not take his advice (in this matter) for granted and people can Thats right, but the acting in this case is IMHO wrong anyways. Because the information is so easy to lookup and proof. So why should someone who really does know that something like the Debian policy exists and where to find it (I assume that he does, because he is a DD) make statements about contents of the policy without looking it up? correct him and inform the list and point out the policy about keeping changelogs or not. I don't like this way of doing things. You can stretch this in any direction. Example: Not in a mentor-mentoree relationship, but in packaging: Why lookup sth. in the policy at all? Someone will make a bugreport and point out to the policy. Right? There are good arguments [..] but there are also good for removing Maybe. But the questioning of the topic starter surely wanted to ask for a rule of thumb. Jose gave one, which is _at least_ questionable. it. For example if you dont plan to merge back and forth in future (IME I We are talking about Ubuntu-to-Debian. So this is not of concern, right? And, yes, the packaging is copyrightable and has a licence. A licence which is a free software licence, which allows modification... You are right. I confused something. Best Regards, Patrick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED]
Re: rpath issue on 64 bit architectures
Hi, Il giorno lun, 03/12/2007 alle 04.38 +0100, Leo costela Antunes ha scritto: Francesco Namuri wrote: I would like to know, what in your opinion is the best solution. And then, I am mistaken thinking that the problem is related to the fact that lib64/ is a symlink to lib/ ? I'm I don't think this is exactly the problem. RPATH is meant to help/supplant the linker on runtime, to make sure it finds the correct library which carries the symbols needed by the executable. There should be no need for it in a system where the linker is correctly configured and all installed libraries are in predictable places, such as Debian, but in a system where libraries could possibly be installed in different places, this becomes useful. I'm thinking this because after the call of ./configure the generated libtool file contains all the lib variables set to corresponding lib64 directory eg (after a call of ./configure): libtool: [...] # Compile-time system search path for libraries sys_lib_search_path_spec=/usr/lib64 /lib64 /usr/local/lib64 # Run-time system search path for libraries sys_lib_dlsearch_path_spec=/usr/lib64 /lib64 /usr/local/lib /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu [...] # Compile-time system search path for libraries sys_lib_search_path_spec=/usr/lib64 /lib64 /usr/local/lib64 # Run-time system search path for libraries sys_lib_dlsearch_path_spec=/usr/lib64 /lib64 /usr/local/lib /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu with this libtool, calling make I see that rpath are set, but if I patch the libtool changing all lib64 to lib eg: libtool: [...] # Compile-time system search path for libraries sys_lib_search_path_spec=/usr/lib /lib /usr/local/lib # Run-time system search path for libraries sys_lib_dlsearch_path_spec=/usr/lib /lib /usr/local/lib /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu [...] # Compile-time system search path for libraries sys_lib_search_path_spec=/usr/lib /lib /usr/local/lib # Run-time system search path for libraries sys_lib_dlsearch_path_spec=/usr/lib /lib /usr/local/lib /lib/x86_64-linux-gnu /usr/lib/x86_64-linux-gnu the rpath is not used... So I thought that are the problem is related to the symlink... I've also tried with the package that is trying to package Jan (gwyddion), same thing... With that in mind, what I interpret from the given reason is that libtool could be trying to deal with a possibly mixed 32/64 installation, where it wouldn't trust the linker to find the correct library. This isn't needed for Debian. At any rate, this is just speculation. What you could suggest upstream is that - if he really believes rpath to still be useful and doesn't want to completely abandon it as other gnome projects have done - he could implement something like the widely used AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option available at configure time. This in turn could be added to debian/rules and the chrpath hack could be removed. Hope it helps. Thanks very much, all help it's welcome when trying to learn something... :) Also, something I hadn't seen while sponsoring the package: it seems that you accidentally copied the rules file to a file named '\' on the base source code dir. Ops, :) it's strange, I don't know what happens... I'll fix this on next upload... Cheers, francesco -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A [EMAIL PROTECTED] signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Re: rpath issue on 64 bit architectures
Hi, Il giorno lun, 03/12/2007 alle 01.00 -0300, Felipe Sateler ha scritto: Leo costela Antunes wrote: could implement something like the widely used AC_RELOCATABLE macro to his scripts, to make a '--disable-rpath' option available at configure time. Is this really needed? Most configure scripts I've dealt with support the --disable-rpath option, even when they don't advertise it in ./configure --help. I don't see any such macro in the sources here in my computer. I've checked, in g-p-m configure script there isn't any documented non-documented --disable-rpath option... Cheers, francesco -- Francesco Namuri francesco(at)namuri(dot)it http://namuri.it/ id gpg key: 21A4702A [EMAIL PROTECTED] signature.asc Description: Questa è una parte del messaggio firmata digitalmente
policy for file headers
Dear Mentors; Can someone point me to policy about file headers? I am currently looking at a package with a GPL copyright file in the top directory, and a terse statment copyright X, released under the GPL in most, but not all files. I think the files without copyright are non-essential, and could in principle be removed. There seems to be nothing reasonable to do as a packager about the lack of the usual gpl boilerplate. I understand that the best practice is to have a copyright statement and a clear statement of license in every file of the source code. What I don't know is if 1) This is a MUST dictated by policy as well as a SHOULD from best-practice? 2) Supposing it is a SHOULD, is the collective wisdom of the mentors that if I want to get the package sponsored, I should get it fixed anyway? We could call this MENTORS-MUST :-). Yours ignorantly, David pgpp3JCQkPEWp.pgp Description: PGP signature
Re: communication, friendlyness, DDs (Re: Ubuntu-to-Debian packaging)
On Sun, Dec 02, 2007 at 09:08:54PM +0100, Holger Levsen wrote: Hi, On Sunday 02 December 2007 13:19, Patrick Schoenfeld wrote: Thats bad. You should not answer to such questions if you don't know it for your self! Thats especially true because of your DD status that causes others to give your saying more confidence. Please, try to keep friendly, I don't think there's anything in this discussion that needs this kind of langage.. Really, it may have sounded more rude to you, then it was meant to be. But I was really annoyed by such a statement, That rather implies you were unfriendly, at least I'm often (too) unfriendly, Misusing then and than can cause confusion. If it is read as ... than it was meant to be. it takes on an entirely different meaning. :-) -- Chris. == -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ubuntu-to-Debian packaging
2007/12/2, Patrick Schoenfeld [EMAIL PROTECTED]: 1) Copyright / license issues: By removing important information from the previous packaging you might insult the packaging license. Redistribution in Debian might therefore be illegal. While I do believe that, as a general rule, it's much better to keep old changelog entries, I'm pretty sure it's not illegal at all toremove them (IANAL) as long as you keep the copyright statements. It might not be polite, but it definitely doesn't look illegal. Greetings, Miry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: policy for file headers
David Bremner [EMAIL PROTECTED] writes: Can someone point me to policy about file headers? I am currently looking at a package with a GPL copyright file in the top directory, and a terse statment copyright X, released under the GPL in most, but not all files. I think the files without copyright are non-essential, and could in principle be removed. There seems to be nothing reasonable to do as a packager about the lack of the usual gpl boilerplate. I understand that the best practice is to have a copyright statement and a clear statement of license in every file of the source code. What I don't know is if 1) This is a MUST dictated by policy as well as a SHOULD from best-practice? It's neither a must nor a should from a Debian Policy perspective. Most upstream packages do not put a copyright statement into every file. If you're upstream, it's probably a good idea, but if you're just packaging someone else's release, don't worry about it. Watch out for files with different copyright or license statements, but if there's a general copyright and license for the whole package in the package documentation, you can safely assume any unmarked files are also released under that copyright and license. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: rpath issue on 64 bit architectures
Francesco Namuri [EMAIL PROTECTED] writes: I'm thinking this because after the call of ./configure the generated libtool file contains all the lib variables set to corresponding lib64 directory eg (after a call of ./configure): Yeah, that's broken, don't do that. /usr/lib is the library path on Debian's AMD64 build. Upstream is probably being too smart for their own good somewhere and setting libdir to lib64. (Red Hat tends to force this, unfortunately.) You could try using --libdir=/usr/lib and seeing if that overrides things. So I thought that are the problem is related to the symlink... The problem is that libtool doesn't think that lib64 is on the regular library search path and hence decides that it needs to add rpath, which is broken at several different levels but best avoided by just using lib. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
