Re: Upstart
1. Why does /lib/init/upstart-job direct us to use service rather than initctl? Because /usr/sbin/service can handle the start/stop/restart/status actions of both traditional System V init scripts in /etc/init.d as well as Upstart scripts in /etc/init. It's intended to be one-stop-shopping for managing services in either /etc/init.d or /etc/init. Many thanks for the explanation. 999. Could initctl be made to recognize, for example, both avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare but it happens - and type stop av//tab//, I end up with stop avahi-daemon.conf which, after pressing //enter// results in an unknown job message.) As answered above, that's service(8)'s job ;-) Perhaps that it is service's job, but it is also initctl's; and without, bash_completion, neither can distinguish between avahi-daemon and avahi-daemon.conf. -- 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
Package version numbers in names
This question has been floating in the back of my mind for a while, and a bug I ran across recently brought it forward. What is the official policy for including version numbers in the package name? This is the way I understand it: In a normal scenario, for a library X, we would have the package libX. When a new version of the lib is released upstream, the new version gets packaged, and the version field of the package gets bumped appropriately. In certain cases where we want to have two versions available in the repos at the same time, we have libX1.0 and libX2.0, which are managed appropriately. The old libX becomes an empty transitional package which depends on the desired default (either libX1.0 or libX2.0). That is how I had originally imagined it must work, but given the way certain packages (in main) have been organized I must be missing something. I have briefly browsed the Ubuntu Policy Manual and found nothing pertinent. Could someone clarify please? Thanks, Evan -- 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: Upstart
999. Could initctl be made to recognize, for example, both
avahi-daemon and avahi-daemon.conf? (If I am in /etc/init - it is rare
but it happens - and type stop av//tab//, I end up with stop
avahi-daemon.conf which, after pressing //enter// results in an
unknown job message.)
That sounds like the lack of a specialised bash-completion function?
This seems to do the job (except for completions of arguments for --dest):
--8---cut here---start-8---
_stop()
{
local cur
COMPREPLY=()
cur=${COMP_WORDS[COMP_CWORD]}
case $cur in
-*)
COMPREPLY=( $( compgen -W '-n --no-wait --system --dest -q
--quiet -v --verbose --help --version' -- $cur ) )
;;
*)
COMPREPLY=( $(initctl list| awk /^$cur/ {print \$1} ) )
;;
esac
return 0
}
complete -F _stop stop
--8---cut here---end---8---
It works perfectly, thanks. I have never used bash_completion before;
it completes avahi-daemon no matter which dir I am in.
--
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: Package version numbers in names
On Tue, 2010-03-09 at 10:36 -0500, Evan wrote: In a normal scenario, for a library X, we would have the package libX. When a new version of the lib is released upstream, the new version gets packaged, and the version field of the package gets bumped appropriately. No, not true at all. This is the scenario for *badly maintained* libraries, which do not maintain their ABI and instead consider the upstream version canonical. Sadly glib, GTK+, etc. were examples of this in the past which is why they have 2.0 in their names :-( The *correct* way for a library, and which the vast majority follow, is that each library has its ABI versioned, and this is reflected in the library's SONAME For example, the first version of a library would be: libexample.so.0 The second version would be libexample.so.1 The third version libexample.so.2 etc. Minor versions are permitted in the library name, so if you add new API/ABI without breaking any existing, you might name it: libexample.so.2.1 this still has a SONAME of libexample.so.2 (since it is compatible) Packaging policy *always* includes the SONAME of the library in its binary package name, e.g. libexample0 libexample1 libexample2 Thus libraries with different SONAMEs are always parallel installable. For the minor version example, both would be libexample2 but different versions of it. dpkg provides the shlibs and symbols systems for identifying the minimum required version of a library at build time, and encoding this in the dependencies. Thus a package built against libexample2 that actually required symbols from 2.1 would have libexample2 (= 2.1) in its dependency list, while a package built against the earlier version (or that did not require symbols from 2.1) would have just libexample2 Both can use the same library package Scott -- Scott James Remnant sc...@ubuntu.com signature.asc Description: This is a digitally signed message part -- 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: Ubuntu-devel-discuss Digest, Vol 40, Issue 13
I assume that the samba job has been split into two because there was a problem with nmbd not starting when smbd and nmbd were launched through samba. If you look at the respective conf files, you will see that nmbd requires a nic other than lo to be up before starting. So, although it makes sense that there is little reason to run nmbd when the only network connection is lo, it makes even _less_ sense, AFAIK, to run smbd when there are no external network connections. I couldn't think of a single scenario where smbd does anything without networking -- mounting local SMB file systems only requires mount.cifs, which is in an entirely different package (smbfs). Is one service/daemon per /etc/init .conf file part of the Upstart design spec, perhaps? I would look at this from a different angle; smbd does not have nmbd's deficiency of requiring a non-loopback interface to be up and the developer chose to have the minimal start on test for smbd - and therefore created two upstart jobs. I don't think that Upstart prevented him from starting smbd and nmdb with the same job (with script; exec smbd...; exec nmbd...; end script). Having two jobs is definitely cleaner than the Karmic situation where there is a script in /etc/network/if-up.d to bring nmbd up when an interface comes up, if smbd is already running. -- 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: Evolution Ubuntu 10.04 LTS
Subject: Re: Evolution Ubuntu 10.04 LTS From:Sebastien Bacher seb...@ubuntu.com Date:Mon, 08 Mar 2010 23:02:32 +0100 To: ubuntu-devel-discuss@lists.ubuntu.com Ubuntu has been bitten by upgrading to new versions which were rewritten in the past and we have learnt, the decision has been made to stay on a version which is not perfect but that we know about rather running to use a rewrite in the risk of being stucked with something not ready quality and feature wise for a lts. As someone who is now running Lucid Alpha 3 on some production servers because I absolutely need some features of programs that have been updated in the last 1.5 years and Karmic is a largely an unusable disaster, I can see both sides of this argument. Why not use something like ubuntu-backports more aggressively to make everyone happy? PPA's are great, but we've already gotten burned once by using the PPA for a newer version of OpenOffice and having it suddenly disappear a few months later, throwing the automatic updates on 300 client machines into disarray. Given the speed with which open source software evolves, and given the need/desire of users to have access to the latest and greatest, it would be very useful to give users access to the newest versions of such things as Firefox, Thunderbird, Dia, gimp, OpenOffice, and so on. Generally these user space programs just work without causing system level regressions. And it's kind of embarrassing to recommend linux to a user and have them tell me they like running Windows because it's a lot easier to keep Firefox/Thunderbird/etc. up to date rather than waiting a year before having access to nifty new features they get instantaneously on their windows box the day after the package is released. Of course there's always the chance of being bitten as described above. To this end, I've been thinking about this for a while and would like to propose the following solution. Unfortunately implementing this would require hacking or modifying the current .deb architecture. The basic idea is to make new packages available through ubuntu-backports (or ubuntu-unstable or ubuntu-experimental or something like this) but with a simple mechanism for backing out of the upgrade if it doesn't work out so well. For example, suppose Ubuntu X.Y ships with gumptaculer version 1.7.3 and a few months later gumptaculer version 2.0 is released with much fanfare, front page articles in Infoworld, Linux Journal, lwn.net, and breathless reviews across the blogosphere. Users start clamoring for the features of gumptacular 2.0, not knowing how they ever lived without them. So, apt-get install gumptacular/ubuntu-experimental installs v. 2.0. Unfortunately it turns out that whenever you run gumptacular 2.0 on a machine with an nVidia graphics card, the GPU fan spins out of control and melts the system board. Problem. The suggested new feature is a way to simply back out of the experimental update whenever you get bitten: apt-revert gumptacular would un-install v. 2.0 and re-install v. 1.7.3 -- problem solved and users will just have to wait until version 2.0.1 is released (shortly). Understood that there could be lots of complications with dependencies, but that's why it's called ubuntu-experimental -- the onus is on the administrator to apply such changes atomically (i.e. one at a time) so that they can be backed out of without having to unwind a spaghetti mess of now inter-related dependencies created by updating several experimental packages at once. If only one package was updated, then all the dependencies can be reverted, too without compromising the system. -- 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: Evolution Ubuntu 10.04 LTS
On Wed, Mar 10, 2010 at 2:28 AM, Patrick Goetz pgo...@mail.utexas.edu wrote: Journal, lwn.net, and breathless reviews across the blogosphere. Users start clamoring for the features of gumptacular 2.0, not knowing how they ever lived without them. So, apt-get install gumptacular/ubuntu-experimental Apt-get already supports this. E.g. it is possible to configure apt-get so that apt-get install gumptacular/lucid will attempt to install the lucid version gumptacular onto a Karmic machine. spins out of control and melts the system board. Problem. The suggested new feature is a way to simply back out of the experimental update whenever you get bitten: apt-revert gumptacular Is is what is unsupported. I understand that deb say how to upgrade you configuration etc. to the new versions, but don't know how to downgrade. I understand that supporting downgrade could double the work required to produce a deb, but I agree that it is worthwhile for at least important projects like firefox (and of course gumptacular ;). -- John C. McCabe-Dansted -- 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: Evolution Ubuntu 10.04 LTS
On Tue, Mar 9, 2010 at 10:28, Patrick Goetz pgo...@mail.utexas.edu wrote: Subject: Re: Evolution Ubuntu 10.04 LTS From: Sebastien Bacher seb...@ubuntu.com Date: Mon, 08 Mar 2010 23:02:32 +0100 To: ubuntu-devel-disc...@lists.ubuntu.com Ubuntu has been bitten by upgrading to new versions which were rewritten in the past and we have learnt, the decision has been made to stay on a version which is not perfect but that we know about rather running to use a rewrite in the risk of being stucked with something not ready quality and feature wise for a lts. As someone who is now running Lucid Alpha 3 on some production servers because I absolutely need some features of programs that have been updated in the last 1.5 years and Karmic is a largely an unusable disaster, I can see both sides of this argument. Why not use something like ubuntu-backports more aggressively to make everyone happy? PPA's are great, but we've already gotten burned once by using the PPA for a newer version of OpenOffice and having it suddenly disappear a few months later, throwing the automatic updates on 300 client machines into disarray. Given the speed with which open source software evolves, and given the need/desire of users to have access to the latest and greatest, it would be very useful to give users access to the newest versions of such things as Firefox, Thunderbird, Dia, gimp, OpenOffice, and so on. Generally these user space programs just work without causing system level regressions. And it's kind of embarrassing to recommend linux to a user and have them tell me they like running Windows because it's a lot easier to keep Firefox/Thunderbird/etc. up to date rather than waiting a year before having access to nifty new features they get instantaneously on their windows box the day after the package is released. Of course there's always the chance of being bitten as described above. To this end, I've been thinking about this for a while and would like to propose the following solution. Unfortunately implementing this would require hacking or modifying the current .deb architecture. The basic idea is to make new packages available through ubuntu-backports (or ubuntu-unstable or ubuntu-experimental or something like this) but with a simple mechanism for backing out of the upgrade if it doesn't work out so well. For example, suppose Ubuntu X.Y ships with gumptaculer version 1.7.3 and a few months later gumptaculer version 2.0 is released with much fanfare, front page articles in Infoworld, Linux Journal, lwn.net, and breathless reviews across the blogosphere. Users start clamoring for the features of gumptacular 2.0, not knowing how they ever lived without them. So, apt-get install gumptacular/ubuntu-experimental installs v. 2.0. Unfortunately it turns out that whenever you run gumptacular 2.0 on a machine with an nVidia graphics card, the GPU fan spins out of control and melts the system board. Problem. The suggested new feature is a way to simply back out of the experimental update whenever you get bitten: apt-revert gumptacular would un-install v. 2.0 and re-install v. 1.7.3 -- problem solved and users will just have to wait until version 2.0.1 is released (shortly). Understood that there could be lots of complications with dependencies, but that's why it's called ubuntu-experimental -- the onus is on the administrator to apply such changes atomically (i.e. one at a time) so that they can be backed out of without having to unwind a spaghetti mess of now inter-related dependencies created by updating several experimental packages at once. If only one package was updated, then all the dependencies can be reverted, too without compromising the system. -- 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 The apt-revert thing would sure be nice for ppa's too, because if someone installs packages from a ppa and then removes the ppa, it takes some searching to find all the ppa packages and revert them to the official version. Erik B. Andersen -- 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: Package version numbers in names
On Tue, Mar 9, 2010 at 11:36 AM, Scott James Remnant sc...@ubuntu.comwrote: On Tue, 2010-03-09 at 10:36 -0500, Evan wrote: In a normal scenario, for a library X, we would have the package libX. When a new version of the lib is released upstream, the new version gets packaged, and the version field of the package gets bumped appropriately. No, not true at all. This is the scenario for *badly maintained* libraries, which do not maintain their ABI and instead consider the upstream version canonical. Sadly glib, GTK+, etc. were examples of this in the past which is why they have 2.0 in their names :-( The *correct* way for a library, and which the vast majority follow, is that each library has its ABI versioned, and this is reflected in the library's SONAME For example, the first version of a library would be: libexample.so.0 The second version would be libexample.so.1 The third version libexample.so.2 etc. Minor versions are permitted in the library name, so if you add new API/ABI without breaking any existing, you might name it: libexample.so.2.1 this still has a SONAME of libexample.so.2 (since it is compatible) Packaging policy *always* includes the SONAME of the library in its binary package name, e.g. libexample0 libexample1 libexample2 Thus libraries with different SONAMEs are always parallel installable. For the minor version example, both would be libexample2 but different versions of it. dpkg provides the shlibs and symbols systems for identifying the minimum required version of a library at build time, and encoding this in the dependencies. Thus a package built against libexample2 that actually required symbols from 2.1 would have libexample2 (= 2.1) in its dependency list, while a package built against the earlier version (or that did not require symbols from 2.1) would have just libexample2 Both can use the same library package Thank you so much for clarifying, that makes more sense. Now let's throw symlinks into the mix :) Suppose libexample is at version 1.0 upstream. The previous version was version 0.5. The current package is named libexample0.5 It has a version field of 1.0 It installs libexample.so.1.0 It also installs the symlink libexample.so.0.5 - libexample.so.1.0 Now as I see it the problem exists in one of two places: Either upstream misincremented the major version number (without changing the API/ABI), or it has been mispackaged. Does this make sense? Thanks, Evan -- 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
logging bugs for pre-release versions
Having abandoned Karmic, I've been installing Lucid Alpha 3 on a number of different systems, mostly for testing, and am finding lots of bugs. For example, on an old Acer Aspire 3000 laptop, after a completely generic Alpha 3 install + or - up to March 8 daily updates: 1. The console driver is broken: vt1-vt6 only display 13.5 characters (yes, I meant 13 and one half characters). 2. X works fine, but will sometimes come up on vt7, other times on vt8 -- I haven't been able to determine a pattern. 3. There is a timing problem with logging in on the gdm console: the first attempt to login always fails, the second always succeeds -- unless I wait 4-5 minutes before attempting to log in, in which case the first login attempt succeeds (usually). For mission critical issues I will take the time to carefully file a bug report on launchpad, but for stuff like this I just don't have time. For example, I have no idea what package to associate the console graphics problem with and don't really have time to find out. What I want to be able to do is have some place to state the build I'm installing, describe the hardware I'm installing it on (e.g. this system has an SIS M760GX graphics chip and an AMD Sempron processor), and then list the problems I'm having and done, back to work. The someone more knowledgeable than me can parse and triage the issues to the right package maintainers. ubuntu-bug doesn't work this way AFAIK (no idea how I'd use it with the problems described above), and apport isn't doing it for me. After one login (I've been turning the machine on and off a lot trying to narrow down the specific list of problems), a dialog box popped up announcing that some serious kernel panic had occurred, that the system was now unstable, and would I like to report a bug to help the developers? Sure, why not. Apport then proceeded to ask me a series of questions not even Linus could answer: e.g., is this bug similar to any of these bugs? How would I know? The only information I have is a dialog box telling me the kernel panicked -- I don't have any information. I've been using linux for 15 years; now imagine throwing these dialogs at some neophyte. This is bound to do more harm than good, since the experience is surreal, to say the least. Assuming no one is available to parse these multi-bug reports, I could probably write a perl script in a couple of days that would search through them looking for keywords and then alert specific package maintainers based on topics they've registered to trigger an alert. SJ Remnant could write an event driven version in an hour. It seems to me that for pre-release code, where users/testers are likely to find multiple problems, it should be made as easy as possible to report these problems. Also, please don't suggest the ubuntu+1 IRC, this is beyond completely useless. -- 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: Evolution Ubuntu 10.04 LTS
Op woensdag 10-03-2010 om 02:50 uur [tijdzone +0800], schreef John McCabe-Dansted: Is is what is unsupported. I understand that deb say how to upgrade you configuration etc. to the new versions, but don't know how to downgrade. I understand that supporting downgrade could double the work required to produce a deb, How will you revert all people's configuration data (e.g. files created with an incompatible new file format)? -- Jan Claeys -- 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
Is it necessary to rebuild mplayer after updating libass?
I noticed on the lucid-changes mailing list that libass was recently updated. https://lists.ubuntu.com/archives/lucid-changes/2010-March/007954.html At one point mplayer used libass for subtitle rendering. I have not looked at mplayer or its packaging in quite some time, but I'm guessing this is still true. Does the changed libass lib have the same api or does mplayer use its own internal copy of libass? Best Regards, Sindhudweep -- 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
Call for Testing: Nouveau
Hi all, The drive towards stabilising Nouveau for a rocking Lucid LTS release has resulted in large changes to the packaging stack. Nouveau's kernel module is now in the main kernel package, which fixes most of the problems people have previously reported. If you have previously tested nouveau and found your VTs didn't work, or that plymouth splash didn't work, or that you just got no display at all please test again with the 2.6.32-16 kernel. If you've updated in the last day, you should already have this kernel installed. You can check which kernel you are running by running “uname -r” from a terminal - it should print something like “2.6.32-16-generic”. The important bit is 2.6.32-16. This work means that nouveau now has a lack of good bugs reported against it. I'm hoping that the fine testers of Ubuntu can rectify this! If you've got an nvidia graphics card, please try disabling the restricted drivers and testing nouveau for a day. Just using your computer with the nouveau drivers and reporting any problems you encounter will be useful, but if you want to test more systematically, there's a list[1] of things to check on the wiki. Filing a good bug is as simple as running “ubuntu-bug xorg” and describing the problem you see, and how you can trigger it, in the report. The apport hooks will magically attach all the relevant logs for you. If you run into a bug and want to invest some extra effort to help get it fixed, after reporting the bug you can test with a newer version of Nouveau. These packages are available in the xorg-edgers/nouveau PPA. Further instructions are on the wiki[2]. Your feedback is greatly appreciated. Let's go find some bugs! [1]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation [2]: https://wiki.ubuntu.com/X/Testing/NouveauEvaluation#upstreamtesting signature.asc Description: This is a digitally signed message part -- 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
