FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu Masters Of The Universe

 
 
LinkBack Thread Tools
 
Old 07-20-2008, 05:06 PM
Franklin PIAT
 
Default Good communication with upstream is good idea

On Sun, 2008-07-20 at 18:42 +0200, Bernhard R. Link wrote:
> * Osamu Aoki <osamu@debian.org> [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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-20-2008, 05:33 PM
Neil Williams
 
Default 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/
 
Old 07-20-2008, 05:44 PM
Reinhard Tartler
 
Default Good communication with upstream is good idea

Florian Weimer <fw@deneb.enyo.de> 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

--
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
 
Old 07-20-2008, 05:44 PM
Reinhard Tartler
 
Default Good communication with upstream is good idea

Florian Weimer <fw@deneb.enyo.de> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-20-2008, 05:53 PM
Scott Kitterman
 
Default 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-20-2008, 05:57 PM
Holger Levsen
 
Default 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
 
Old 07-20-2008, 06:08 PM
Neil Williams
 
Default 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/
 
Old 07-20-2008, 08:43 PM
Steve Langasek
 
Default 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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-20-2008, 09:58 PM
Ben Finney
 
Default Good communication with upstream is good idea

Neil Williams <codehelp@debian.org> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 07-20-2008, 09:59 PM
Neil Williams
 
Default 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 and thus gives us a usable cross-buildd until such time as
the patches become compatible with Debian. Emdebian drops large amounts
of Debian Policy [1] and therefore the current patches cannot be
directly applied in the Debian package - other support is needed for
DEB_BUILD_OPTIONS and dpkg variants.

apt-cross - when used by emdebian-tools - needs to be able to understand
the Debian repositories and know how to handle primary mirrors that have
ARM alongside amd64 rather than partial mirrors that might not.

> 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.)

Ubuntu mirrors do not contain the ARM, armel, mips, mipsel or any other
architecture binaries which are converted into cross-dependencies for
the cross-build. This is entirely in line with the aims of Ubuntu and is
not something that I'd expect to change.

> > 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?

Emdebian keeps pace with the Debian packages - that is what the
autobuilder and the patches do. There is no such method for Ubuntu and
the Emdebian patches will not apply because Ubuntu has made their own
changes. Typically, the packages concerned are the standard debootstrap
packages, the very ones that Ubuntu changes to make Ubuntu what it is.

> > 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.

The lack of all other cross-building ports is also sufficient reason.
There is no possibility of Ubuntu supporting *all* the architectures
that Debian supports - that is why I wrote the tools for Emdebian, not
UbuntuMobile.

The lack of patches for Ubuntu packages would also prevent support. Once
more Debian packages cross-build without any patches at all, these
changes will feed into Ubuntu (and other derivatives) but some patches
may still be needed.

The basic problem is a bootstrapping one. It is possible to choose to
start from scratch and only use cross-built packages as the
cross-dependencies of other cross-built packages but the path through
the dependencies is very difficult to forecast and can change with each
iteration. This is why I have 245 source packages in the repository but
only use 145 on the actual device. I've had to cross-build some packages
that I now do not need because the Emdebian changes have dropped
optional components from the Debian builds (changing --enable-foo to
--disable-foo by patching debian/rules and debian/foo.install files) and
dropped the dependencies along the way. Hence, emdebian-tools takes the
simpler route of using the Debian packages to create the
cross-dependencies during each build, via apt-cross.

emdebian-tools then uses edos-debcheck to ensure the integrity of the
Emdebian unstable repository by checking the compatibility of each
potential upload *before* dput is called. edos-debcheck is also used
when identifying the packages that need to be updated in Emdebian -
checking the integrity of the entire repository in each of the three
current flavours (base, X and full GPE GUI). In this way, Emdebian can
ensure that root filesystems can be generated at any time to aid testing
and development.

apt-cross and dpkg-cross are fundamental to how emdebian-tools operates
- which is why I develop all three together for Emdebian and Debian.

> > 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.

Scott has indeed offered to arrange this and I am very grateful for his
help. The removal bug has now been filed for ibex.

> 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.

Didn't know that, thanks. (Wouldn't have helped for that particular bug
which needed a Won'tFix closure, not a "Fixed in version foo" closure.)

[0] http://www.emdebian.org/buildd/
[1] http://wiki.debian.org/EmdebianPolicy

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
 

Thread Tools




All times are GMT. The time now is 09:37 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org