Re: Brainstorming for UDS-P
Scott Kitterman [2011-09-28 1:33 -0400]: > Will we sync from Testing or Unstable this cycle? My feeling is that syncing from testing served us well for the last LTS, and Debian is not in a freeze which would force unstable to calm down, so I would go again for autosyncing from testing, and letting developers manually sync from unstable at will. Now that this is by and large a self-service, this should work even better than in lucid. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Brainstorming for UDS-P
On Friday, September 23, 2011 09:56:17 PM Allison Randal wrote: > Hi all, > > While we're all in the final preparations for Oneiric, it's round about > that time in the cycle to start thinking about plans for the next cycle. > What's on your mind? > Will we sync from Testing or Unstable this cycle? Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Tue, Sep 27, 2011 at 11:03:55AM -0700, Matt Alexander wrote: > On Tue, Sep 27, 2011 at 8:06 AM, Colin Watson wrote: > > On Tue, Sep 27, 2011 at 06:12:24AM -0700, Matt Alexander wrote: > > > On Tue, Sep 27, 2011 at 1:28 AM, Colin Watson > > wrote: > > > > I'm afraid this is backwards. If you want to go and hunt down packages > > > > that rely on those global static users and get their maintainers > > > > (preferably in Debian) to work on a migration to dynamically-allocated > > > > system users, perhaps after that it would be worth removing the global > > > > static users. Until then, they need to stay where they are. > > > > > > Seems like detecting broken packages from system changes would already be > > > part of the Ubuntu qual. process. > > > > It's always better to not break things in the first place. > > Sometimes breaking things is necessary for forward progress. Certainly, in general. This isn't one of those times. -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Brainstorming for UDS-P
On Sep 27, 2011, at 01:02 AM, Scott Kitterman wrote: >If you aim your minimum Python version at 2.6, it's not that hard to write >code that works with both python and python3. If you want a "P" target for >Python3, I'd suggest getting Ubuntu custom code working in either so that we >can through the switch when ready would be a really good goal. If we drop 2.6 for P, then 2.7 will be the minimum Python, but in any event, I agree with you. I have to admit that after thinking about this a lot, I am torn between wanting to aggressively lead on the migration to Python 3, and wanting to have a really stable P-series with no ftbfs or other lurking problems in our Python 2 stack. My conservative side is peeking out. :) To the extent that we can do both, great. I will put this on our agenda for UDS-P and I'm sure we'll get a lively and diverse discussion about our short and long term plans here. -Barry signature.asc Description: PGP signature -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Brainstorming for UDS-P
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 23 Sep 2011 21:56:17 +0100 Allison Randal wrote: > Hi all, > > While we're all in the final preparations for Oneiric, it's round about > that time in the cycle to start thinking about plans for the next cycle. > What's on your mind? > > Allison > As a member of the Accessibility team, a release where accessibility actually gets to be working through most of the cycle, rather than the few days before final freeze. We hear that accessibility is very important every UDS, but we really can't use it until after the beta2 releases. - -- Charlie Kravetz Linux Registered User Number 425914 [http://counter.li.org/] Never let anyone steal your DREAM. [http://keepingdreams.com] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJOghJCAAoJEFNEIRz9dxbAsIUH/ji6BGqjRyzi3JW4otIIJCqc 1MOoyKvg1r26K2WR/BQ47yY8ex+Syxb28LINNyVPp1pWsJ+KRN9eDz8K8a0VFb12 DWaTVAnid0pY19kuvFPthE53g3zcpIqbHJ3JUDd9BjBFjR1XHPyw8vFz9Zh2cLTw Sr3lijUA+xm9yw7D55uRVPmarvHSdGbgnuuoAsnHfs67SJ65cfbRIzGuVh4KMjhC a27w6owyRNnRp0AF3dBJXx7ZdcEFnriXjIoibEHFqvtcX1EB4jPCzsKDc+qMq6Bg VyRloB6719V4pncjyYdtrY7G0CBcPDTbLcGHqspmwbIGuY5mLP6oD6mesH9mitQ= =eOT6 -END PGP SIGNATURE- -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Tue, Sep 27, 2011 at 8:06 AM, Colin Watson wrote: > On Tue, Sep 27, 2011 at 06:12:24AM -0700, Matt Alexander wrote: > > On Tue, Sep 27, 2011 at 1:28 AM, Colin Watson > wrote: > > > I'm afraid this is backwards. If you want to go and hunt down packages > > > that rely on those global static users and get their maintainers > > > (preferably in Debian) to work on a migration to dynamically-allocated > > > system users, perhaps after that it would be worth removing the global > > > static users. Until then, they need to stay where they are. > > > > Seems like detecting broken packages from system changes would already be > > part of the Ubuntu qual. process. > > It's always better to not break things in the first place. > Sometimes breaking things is necessary for forward progress. > > > But, OK, I'll setup a box, remove users, and run a script that > > installs/uninstalls everything one by one from the default repos and > > makes note of any packages that break. I'll then open bugs with the > > Debian maintainers of those packages to modify their install/uninstall > > script. > > Sounds great, thanks! > > Note that I will not remove these users in any event: > > root (obviously) > daemon (required by LSB) > bin (required by LSB) > sync (specialised, described in users-and-groups documentation) > games (shared among many packages, likely to be too disruptive) > man (man-db is widely installed anyway so any gain is not worth it) > mail (often has many non-system-owned files, too disruptive) > www-data (often has many non-system-owned files, too disruptive) > nobody (obviously) > > You can refer to /usr/share/doc/base-passwd/users-and-groups.txt.gz for > what's known about various system users. > > Great info. Thanks! -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Brainstorming for UDS-P
On Friday, September 23, 2011 09:56:17 PM Allison Randal wrote: > Hi all, > > While we're all in the final preparations for Oneiric, it's round about > that time in the cycle to start thinking about plans for the next cycle. > What's on your mind? Having a release where the release team wasn't flooded with last minute feature freeze exception requests from Canonical projets like Ubuntuone and Ayatana. Scott K -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Tue, Sep 27, 2011 at 06:12:24AM -0700, Matt Alexander wrote: > On Tue, Sep 27, 2011 at 1:28 AM, Colin Watson wrote: > > I'm afraid this is backwards. If you want to go and hunt down packages > > that rely on those global static users and get their maintainers > > (preferably in Debian) to work on a migration to dynamically-allocated > > system users, perhaps after that it would be worth removing the global > > static users. Until then, they need to stay where they are. > > Seems like detecting broken packages from system changes would already be > part of the Ubuntu qual. process. It's always better to not break things in the first place. > But, OK, I'll setup a box, remove users, and run a script that > installs/uninstalls everything one by one from the default repos and > makes note of any packages that break. I'll then open bugs with the > Debian maintainers of those packages to modify their install/uninstall > script. Sounds great, thanks! Note that I will not remove these users in any event: root (obviously) daemon (required by LSB) bin (required by LSB) sync (specialised, described in users-and-groups documentation) games (shared among many packages, likely to be too disruptive) man (man-db is widely installed anyway so any gain is not worth it) mail (often has many non-system-owned files, too disruptive) www-data (often has many non-system-owned files, too disruptive) nobody (obviously) You can refer to /usr/share/doc/base-passwd/users-and-groups.txt.gz for what's known about various system users. -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Tue, Sep 27, 2011 at 1:28 AM, Colin Watson wrote: > On Mon, Sep 26, 2011 at 03:05:58PM -0700, Matt Alexander wrote: > > On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson > wrote: > > > For almost everything, and certainly for the overwhelming majority of > > > new entries, we do exactly as you say. However, I (as base-passwd > > > maintainer) will not remove entries from the global static list unless > > > there is a very compelling reason to do so beyond cleaning up cruft; > > > packages are entitled to assume that they are present without declaring > > > any particular dependency and there's no reasonable way to know what > > > removing such entries would break. > > > > I end up modifying the passwd/group files on my computers for auditing > > purposes and to ensure that the only accounts on the system are required > > accounts. Removing cruft seems like a perfectly valid reason. In 10 > years > > will Ubuntu still have a uucp user and a news user and an irc user? > Seems > > silly. Let's clean things up and keep it to just the accounts that must > be > > there. We can then easily fix packages that wrongly assumed that their > > particular user would be always be there. > > I'm afraid this is backwards. If you want to go and hunt down packages > that rely on those global static users and get their maintainers > (preferably in Debian) to work on a migration to dynamically-allocated > system users, perhaps after that it would be worth removing the global > static users. Until then, they need to stay where they are. > Seems like detecting broken packages from system changes would already be part of the Ubuntu qual. process. But, OK, I'll setup a box, remove users, and run a script that installs/uninstalls everything one by one from the default repos and makes note of any packages that break. I'll then open bugs with the Debian maintainers of those packages to modify their install/uninstall script. -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Mon, Sep 26, 2011 at 3:28 PM, Bear Giles wrote: > Matt, why not create a hardening package? Just write a script that scrubs > /etc/passwd and /etc/group and then create a small package that runs it once > (in postinst). I would also install it in, e.g., /etc/cron.daily so it's > rerun periodically. I haven't kept track of existing hardening packages > but I wouldn't be surprised if somebody else has already done this. I've used Bastille in the past, for example, but I think most users would prefer that Ubuntu is already hardened by default. > > P.S., if you want to have fun with package installation failing try > mounting /tmp as noexec. It's easy to fix - if you know how to do it. If not > you'll bang your head against the wall for hours while you're trying to > figure out why installations are failing. > > bear > > > On Mon, Sep 26, 2011 at 4:05 PM, Matt Alexander < > ubuntu@mattalexander.com> wrote: > >> On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson wrote: >> >>> On Thu, Sep 22, 2011 at 04:33:00PM -0700, Matt Alexander wrote: >>> > Would it be possible to remove the vast majority of users from >>> /etc/passwd >>> > and instead rely on the application being installed to create the >>> specific >>> > user if needed? Most of the users appear to be historical remnants >>> that >>> > have been carried over from release to release. >>> >>> For almost everything, and certainly for the overwhelming majority of >>> new entries, we do exactly as you say. However, I (as base-passwd >>> maintainer) will not remove entries from the global static list unless >>> there is a very compelling reason to do so beyond cleaning up cruft; >>> packages are entitled to assume that they are present without declaring >>> any particular dependency and there's no reasonable way to know what >>> removing such entries would break. >>> >> >> I end up modifying the passwd/group files on my computers for auditing >> purposes and to ensure that the only accounts on the system are required >> accounts. Removing cruft seems like a perfectly valid reason. In 10 years >> will Ubuntu still have a uucp user and a news user and an irc user? Seems >> silly. Let's clean things up and keep it to just the accounts that must be >> there. We can then easily fix packages that wrongly assumed that their >> particular user would be always be there. >> >> >> >>> >>> In any case, there are only 18 entries in the global static list >>> (/usr/share/base-passwd/passwd.master), and even without thinking about >>> it too hard I know that at least four or five are still in use and >>> probably more, so there's not that much to be gained. All other system >>> entries in the passwd file are created dynamically by applications. >>> >>> Since I took over base-passwd in 2002, I have added no new global static >>> users and only two new global static groups, the last of which was in >>> 2004. >>> >>> > In addition, for users in the passwd file that must be there, could you >>> > please set their shell to /usr/sbin/nologin? >>> >>> Yes, I would like to do this eventually >>> (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=274229). However, >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184979 has to be fixed >>> first, otherwise everyone will have their upgrades interrupted by a >>> non-debconf prompt. I haven't had time to work on #184979 in quite a >>> number of years, and to the best of my knowledge nobody has ever >>> contributed a patch for it; I'd be happy to review one if somebody did >>> so. >>> >>> The one wart here is that using /usr/sbin/nologin will break anything >>> that runs commands as one of those users using the 'su' command. This >>> isn't theoretical; one of my packages used to do so some years ago, >>> although it now uses start-stop-daemon instead. The breakage is >>> probably worthwhile, I'll admit, but I can't say that there would be no >>> problems with changing those users' shell since there's been such a long >>> time for packages to get used to it being /bin/sh. >>> >>> Cheers, >>> >>> -- >>> Colin Watson [cjwat...@ubuntu.com] >>> >>> -- >>> Ubuntu-devel-discuss mailing list >>> Ubuntu-devel-discuss@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >>> >> >> >> -- >> Ubuntu-devel-discuss mailing list >> Ubuntu-devel-discuss@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss >> >> > -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: libguile 2.0 packages for ubuntu?
On Tue, Sep 27, 2011 at 01:36:25PM +0200, Reinhold Kainhofer wrote: > I'm one of the developers or LilyPond (the GNU music notation application), > and we heavily depend on guile (actually, large parts of lilypond are written > in guile). > > Now, in February, guile 2.0 was released, which has a much improved garbage > collection (based on libgc), proper unicode support, compiled code and is > MUCH > faster. > So, we'd like to finally switch to guile 2.0 from guile 1.8. > > Unfortunately, we depend on ubuntu packages of our dependencies (for our > documentation writers and the bug squad, which we cannot require to build > external dependencies manually; we even provide a custom ubuntu flavor called > lilydev with all the dependencies in place). So, we cannot switch to guile > 2.0 > until there are ubuntu packages available. > > Do you have any estimate when guile 2.0 packages will finally be available > for > ubuntu, so that we can start the switch? We don't have any guile experts in Ubuntu that I'm aware of, so we're ourselves dependent on Debian for this. Rob Browning appears to be working on it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615479 According to that bug log, he's blocked on a problem with libgc. Perhaps somebody knowledgeable could help him out? Regards, -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
libguile 2.0 packages for ubuntu?
Dear Ubuntu developers, I'm one of the developers or LilyPond (the GNU music notation application), and we heavily depend on guile (actually, large parts of lilypond are written in guile). Now, in February, guile 2.0 was released, which has a much improved garbage collection (based on libgc), proper unicode support, compiled code and is MUCH faster. So, we'd like to finally switch to guile 2.0 from guile 1.8. Unfortunately, we depend on ubuntu packages of our dependencies (for our documentation writers and the bug squad, which we cannot require to build external dependencies manually; we even provide a custom ubuntu flavor called lilydev with all the dependencies in place). So, we cannot switch to guile 2.0 until there are ubuntu packages available. Do you have any estimate when guile 2.0 packages will finally be available for ubuntu, so that we can start the switch? Cheers, Reinhold PS: We just got a message from a packages of another distribution, who was quite frustrated that lilypond still requires an outdated library, where the latest stable release has been available for more than half a year. -- -- Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/ * Financial & Actuarial Math., Vienna Univ. of Technology, Austria * http://www.fam.tuwien.ac.at/, DVR: 0005886 * LilyPond, Music typesetting, http://www.lilypond.org -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: project ideas ubuntu
Hello Komputes, Thanks for your reply. On Tue, Sep 27, 2011 at 12:13 AM, komputes wrote: > Gaurav Saxena wrote on 25/09/11 18:08: > > > hello all i want to do a my fina; year projrct on ubuntu.. please > > > help me with some ideas realted to ubuntu on which i can work... > > Hi Gaurav, > > I am extremely happy any time a developer asks for what to do to help > Ubuntu. I have many project ideas that I have published on my wiki page:s > very great indeed. > > https://wiki.ubuntu.com/komputes/Projects Thats very great indeed. I have gone through the ideas, and I have decided my topic of project to be writing a system restore for ubuntu. I think that will be suitable for me. If that has already been implemented please inform me so that I can start working on the project. > > > Feel free to get in touch with me by email or on IRC should you be > interested in one of these ideas. > > Fore more info on how you can help with Ubuntu check out: > https://wiki.ubuntu.com/komputes/HowToHelpUbuntu > > Cheers, > > -komputes > > (]( -. .- )[) > > Could you please provide me some pointers related to how to start with such an application, and the ubuntu way of coding. That will be really great. -- Thanks and Regards , Gaurav -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
Re: Cleaning up the users and locking down the shells in /etc/passwd
On Mon, Sep 26, 2011 at 03:05:58PM -0700, Matt Alexander wrote: > On Sat, Sep 24, 2011 at 9:48 AM, Colin Watson wrote: > > For almost everything, and certainly for the overwhelming majority of > > new entries, we do exactly as you say. However, I (as base-passwd > > maintainer) will not remove entries from the global static list unless > > there is a very compelling reason to do so beyond cleaning up cruft; > > packages are entitled to assume that they are present without declaring > > any particular dependency and there's no reasonable way to know what > > removing such entries would break. > > I end up modifying the passwd/group files on my computers for auditing > purposes and to ensure that the only accounts on the system are required > accounts. Removing cruft seems like a perfectly valid reason. In 10 years > will Ubuntu still have a uucp user and a news user and an irc user? Seems > silly. Let's clean things up and keep it to just the accounts that must be > there. We can then easily fix packages that wrongly assumed that their > particular user would be always be there. I'm afraid this is backwards. If you want to go and hunt down packages that rely on those global static users and get their maintainers (preferably in Debian) to work on a migration to dynamically-allocated system users, perhaps after that it would be worth removing the global static users. Until then, they need to stay where they are. Regards, -- Colin Watson [cjwat...@ubuntu.com] -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
