gmane.linux.ubuntu.devel

Re: feisty still in the archive?

Martin Pitt — 2008-12-03T14:48:44

Dustin Kirkland [2008-12-02 22:24 -0600]: I can only recommend to use debmirror and only pull particular releases and architectures, instead of sucking down the entire thing. Martin

Re: libtool updates

Alexander Sack — 2008-12-03T12:40:49

So I guess cdbs should get a DEB_AUTO_UPDATE_AUTORECONF hint. Patch for discussion: diff -Nru cdbs-0.4.52ubuntu7/1/class/autotools-files.mk.in cdbs-0.4.52ubuntu8/1/class/autotools-files.mk.in --- cdbs-0.4.52ubuntu7/1/class/autotools-files.mk.in2008-08-29 15:07:49.000000000 +0200 +++ cdbs-0.4.52ubuntu8/1/class/autotools-files.mk.in2008-12-03 13:30:10.000000000 +0100 < at >< at > -44,6 +44,24 < at >< at > endif endif +ifneq ($(DEB_AUTO_UPDATE_AUTORECONF), ) +ifneq ($(DEB_AUTO_UPDATE_ACLOCAL), ) +$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_ACLOCAL) +endif +ifneq ($(DEB_AUTO_UPDATE_AUTOCONF), ) +$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_AUTOCONF) +endif +ifneq ($(DEB_AUTO_UPDATE_AUTOHEADERS), ) +$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_AUTOHEADERS) +endif +ifneq ($(DEB_AUTO_UPDATE_AUTOMAKE), ) +$(warning WARNING: DEB_AUTO_UPDATE_AUTORECONF conflicts with DEB_AUTO_UPDATE_LIBTOOL) +endif +ifneq ($(DEB_AUTO_UPDATE_LIBTOOL),

Re: Server Team 20081202 meeting minutes

Reinhard Tartler — 2008-12-03T07:34:30

filed as #304010

feisty still in the archive?

Dustin Kirkland — 2008-12-03T04:24:36

I just noticed that the filesystem serving my local mirror of the Ubuntu archive is full. In looking for a little more disk space, I see that the feisty deb's are still in the archive. Out of curiosity, are these to be removed soon?

Re: libtool updates

James Westby — 2008-12-02T20:21:44

Thanks I'm happy to use this rule for now and to learn about the other cases in the future. I was asking this as I expected the answer above, and as cdbs provides these than a method to run autoreconf, I assume that specifying e.g. just "DEB_AUTO_UPDATE_LIBTOOL = pre" is going to hit the same sort of problems. Therefore it seems like specifying all of them, or adding a makefile rule to actually run "autoreconf" would be the best way to handle it. Maybe there is a subtlety I am missing though. Thanks, James

Re: libtool updates

Steve Langasek — 2008-12-02T20:11:21

Calling libtoolize on its own is always wrong because this can result in version skew between ltmain.sh and (aclocal.m4/configure). Calling automake on its own is always wrong because this can result in version skew between **/Makefile.in and (aclocal.m4/configure). Both of these issues can be addressed by calling "autoreconf" instead. There are other combinations that are "safe" (libtoolize+aclocal+autoconf w/o automake; automake+aclocal+autoconf w/o libtoolize), but distinguishing the safe cases from the unsafe ones requires finer knowledge of autotools workings than we can probably expect most developers to retain, so as a general rule, using "autoreconf" is probably best. That probably depends on whether you have a reason in that package to modify any of the other autotools input files?

Re: libtool updates

James Westby — 2008-12-02T12:08:00

Hi Scott, Thanks for this information. I would like to clarify about what this call should replace. I assume it replaces calling autoreconf with any other arguments, and indeed calling all the scripts individually, is that right? Should we do this instead of just calling libtoolize without auto*? What about automake but none of the others? You mention cdbs, is the correct thing to do with that to always specify all DEB_AUTO_UPDATE_* or none of them? Failures caused by this are easy to solve, but I'm always unsure if I am solving it in the correct manner, or whether it will just break again soon. Knowing what is correct also makes it a lot easier to take these patches to Debian. Thanks, James

If you REALLY want to share a taxi...

Daniel Holbach — 2008-12-02T07:40:19

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ...please mention WHEN you arrive and WHERE! There are a lot of entries with * no data about the arrival departure at all * no information if you’re going to land at San Jose or San Francisco Another minor point is that everybody uses a different format for specifying date and time, which makes it very hard to spot who arrives when. (It’s probably just me, but I prefer something like "2008-09-12 15:45" ... local time.) I sorted https://wiki.ubuntu.com/UDSJaunty/Attendees and tried to make things easier to spot. Please update your information... if you really want to share a taxi at UDS. Have a nice day, Daniel - -- My 5 today: #278418 (human-icon-theme), #275989 (silc-toolkit), #304105 (jcc), #303783 (openal-soft), #303916 (nginx) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkk05mMACgkQRjrlnQ

Re: armel architecture info wanted

Oliver Grawert — 2008-11-29T14:01:33

armel architecture info wanted

Morten Kjeldgaard — 2008-11-29T13:54:19

Hi, Will someone with access to a machine running the armel platform please run the following commands: touch foo.c gcc -E -dM foo.c ... and post the output here? (Or perhaps even better, on the Wiki, where similar information from other platforms could be added). Thanks, Morten

The Mono 2.0 transition [Phase 1 complete: core stack]

Jo Shields — 2008-11-28T00:17:40

Re: /etc/motd template

Fabian Rodriguez — 2008-11-27T16:03:43

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I got this answer on our side (Canonical) from our legal counsel (Amanda Brock). I had ccd here on my previous post. "Wording is there for legal purposes and should remain. Warranty refers to the applicable statutory warrantie etc s. Please do not remove." My messages here are moderated so I may not be able to follow up on any discussion on the list itself. Hoping that helps. Cheers, Fabian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: PGP/Mime available upon request Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIcBAEBAgAGBQJJLsTaAAoJEFQP0XBCvjQJ+NQQAJu+jpoq+LU4UGTFoqcc/fCl Nmh320JdaHA5q3wMhjJzacBeJV9S112gXPWE11PMfgJBceSjKoHBjl+k57YvCFtU 06timrwlsqfUm9lrwZWWkmux6zynoTl34WgEmusyw2wSVNh08Ng/P4/uSkv6at9B k3yRv7eI3oYGPhlTt0AOVJmaPsEJEfVgsSCPXJV/i5ELdMagYOmBvYftdSTfXU5D Xl2GZd4q+LgSMqh6B3IzqoEk8SIdfWCYVUHCSVnG+AqVebYzxuUFy8bh2RIM48G9 TGeKYC5Ew5DMSzcx7lMzj1hfeGDG65eOa3M/gQfYoLbF1v+1k16f+DjREmHVxwV6 m+b2Ka87jMR719Y

Re: Disclaimer

Christopher Armstrong — 2008-11-27T16:10:09

On Thu, Nov 27, 2008 at 10:55 AM, Amanda Brock canonical.com> wrote: I think this is kind of a weak argument when we *don't* display this information on graphical logins. What's so special about a login, that it requires the display of this legal information? And why is a textual login *particularly* special, compared to a GUI login?

Re: Disclaimer

Martin Pitt — 2008-11-27T21:12:27

Matthew East [2008-11-27 20:50 +0000]: I fully agree, with my admittedly naive and ignorant user hat on. To you lawyers it might come across rude and surprising, but in fact usually when I log into a remote system, the first thing that I want to do and chek is _not_ reading licenses and usage privileges. As long as I can run it from my ssh session, I don't care about legalese. :-) And if I can't, well, then I can still read error messages and copyright files to figure it out. However, in its current form I agree that motd is just rather uninteresting. For one it's boilerplate, and also I guess few admins will actually update it everytime they actually install a piece of proprietary software. Martin

Re: Disclaimer

Matthew East — 2008-11-27T20:50:51

I got thinking about this distinction a bit further, looked into some basic software law and read the GPL properly. What I said in the paragraph above isn't right - our licences do in fact grant permission to use software, as well as to redistribute it. Doh. The point about how best to communicate whatever terms of use we seek to impose for using Ubuntu is still an interesting one, and I still think the MOTD is not the best place.

Re: Disclaimer

Matthew East — 2008-11-27T18:56:37

Hi Amanda, On Thu, Nov 27, 2008 at 3:55 PM, Amanda Brock canonical.com> wrote: Pleased to make your acquaintance - I'm also a lawyer in London although my involvement in Ubuntu is purely voluntary. I'm posting again on this subject because I'm genuinely interested in the way in which Ubuntu treats its legal relationships with users and distributors. I haven't researched it at all and am just posting my personal thoughts. In the jurisdiction where I work (England & Wales), warranties are only implied by statutes where there is a contract. I can't think of any way that a contract could form between a user on the one hand, and Ubuntu (which doesn't exist as a legal entity), Canonical or the Ubuntu Foundation on the other hand. This is because a user isn't giving any consideration in return for the product (because it is free). If that's right, then the exclusion of warranties is not genuinely necessary. Do you disagree with that analysis? I can't say of course whether other jurisdictions are

Disclaimer

Amanda Brock — 2008-11-27T15:55:06

Hi there Wording is there for legal purposes and should remain. Warranty refers to the applicable statutory warrantie etc s. Please do not remove. Kat Kinnie in marketing owns this and I have ccd her. With kind regards Amanda AmandaBrock Solicitor / General Counsel Canonical 27th Floor, Millbank Tower, 21-24 Millbank, London SW1P 4QP +44(0)2076302446 Ubuntu - Linux for human beings Fabian Rodriguez wrote:

Re: /etc/motd template

Fabian Rodriguez — 2008-11-27T13:49:06

Re: /etc/motd template

Matthew East — 2008-11-27T12:07:23

Hi, On Thu, Nov 20, 2008 at 3:49 PM, Dustin Kirkland ubuntu.com> wrote: I don't think the "no warranty" paragraph is either necessary or useful. In fact, it's always had a negative effect on me, especially the use of capital letters. As for the "free software" paragraph, It's quite nice to tell users that Ubuntu is free software, but we do that on our website already and in various other places. Those logging in to Ubuntu on the command line already know it. It's not really helpful to tell ordinary users who are just logging in what the distribution terms of the software are, because logging in has nothing to do with distributing the software.

Foundations Team Weekly Summary, 2008-11-26

Robbie Williamson — 2008-11-26T17:52:27

== Apologies == * EvanDandrea - vacation * LarsWirzenius - vacation * ScottJamesRemnant - vacation == Activity reports == === Colin Watson === * Jaunty Alpha 1: * Fixed some dmraid issues in hw-detect. Later, realised that the same bug affected four other installer components (base-installer, grub-installer, os-prober, and partman-base), and fixed them all. Filed dmraid #300825 about the general issue. * Tracked down and fixed udev #300426. * Basic smoke-testing and release. * ARM porting assistance: * No-change rebuilds: contact-lookup-applet, foomatic-filters * lynx-cur build-dependency adjustment so that it can build now that it needs to be in main. * Fixed misbuilt libtool on armel (noticed while investigating dictd build failure; filed as #299931). * Sent patch series to kernel-team< at > to add d-i modules for armel. * Some fiddling with the d-i build system, but it won't quite work yet. * Merges: * Finished debian-installer merge. * installation-guide, klibc, network-console,

Re: pbuilder-satisfydepends-dummy thinks libmilter-dev is avirtualpackage

Alban Deniz — 2008-11-26T01:31:36

Thanks, that solved the problem. Thanks again. Okay. I'll switch to that list, thanks. --Alban