Re: Good communication with upstream is good idea
* Russ Allbery: Unfortunately, this then generates a whole pile of web pages supposedly for you that then show up in Google searches and the like despite having no information on them. I think that's one of the things that's turned DDs off on Launchpad; I know that it gave me a bad initial impression. I guess it's more of a Google QA issue, but I see what you mean. I agree that this is a strange situation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Florian Weimer [EMAIL PROTECTED] writes: * Russ Allbery: Unfortunately, this then generates a whole pile of web pages supposedly for you that then show up in Google searches and the like despite having no information on them. I think that's one of the things that's turned DDs off on Launchpad; I know that it gave me a bad initial impression. I guess it's more of a Google QA issue No, if the pages exist and other pages tend to treat them as interesting (i.e. interesting pages link to those pages), Google is working as advertised if it indexes and reports them. The problem is the treatment of this information by Launchpad, i.e. creating pages that have no prospect of being useful, yet linking to them (I presume, from the discussion here) as though they're important. -- \ “To label any subject unsuitable for comedy is to admit | `\ defeat.” —Peter Sellers | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Mon, 2008-07-28 at 23:18 +1000, Ben Finney wrote: No, if the pages exist and other pages tend to treat them as interesting (i.e. interesting pages link to those pages), Google is working as advertised if it indexes and reports them. On unactivated account pages launchpad now sets meta name=robots content=noindex,nofollow / so these pages should not show up in results from well behaved search engines. Thanks, James -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
* Ben Finney: I guess it's more of a Google QA issue No, if the pages exist and other pages tend to treat them as interesting (i.e. interesting pages link to those pages), Google is working as advertised if it indexes and reports them. Sorry, but this is just wrong. If the page is not interesting to a particular query and its sender, it's got no place in the search results. Searching isn't about spec conformance, it's about results. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
James Westby [EMAIL PROTECTED] writes: On unactivated account pages launchpad now sets meta name=robots content=noindex,nofollow / so these pages should not show up in results from well behaved search engines. Ah, excellent, thank you. -- 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: Good communication with upstream is good idea
Florian Weimer [EMAIL PROTECTED] writes: * Ben Finney: I guess it's more of a Google QA issue No, if the pages exist and other pages tend to treat them as interesting (i.e. interesting pages link to those pages), Google is working as advertised if it indexes and reports them. Sorry, but this is just wrong. If the page is not interesting to a particular query and its sender, it's got no place in the search results. Searching isn't about spec conformance, it's about results. That's why the statement above is qualified. Google's Page Rank algorithm — its heuristic for is the page interesting to a particular querent — is advertised to be largely driven by other pages (which have their own Page Rank affecting their weight) linking to the page under consideration. So, if this is indeed what occurs, Google is working as advertised. Now that (reportedly) these pages under discussion have a standard please don't spider request, perhaps this issue has become moot. -- \ “Never use a long word when there's a commensurate diminutive | `\available.” —Stan Kelly-Bootle | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
#include hallo.h * Reinhard Tartler [Wed, Jul 23 2008, 04:36:39PM]: How about activating it the first time they send a gpg-signed mail to the mail interface? My point is that I don't have the impression that Debian Developers want Fine. And mine tends to differ. to have an LP account activated at all, so IMO it doesn't really matter if the account is activated implicitly via some (authenticated) action or exlicitly by clicking on the 'claim this account' link. Of course it does. Give every DD a hidden account, i.e. not displayed anywhere on the web. For external observer this would not change the current situation but provide DDs the flexibility requested in this thread. Regards, Eduard. -- HE caro Ganneff: passt auf, ich bin blond, habe keine ahnung von computern, aber einen client kann ich einrichten, sogar alleine. *stolz guck* -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Reinhard Tartler [Wed, Jul 23 2008, 04:36:39PM]: How about activating it the first time they send a gpg-signed mail to the mail interface? My point is that I don't have the impression that Debian Developers want Fine. And mine tends to differ. I should clarify. I don't have the impression that *every* Debian Developer wants ... to have an LP account activated at all, so IMO it doesn't really matter if the account is activated implicitly via some (authenticated) action or exlicitly by clicking on the 'claim this account' link. Of course it does. Give every DD a hidden account, ... Every DD and debian contributor already has a hidden account that is created on package import. https://launchpad.net/~blade e.g. is yours, but it seems that you already have activated it and used it already in the past. As an example for an unclaimed Launchpad account, see e.g. https://launchpad.net/~joerg. ... i.e. not displayed anywhere on the web. Why should those accounts be hidden? What problem would be solved with that? For external observer this would not change the current situation but provide DDs the flexibility requested in this thread. Which would be exactly what? Close Bugs via changelog? No need for an LP account here. Or use the malone mail interface? See https://help.launchpad.net/BugTrackerEmailInterface for the documentation how to use that. Note that you need to claim your LP account first and associate your gpg key with it. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Hi, On Sun, Jul 20, 2008 at 12:30:21PM -0400, Joey Hess wrote: Osamu Aoki wrote: I think we should encourage packager to contact upstream with simple hello! message and he (or myself) should be part of active upstream ML. When I had upstreams, I always used to do this. Often though, I'd wait until I had some patches to go with the hello, to make the message have a bit more value. This is what I did and good trigger point of contacting upstreams. Developers Reference needs to add this point. Hello is OK but this is good recommendation point to act. Osamu PS: I expected some thread to follow but this one was good response for me. Thanks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 2008-07-27 at 15:36 +0200, Reinhard Tartler wrote: Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Reinhard Tartler [Wed, Jul 23 2008, 04:36:39PM]: How about activating it the first time they send a gpg-signed mail to the mail interface? How about simply allowing any DD to send gpg-signed email to add comments to any LP bug without any login? It is the login that I want to avoid. Of course it does. Give every DD a hidden account, ... Every DD and debian contributor already has a hidden account that is created on package import. https://launchpad.net/~blade e.g. is yours, but it seems that you already have activated it and used it already in the past. Why force activation in the first place? All the information needed to activate a DD account already exists - our GnuPG fingerprints, our DD email addresses and full names. If an email is received that is signed by a known key belonging to a DD, LP should just accept the blasted thing and stop looking for any other authentication or activation or login or anything else of any kind, ever. If someone can send an email to LP signed by my key then I have a lot more to worry about than whether LP is going to refuse to authenticate that email. Any email signed by a known key belonging to a DD should be accepted without question or authentication or activation or anything else. As an example for an unclaimed Launchpad account, see e.g. https://launchpad.net/~joerg. Or, presumably, ~codehelp. I don't see why that should exist at all, I'd much prefer that such a URL just got a 404. *IF* the DD wants to have some content under such a URL, it can be enabled with the current login (which in turn could simply be available as an upgrade from the hidden account already assigned automatically). Even better, do it in a similar manner to people.debian.org and give DD's SSH access. ... i.e. not displayed anywhere on the web. Why should those accounts be hidden? What problem would be solved with that? Avoiding giving Ubuntu users the impression that a particular DD will be contactable via the LP interface when actually all that is being enabled is Send. Receiving would still need email to the [EMAIL PROTECTED] email address - i.e. explicit CC:. For external observer this would not change the current situation but provide DDs the flexibility requested in this thread. Which would be exactly what? Add comments - the one thing that LP refuses at the moment. After discussions earlier in this thread, closing can be done but marking a bug as wontfix cannot - neither can reassigning or altering tags or all the other features that the BTS supports via email. Closing a bug without any comment whatsoever is just plain rude but LP forces such rudeness. Close Bugs via changelog? No need for an LP account here. Or use the malone mail interface? See https://help.launchpad.net/BugTrackerEmailInterface for the documentation how to use that. Note that you need to claim your LP account first and associate your gpg key with it. It is precisely this activation that is completely pointless and unnecessary. LP could just activate the accounts based on the publicly available data already in existence for all DD's and accept our GnuPG keys. What extra data is actually being obtained during the activation process? LP knows the username, the verified email address and the gpg key fingerprint - I'm certainly not going to trust any other details of my identity to LP. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Good communication with upstream is good idea
On Sun, 27 Jul 2008 15:58:57 +0100 Neil Williams [EMAIL PROTECTED] wrote: Why force activation in the first place? All the information needed to activate a DD account already exists - our GnuPG fingerprints, our DD email addresses and full names. If an email is received that is signed by a known key belonging to a DD, LP should just accept the blasted thing and stop looking for any other authentication or activation or login or anything else of any kind, ever. If someone can send an email to LP signed by my key then I have a lot more to worry about than whether LP is going to refuse to authenticate that email. Any email signed by a known key belonging to a DD should be accepted without question or authentication or activation or anything else. Great idea. Bug filed: https://bugs.launchpad.net/bugs/252368 Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, Jul 27, 2008 at 03:58:57PM +0100, Neil Williams wrote: On Sun, 2008-07-27 at 15:36 +0200, Reinhard Tartler wrote: Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Reinhard Tartler [Wed, Jul 23 2008, 04:36:39PM]: How about activating it the first time they send a gpg-signed mail to the mail interface? How about simply allowing any DD to send gpg-signed email to add ^^ That requires LP to know who is or isn't a DD. Currently it has no such knowledge, and I think it would require a fair amount of discussion to decide how best to get such information, with a none-too-elegant outcome (special-casing Debian out of all the projects in the world that Launchpad seeks to interface with), which is why I didn't suggest this. That doesn't mean that the Launchpad developers won't implement it; perhaps the bug Scott filed will bear fruit. But I think it's worth considering other solutions in the meantime. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 27 Jul 2008 14:33:17 -0700 Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 03:58:57PM +0100, Neil Williams wrote: On Sun, 2008-07-27 at 15:36 +0200, Reinhard Tartler wrote: Eduard Bloch [EMAIL PROTECTED] writes: #include hallo.h * Reinhard Tartler [Wed, Jul 23 2008, 04:36:39PM]: How about activating it the first time they send a gpg-signed mail to the mail interface? How about simply allowing any DD to send gpg-signed email to add ^^ That requires LP to know who is or isn't a DD. Currently it has no such knowledge, and I think it would require a fair amount of discussion to decide how best to get such information, with a none-too-elegant outcome (special-casing Debian out of all the projects in the world that Launchpad seeks to interface with), which is why I didn't suggest this. Since Debian is (mostly) upstream for Ubuntu and we already implicitly trust code uploaded by DDs and DMs, Debian is a special case. If some other distro with an external upstream were to start using Launchpad, I think it'd be reasonable for them to want something similar. That doesn't mean that the Launchpad developers won't implement it; perhaps the bug Scott filed will bear fruit. But I think it's worth considering other solutions in the meantime. Agreed. I've asked, but I'm not holding my breath. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, Jul 27, 2008 at 05:53:28PM -0400, Scott Kitterman wrote: That requires LP to know who is or isn't a DD. Currently it has no such knowledge, and I think it would require a fair amount of discussion to decide how best to get such information, with a none-too-elegant outcome (special-casing Debian out of all the projects in the world that Launchpad seeks to interface with), which is why I didn't suggest this. Since Debian is (mostly) upstream for Ubuntu and we already implicitly trust code uploaded by DDs and DMs, Debian is a special case. Practically speaking, though, this doesn't require LP to know *who* has upload rights in Debian; it only requires trusting the Debian archive key used to sign the repo that's being pulled from. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 27 Jul 2008 15:01:46 -0700 Steve Langasek [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 05:53:28PM -0400, Scott Kitterman wrote: That requires LP to know who is or isn't a DD. Currently it has no such knowledge, and I think it would require a fair amount of discussion to decide how best to get such information, with a none-too-elegant outcome (special-casing Debian out of all the projects in the world that Launchpad seeks to interface with), which is why I didn't suggest this. Since Debian is (mostly) upstream for Ubuntu and we already implicitly trust code uploaded by DDs and DMs, Debian is a special case. Practically speaking, though, this doesn't require LP to know *who* has upload rights in Debian; it only requires trusting the Debian archive key used to sign the repo that's being pulled from. Yes, but that's an implementation detail. Debian is a special case, so special casing is reasonable. How to accomplsh that special casing is up to them. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
]] Andrei Popescu | IMHO (IANADD) this is too much black-white. What if a DD would be | interested in Ubuntu bugs, but doesn't have enough time to read the | docs? As seen in this thread some are not even aware that Launchpad | can be used via mail. Then they probably don't have time to process the bugs properly, nor use learn how to use LP's mail interface either. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Mon Jul 21 14:07, Steve Langasek wrote: I do feed info upstream (via yet more website logins), I really can't add yet another one. I guess OpenID support will come to the rescue here. It will help, if one wants to use the web interface. However, Launchpad accepting bug report submission and interaction purely via email (like the Debian BTS has done for many years) doesn't seem to be up for consideration. Launchpad does allow manipulation of bug reports via email, but only by authenticated users (i.e., registered LP users with known GPG keys). Given that Ubuntu takes things directly from Debian, and hence all Debian Developers have a vested interest in Ubuntu packages, would it make sense to (provide|ask ubuntu to provide) a way for bug reports to be manipulated by users with keys in the Debian keyring? Obviously this could be created by someone with a LP account and a bouncer that checks the Debian keyring, but it would probably be better to have Ubuntu on board with this. Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
Matthew Johnson [EMAIL PROTECTED] writes: Given that Ubuntu takes things directly from Debian, and hence all Debian Developers have a vested interest in Ubuntu packages, would it make sense to (provide|ask ubuntu to provide) a way for bug reports to be manipulated by users with keys in the Debian keyring? This would effectivly mean activating the respective LP account [1] and associating the respective gpg key with that account. This would be of course doable, but given from this and previous discussions, I do not have the impression that this is generally desired by all debian developers. [1] launchpad automatically creates an account for each package maintainer on package import, but leaves it /deactivated/ until the person /claims/ it by confirming a cookie sent via email. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Wed Jul 23 16:13, Reinhard Tartler wrote: Matthew Johnson [EMAIL PROTECTED] writes: Given that Ubuntu takes things directly from Debian, and hence all Debian Developers have a vested interest in Ubuntu packages, would it make sense to (provide|ask ubuntu to provide) a way for bug reports to be manipulated by users with keys in the Debian keyring? This would effectivly mean activating the respective LP account [1] and associating the respective gpg key with that account. This would be of course doable, but given from this and previous discussions, I do not have the impression that this is generally desired by all debian developers. How about activating it the first time they send a gpg-signed mail to the mail interface? Matt -- Matthew Johnson signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
Matthew Johnson [EMAIL PROTECTED] writes: On Wed Jul 23 16:13, Reinhard Tartler wrote: Matthew Johnson [EMAIL PROTECTED] writes: Given that Ubuntu takes things directly from Debian, and hence all Debian Developers have a vested interest in Ubuntu packages, would it make sense to (provide|ask ubuntu to provide) a way for bug reports to be manipulated by users with keys in the Debian keyring? This would effectivly mean activating the respective LP account [1] and associating the respective gpg key with that account. This would be of course doable, but given from this and previous discussions, I do not have the impression that this is generally desired by all debian developers. How about activating it the first time they send a gpg-signed mail to the mail interface? My point is that I don't have the impression that Debian Developers want to have an LP account activated at all, so IMO it doesn't really matter if the account is activated implicitly via some (authenticated) action or exlicitly by clicking on the 'claim this account' link. And frankly, I don't think that the account activation is really the problem here. Interested developers can easily read up the documentation how to use the email interface and activate their LP account. Doing this for all DD developers is guaranteed to annoy developers who refuse to be remotly associated with launchpad or ubuntu. By requiring to activate accounts explicitly we avoid this in the first place. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Wed,23.Jul.08, 16:36:39, Reinhard Tartler wrote: My point is that I don't have the impression that Debian Developers want to have an LP account activated at all, so IMO it doesn't really matter if the account is activated implicitly via some (authenticated) action or exlicitly by clicking on the 'claim this account' link. And frankly, I don't think that the account activation is really the problem here. Interested developers can easily read up the documentation how to use the email interface and activate their LP account. Doing this for all DD developers is guaranteed to annoy developers who refuse to be remotly associated with launchpad or ubuntu. By requiring to activate accounts explicitly we avoid this in the first place. IMHO (IANADD) this is too much black-white. What if a DD would be interested in Ubuntu bugs, but doesn't have enough time to read the docs? As seen in this thread some are not even aware that Launchpad can be used via mail. Regards, Andrei -- If you can't explain it simply, you don't understand it well enough. (Albert Einstein) signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
Steve Langasek wrote: And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) I've seen websites get openid wrong in a variety of amusing ways, but on reasonable implementations, you generally indicate your openid provider by trying your openid into the openid login box when first visiting a web site, and are then immediatly logged into that web site. -- see shy jo signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
On Wed, Jul 23, 2008 at 12:15:20PM -0400, Joey Hess wrote: Steve Langasek wrote: And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) I've seen websites get openid wrong in a variety of amusing ways, but on reasonable implementations, you generally indicate your openid provider by trying your openid into the openid login box when first visiting a web site, and are then immediatly logged into that web site. You first have to have some way of associating your openid login with an account on that website. The only way to make that initial association would be by logging in to Launchpad using a one-time password from their registration interface. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Reinhard Tartler [EMAIL PROTECTED] writes: This would effectivly mean activating the respective LP account [1] and associating the respective gpg key with that account. This would be of course doable, but given from this and previous discussions, I do not have the impression that this is generally desired by all debian developers. [1] launchpad automatically creates an account for each package maintainer on package import, but leaves it /deactivated/ until the person /claims/ it by confirming a cookie sent via email. Unfortunately, this then generates a whole pile of web pages supposedly for you that then show up in Google searches and the like despite having no information on them. I think that's one of the things that's turned DDs off on Launchpad; I know that it gave me a bad initial impression. (I've since activated my account so that I can subscribe to Ubuntu bugs for packages for which I'm also upstream.) -- 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: Good communication with upstream is good idea
Steve Langasek [EMAIL PROTECTED] writes: On Wed, Jul 23, 2008 at 12:15:20PM -0400, Joey Hess wrote: I've seen websites get openid wrong in a variety of amusing ways, but on reasonable implementations, you generally indicate your openid provider by trying your openid into the openid login box when first visiting a web site, and are then immediatly logged into that web site. You first have to have some way of associating your openid login with an account on that website. In the workflow Joey describes above, this is usually done by the server creating the account on first login. The only way to make that initial association would be by logging in to Launchpad using a one-time password from their registration interface. No, this could (instead) be done by Launchpad authorising the OpenID login, creating the account, and treating the session as logged into that account from that point on. In other words, the OpenID *is* the authentication, as far as Launchpad is concerned. Whether this requires changes to Launchpad so that it conforms with normal OpenID replying party behaviour, I don't know; probably it does. But until it dos, Launchpad is not behaving as a normal OpenID relying party. -- \ “I believe in making the world safe for our children, but not | `\our children's children, because I don't think children should | _o__) be having sex.” —Jack Handey | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Charles Plessy [EMAIL PROTECTED] writes: Le Sun, Jul 20, 2008 at 01:43:13PM -0700, Steve Langasek a écrit : You can close Launchpad bugs in Ubuntu packages from Debian. The LP: ## syntax lets bugs get autoclosed when your package is synced to Debian, or when it's merged by an Ubuntu developer. Interesting... Does it work exactly like for the Debian BTS: i.e. it must be part of the .changes files? Yes, but that is not really relevant since the sync process works by 'faking' a .changes file featuring the sync target (e.g. 'intrepid' instead of 'unstable') and introduces the X-Launchpad-Closes-Bugs fields in addition to the Debian-Closes-Bugs fields. So in the end, you don't need care about this problem when writing changelogs. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Mon, 2008-07-21 at 12:58 +0200, Loïc Minier wrote: It is a bootstrapping problem - to build packages, you need the dependencies. Ubuntu does not have any ARM packages and the packages that we need to use are the ones with the most changes between Debian and Ubuntu. The patches that we use are Debian-specific. I certainly hear you concerning missing binaries; this is likely to change soonish with armel: I suppose Emdebian will move to armel soonish (as arm will probably be dropped in favor of armel post lenny), ARM will be dropped in the same way as m68k (AFAICT) such that ARM packages will not suddenly disappear from the mirrors the moment Lenny is released. As long as ARM keeps up for the fraction of packages that I need, Emdebian can continue to support ARM. Armel will happen in due course. and Ubuntu will soon start an armel port as well (based on Debian's). However I don't quite get the patches part. Ubuntu basically rebases on a new Debian snapshot every six months; this just happened for Ubuntu intrepid suite, so anything which happened on the Debian side should also be present in the Ubuntu side. Emdebian only cares about a fraction of the packages in the Debian archive - principally because Emdebian cannot hope to support certain kinds of packages like maths libraries or OOo that no sane person would expect to run on an embedded device. The packages that do matter to Emdebian are the main ones used by debootstrap (with a few omissions like perl and coreutils) and are also the main ones that Ubuntu would change as part of the Ubuntu installer and Ubuntu-isation (if that is a word) of the OS itself. The patches in Emdebian SVN are specific to the current version in Debian and whenever Ubuntu also makes changes to those packages, those patches would fail. I'm not a git-phile so I have no concept of rebasing stuff (I'm a complete git-phobe if I'm honest). I just know that many of the packages that I build have Ubuntu-specific changes described in their PTS entries. Any Ubuntu-specific change would cause the Emdebian patches to fail. The solution to that is to get the patches supported in Debian but this requires fixes to existing bugs in Debian (e.g. in debhelper and CDBS as described in earlier messages) to support things like nodocs in DEB_BUILD_OPTIONS to be able to produce packages compliant with Emdebian Policy. http://wiki.debian.org/EmdebianPolicy Allow me to come back to your blog post now if you don't mind: 1) you're saying Launchpad is another web-login to carry; I'm happy to report that Launchpad is moving to openid [already commented in this thread] Hmmm, ok. A step in the right direction, true. 2) you're explaining that nobody cared about a bug filed against emdebian-tools in Ubuntu in a long time; that's certainly sad, the same could be said about many Debian bugs too, and many other Ubuntu bugs; because Debian packages are automatically imported into Ubuntu, this might happen; I personally think it's more beneficial for people intereted in random Debian packages which have been auto-imported to continue this way; this might be problematic for e.g. security sensitive packages, but I don't see why it would be for emdebian Until recently, I had no way of knowing about the Ubuntu bug - as the blog post describes, once I was aware, I was (at that time) unable to do anything about it. That individual issue was subsequently resolved via a comment on that blog post. Equally, I am upstream for various projects that have packages in Debian - I am happy to use the BTS for upstream issues with those packages but I know of many upstreams who would not consider scanning the BTS and expect Debian to forward bugs to them. This is perfectly understandable and absolutely not a problem in Debian. Maybe Ubuntu should do more to communicate with Debian about Debian-native packages? Debian is the upstream of emdebian-tools, Debian is where I listen out for problems and issues with my native Debian packages. I am no more likely to go rummaging in Ubuntu than other upstream teams would be to go scanning the BTS. 3) emdebian-tools is not intended for Ubuntu but I don't have a way of encoding that in the package; I think it's hard to tell from your side what derivatives would /not/ be interested in; I believe there are very little packages which are truly distro specific: perhaps keyrings or meta packages, and I'm not even sure. True (note that emdebian-tools does include a keyring package). There probably are very few packages in this kind of situation - typically native Debian packages that have a high dependency on Debian infrastructure. Identifying such packages is not trivial. Consider debootstrapping Debian from Ubuntu or vice versa, pbuilding in the same combinations, or creating virtual machines. The same could apply to emdebian tools; of course there's no official Ubuntu arm port, but did you know that Nokia
Re: Good communication with upstream is good idea
On Mon, 2008-07-21 at 08:17 -0700, Steve Langasek wrote: On Mon, Jul 21, 2008 at 12:58:39PM +0200, Loïc Minier wrote: Allow me to come back to your blog post now if you don't mind: 1) you're saying Launchpad is another web-login to carry; I'm happy to report that Launchpad is moving to openid [already commented in this thread] Launchpad can already be used as an openid /provider/ today, but I haven't heard anything to indicate it will allow logins via other openid providers; is more information available about this somewhere? And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) Umm, yes - definitely. That isn't good. I do have an openid which I use with ikiwiki but it sounds like Ubuntu would not be able to use http://codehelp.myopenid.com/ ? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Good communication with upstream is good idea
On Mon, 21 Jul 2008 21:59:37 +0200 Florian Weimer [EMAIL PROTECTED] wrote: * Stephan Hermann: What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. What needs to be done to make it work on Ubuntu, too? debsecan needs to be patched to download CVE meta-data from Launchpad, and someone needs to maintain the data in Launchpad. So, we need somehow the CVE data from LP or from a source which is being trusted by Ubuntu... A relation between open CVEs in Ubuntu packages and closed CVEs in ubuntu-security packages... I don't know how far the LP guys are in giving out this data, but I know that we have the CVE tracker of Ubuntu (kees, jd, emgent please jump in and fill in any gaps ;)) and we could use this data, right? Now I need to find the time to check the source in general, and how difficult it will to patch it to our needs...and to make Florian happy :) \sh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote: I ask because emdebian-tools isn't intended for Ubuntu either. See [0] - emdebian-tools also depends on server resources provided only by Debian (in this case, the package repositories containing compatible packages which I can use to generate cross-dependencies). FWIW, couldn't emdebian-tools be used to build a Debian target on a Ubuntu host? You need Debian's packages for the target architecture, but you don't have to be running Debian on your host to access those. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Tue, 2008-07-22 at 19:53 +1000, Hamish Moffatt wrote: On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote: I ask because emdebian-tools isn't intended for Ubuntu either. See [0] - emdebian-tools also depends on server resources provided only by Debian (in this case, the package repositories containing compatible packages which I can use to generate cross-dependencies). FWIW, couldn't emdebian-tools be used to build a Debian target on a Ubuntu host? You need Debian's packages for the target architecture, but you don't have to be running Debian on your host to access those. debootstrap does a better job at that. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Good communication with upstream is good idea
On Tue, Jul 22, 2008 at 02:46:01PM +1000, Brian May [EMAIL PROTECTED] was heard to say: Steve Langasek wrote: And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) It would certainly address the issues I regularly face with being forced to register with XYZ different websites: * Have I registered here before? * What is my username? * What is my password? * Ok, I can't work that out. What email address did I give this site? Does it still work? * What sites have I registered on? If you can live with having this information in an encrypted file, you might want to take a look at the pwsafe package. Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Mon, Jul 21, 2008, Steve Langasek wrote: Launchpad can already be used as an openid /provider/ today, but I haven't heard anything to indicate it will allow logins via other openid providers; is more information available about this somewhere? (I don't have more information; like you I just witnessed progress on OpenID support indirectly :-) And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) Good point -- of course that's still an improvement as it's only once per account instead of being once per (host, browser, account), and removing the need for a LP specific password entirely. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Tue, Jul 22, 2008, Neil Williams wrote: Equally, I am upstream for various projects that have packages in Debian - I am happy to use the BTS for upstream issues with those packages but I know of many upstreams who would not consider scanning the BTS and expect Debian to forward bugs to them. This is perfectly understandable and absolutely not a problem in Debian. Maybe Ubuntu should do more to communicate with Debian about Debian-native packages? Debian is the upstream of emdebian-tools, Debian is where I listen out for problems and issues with my native Debian packages. I am no more likely to go rummaging in Ubuntu than other upstream teams would be to go scanning the BTS. [...] True, but there are areas where native Debian packages may need more support from Ubuntu: 1. Forwarding Ubuntu bugs to the BTS - treating Debian as the upstream. Sure; Ubuntu should forward bugs upstream. (Various team in Ubuntu do so for actively used packages; it seems emdebian-tools didn't find an Ubuntu maintainer / contributor interested in forwarding bugs yet though.) 3) emdebian-tools is not intended for Ubuntu but I don't have a way of encoding that in the package; I think it's hard to tell from your side what derivatives would /not/ be interested in; I believe there are very little packages which are truly distro specific: perhaps keyrings or meta packages, and I'm not even sure. True (note that emdebian-tools does include a keyring package). There probably are very few packages in this kind of situation - typically native Debian packages that have a high dependency on Debian infrastructure. Identifying such packages is not trivial. Yes, and I would add it's quite subjective. Even keyring packages aren't clear: consider the recent backports' keyring package. Or simply the example I already gave of debootstrap-ing Ubuntu from Debian or vice-versa. Consider debootstrapping Debian from Ubuntu or vice versa, pbuilding in the same combinations, or creating virtual machines. The same could apply to emdebian tools; of course there's no official Ubuntu arm port, but did you know that Nokia built many of the last Ubuntu releases for arm with almost zero modifications? Ubuntu is also preparing an armel port. So I'm not sure it's easy to tell whether emdebian is suitable for Ubuntu or not. Not sure if those builds were done natively or as cross-builds. Cross-building support is the issue here, in particular obtaining the cross-architecture dependencies as pre-built, compatible, binary packages. The unofficial Ubuntu arm port (ports actually) I mention were done natively for reasons outlined in the article (many packages don't cross build properly): http://www.linuxdevices.com/news/NS2097004728.html NB: this isn't actually Debian's arm, but uses this dpkg architecture Certainly using the criteria of native versionning of a package is not a good criteria to decide. True, but there are areas where native Debian packages may need more support from Ubuntu: [...] 2. Removing those few packages that are both native Debian and highly Debian dependent. This is a manual step. This is quite subjective. Even Ubuntu has derivatives itself (see above port example). But I agree it might be best to simply remove some packages which might be irrelevant, dangerous, or useless clutter for Ubuntu users, or a waste of resources in general. So, yes, Ubuntu Mobile wouldn't make a good use of Emdebian tools because it's unrelated; however there might be interest for these tools from an Ubuntu environment. To do so, the binaries must exist to prepare using apt-cross/dpkg-cross. Currently, that is not the case and I don't think that is going to change before ibex is released. (If it does, by the sound of it this would only happen for armel and the Emdebian patches would still fail to apply.) I can't tell how it will be at the time of the intrepid release, but as you could witness with the third-party port, it's entirely possible that a third party provides a ported archive somewhere. And it's still useful to run the tools again the Debian archive from an Ubuntu environment. i) all the packages you mention (patched packages and tools) are being imported and updated in Ubuntu regularly but are not available in Ubuntu as ARM binaries. (But might be at any time from anybody, and will hopefully soon be available as armel binaries.) ii) you might want to build Debian based images from an Ubuntu env debootstrap can do that. I meant: you might want to run emdebian-tools from an Ubuntu environment against the Emdebian / Debian archives. iii) an Ubuntu arm port might as well exist outside of the Ubuntu official mirrors, just like the Nokia one, or might come to life later on And mips, mipsel, uClibc-arm, and the rest? emdebian-tools is not a one-architecture support package, it can
Re: Good communication with upstream is good idea
On Tue, 2008-07-22 at 17:43 +0200, Loïc Minier wrote: On Tue, Jul 22, 2008, Neil Williams wrote: Consider debootstrapping Debian from Ubuntu or vice versa, pbuilding in the same combinations, or creating virtual machines. The same could apply to emdebian tools; of course there's no official Ubuntu arm port, but did you know that Nokia built many of the last Ubuntu releases for arm with almost zero modifications? Ubuntu is also preparing an armel port. So I'm not sure it's easy to tell whether emdebian is suitable for Ubuntu or not. Not sure if those builds were done natively or as cross-builds. Cross-building support is the issue here, in particular obtaining the cross-architecture dependencies as pre-built, compatible, binary packages. The unofficial Ubuntu arm port (ports actually) I mention were done natively for reasons outlined in the article (many packages don't cross build properly): I am fully aware of how many packages do and do not cross-build. I've been the one cross-building them. ;-) http://www.emdebian.org/buildd/ Unofficial ARM ports might or might not work with the Emdebian patch sets (I would say it is unlikely) and for as long as these patch sets are still necessary, the patches will fail to apply. Unofficial ports are irrelevant to emdebian-tools - at least until more packages cross-build without patches in Debian. If this is important to you or anyone else, then persuade the debhelper and CDBS maintainers to close their cross-building bugs so that I can start removing most of the patches. I cannot rely on unofficial ports - I have no idea if the right version is available or in sync. For this reason, emdebian-tools requires access to a Primary Debian Mirror - trying to setup one of those outside a chroot can easily result in an Ubuntu install being converted to Debian sid. (Depending on your viewpoint, this may be an upgrade but it still isn't what the user would expect.) So, yes, Ubuntu Mobile wouldn't make a good use of Emdebian tools because it's unrelated; however there might be interest for these tools from an Ubuntu environment. To do so, the binaries must exist to prepare using apt-cross/dpkg-cross. Currently, that is not the case and I don't think that is going to change before ibex is released. (If it does, by the sound of it this would only happen for armel and the Emdebian patches would still fail to apply.) I can't tell how it will be at the time of the intrepid release, but as you could witness with the third-party port, it's entirely possible that a third party provides a ported archive somewhere. And it's still useful to run the tools again the Debian archive from an Ubuntu environment. Inside a Debian chroot on whatever derivative you like. Running the tools against a Debian archive on an Ubuntu install means making a Debian archive source available to the system apt which (without careful pinning) could easily result in the system being upgraded to Sid. Such pinning cannot (and probably should not) be done reliably by a postinst. Any bug requesting such a method would be tagged wontfix and closed. Trying to install cross-dependencies built from Debian sources on an Ubuntu install has unknown implications and is a source of avoidable bugs. This isn't a typical application that can be made to be distro-agnostic, this is a package building toolset and just like in Debian or Ubuntu, built packages must target the suite upon which they are built. Would anyone seriously recommend building packages to be uploaded to Debian unstable on Ubuntu, outside a chroot ? With cross-building, the whole issue becomes thrice more complicated due to the cross-dependencies and the cross-building toolchain packages. It is, IMNSHO, insane to expect any toolset to be able to build usable packages on a completely different base system without using a chroot. It's not just the availability of binary packages, it is the whole premise that building Debian packages on Ubuntu is worthwhile. Emdebian is Embedded Debian - the packages are Debian packages, Debian builds, Debian versions and Debian compatibility is tested and assured via the existing tools. Once it is agreed that a chroot is required, it is obvious that this chroot needs to be Debian Sid, at which point emdebian-tools works without any changes and without the unnecessary bugs inherent in trying to mangle the underlying installation. ii) you might want to build Debian based images from an Ubuntu env debootstrap can do that. I meant: you might want to run emdebian-tools from an Ubuntu environment against the Emdebian / Debian archives. Not possible - honestly, it just won't work. There are two many differences in the packages and in the build environment, let alone trying to deal with an unofficial port that might or might not contain compatible binaries at the relevant versions. There is simply no point in doing so, running
Re: Good communication with upstream is good idea
Hi, On Tue, Jul 22, 2008 at 12:06:08PM +0200, Stephan Hermann wrote: On Mon, 21 Jul 2008 21:59:37 +0200 Florian Weimer [EMAIL PROTECTED] wrote: * Stephan Hermann: What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. What needs to be done to make it work on Ubuntu, too? debsecan needs to be patched to download CVE meta-data from Launchpad, and someone needs to maintain the data in Launchpad. So, we need somehow the CVE data from LP or from a source which is being trusted by Ubuntu... A relation between open CVEs in Ubuntu packages and closed CVEs in ubuntu-security packages... I don't know how far the LP guys are in giving out this data, but I know that we have the CVE tracker of Ubuntu (kees, jd, emgent please jump in and fill in any gaps ;)) and we could use this data, right? LP does not currently have a way to record all the information the security team needs recorded for our work, so we use the ubuntu-cve-tracker[1]. And another reason this isn't in LP yet is because there is no stable API for doing data queries -- asking LP for the CVE state of 500 installed packages would take a looong time right now. We are already outputting human-readable state information[2], so perhaps a long-term solution would be for someone to produce an output mode for the tracker on a per-package basis (right now the output is CVE-oriented). Now I need to find the time to check the source in general, and how difficult it will to patch it to our needs...and to make Florian happy :) Perhaps the best short-term solution would be to have the tool check the LSB info and abort on non-Debian machines? -Kees [1] https://launchpad.net/ubuntu-cve-tracker/trunk [2] http://people.ubuntu.com/~ubuntu-security/cve/open.html -- Kees Cook Ubuntu Security Team -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, Jul 20, 2008 at 01:43:13PM -0700, Steve Langasek wrote: You can close Launchpad bugs in Ubuntu packages from Debian. The LP: ## syntax lets bugs get autoclosed when your package is synced to Debian, or when it's merged by an Ubuntu developer. Very interesting, is it documented somewhere already? (for Debian purposes) I've looked in the wiki but I haven't found an obvious place where such an information should be put ... Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
ma, 2008-07-21 kello 09:26 +0200, Stefano Zacchiroli kirjoitti: On Sun, Jul 20, 2008 at 01:43:13PM -0700, Steve Langasek wrote: You can close Launchpad bugs in Ubuntu packages from Debian. The LP: ## syntax lets bugs get autoclosed when your package is synced to Debian, or when it's merged by an Ubuntu developer. Very interesting, is it documented somewhere already? (for Debian purposes) I've looked in the wiki but I haven't found an obvious place where such an information should be put ... The Developer's Reference could perhaps do with a short section on how to deal with downstream distros, and this could be added to it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: Good communication with upstream is good idea
I found Osamu's original post to be very uplifting. Whilst your Ubuntu issue is something of importance and worth discussing, given the more pessimistic nature of the problem (and suggested solutions); it's a shame you've both hijacked Osamu's thread with it :( -- Jon Dowland -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Mon, Jul 21, 2008 at 09:26:30AM +0200, Stefano Zacchiroli wrote: On Sun, Jul 20, 2008 at 01:43:13PM -0700, Steve Langasek wrote: You can close Launchpad bugs in Ubuntu packages from Debian. The LP: ## syntax lets bugs get autoclosed when your package is synced to Debian, or when it's merged by an Ubuntu developer. Very interesting, is it documented somewhere already? (for Debian purposes) I've looked in the wiki but I haven't found an obvious place where such an information should be put ... In the Ubuntu wiki, there's https://wiki.ubuntu.com/UbuntuForDebianDevelopers which is intended to provide practical information about Ubuntu specifically for Debian developers. I've just added a new section, How can I indicate that a bug filed in Ubuntu against one of my packages is fixed in Debian? explaining the changelog handling. On the Debian side, I would suggest that an explanation be linked from anywhere that the Ubuntu bugs themselves are displayed (e.g., in the PTS). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Steve Langasek wrote: Launchpad can already be used as an openid /provider/ today, but I haven't heard anything to indicate it will allow logins via other openid providers; is more information available about this somewhere? And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) What is the problem with closing the Debian bugs in the Debian changelog, and letting the Ubuntu MOTU (I hope I am using the right terminology here) handle the Ubuntu bug tracking? I am speaking from the standpoint of a Debian Developer that is not affiliated with Ubuntu. If a Developer is handling both the Debian and Ubuntu packaging, then they can do as they feel best. I know that I test the Debian bugs prior to closing. I don't test Ubuntu builds - so I wold find it very presumptuous to close an Ubuntu bug. Or am I missing what LP: ### does? -- John H. Robinson, IV [EMAIL PROTECTED] http WARNING: I cannot be held responsible for the above, sbih.org ( )(:[ as apparently my cats have learned how to type. spiders.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Mon, Jul 21, 2008 at 09:38:01AM -0700, John H. Robinson, IV wrote: What is the problem with closing the Debian bugs in the Debian changelog, and letting the Ubuntu MOTU (I hope I am using the right terminology here) handle the Ubuntu bug tracking? No one is saying that Debian developers *have* to close Ubuntu bugs. Steve was just describing that it is possible for Debian developers to address Ubuntu bugs if they choose to. Just like some upstream authors may reference Debian bugs when they fix problems, Debian (as upstream for Ubuntu) can do the same. Choose as much or as little involvement as you like. -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
On Mon, 2008-07-21 at 09:38 -0700, John H. Robinson, IV wrote: Steve Langasek wrote: Launchpad can already be used as an openid /provider/ today, but I haven't heard anything to indicate it will allow logins via other openid providers; is more information available about this somewhere? And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) What is the problem with closing the Debian bugs in the Debian changelog, and letting the Ubuntu MOTU (I hope I am using the right terminology here) handle the Ubuntu bug tracking? There is none. I am speaking from the standpoint of a Debian Developer that is not affiliated with Ubuntu. If a Developer is handling both the Debian and Ubuntu packaging, then they can do as they feel best. I know that I test the Debian bugs prior to closing. I don't test Ubuntu builds - so I wold find it very presumptuous to close an Ubuntu bug. There are situations where you would know that the bug is fixed on both builds, e.g. if it's just an outright bug in the source and not a Debian-specific problem. In those cases, if you wish to, you can use (LP: ###) to close out the bugs just like you close out Debian bugs. You're not required to do that, but if you want to be helpful to them, then it's an option you have available. There are clear advantages to doing it, such as that it helps improve the Debian distribution ecosystem. As Ubuntu is the largest derivitive, to some extent, monitoring the buglist for your packages there helps to improve your own QA efforts on the packaging. William signature.asc Description: This is a digitally signed message part
Re: Good communication with upstream is good idea
* Stephan Hermann: What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. What needs to be done to make it work on Ubuntu, too? debsecan needs to be patched to download CVE meta-data from Launchpad, and someone needs to maintain the data in Launchpad. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Loïc Minier [EMAIL PROTECTED] writes: On Sun, Jul 20, 2008, Neil Williams wrote: Which cannot be done without yet-another-website-login-combo-to-use-once-and-lose-forevermore - useless Ubuntu bug tracker. :-( I do feed info upstream (via yet more website logins), I really can't add yet another one. I guess OpenID support will come to the rescue here. It will help, if one wants to use the web interface. However, Launchpad accepting bug report submission and interaction purely via email (like the Debian BTS has done for many years) doesn't seem to be up for consideration. -- \ “I don't care to belong to a club that accepts people like me | `\as members.” —Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Loïc Minier [EMAIL PROTECTED] writes: On Mon, Jul 21, 2008, Ben Finney wrote: However, the above bug in the Debian BTS has been archived. Must we open another bug to ask for the change to be reverted? Perhaps you can use a GreaseMonkey script to remove it for you, or request a cookie / URL parameter to hide it. That's possible, but orthogonal to my contention that it's better if the Debian PTS avoids showing *any* bug reports against a Debian package that aren't the domain of the maintainer of that Debian package. Apparently that's closed for discussion, though. Sorry for the thread-jack. -- \ “Men never do evil so completely and cheerfully as when they do | `\it from religious conviction.” —Blaise Pascal (1623-1662), | _o__) Pensées, #894. | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Tue, Jul 22, 2008 at 06:58:10AM +1000, Ben Finney wrote: Loïc Minier [EMAIL PROTECTED] writes: On Sun, Jul 20, 2008, Neil Williams wrote: Which cannot be done without yet-another-website-login-combo-to-use-once-and-lose-forevermore - useless Ubuntu bug tracker. :-( I do feed info upstream (via yet more website logins), I really can't add yet another one. I guess OpenID support will come to the rescue here. It will help, if one wants to use the web interface. However, Launchpad accepting bug report submission and interaction purely via email (like the Debian BTS has done for many years) doesn't seem to be up for consideration. Launchpad does allow manipulation of bug reports via email, but only by authenticated users (i.e., registered LP users with known GPG keys). -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Package: qa.debian.org On Mon, Jul 21, 2008 at 08:55:40AM -0700, Steve Langasek wrote: In the Ubuntu wiki, there's https://wiki.ubuntu.com/UbuntuForDebianDevelopers which is intended to provide practical information about Ubuntu specifically for Debian developers. I've just added a new section, How can I indicate that a bug filed in Ubuntu against one of my packages is fixed in Debian? explaining the changelog handling. Thanks. On the Debian side, I would suggest that an explanation be linked from anywhere that the Ubuntu bugs themselves are displayed (e.g., in the PTS). OK, opening a bug report on that. In the meantime I've added a subsection to http://wiki.debian.org/Ubuntu linking to the UbuntuForDebianDevelopers wiki page. Anybody feel free to suggest a better placement for that information (it is the most appropriate page I've found on wiki.d.o) and/or a better wording. Cheers. -- Stefano Zacchiroli -*- PhD in Computer Science \ PostDoc @ Univ. Paris 7 [EMAIL PROTECTED],pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/ I'm still an SGML person,this newfangled /\ All one has to do is hit the XML stuff is so ... simplistic -- Manoj \/ right keys at the right time signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
Steve Langasek wrote: And even if LP accepted other openid providers, one would still have to log in to LP the first time in order to configure which openid provider to use, which I guess is still going to be more effort than some are interested in doing. :) It would certainly address the issues I regularly face with being forced to register with XYZ different websites: * Have I registered here before? * What is my username? * What is my password? * Ok, I can't work that out. What email address did I give this site? Does it still work? * What sites have I registered on? The big problem with openid is not many websites I use regularly support it (yet). I was surprised to notice recently sourceforge is one of them. If LP supported it that would certainly be good IMHO. Brian May -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
* Osamu Aoki: I found some of my packages are offered as a part of Ubuntu archive. Same here. In my case (debsecan), it's a bit irresponsible because the package doesn't really work on Ubuntu--but it's not readily apparent to potential users. Furthermore, it uses server resources provided to Debian, and not to Ubuntu. What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sunday 20 July 2008 12:05, Florian Weimer wrote: * Osamu Aoki: I found some of my packages are offered as a part of Ubuntu archive. Same here. In my case (debsecan), it's a bit irresponsible because the package doesn't really work on Ubuntu--but it's not readily apparent to potential users. Furthermore, it uses server resources provided to Debian, and not to Ubuntu. What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. The preferred way of 'asking politely' is a removal bug. The process is described here: https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive?highlight=%28archive%29#head-6a4a4d2ad0cc004c6199f465539e3bbc2239291e or if you don't want to unwrap the long URL: http://preview.tinyurl.com/5ce4jk Other than reading the pacakge description just now, I'm not familiar with the package. Would it make more sense for someone in Ubuntu to adapt the package to work in the Ubuntu context than to remove it? It looks like it would be useful there too. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Osamu Aoki wrote: I think we should encourage packager to contact upstream with simple hello! message and he (or myself) should be part of active upstream ML. When I had upstreams, I always used to do this. Often though, I'd wait until I had some patches to go with the hello, to make the message have a bit more value. -- see shy jo, downstream from noone signature.asc Description: Digital signature
Re: Good communication with upstream is good idea
On Sun, 2008-07-20 at 18:05 +0200, Florian Weimer wrote: * Osamu Aoki: I found some of my packages are offered as a part of Ubuntu archive. Have you found any that are not? Same here. In my case (debsecan), it's a bit irresponsible because the package doesn't really work on Ubuntu--but it's not readily apparent to potential users. Furthermore, it uses server resources provided to Debian, and not to Ubuntu. What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. How would you relicence it in a manner that prevents use in Ubuntu but retains DFSG compatibility to remain in Debian main? Trying to ban Ubuntu usage would, AFAICT, fall foul of discrimination against fields of endeavour. I ask because emdebian-tools isn't intended for Ubuntu either. See [0] - emdebian-tools also depends on server resources provided only by Debian (in this case, the package repositories containing compatible packages which I can use to generate cross-dependencies). emdebian-tools is not intended for Ubuntu but I don't have a way of encoding that in the package. emdebian-tools is tightly integrated into Debian (and Debian unstable in particular) and is, naturally, a Debian native package (it was written to support Embedded Debian after all, not UbuntuMobile). It isn't intended to work on Ubuntu because Ubuntu does not provide the foreign packages needed for linking when cross building, those come exclusively from Debian. Same with apt-cross, it is exclusively designed for Debian, Debian mirrors and Debian buildd configurations. How is emdebian-tools meant to cross-build for ARM on Ubuntu when Ubuntu does not provide ARM packages and makes changes to the equivalent Debian packages? To me it seems highly unlikely that cross versions of Debian packages would install over a Ubuntu base, especially when those packages are the typical debootstrap selection that have a variety of changes in Ubuntu. I don't run Ubuntu, I have no inclination to test for Ubuntu and as no-one else has offered, I cannot support Ubuntu. How many packages could be in this situation? I don't expect it to be many. Some form of filter on the Ubuntu side may be necessary. Alternatively, is there a package that I can list in Conflicts: that is only present in Debian derivatives? Yes, any mechanism could be abused but MOTU-people could always file bugs in the BTS about such usage. [0] http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/122-Migrating-Emdebian-changes-into-Debian,-not-Ubuntu.html -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Good communication with upstream is good idea
2008/7/20 Florian Weimer [EMAIL PROTECTED]: * Osamu Aoki: I found some of my packages are offered as a part of Ubuntu archive. Same here. In my case (debsecan), it's a bit irresponsible because the package doesn't really work on Ubuntu--but it's not readily apparent to potential users. Furthermore, it uses server resources provided to Debian, and not to Ubuntu. What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. Packages are automatically synced from Debian as part of the development process, if a package doesn't want to be in Ubuntu then as far as I know there needs to be a manual override set up. Relicensing your software to stop other people redistributing seems like overkill to be honest, and no doubt would cause your package to break the Debian Free Software Guidelines. You can't release under a free license and keep 100% control over redistribution! Caroline -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
* Neil Williams: What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. How would you relicence it in a manner that prevents use in Ubuntu but retains DFSG compatibility to remain in Debian main? Relicensing would involve moving the package to non-free, that's correct. I could try some trademark stunt, but I don't want to spend any money on a trademark registration. I don't see why such cases (including yours) can't be resolved amicably. It's not rocket science, after all. How many packages could be in this situation? I don't expect it to be many. Some form of filter on the Ubuntu side may be necessary. Alternatively, is there a package that I can list in Conflicts: that is only present in Debian derivatives? Yes, any mechanism could be abused but MOTU-people could always file bugs in the BTS about such usage. MOTU bugs should end up in the Canonical bug tracker. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
* Osamu Aoki [EMAIL PROTECTED] [080720 14:57]: I think we should encourage packager to contact upstream with simple hello! message and he (or myself) should be part of active upstream ML. After all, we all are human. Friendly hello always helps people. I know this is not something we need to have as policy but as a part of best practice document, it is good to mention. For Debian, Developers Reference. If I miss it in Developers Reference, I am sorry. Developers' Reference has only http://www.debian.org/doc/developers-reference/developer-duties.html#upstream-coordination but I guess saying hello is already implied in the title Coordination with upstream developers. The New Maintainers' Guide has in the list of things to do when packaging the first program: you should contact program's author(s) to check if they agree with packaging it. It is important to be able to consult with author(s) about the program in case of any program specific problems, so don't try to package unmaintained pieces of software. I think I saw it also in some instructions on how to ITP something but I no longer find it. But saying helo is not always easy. First of all one has to be able to contact upstream (I once adopted a package where all email addresses of upstream in the software and on the website there was none. Only behind a link to another project was the mailinglist also for this package). And then formulating such a mail is always a bit complicated. Not everyone knows that package maintainers in Debian are really about source modifications and saying helo can easily result in being offered the upstream maintainer hat. Hochachtungsvoll, Bernhard R. Link -- Never contain programs so few bugs, as when no debugging tools are available! Niklaus Wirth -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 2008-07-20 at 18:42 +0200, Bernhard R. Link wrote: * Osamu Aoki [EMAIL PROTECTED] [080720 14:57]: I think we should encourage packager to contact upstream with simple hello! message and he (or myself) should be part of active upstream ML. After all, we all are human. Friendly hello always helps people. I know this is not something we need to have as policy but as a part of best practice document, it is good to mention. For Debian, Developers Reference. If I miss it in Developers Reference, I am sorry. [..] And then formulating such a mail is always a bit complicated. Not everyone knows that package maintainers in Debian are really about source modifications and saying helo can easily result in being offered the upstream maintainer hat. The mail to upstream could include a snipet like : If you are curious about what `Packaging for Debian' involves, you can read : http://wiki.debian.org/GettingPackaged A lot of good work was done on that page, it could probably still be improved and be migrated to www.d.o/doc/. Franklin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 2008-07-20 at 12:16 -0400, Scott Kitterman wrote: On Sunday 20 July 2008 12:05, Florian Weimer wrote: * Osamu Aoki: I found some of my packages are offered as a part of Ubuntu archive. Same here. In my case (debsecan), it's a bit irresponsible because the package doesn't really work on Ubuntu--but it's not readily apparent to potential users. Furthermore, it uses server resources provided to Debian, and not to Ubuntu. What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. The preferred way of 'asking politely' is a removal bug. The process is described here: Which cannot be done without yet-another-website-login-combo-to-use-once-and-lose-forevermore - useless Ubuntu bug tracker. :-( I do feed info upstream (via yet more website logins), I really can't add yet another one. That was the main point of my original blog entry linked from the previous post. Having to ask the lazy web to sort out bugs in Ubuntu is just daft, IMHO, but that's what LP requires. As I say, daft. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Good communication with upstream is good idea
Hi, On Sunday 20 July 2008 18:42, Florian Weimer wrote: Relicensing would involve moving the package to non-free, that's correct. Ui, I dint expect you really would want that. Why not detect if the system is really Debian and if not output system type unsupported? regards, Holger pgpwbE9WSk5WM.pgp Description: PGP signature
Re: Good communication with upstream is good idea
On Sunday 20 July 2008 13:33, Neil Williams wrote: On Sun, 2008-07-20 at 12:16 -0400, Scott Kitterman wrote: On Sunday 20 July 2008 12:05, Florian Weimer wrote: * Osamu Aoki: I found some of my packages are offered as a part of Ubuntu archive. Same here. In my case (debsecan), it's a bit irresponsible because the package doesn't really work on Ubuntu--but it's not readily apparent to potential users. Furthermore, it uses server resources provided to Debian, and not to Ubuntu. What's the correct way to get it out of Unbuntu (universe)? I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. The preferred way of 'asking politely' is a removal bug. The process is described here: Which cannot be done without yet-another-website-login-combo-to-use-once-and-lose-forevermore - useless Ubuntu bug tracker. :-( I do feed info upstream (via yet more website logins), I really can't add yet another one. That was the main point of my original blog entry linked from the previous post. Having to ask the lazy web to sort out bugs in Ubuntu is just daft, IMHO, but that's what LP requires. As I say, daft. Agreed. There's a lot of stuff about Launchpad that is daft. If would put together the information requested in the removal bug, I'll file it. That would avoid the need to make an account. Feel free to follow-up offlist. Scott K -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 2008-07-20 at 19:57 +0200, Holger Levsen wrote: Hi, On Sunday 20 July 2008 18:42, Florian Weimer wrote: Relicensing would involve moving the package to non-free, that's correct. Ui, I dint expect you really would want that. Why not detect if the system is really Debian and if not output system type unsupported? I tried that - it generates a bug report within Ubuntu that I can't close from within Debian but which shows up on the PTS page. :-( Plus it adds unnecessary code to the package without removing it from the apt-cache search results in Ubuntu which only confuses people. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Re: Good communication with upstream is good idea
Florian Weimer [EMAIL PROTECTED] writes: What's the correct way to get it out of Unbuntu (universe)? I'd suggest filing a bug, and perhaps advertise it on the relevant developer mailing lists. I don't want to relicense it, but if asking politely does not work, it seems to be my only choice. Relicensing would most probably make the package end up in multiverse instead of univserse. In any case it would end up much confusion and very litte benefit for all involved parties. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Hi Neil, On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote: I ask because emdebian-tools isn't intended for Ubuntu either. See [0] - emdebian-tools also depends on server resources provided only by Debian (in this case, the package repositories containing compatible packages which I can use to generate cross-dependencies). That doesn't seem particularly Debian-specific, though? It's not out of the question that Ubuntu could have an armel port later, and that's the only thing I can think of that /should/ cause emdebian-tools to be incompatible with Ubuntu. emdebian-tools is not intended for Ubuntu but I don't have a way of encoding that in the package. emdebian-tools is tightly integrated into Debian (and Debian unstable in particular) and is, naturally, a Debian native package (it was written to support Embedded Debian after all, not UbuntuMobile). It isn't intended to work on Ubuntu because Ubuntu does not provide the foreign packages needed for linking when cross building, those come exclusively from Debian. So if an armel port of Ubuntu becomes available, is there anything else that stops emdebian-tools from working with it? Same with apt-cross, it is exclusively designed for Debian, Debian mirrors and Debian buildd configurations. How does apt-cross have anything to do with the Debian buildds, at all? Surely you're not using this as a build-dependency to force Debian cross-builds on the Debian buildds, are you? Nor do I see how apt-cross would be affected by differences between a Debian vs. an Ubuntu mirror. (Ubuntu main is smaller than Debian main, but is still self-contained, to be sure.) How is emdebian-tools meant to cross-build for ARM on Ubuntu when Ubuntu does not provide ARM packages and makes changes to the equivalent Debian packages? Hrm, what changes are at issue here? The Debian maintainers also make changes to Debian packages, all the time. In what way do the Ubuntu changes differ that makes emdebian-tools incompatible with Ubuntu? To me it seems highly unlikely that cross versions of Debian packages would install over a Ubuntu base, especially when those packages are the typical debootstrap selection that have a variety of changes in Ubuntu. I don't run Ubuntu, I have no inclination to test for Ubuntu and as no-one else has offered, I cannot support Ubuntu. While the current absence of any official Ubuntu armel port seems like a pretty good reason to omit emdebian-tools from Ubuntu for the moment, the fact that the Debian package maintainer or upstream author doesn't support Ubuntu would not generally be a reason for Ubuntu not to include the package. Debian also has any number of upstreams who don't support Debian, after all. How many packages could be in this situation? I don't expect it to be many. Some form of filter on the Ubuntu side may be necessary. Yes, there is a blacklist in Ubuntu to prevent certain packages from being synced from Debian. Scott Kitterman has already started the process now of getting emdebian-tools added to that list. BTW, in your cited blog post, I noticed that you wrote: I really don't like Launchpad (I have quite enough web-logins thank you very much) or the PTS link that shows Ubuntu bugs that I cannot close from Debian. You can close Launchpad bugs in Ubuntu packages from Debian. The LP: ## syntax lets bugs get autoclosed when your package is synced to Debian, or when it's merged by an Ubuntu developer. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
Neil Williams [EMAIL PROTECTED] writes: On Sun, 2008-07-20 at 19:57 +0200, Holger Levsen wrote: Why not detect if the system is really Debian and if not output system type unsupported? I tried that - it generates a bug report within Ubuntu that I can't close from within Debian but which shows up on the PTS page. :-( Yes, this is a good argument against the change to the PTS introduced by bug#483179. The Debian BTS should *only* report problems that can be solved from within Debian, otherwise it's useless noise that leads to that section being ignored even when it might have something important to say. However, the above bug in the Debian BTS has been archived. Must we open another bug to ask for the change to be reverted? -- \ “Two paradoxes are better than one; they may even suggest a | `\ solution.” —Edward Teller | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Good communication with upstream is good idea
On Sun, 2008-07-20 at 13:43 -0700, Steve Langasek wrote: Hi Neil, On Sun, Jul 20, 2008 at 05:32:31PM +0100, Neil Williams wrote: I ask because emdebian-tools isn't intended for Ubuntu either. See [0] - emdebian-tools also depends on server resources provided only by Debian (in this case, the package repositories containing compatible packages which I can use to generate cross-dependencies). That doesn't seem particularly Debian-specific, though? It's not out of the question that Ubuntu could have an armel port later, and that's the only thing I can think of that /should/ cause emdebian-tools to be incompatible with Ubuntu. emdebian-tools supports all the architectures currently supported by Debian and a few that are pending (like uclibc ones - once the well-known problems in uClibc are sorted out and uclibc returns to Debian after Lenny). To support emdebian-tools properly, Ubuntu would have to support all the Debian architectures with appropriate buildds and repositories. This is more than a little pointless. The other problem is that emdebian-tools is working towards getting cross-building support into Debian packages but currently needs patches to cross-build all current packages (even those that have closed the relevant cross-building support bugs) due to issues in CDBS and debhelper etc. Those patches are constantly updated against the versions of the packages in Debian Sid - e.g. I've just updated the patches for pam, pcre3 and a few others that allow me to upload a usable cross-built package in advance of a solution compatible with the Debian package itself. With the newly created cross-building autobuilder for Emdebian, [0] I will now have more time to file such bugs to get the next round of cross-building support into packages. I was concentrating on getting the basic support into at least some packages for Lenny and that is now done. All the time, the tools themselves are developing and becoming more powerful. As support improves, patches change. It's a lot of work and I am not about to make those patches compatible with the versions in Ubuntu (or any other derivative) - the only solution for non-Debian usage is to wait until the changes are made in the appropriate Debian packages that remove the need for the patches. That is a slow process and in the meantime, Emdebian needs packages to test and those need the patches. Even when the patches are folded into Debian, the lack of suitable architecture repositories will prevent emdebian-tools being useful on Ubuntu, especially when compared with running the tools inside a Debian chroot on Ubuntu. emdebian-tools is not intended for Ubuntu but I don't have a way of encoding that in the package. emdebian-tools is tightly integrated into Debian (and Debian unstable in particular) and is, naturally, a Debian native package (it was written to support Embedded Debian after all, not UbuntuMobile). It isn't intended to work on Ubuntu because Ubuntu does not provide the foreign packages needed for linking when cross building, those come exclusively from Debian. So if an armel port of Ubuntu becomes available, is there anything else that stops emdebian-tools from working with it? mips, mipsel, ARM, uclibc-arm, uclibc-mips . . . . Currently, emdebian-tools only has prebuilt binary packages for ARM (not armel) but adding more is supported (although not particularly trivial at this time). For Ubuntu to support emdebian-tools, Ubuntu would have to become Debian which would be pointless (and futile). Those who want to do things with Emdebian on Ubuntu are simply advised to create a Debian chroot - Lenny or better - and run things from there. Same with apt-cross, it is exclusively designed for Debian, Debian mirrors and Debian buildd configurations. How does apt-cross have anything to do with the Debian buildds, at all? Surely you're not using this as a build-dependency to force Debian cross-builds on the Debian buildds, are you? The Emdebian autobuilder uses apt-cross, yes. There is no other way of downloading ARM packages on amd64 and converting them to -arm-cross packages for use in /usr/arm-linux-gnu/lib/ etc and reconciling all the dependencies to be compatible with dpkg. emdebian-tools uses a debootstrap wrapper to create a disposable chroot cross-building environment with emdebian-tools installed and configured inside (including a cross-building toolchain for the desired arch). Yes, this is a larger .tgz than a standard pbuilder but it works. i.e. for Emdebian build-essential, in effect, includes emdebian-tools (which in turn depends on apt-cross). Debian buildds don't support cross-building, I'm using emdebian-tools autobuilder support. (We also have an autobuilder for the toolchains.) The autobuilders grew organically from the basic scripts due to the inevitable need to let packages cross-build unattended whilst I get on with the rest of my life. The autobuilder works with the patches using subversion
