Re: motu-release will revert libgems-ruby to the old state.

[Stephan Hermann]

Dear Colleagues,


On Mon, 2008-09-01 at 12:21 -0400, Mathias Gug wrote:
> Hi,
> 
> I'd like to appeal against motu-release decision to revert the
> libgem-ruby upload 1.3.0~RC1really1.2.0-2ubuntu2 based on the following
> reasons:
> 
> On Fri, Aug 29, 2008 at 11:39:52PM +0200, Stefan Potyra wrote:
> > 
> > first off, this was not an easy decision. It didn't happen so far yet, that 
> > motu-release had to decide if an upload should indeed get reverted, and 
> > hence 
> > this decision was done only with consent among all motu-release members. 
> > The 
> > key factor in regards to this decision was if this upload does work towards 
> > making an improvement in regards to the intrepid-release, or if it did in 
> > fact 
> > result in the opposite, hence making it unfit for release.
> > 
> 
> Let me reiterate what the upload was trying to achieve. As outlined in
> [1]:
> 
>   Providing binaries shipped by gems on the default path.
> 
>   In hardy, the end user using a gem (let's say the rails gem) would
>   have to do the following things:
> 
>   1. sudo apt-get install rubygems
>   2. sudo gem install rails
>   3. Modify the default PATH in the environment to include
>   /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the
>   command line.
> 
>   The upload aims at removing step number 3 from the process by symlinking
>   the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/.
> 
> [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026240.html

Step 3 is the right thing to do, IMHO. The Sysadmin who "needs" to use
gem in the first place, is doomed anyhow. But letting the sysadmin do
his work, he/she knows very well what to do with bins/libs installed by
gem under /var/lib/gems/* . We shouldn't overrule him/her.

A manual link is just a finger click away. But it's the sysadmin who is
doing this.

Furthermore, I tried to get the old source package of the gem I was
giving as example. Sadly it's gone. Anyways, to make it again clear what
happend with this gem was this:

Gem has the possibility to give e.g. DESTDIR or other installation
locations to all included dependencies. The same as in RPM spec files or
debian/rules files. No question, this is a good way, if that works as
explained, everything is fine.

But now, the package of this particular gem wasn't a pro, and had no
clue about attaching the needed shell vars to his makefile, so he just
overruled the sysadmin or the guy who was in favour to compile this gem,
and the gem packager just forced: /usr/* as installation path. 

As there is no real trusted source of gems, mostly all packages are
non-signed, it's quite difficult for the "normal rails user" to know
what happens on his/her system, especially when building those software,
which is mostly necessary, because of different other deps e.g.
libmysqlclient, or whatever.


The problem is not distro-specific, it's upstream cruft, because they
don't have a good policy for packaging those gems. If there is something
like the debian policy, or the redhat rpm policy, I wouldn't object, but
as long there is nothing like that, most sysadmins need to be careful,
and in most cases they are, especially when they fall into a pit with
gem.


Even if I'm sounding like an old fart, regarding this, but I think the
old way of installation of gem parts in /var/lib/gems/* is much better,
and letting the sysadmin do the work is even more sane. 

The other fact is, that most gems are using newer software deps then
older distros (e.g. dapper, hardy, etch, lenny (TBR)) have. So it's
quite usual, that the sysadmin needs to break his distro anyways with
new lib dependencies. That's why we shouldn't encourage the use of gems
anyways. Much better would be, if we would have a policy in place, as we
have with php pear stuff or with perl modules. the more packaged gems we
have in our archives the better (this is not ubuntu or debian specific).
So no sysadmin has to break his system because of a faulty webapp.

regards,

\sh


-- 
Stephan '\sh' Hermann   | OSS Developer & Systemadministrator
JID: [EMAIL PROTECTED]| http://www.sourcecode.de/
GPG ID: 0xC098EFA8  | http://leonov.tv/
3D8B 5138 0852 DA7A B83F  DCCB C189 E733 C098 EFA8



-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Emmet Hikory]

Soren Hansen wrote:
> As much as I dislike upstream tarballs shipping debian directories, I
> really don't approve much of the practice of repacking tarballs just for
> that reason.
>
> If I find something that claims to be the original tarball of passenger
> 2.0.3 (by having a filename such as passenger_2.0.3.orig.tar.gz), and
> the checksum doesn't match what I can find on the upstream's ftp site, I
> get *very* suspicious.

In support of not repacking tarballs just because upstream has a
debian/ directory, debhelper has include the -i (ignore) feature since
major version 6, specifically to allow a packager to create a working
package despite what upstream may have added in the debian/ directory.
 That said, in cases where these sorts of confusions exist, it may be
worth documenting it in debian/README.source

-- 
Emmet HIKORY

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Soren Hansen]

On Mon, Sep 01, 2008 at 08:47:15PM +0200, Stefan Potyra wrote:
>>> In this regard, I'd like to bring your attention however to [1],
>>> without further comments.  [1]: >> incoming/passenger-0808222010/passenger-2.0.3/debian/postinst>
>> While this file is there because it's in the upstream tarball, it
>> isn't used. The diff.gz file adds the file
>> debian/libapache2-mod-passenger.postinst [2].
> Maybe you/the packager might want to strip debian out of the upstream
> tarball then?

As much as I dislike upstream tarballs shipping debian directories, I
really don't approve much of the practice of repacking tarballs just for
that reason.

If I find something that claims to be the original tarball of passenger
2.0.3 (by having a filename such as passenger_2.0.3.orig.tar.gz), and
the checksum doesn't match what I can find on the upstream's ftp site, I
get *very* suspicious.

-- 
Soren Hansen   | 
Virtualisation specialist  | Ubuntu Server Team
Canonical Ltd. | http://www.ubuntu.com/


signature.asc
Description: Digital signature
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.

[Scott Kitterman]

On Mon, 1 Sep 2008 23:33:40 +0200 Stefan Potyra <[EMAIL PROTECTED]> wrote:
>Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.
>
>motu-release members present (4/4):
>* Cesare Tirabassi (norsetto)
>* Scott Kitterman (ScottK)
>* Luke Yelavich (TheMuso)
>* Stefan Potyra (sistpoty|work)
>
>Present on invitation:
>* Luca Falavigna (DktrKranz)
>
>Relationship between ubuntu-release and motu-release:
>There were no objections raised, that ubuntu-release could also approve 
FFe's 
>for universe packages in case of need. Scott noted, that ubuntu-release 
"may, 
>but [they] generally ought not" to approve universe FFe's.
>[Note: To reflect this, ubuntu-release was added as a member to 
motu-release  
>on request from Colin Watson].
>
>ACK's for FFe's:
>All members agreed to go with 2 ACKs from motu-release for exception 
requests 
>again, as has been the case during the last cycle.
>
>Delegations:
>All motu-release members were very much in favour to once again have 
delegates 
>handling relevant subsets of packages.
>
>The following flavors have been agreed on to be handled by the following 
>delegates:
>
>- Kubuntu: Jonathan Ridell (Ridell)
>- Mythbuntu: Mario Limonciello (superm1)
>- Xubuntu: Cody Sommerville (cody-sommerville)
>- Mozilla Team: Alexander Sack (asac)
>- Ubuntu Studio: _MMA_
>- Ubuntu Destkop: Sebastien Bacher (seb128)
>- Ubuntu Mobile: Oliver Gravert (ogra)
>- Ubuntu MID: Loic Minier (lool)
>- Ubuntu Server: Scott Kitterman (ScottK)
>
>Packages covered by delegations:
>Scott raised the question, what package sets would be covered by 
delegates. 
>After a short discussion, it was agreed on that every delegate should 
reply to 
>this mail with a set of packages to take release responsibility for. In 
case 
>of overlap, motu-release can then trim down the lists, taking over 
>coordination of conflicting packages.

I'll ask in the Server Team for input.

>Standing freeze exceptions:
>To request a standing freeze exception, an email should be sent to the Ubuntu 
>MOTU mailing list for discussions. It is granted, once three members of motu-
>release have given their ACK.
>
>At around 12.00 UTC, Cesare, Stefan and Luca had to leave, so that quorum was 
>no longer guaranteed. The following points where discussed afterwards:
>
>Per-Package delegations:
>In case of need, persons requesting per-package delegations should sent a mail 
>the MOTU mailing list with the request, so that it can be discussed there.
>
>Diffstat requirements:
>Scott raised the point, to get rid of the requirement to add a diffstat.

Please can we make this go away.  See Colin Watson for details.

>Bugfix only releases:
>Another point Scott raised, was wether bugfix only releases would need 
freeze 
>exceptions as well.

I'd like to repeat what we did in Hardy with a file a bug to document what 
you did and why and then upload it rule.  It seemed to work well in Hardy 
and I'd like to see it again.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.

[Scott Kitterman]

On Mon, 1 Sep 2008 23:42:39 +0200 Stefan Potyra <[EMAIL PROTECTED]> wrote:
>Hi,
>
>On Monday 01 September 2008 23:33:40 Stefan Potyra wrote:
>[..]
>>
>> - Kubuntu: Jonathan Ridell (Ridell)
>> - Mythbuntu: Mario Limonciello (superm1)
>> - Xubuntu: Code Sommerville (code-sommerville)
>ahem, mea culpa, Cody, for getting your name/nick wrong.
>
>> - Mozilla Team: Alexander Sack (asac)
>> - Ubuntu Studio: _MMA_
>> - Ubuntu Destkop: Sebastien Bacher (seb128)
>> - Ubuntu Mobile: Oliver Gravert (ogra)
>> - Ubuntu MID: Loic Minier (lool)
>> - Ubuntu Server: Scott Kitterman (ScottK)
>
>Finally, I'm not 100% sure who already agreed to accept the delegation 
during 
>the meeting. If you're on the list and haven't been asked during the 
meeting, 
>please state if you accept the delegation, or if not, please make a 
suggestion 
>for a replacement. Thanks.

I don't think I actually said I'd accept.  I do.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Delegate/Project package lists (Was: Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.)

[Cory K.]

Stefan Potyra wrote:
> Delegations:
> All motu-release members were very much in favour to once again have 
> delegates 
> handling relevant subsets of packages.
>
> The following flavors have been agreed on to be handled by the following 
> delegates:
>
> - Ubuntu Studio: _MMA_
>   

Man. I feel loved. Nobody knows my name? :) Cory Kontros ;)

> Packages covered by delegations:
> Scott raised the question, what package sets would be covered by delegates. 
> After a short discussion, it was agreed on that every delegate should reply 
> to 
> this mail with a set of packages to take release responsibility for. In case 
> of overlap, motu-release can then trim down the lists, taking over 
> coordination of conflicting packages.

I would like that these lists be maintained on the wiki. Where would be
an appropriate place? A subpage of a MOTU page or of the projects page?

-Cory K.

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.

[Stefan Potyra]

Hi,

On Monday 01 September 2008 23:33:40 Stefan Potyra wrote:
[..]
>
> - Kubuntu: Jonathan Ridell (Ridell)
> - Mythbuntu: Mario Limonciello (superm1)
> - Xubuntu: Code Sommerville (code-sommerville)
ahem, mea culpa, Cody, for getting your name/nick wrong.

> - Mozilla Team: Alexander Sack (asac)
> - Ubuntu Studio: _MMA_
> - Ubuntu Destkop: Sebastien Bacher (seb128)
> - Ubuntu Mobile: Oliver Gravert (ogra)
> - Ubuntu MID: Loic Minier (lool)
> - Ubuntu Server: Scott Kitterman (ScottK)

Finally, I'm not 100% sure who already agreed to accept the delegation during 
the meeting. If you're on the list and haven't been asked during the meeting, 
please state if you accept the delegation, or if not, please make a suggestion 
for a replacement. Thanks.

[..]
>
> At around 12.00 UTC, Cesare, Stefan and Luca had to leave, so that quorum
> was no longer guaranteed. The following points where discussed afterwards:
>
[..]
>
> Diffstat requirements:
> Scott raised the point, to get rid of the requirement to add a diffstat.

Well, it's partly usuable, to get a quick overview of the amount of changes. 
However most of the times during hardy, I didn't find the diffstat to be 
particular useful, so I don't object to dropping the requirement.

>
> Bugfix only releases:
> Another point Scott raised, was wether bugfix only releases would need
> freeze exceptions as well.

Imho we shouldn't need exceptions for bugfix only releases, but it would be 
nice have it documented (be it either in debian/changelog or via a bug or 
both).

Cheers,
   Stefan.


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.

[Stefan Potyra]

Minutes of motu-release meeting, Friday 29th August, 11.00 UTC.

motu-release members present (4/4):
* Cesare Tirabassi (norsetto)
* Scott Kitterman (ScottK)
* Luke Yelavich (TheMuso)
* Stefan Potyra (sistpoty|work)

Present on invitation:
* Luca Falavigna (DktrKranz)

Relationship between ubuntu-release and motu-release:
There were no objections raised, that ubuntu-release could also approve FFe's 
for universe packages in case of need. Scott noted, that ubuntu-release "may, 
but [they] generally ought not" to approve universe FFe's.
[Note: To reflect this, ubuntu-release was added as a member to motu-release  
on request from Colin Watson].

ACK's for FFe's:
All members agreed to go with 2 ACKs from motu-release for exception requests 
again, as has been the case during the last cycle.

Delegations:
All motu-release members were very much in favour to once again have delegates 
handling relevant subsets of packages.

The following flavors have been agreed on to be handled by the following 
delegates:

- Kubuntu: Jonathan Ridell (Ridell)
- Mythbuntu: Mario Limonciello (superm1)
- Xubuntu: Code Sommerville (code-sommerville)
- Mozilla Team: Alexander Sack (asac)
- Ubuntu Studio: _MMA_
- Ubuntu Destkop: Sebastien Bacher (seb128)
- Ubuntu Mobile: Oliver Gravert (ogra)
- Ubuntu MID: Loic Minier (lool)
- Ubuntu Server: Scott Kitterman (ScottK)

Packages covered by delegations:
Scott raised the question, what package sets would be covered by delegates. 
After a short discussion, it was agreed on that every delegate should reply to 
this mail with a set of packages to take release responsibility for. In case 
of overlap, motu-release can then trim down the lists, taking over 
coordination of conflicting packages.

Standing freeze exceptions:
To request a standing freeze exception, an email should be sent to the Ubuntu 
MOTU mailing list for discussions. It is granted, once three members of motu-
release have given their ACK.

At around 12.00 UTC, Cesare, Stefan and Luca had to leave, so that quorum was 
no longer guaranteed. The following points where discussed afterwards:

Per-Package delegations:
In case of need, persons requesting per-package delegations should sent a mail 
the MOTU mailing list with the request, so that it can be discussed there.

Diffstat requirements:
Scott raised the point, to get rid of the requirement to add a diffstat.

Bugfix only releases:
Another point Scott raised, was wether bugfix only releases would need freeze 
exceptions as well.

Misc/personal notes:
Luke will be on vacation for the next two weeks.
Stefan will be on vacation for the next week.

The logs can be found at [1], mootbot wasn't used due to technical problems.

Cheers,
   Stefan.
--
[1]: 


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

RE: how to submit a atftp server patch

[Christopher Houdeshell]

You can check Freshmeat
(http://freshmeat.net/projects/atftp/?branch_id=133). To submit a patch -
either get in contact with the maintainer of the package or send a message
to the Ubuntu-patches ML. I would suggest getting the dpkg-source and
applying your patch against it and sending that along with the diff of your
patch. Makes life easier.

Chris.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Nick Weedon
Sent: Monday, September 01, 2008 12:35 AM
To: ubuntu-motu@lists.ubuntu.com
Subject: how to submit a atftp server patch

Hi there,
I am looking to submit a patch for the atftp server and am wondering 
what the process involves (or where i can go to find out).
I also have had no luck at all in trying to find any sort of CVS 
repository for this package.
How do i submit a patch?

Thanks,
Nick Weedon

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Loïc Minier]

On Mon, Sep 01, 2008, Mathias Gug wrote:
> This was indeed suggested at the very beginning of the bug thread [1] by
> using /etc/profile.d/. However it was rejected on the following grounds
> [2]

 I'm not quite sure I agree with the rationale; I agree it's a good
 policy that programs /installed by packages/ must not depend on
 environment variables to get reasonable /defaults/.  However:
 * it's not against policy that programs installed via gems (not
   installed by packages) rely on a specific PATH or LD_LIBRARY_PATH to
   work
 * it's not against policy to setup a system to try to expand its PATH
   to use additional data, as long as using the default PATH wouldn't
   break the system and its packages
 * the rubygems package doesn't require a custom PATH setting to do its
   work (installing gems) -- however you do need special settings to use
   the installed data (gems)
 * Ubuntu went through the hassle of promising that PATH is set in
   exactly one place across the whole system
   ; especially in light of "Ubuntu
   wants to remove /usr/games from the default $PATH" in the above spec,
   it seems that it's a long term desired distro feature to define the
   PATH in a central place for various use cases and this sounds like a
   good use case

 An issue I see with relying on the PATH env var is that its old value
 is in a bunch of running processes; probably not worse than upgrading a
 lib such as libssl and having to restart services to pick it up.


 So I don't know whether it would be hard to implement a
 /etc/environment.d which would be guaranteed to be used in all cases
 where /etc/environment is used, or whether it would be too dangerous to
 update PATH in /etc/environment -- there are certainly implementation
 questions -- but I don't think this should go against policy.

> This is related to section 9.9 of the Debian Policy [3], Environment 
> variables:
>   A program must not depend on environment variables to get reasonable
>   defaults. (That's because these environment variables would have to be
>   set in a system-wide configuration file like /etc/profile, which is not
>   supported by all shells.) 

 Is there any shell which doesn't honor the PATH in /etc/environment?
 If yes, I think it's a bug; if not, we can build on the PATH set in
 this file IMO.

 And even if there were such shells, these shells would simply miss
 gems; the programs installed by packages would still work correctly,
 even commands to add / remove gems.  What might not work are gems
 themselves.

-- 
Loïc Minier

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Stefan Potyra]

Hi Matthias,

On Monday 01 September 2008 20:27:27 Mathias Gug wrote:
> Hi Stefan,
>
> On Mon, Sep 01, 2008 at 08:04:06PM +0200, Stefan Potyra wrote:
> > On Monday 01 September 2008 18:21:53 Mathias Gug wrote:
> > Oh, one thing that hasn't been discussed by motu-release is actually the
> > effect on the passenger package, as posted by the server team meeting
> > minutes.
> >
> > In this regard, I'd like to bring your attention however to [1], without
> > further comments.
> > [1]:  > incoming/passenger-0808222010/passenger-2.0.3/debian/postinst>
>
> While this file is there because it's in the upstream tarball, it isn't
> used. The diff.gz file adds the file
> debian/libapache2-mod-passenger.postinst [2].

phew, that's good news! :)

Maybe you/the packager might want to strip debian out of the upstream tarball 
then?

Cheers,
Stefan.


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Mathias Gug]

Hi Stefan,

On Mon, Sep 01, 2008 at 08:04:06PM +0200, Stefan Potyra wrote:
> On Monday 01 September 2008 18:21:53 Mathias Gug wrote:
> Oh, one thing that hasn't been discussed by motu-release is actually the 
> effect on the passenger package, as posted by the server team meeting minutes.
>
> In this regard, I'd like to bring your attention however to [1], without 
> further comments.
> [1]:  incoming/passenger-0808222010/passenger-2.0.3/debian/postinst>

While this file is there because it's in the upstream tarball, it isn't
used. The diff.gz file adds the file
debian/libapache2-mod-passenger.postinst [2].

[2]: 
http://revu.ubuntuwire.com/revu1-incoming/passenger-0808222010/passenger-2.0.3/debian/libapache2-mod-passenger.postinst

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Stefan Potyra]

Hi,

On Monday 01 September 2008 18:21:53 Mathias Gug wrote:
>
> What goes in /usr/local/ is under the responsibility of the end users.
> It's disappointing if end users install broken versions of things in
> /usr/local, but it's up to them in the end.  They can download and
> install things in /usr/local (via CPAN, PEAR, ./configure; make; make
> install, or any other way) and would run into the same issue mentioned
> above.

yes, but putting stuff there is always an active task of the sysadmin. And a 
sysadmin has very fine granular control when doing so (e.g. she could choose 
to use a different path, that's only visible for one particular service). This 
is imho missing from the approach as seen in the upload. 

Oh, one thing that hasn't been discussed by motu-release is actually the 
effect on the passenger package, as posted by the server team meeting minutes. 
In this regard, I'd like to bring your attention however to [1], without 
further comments.

Finally, whatever MC should choose as resolution, I'd like to add to please do 
it in a short time frame, so that intrepid won't possibly get affected by 
last-minute changes.

Cheers,
Stefan.
--
[1]: 


-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Lucas Nussbaum]

On 01/09/08 at 12:21 -0400, Mathias Gug wrote:
> Hi,
> 
> I'd like to appeal against motu-release decision to revert the
> libgem-ruby upload 1.3.0~RC1really1.2.0-2ubuntu2 based on the following
> reasons:
> 
> On Fri, Aug 29, 2008 at 11:39:52PM +0200, Stefan Potyra wrote:
> > 
> > first off, this was not an easy decision. It didn't happen so far yet, that 
> > motu-release had to decide if an upload should indeed get reverted, and 
> > hence 
> > this decision was done only with consent among all motu-release members. 
> > The 
> > key factor in regards to this decision was if this upload does work towards 
> > making an improvement in regards to the intrepid-release, or if it did in 
> > fact 
> > result in the opposite, hence making it unfit for release.
> > 
> 
> Let me reiterate what the upload was trying to achieve. As outlined in
> [1]:
> 
>   Providing binaries shipped by gems on the default path.
> 
>   In hardy, the end user using a gem (let's say the rails gem) would
>   have to do the following things:
> 
>   1. sudo apt-get install rubygems
>   2. sudo gem install rails
>   3. Modify the default PATH in the environment to include
>   /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the
>   command line.
> 
>   The upload aims at removing step number 3 from the process by symlinking
>   the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/.

The following one-liner installs all gems binaries to /usr/local/bin instead of
/var/lib/gems/1.X/bin. It doesn't use update-alternatives, so the last
installed gem wins (which might be less confusing to our users).

--- a/debian/patches/01_default_gem_path.dpatch
+++ b/debian/patches/01_default_gem_path.dpatch
@@ -5,9 +5,9 @@
 ## DP: Changes the default gem dir from inside the ruby lib to 
/var/lib/gems/{ruby version}
 
 @DPATCH@
-diff -urNad trunk~/lib/rubygems/defaults.rb trunk/lib/rubygems/defaults.rb
 trunk~/lib/rubygems/defaults.rb2008-03-09 12:42:07.0 +0900
-+++ trunk/lib/rubygems/defaults.rb 2008-05-10 16:07:33.0 +0900
+diff -urNad libgems-ruby-1.2.0~/lib/rubygems/defaults.rb 
libgems-ruby-1.2.0/lib/rubygems/defaults.rb
+--- libgems-ruby-1.2.0~/lib/rubygems/defaults.rb   2008-09-01 
19:48:51.0 +0200
 libgems-ruby-1.2.0/lib/rubygems/defaults.rb2008-09-01 
19:49:00.0 +0200
 @@ -7,16 +7,14 @@
  
# Default home directory path to be used if an alternate value is not
@@ -44,7 +44,7 @@ diff -urNad trunk~/lib/rubygems/defaults.rb 
trunk/lib/rubygems/defaults.rb
 -else # generic install
 -  ConfigMap[:bindir]
 -end
-+File.join('/', 'var', 'lib', 'gems', ConfigMap[:ruby_version], 'bin')
++'/usr/local/bin'
end
  
# The default system-wide source info cache directory.

It applies to version 1.2.0-2, and you probably want to apply it to 1.2.0-3 
currently in Debian.

Disclaimer: I didn't test it very carefully.
-- 
| Lucas Nussbaum
| [EMAIL PROTECTED]   http://www.lucas-nussbaum.net/ |
| jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F |


signature.asc
Description: Digital signature
-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Mathias Gug]

Hi Loïc,

On Mon, Sep 01, 2008 at 07:17:29PM +0200, Loïc Minier wrote:
> On Mon, Sep 01, 2008, Mathias Gug wrote:
> >   1. sudo apt-get install rubygems
> >   2. sudo gem install rails
> >   3. Modify the default PATH in the environment to include
> >   /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the
> >   command line.
> >   The upload aims at removing step number 3 from the process by symlinking
> >   the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/.
> 
>  -You certainly considered the following option, but I'm curious about
>  the rationale for excluding it from the implementation.)
> 
>  Why don't you do 3 in place of the admin instead of using /usr/local?
> 
>  If touching /etc/environment is too fragile, could we add some new
>  mechanism to handle default PATH changes (e.g. /etc/environment.d)?
> 
>  For example, libnssmdns mangles /etc/nsswitch.conf to add its entries:
>  this sounds equally intrusive to me.
> 

This was indeed suggested at the very beginning of the bug thread [1] by
using /etc/profile.d/. However it was rejected on the following grounds
[2]:

base-files (4.0.1ubuntu2) hardy; urgency=low

  * Implement LSB-3.1, 16.2 (/etc/profile.d). Addresses LP #102105.
According to Debian policy 9.9 (Environment variables), programs
installed by packages must not depend on environment variables
to get reasonable defaults. Do not use this LSB feature to
set or modify environment variables.

  -- Matthias Klose <[EMAIL PROTECTED]> Wed, 06 Feb 2008 15:27:17 +0100

This is related to section 9.9 of the Debian Policy [3], Environment variables:

  A program must not depend on environment variables to get reasonable
  defaults. (That's because these environment variables would have to be
  set in a system-wide configuration file like /etc/profile, which is not
  supported by all shells.) 

Colin Watson gave other reasons in bug 18808 [4] related to this issue.

[1]: 
https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/7
[2]: 
https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/11
[3]: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.9
[4]: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/18808/comments/1

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Loïc Minier]

On Mon, Sep 01, 2008, Mathias Gug wrote:
>   1. sudo apt-get install rubygems
>   2. sudo gem install rails
>   3. Modify the default PATH in the environment to include
>   /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the
>   command line.
>   The upload aims at removing step number 3 from the process by symlinking
>   the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/.

 -You certainly considered the following option, but I'm curious about
 the rationale for excluding it from the implementation.)

 Why don't you do 3 in place of the admin instead of using /usr/local?

 If touching /etc/environment is too fragile, could we add some new
 mechanism to handle default PATH changes (e.g. /etc/environment.d)?

 For example, libnssmdns mangles /etc/nsswitch.conf to add its entries:
 this sounds equally intrusive to me.

-- 
Loïc Minier

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Scott Kitterman]

Another issue that is not addressed in your response is the version naming.

You uploaded something called a release candidate that was not, in fact a 
release candidate.  Based on the dialogue in the bug, it seems clear to me 
that you knew it was a Git snapshot.  Additionally, it appears to me that the 
upstream code for the upload was taken from an untrusted source (a PPA 
maintained by a non-developer) and not from upstream.

Personally, I find both of these issues severe problems.  

Since the upload was reverted I learned that 1.3 will provide the ability to 
do unpriviledged installs of Gems in user's home directories.  I can see this 
having some potential to mitigate some concerns that people have expressed.  

Aside from the redesign effort that has proven controversial, I'd be willing 
to consider an FFe for 1.3 based on the Debian packaging for this reason.  
It'd need to be evaluated for maturity and all the usual things, but I think 
it's worth considering.

Additionally, in the case of Python ez_install (of the ones you mentioned, 
that's the one I'm most familiar with) it's use is highly discouraged in 
Debian and it has been patched to be aware when there is a system installed 
version of a module already present and to not over-ride it with installing 
it's own in /usr/local.  I think this is a substantially more reasonable 
approach than the one that was removed.

Scott K

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

Re: motu-release will revert libgems-ruby to the old state.

[Mathias Gug]

Hi,

I'd like to appeal against motu-release decision to revert the
libgem-ruby upload 1.3.0~RC1really1.2.0-2ubuntu2 based on the following
reasons:

On Fri, Aug 29, 2008 at 11:39:52PM +0200, Stefan Potyra wrote:
> 
> first off, this was not an easy decision. It didn't happen so far yet, that 
> motu-release had to decide if an upload should indeed get reverted, and hence 
> this decision was done only with consent among all motu-release members. The 
> key factor in regards to this decision was if this upload does work towards 
> making an improvement in regards to the intrepid-release, or if it did in 
> fact 
> result in the opposite, hence making it unfit for release.
> 

Let me reiterate what the upload was trying to achieve. As outlined in
[1]:

  Providing binaries shipped by gems on the default path.

  In hardy, the end user using a gem (let's say the rails gem) would
  have to do the following things:

  1. sudo apt-get install rubygems
  2. sudo gem install rails
  3. Modify the default PATH in the environment to include
  /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the
  command line.

  The upload aims at removing step number 3 from the process by symlinking
  the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/.

[1]: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026240.html


> In order to find out, if 1) was a possible way, the possible regressions of 
> gem handling in the change were examined compared to the previous package. 
> This lead to the following findings:
> 
> Executables of gems get symlinked via the alternatives mechanism to 
> /usr/local/bin.
> 
> Using the alternatives mechanism was considered inappropriate and counter-
> intuitive.
> 
> /usr/local/bin is the first entry in $PATH, so executables installed there 
> override any executables installed from Debian/Ubuntu packages.
> 
> As a result, this can lead to problems in case there is a name clash between 
> a 
> binary shipped from an Ubuntu package and a binary installed from a gem. 
> Among 
> the problems of non-determinism and possible failing behaviour of Ubuntu-
> packages in case such a name-clash occurs, this situation is both hard to 
> detect for a user/sysadmin, but also hard to fix without modifying 
> /usr/local/bin in the first place (which however counter-acts the idea of the 
> new gem handling).
>

According to the FHS [2]:

  The /usr/local hierarchy is for use by the system administrator when
  installing software locally.

[2]: http://pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY

The reason why /usr/local/bin is first on the path is that sys admin
choices for the local system are more important then the system choices.
When an end user uses the gem command to install a gem he wants to
install something that is not available in the archive. Lucas Nussbaum
stated something similar in the bug thread [3]:

> That's one problem. gem installed systems would then override apt
> installed systems and I'm not sure that is where we want to go.

I think it is where we want to go: if an admin installs stuff manually,
that's probably because the things provided by the distro don't suit his
needs. So the distro stuff should be overriden by default.

[3]: 
https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/145267/comments/25

What goes in /usr/local/ is under the responsibility of the end users.
It's disappointing if end users install broken versions of things in
/usr/local, but it's up to them in the end.  They can download and
install things in /usr/local (via CPAN, PEAR, ./configure; make; make
install, or any other way) and would run into the same issue mentioned
above.

Trying to block people from installing 3rd party software isn't the
answer. We cannot protect an admin (or user) from themselves, so we
better _help_ them as much as possible.

As pointed by Steve Langasek [4], there are other packages in the
archive that facilitate the management of /usr/local/.  Given the
evidence of other /usr/local-helper tools, why should gems not be
allowed to use /usr/local ?

[4]: 
https://bugs.launchpad.net/ubuntu/+source/libgems-ruby/+bug/262063/comments/4


> Especially the possible security problems arising from this approach (the 
> mail 
> from Stephan Hermann with imagemagick shipped by a gem served as an example 
> in 
> the motu-release discussion, especially since imagemagick is often called by 
> web applications), was considered a critical enough issue to eliminate option 
> 1).
>

Agreed. To be more precise imagemagick was installing itself in
/usr/lib/ bypassing the gem infrastructure and overriding system
libraries. If a gem install destroys a system, that's still the end
user's fault. It'd do that if they ran the Ubuntu gem installer or the
from-source gem installer. The upload doesn't make things worse nor can
protect against it.


> Another non-technical concern was also raised against option 1): The advice 
> of 
>

Re: how to submit a atftp server patch

[Daniel Holbach]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Nick Weedon schrieb:
> I am looking to submit a patch for the atftp server and am wondering 
> what the process involves (or where i can go to find out).
> I also have had no luck at all in trying to find any sort of CVS 
> repository for this package.
> How do i submit a patch?

https://wiki.ubuntu.com/SponsorshipProcess should have the relevant
information on hwo to get the patch included in Ubuntu,
https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff how to get it
into the preferred format for patches.

Have a nice day,
 Daniel
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIu5/bRjrlnQWd1esRAjc6AJ4zrX1nhJE9Is+fRFyU+3jLjuag1wCeLuTy
pDumLg0iUInA0tjUvmPS2ZI=
=CaTn
-END PGP SIGNATURE-

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu

how to submit a atftp server patch

[Nick Weedon]

Hi there,
I am looking to submit a patch for the atftp server and am wondering 
what the process involves (or where i can go to find out).
I also have had no luck at all in trying to find any sort of CVS 
repository for this package.
How do i submit a patch?

Thanks,
Nick Weedon

-- 
Ubuntu-motu mailing list
Ubuntu-motu@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu