[00:12] <cjohnston> Can someone please take a look at bug 532633 and confirm that this is now the intended look?
[00:30] <bhundven> a quick question about version in changelog. why would package-1.0.0+20100101-1ubuntu1 be newer then package-1.0.1+20100305-1. Is it because of the 1ubuntu1 part at the end?
[00:30] <Caesar> bhundven: you can use dpkg --compare-versions to test
[00:30] <Caesar> But the answer to your question is yes
[00:33] <Caesar> slangasek: Upstart is hurting my brane
[00:34] <slangasek> Caesar: oh?
[00:35] <Caesar> So I tried to write an upstart job for autofs5
[00:35] <Caesar> But it seems very unreliable
[00:35] <Caesar> I can get start and stop to just hang
[00:36] <Caesar> I can get upstart to think it's started the process when it's not running, and get all bitter and twisted when I try to stop it when it's already stopped
[00:36] <Caesar> I've put my upstart job spec in #533029
[00:36] <slangasek> you probably need a different option for 'expect'
[00:37] <bhundven> ah. it wasn't the 1ubuntu1 at the end that was throwing me... it was the 1: before the version that I didn't see before.
[00:37] <Caesar> I tried both
[00:37] <slangasek> expect fork, expect daemon, expect the-unexpected, etc
[00:37] <Caesar> Yeah, I've tried both fork and daemon
[00:37] <Caesar> I'm currently getting the unexpected :-)
[00:37] <slangasek> does automount have an option to run in the foreground?
[00:37] <slangasek> you may have to do that
[00:37] <Caesar> Yes, I can try that I guess
[00:37] <slangasek> smbd similarly behaves in a way that upstart is unable to trace
[00:37] <Caesar> That always strikes me as a crude hack
[00:39] <Caesar> It makes me sad that start and stop can just totally hang though
[00:39] <cjwatson> FWIW there is an outstanding upstart bug where you can get it permanently into a confused state by the wrong 'expect' value - if you've done that, you'll have to reboot before you can evaluate whether the other setting works
[00:39] <Caesar> cjwatson: ok, I'll give it a reboot
[00:40] <cjwatson> bug 406397
[00:41] <Caesar> Lame-o, automount with -f also wants to log to stderr
[00:41] <cjwatson> BTW you have 'if !modprobe ...' which is an error
[00:41] <cjwatson> (missing space)
[00:42] <Caesar> Gar
[00:43] <Caesar> I do love the idea of Upstart
[00:43] <Caesar> The jobs are very clean
[00:43] <Caesar> I dislike the current inability to have a good handle on what the bootup process is like
[00:44] <cjwatson> I've seen job graphs, although I'm not sure what produces them
[00:44] <cjwatson> brushing that up might be an interesting way to tackle the problem
[00:44] <Caesar> Yes
[00:44] <cjwatson> I agree that you have to have a very, very clear idea of the state machine in your head
[00:45] <Caesar> Booting with --verbose may help, provided it's logged somewhere
[00:45] <cjwatson> mostly ends up in /var/log/syslog, with the possible exception of early stuff
[00:46] <cjwatson> I think not absolutely everything is logged, but it's usually enough for the sort of things users would be writing
[00:46] <Caesar> I imagine if the PID of the process doesn't match what Upstart's status says it is, I'm in for a world of pain?
[00:47] <cjwatson> yeah, it's probably lost track per the bug above and you're toast
[00:47] <Caesar> Okay, I'll try the other value of expect after a reboot
[00:47] <cjwatson> bit me with ssh a while back
[00:48] <Caesar> Did you run it in the foreground to get around it?
[00:48] <cjwatson> no
[00:48] <cjwatson> I used 'expect fork' rather than 'expect daemon', since the main process only forks once
[00:48] <Caesar> That's what I'm trying now post reboot
[00:49] <Caesar> \o/
[00:50] <Caesar> I've at least got reality and Upstart to agree
[00:50] <Caesar> Yep, that's a winner
[00:50] <Caesar> Now if only switching to an upstart job had actually solved the problem I was trying to solve...
[01:05] <Caesar> cjwatson: so OpenSSH isn't using Upstart in Lucid?
[01:06] <cjwatson> OpenSSH is using Upstart in Lucid
[01:06] <Caesar> Hmm
[01:06] <cjwatson> $ status ssh
[01:06] <cjwatson> ssh start/running, process 999
[01:06] <Caesar> Bah, I'm an idiot, don't mind me
[01:06] <cjwatson> you noticed that the init script was still there?
[01:06] <Caesar> We're not using Ubuntu's OpenSSH (duh)
[01:06] <cjwatson> ah :)
[01:07] <Caesar> I'm currently trying to figure out why syslog-ng isn't starting
[01:07] <cjwatson> well, you should be able to now ;-)
[01:07] <Caesar> No syslog, no logs, makes debugging very hard
[01:07] <Caesar> syslog-ng is using old-style init scripts though
[01:07] <cjwatson> I thought you guys were using rsyslog
[01:08] <Caesar> Not at the current time
[01:08] <Caesar> We've always used syslog-ng
[01:08] <Caesar> I've yet to investigate the feasibility of switching to rsyslog
[01:08] <Caesar> But the fact that syslog-ng isn't even starting for me is helping expedite that
[01:11] <Caesar> Ooh, I wonder if it's also network related
[01:12] <Caesar> It may be throwing up its hands because it can't resolve the remote host it's being told to log to
[01:12]  * Caesar gets to write another upstart job
[01:14] <RoAkSoAx> cjwatson, what are -p, -i, or -a in dh_apport?
[01:15] <cjwatson> RoAkSoAx: same as in any other debhelper command, I guess?
[01:15] <slangasek> RoAkSoAx: debhelper(7)
[01:15] <cjwatson> select the set of packages to operate on in various ways
[01:17] <RoAkSoAx> ok thanks
[01:17] <RoAkSoAx> and where hsould it be placed? dh_install?
[01:17] <RoAkSoAx> i mean
[01:17] <RoAkSoAx> install rule
[01:17] <RoAkSoAx> or when overriding a dh_install for example?
[01:17] <cjwatson> normally binary-{arch,indep}
[01:17] <cjwatson> if you're using dh(1), you don't need to do anything
[01:17] <cjwatson> well, you do
[01:17] <cjwatson> but you just need to do 'dh --with apport $@'
[01:18] <cjwatson> see openssh for an example of doing it manually
[01:18] <RoAkSoAx> cjwatson, awesome thanks!!
[01:20] <cjwatson> and you can run (e.g.) 'dh --with apport --no-act binary' in a package's working tree to get the canonical command sequence, though not broken up by debian/rules target.  though in most cases you don't want to call all of them and the ordering between dh_installdocs down to dh_link (or thereabouts) usually doesn't matter much
[01:23] <RoAkSoAx> ok :)
[01:26]  * Keybuk wonders how long he should let update-manager calculate the upgrade to lucid before killing it
[01:27] <LaserJock> perhaps it's gotten a little debianified, "you'll get your new release when it's ready"
[01:38]  * Caesar <3 how easy it easy to write upstart jobs
[01:38] <Caesar> (once you know the event names)
[02:00] <Keybuk> ooh, finally, update-manager is on its awy
[02:03] <jdong> pitti: did I ever tell you how much I love you? [thanks for vmmouse lucid magic!] :)
[02:06] <jdong> and *giggles* plymouth just gave me the fedora-esque blue stripes racing across the screen bootsplash... confused me for a moment as to which VM I started.
[02:15] <Caesar> Are there any plans to make Plymouth do something useful with nvidia graphics for 10.04?
[04:42] <alabd> good day all
[04:42] <alabd> for pkg in *deb ; do <what should be here?> "$pkg" && mv "$pkg" Karmic || mv "$pkg" Jaunty ; done
[04:43] <alabd> <what should be here?> =  a command that returns 0 for juanty 1 for others .....such thing ?
[04:43] <alabd> do you know such command ?
[07:35] <mtx_init> are there any hellanzb devs in here?
[07:55] <geser> slangasek: Could you please tag the new ubuntu-dev-tools upload in bzr. Thanks
[07:57] <slangasek> geser: hmm, yes - pushed now
[07:57] <slangasek> (well, pushing)
[08:13] <dehqan> there is a folder containing jaunty and karmic packages how to separate the jaunty packages from the karmic packages?
[08:19] <lifeless> dehqan: you can look at the changelog in the package, though its not guaranteedd for packages that haven't been uploaded again
[08:20] <lifeless> dehqan: generally speaking you need the Packages file to sort that out
[08:21] <dehqan> ok they are in /var/cahce/apt/archives
[08:21] <dehqan> how to sort that out ?
[08:21] <lifeless> This is a channel for development of ubuntu itself. We direct people to #ubuntu for support questions
[08:30] <dehqan> you should asked it there some time but no proper answer
[08:31] <dehqan> lifeless: ^
[08:37] <dehqan> anyway thanks
[08:56] <tjaalton> so the music store should be availble in finland? rb just says "coming soon"
[08:57] <emgent> Riddell, ping.
[09:10] <lifeless> cjwatson: ping; wondering if you know anything about the mini.img in the ubuntu-installer dir of a.u.c : it doesn't seem to have the ath9k driver in it.
[09:32] <dehqan>  there is a folder containing jaunty and karmic packages how to separate the jaunty packages from the karmic packages? packges in .deb format in /var/cache/apt/archives
[11:23] <sebner> Please tell me that there is a gconf value for the changing the windows controls back (from the left to the right) or /me waves goodbye
[11:43] <elleuca> could someone test if patch to bug #436887 is fine?
[11:46] <persia> sebner: There is.
[11:46]  * sebner hugs persia and calls him a god
[11:48] <persia> sebner: By the tenets of the religion I impose on my believers, it is blasphemy to imply that I have deistic properties.
[11:48] <sebner> hahaha
[11:48] <sebner> persia: now, would you mind telling me how to fix this "ohmy!" thing?
[11:49] <persia> grep the logs for the past 48 hours for gconf.  Flip that setting.
[11:49] <persia> (this channel)
[11:49]  * sebner greps
[12:06] <sebner> persia: I flipped the colon but it's still not working (did a X-restart)
[12:06] <persia> sebner: You have as much information as I then.
[12:07] <sebner> persia: heh, at least I hope whoever did this upload, did this change by accident. If not ....
[12:09] <Ng> there are many blog posts about how to move the window controls back to the right, check Planet Ubuntu
[12:09] <persia> sebner: I believe there exists a bug about it.  you can also select a different theme.
[12:09] <sebner> persia: Well, I'm not using standard-theme anyways
[12:11] <sebner> Ng: grr, I already did the change proposed but it magically happens *not*
[12:12]  * sebner kicks his XServer once again
[12:14] <sebner> Woo, it's now on the right side but I want maximize in the middle which is not working xD
[12:17] <sebner> interesting, restarting Xserver a hundred times and doing the change over and over again in gconf (resets somehow) fixed it for me xD
[12:35] <fmarl> elleuca, your patch doesn't apply cleanly against indicator-session package in lucid?
[13:36] <mdeslaur> ccheney: I've backported GtkStatusIcon support to lucid's pidgin to fix the tray icon transparency. If you could try it, out of my "testing" PPA, that would be great.
[13:37] <mdeslaur> After a couple of people test it, I'll see if anyone minds if I upload it.
[13:37] <mdeslaur> Same with liferea
[14:28] <elleuca> fmarl, dunno, I simply wrote it, but currently I've not time to test is; it seems fine to me...
[14:49] <Riddell> cjwatson: live CDs not booting today, at least on virtualbox, so can't test installer
[14:52] <cjwatson> odd, I'll take a look at some point
[18:01] <dehqan> we have list of packages with their version how to know if one package is from jaunty repo or karmic repo , for example a package with version of 1:1.10.2-2ubuntu7
[18:01] <crimsun> apt-cache policy foo
[18:01] <crimsun> (foo is the binary package name)
[18:02] <crimsun> if you want to poll LP directly, use rmadison
[18:07] <dehqan> crimsun: no package name package address like /ddf/dfdf/ds.deb
[18:09] <geser> try the package name not the filename
[18:10] <geser> so you have only the filename and not the package name?
[18:10] <dehqan> geser:  yes
[18:10] <dehqan> a folder with packages
[18:11] <geser> dpkg-deb -I filename.deb | grep Package
[18:11] <geser> perhaps some sed too to get the package name of a file
[18:12] <geser> and if a package didn't change between jaunty and karmic, the same version can be in both
[18:14] <dehqan> geser:  no dpkg-deb -I
[18:15] <dehqan> dpkg-deb: unknown option -l
[18:15] <geser> -I (big i)
[18:15] <crimsun> (use a better font! ;-)
[18:16]  * jdong prepares to break his machine with the help of btrfs... again...
[18:17] <dehqan> geser:  no ubuntu version in info
[18:22] <dehqan> geser:  ok now we have package name and apt-cache policy gives         500 http://archive.ubuntu.com jaunty/main Packages
[18:22] <dehqan>  that's nice now imagine a folder with a packages how to seprate jaunty packages from them ?
[18:26] <ikonia> dehqan: this is not a support channel
[18:42] <ccheney> mdeslaur: it worked
[18:59] <cjwatson> dehqan: there is in general *no way*.  as you've been told, it's perfectly possible for the same package to be in both jaunty and karmic.  you are supposed to track this separately, not by examining the .deb files.
[19:01] <cjwatson> dehqan: the .changes file has a Distribution file that says where the package was originally uploaded.  (if you've thrown that file away, well ...)
[19:01] <cjwatson> *Distribution field
[19:29] <T`> anyone here know much about upstart?
[19:30] <T`> start on interface-up br0  <-- wondering if this is supposed to work
[19:56] <slangasek> T`: not with that syntax, no
[19:57] <slangasek> T`: 'start on net-device-up IFACE=br0' would be the right syntax
[20:03] <bluefoxicy> rhythmbox "add to musicbrainz" opens a web browser with a web page that's unhelpful
[20:04] <bluefoxicy> it doesn't even open it to a filled-in form with all the information Rhythmbox has (it has all the track titles for the CD)
[20:08] <slangasek> geser: hmm, so, clarification: debcommit uses the same implementation of the changelog bug parser as dpkg-dev when generating the --fixes args to bzr, so I guess you just weren't using debcommit?
[20:09] <slangasek> geser: (bzr itself doesn't attempt to parse changelogs, dunno what I was thinking when I said that)
[20:13] <dehqan> cjwatson: where is .changes file ?
[20:16] <cjwatson> dehqan: it's generated alongside the .deb files when building packages in the normal way
[20:17] <dehqan> how to read it ? cjwatson
[20:17] <cjwatson> slangasek: there's a plugin somewhere that makes bzr ci pick it up from the changelog I think ...
[20:17] <slangasek> cjwatson: oh?  even when not using debcommit?
[20:17] <cjwatson> dehqan: please use your initiative and look at the file; if you'd looked at it, you wouldn't need to ask
[20:18] <cjwatson> slangasek: I believe so.  not in a place where I can check just now
[20:45] <dehqan> cjwatson: thanks
[21:15] <geser> slangasek: I used "bzr ci --fixes lp:xxx". Is that wrong?
[21:16] <less1> Hi, I am looking for someone who is working on ubuntu boot process to fire few question, may I know where I can find them?
[21:16] <slangasek> geser: huh, that's right... so ... ignore me, I guess
[21:16] <slangasek> geser: apparently I don't know what I'm talking about :)
[21:21] <geser> slangasek: I see only that this makes LP add a link to the branch with the commit (here ubuntu-dev-tools trunk) but doesn't update the bug status or add a comment. I usually add a comment with the revision, so it later easily to spot which rev contains the fix (e.g. for backporting for a SRU).
[21:21] <slangasek> geser: ack
[21:25] <geser> slangasek: you don't have by chance some time to review and sponsor bug #509900?
[21:56] <sistpoty> lamont: if you have some spare time, fpc needs bootstrapping on armel and powerpc
[21:57] <sistpoty> (not too high priority though)
[22:27] <slangasek> geser: new upstream version, no FFe needed?  Could you document why in the bug?
[22:28] <slangasek> geser: also, I don't suppose you'd want to do that as a bzr branch I can just pull into lp:ubuntu/vim?
[22:28] <slangasek> (i.e., merge lp:debian/vim, push somewhere, etc)
[22:29] <cjwatson> merging lp:debian/vim ran into hideous bzr problems
[22:29] <cjwatson> been there done that :(
[22:32] <slangasek> cjwatson: drat
[22:42] <geser> slangasek: do the additional (upstream) patches count as a new upstream version? it's still version 7.2 but with the collected patches till patch 330
[22:42] <geser> and I tried to get it reviewed before FFe but cjwatson told me that there is no hurry as it won't need a FFe
[22:42] <geser> but I can add the missing bits if needed
[22:43] <sistpoty> asac: mind sharing some wisdom for FFe bug #482890?
[22:43] <cjwatson> I don't remember saying that in particular, though it's possible that I did
[22:44] <cjwatson> I may have said that I didn't think it would be a major problem, or something
[22:44] <geser> you might be right, don't remember your exact wording
[23:13] <sistpoty> hm, anyone got a clue why this is a FTBFS (build log says it built fine!): http://launchpadlibrarian.net/40376516/buildlog_ubuntu-lucid-amd64.mksh_39.3-1ubuntu1_FAILEDTOBUILD.txt.gz
[23:15] <slangasek> sistpoty: the problem is detailed at the bottom of the log file...
[23:15] <sistpoty> slangasek: you mean the conftest pointer conversion?
[23:16] <slangasek> yes
[23:16] <wgrant> I thought that was now meant to be non-fatal except on ia64.
[23:16]  * wgrant checks.
[23:17] <slangasek> wgrant: eh?  amd64 has the same issue, and it certainly shouldn't be given a pass there
[23:17] <slangasek> (now in this case it's a false positive since the error comes from a check for the *existence* of this function)
[23:18] <wgrant> Ah, right, it's only definitely going to break on ia64, but might still break on amd64.
[23:18] <slangasek> it's always a bug on both ia64 and amd64, it just won't always strike on amd64
[23:19] <slangasek> which, if anything, makes it harder to track down after the fact
[23:19] <wgrant> Right.
[23:21] <sistpoty> so how can I work around the broken buildds?
[23:22] <slangasek> sistpoty: the test case that's throwing this error should be rewritten to include its own strcasestr prototype
[23:23] <sistpoty> slangasek: ok, thanks for the hint
[23:23] <slangasek> (or upstream could use autoconf, which doesn't have this problem...)
[23:24] <crypt-0> does kcryptd support SMP?
[23:31] <slangasek> geser: vim> well, it's packaged with a new upstream version number; I'm not familiar with the versioning on this package, but the main point is whether it includes new features or not
[23:38] <jdong> in non-KMS-mode, is the fedora-like plymouth bootsplash intended?
[23:39] <cjwatson> jdong: not according to bug 526892
[23:40] <jdong> cjwatson: ah, thank you. Kind of feels like booting Fedora for a moment until *boom* purple :)