[00:39] <psusi> I'm trying to reproduce a bug reported installing grub on a usb disk, but when I try with my 8 gb flash stick, ubiquity does not list the drive ( sde ) as an option.  It is mentioned in the partman log files as being discovered, but ubiquity hides it.  Does it hide usb flash drives on purpose?
[00:44] <cjwatson> it hides the disk you're installing from on purpose
[00:45] <cjwatson> since there are going to be serious limitations on partitioning it and attempts to do so usually lead to enormous confusion and bug reports
=== sanchaz is now known as sanchaz-away
[01:36] <james_w> SpamapS, barry: https://lists.launchpad.net/pkgme-devs/msg00000.html
[01:36] <psusi> cjwatson, that's what I thought, but I booted from a cdrom and tried to install to the usb stick
[01:36] <james_w> SpamapS, barry: may I suggest you join https://launchpad.net/~pkgme-devs and subscribe to the mailing list?
[01:37] <psusi> maybe I messed up and booted from the wrong one... I'll give it another go when I finish writing up this wiki entry on LVM
[01:41] <barry> james_w: done. thanks for the write-up
[01:42] <james_w> thanks
=== MikeGuo is now known as hylinux
[04:25] <adamsa> hi i am trying to develop and test my software on 64bit ubuntu but libmudflap64 is only compiled / available for i386? ... so i get errors about real_munmap etc. --> has anyone else found this?
[04:26] <adamsa> (10.10)
[04:29] <micahg> adamsa: you might be looking for libmudflap0
[04:29] <maco> seriously? theres a lib named that? O_o
[04:29] <adamsa> i have that installed, that isn't the issue, i also have gcc-multilib and the -dbg packages etc.
[04:29] <micahg> adamsa: #ubuntu-app-devel might be a good resource for you
[04:30] <adamsa> perhaps but i was hoping a dev here already hit it ...
[04:57] <adamsa_> fixed it --> broken symlink :) reporting bug
=== ion_ is now known as ion
=== kees___ is now known as kees
=== almaisan-away is now known as al-maisan
=== dendro-afk is now known as dendrobates
[07:07] <wgrant> pitti, cjwatson: Is there any reason we would ever need to accept an upload in any pocket of an obsolete series?
=== Tm_K is now known as Tm_T
[07:34] <pitti> Good morning
[07:34] <pitti> wgrant: we should never accept an upload into a released series, obsolete or not; and for the other pockets they should always land in unapproved
[07:35] <RAOF> Aloha pitti
[07:35] <pitti> wgrant: there might be a corner case where we do accept a package into an obsolete series, like a fixed update-manager or whatnot
[07:35] <pitti> hey RAOF
=== lamont` is now known as lamont
[07:36] <wgrant> pitti: Right, I (and Launchpad, fortunately...) know about the supported/current pocket restriction. But it would be convenient if we could just reject anything for an obsolete series.
[07:36] <wgrant> I guess I'll just make it behave like supported/current.
[07:36] <RAOF> You'll be happy to know my local libgl1-mesa-dri package now takes up 30MB less on-disc :)
[07:43] <pitti> RAOF: oooh! *hug*
[07:43] <pitti> RAOF: dynamic linking FTW?
[07:43] <RAOF> Indeed.
[07:43] <RAOF> That's without stripping out any of the lesser-used DRI drivers.
[07:44] <pitti> RAOF: I guess these just take ~ 200 kB now?
[07:44] <ebroder> pitti: by the way, libnss-mdns's perl dependency is completely bogus. it just uses perl -i in the postinst
[07:44] <pitti> ebroder: nice
[07:44] <ebroder> but i think apparmor is going to be our downfall
[07:44] <RAOF> Mmm, mga is as big as 330kB :)
[07:45] <pitti> ebroder: yes, that's going to be tough
[07:45] <pitti> RAOF: heh
[07:45] <RAOF> So there's ~1MB to be claimed by sacrificing the lesser-used drivers.
[07:52] <pitti> RAOF: I think that's much less urgent now
[07:53] <pitti> RAOF: but we can shelve that idea for a later cycle when we get desperate again :)
=== Adri2000_ is now known as Adri2000
[07:53] <RAOF> :)
[08:08] <dholbach> good morning!
=== hunger_ is now known as hunger
[08:55] <\sh> Riddell: kirkland: Testing bug #533369
[08:55] <ubottu> Launchpad bug 533369 in debootstrap (Ubuntu Lucid) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,Fix committed] https://launchpad.net/bugs/533369
[09:19] <\sh> Riddell: tested bug #533369 and it works...please see the my comment
[09:19] <ubottu> Launchpad bug 533369 in debootstrap (Ubuntu Lucid) "Fails to debootstrap squeeze chroot due to missing apt-get" [Undecided,Fix committed] https://launchpad.net/bugs/533369
=== nenolod_ is now known as nenolod
=== dendrobates is now known as dendro-afk
[10:47] <pitti> ebroder: thanks for the gst-plugins-base0.10 fix! can you please send this to Debian as well?
[10:54]  * ogra hugs RAOF ... thanks for bringing back the kbd driver
=== seiflotfy_ is now known as seiflotfy
=== MacSlow is now known as MacSlow|lunch
[12:16] <ogra_ac> ouch
[12:16] <ogra_ac> cjwatson, apparently i get a segfault trying to boorstrap natty on arm
[12:17] <ogra_ac> *boot
[12:17] <ogra_ac> it ends with:
[12:17] <ogra_ac> W: Failure trying to run: chroot /mnt/natty-chroot dpkg --force-depends --install /var/cache/apt/archives/base-files_5.0.0ubuntu25_armel.deb /var/cache/apt/archives/base-passwd_3.5.22_armel.deb
[12:17] <ogra_ac> looking at natty-chroot/debootstrap/debootstrap.log there is only "Segmentation fault" in it
[12:19] <ogra_ac> ogra@ac100:/mnt$ sudo chroot /mnt/natty-chroot dpkg -l
[12:19] <ogra_ac> Segmentation fault
[12:19] <ogra_ac> hmm, seems to be dpkg
[12:23] <ogra_ac> things like --help seem to still work
=== bilalakhtar changed the topic of #ubuntu-devel to: Archive: Open | maverick-proposed is now unfrozen | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper -> maverick | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
[12:24] <cjwatson> ogra_ac: I saw the build failure, but I will need the arm team's help to debug it
[12:24] <ogra_ac> cjwatson, oh, it didnt build ? i missed that
[12:25] <cjwatson> the livefs build failure
[12:25] <ogra_ac> strace doesnt show anything obvious http://paste.ubuntu.com/529305/
[12:25] <ogra_ac> ah, k
[12:33] <cjwatson> the change to lib/compat/scandir.c is the only one I can imagine being involved
[12:33] <ogra_ac> hmpf, how do i run gdb on that
[12:33] <cjwatson> not sure how that would have made anything *worse* though
[12:34] <ogra_ac> running sudo gdb chroot /mnt/natty-chroot dpkg only gets me chroot backtrace ... and indeed i dont have gdb inside the chroot yet
[12:34] <cjwatson> and you'll want dpkg-query anyway, since dpkg just execs that for -l
[12:35] <cjwatson> try something like  sudo gdb --args /mnt/natty-chroot/usr/bin/dpkg-query --admindir=/mnt/natty-chroot/var/lib/dpkg -l
[12:35] <cjwatson> in fact I suspect you won't even need --admindir
[12:36] <ogra_ac> ah, yeah, that seems to be better ... i need the ddeb though
[12:36]  * ogra_ac goes fiddling
[12:37] <cjwatson> hm, actually, I don't see how it can be scandir either
[12:37] <cjwatson> if it were due to that patch, we'd at least see it opening /var/lib/dpkg
[12:38] <ogra_ac> it does that if i dont use -l
[12:38] <cjwatson> well, let's try to explain one segfault at a time though
[12:38] <ogra_ac> http://paste.ubuntu.com/529315/
[12:38] <ogra_ac> thats for the command debootstrap tries to run
[12:38] <cjwatson> still not in scandir
[12:38] <cjwatson> that's just lock stuff in filesdbinit
[12:39] <ogra_ac> ah, k
[12:39] <cjwatson> I mean modstatdb_init
=== yofel_ is now known as yofel
[12:43] <ogra_ac> geez
[12:43] <ogra_ac> SIGILL
[12:44] <ogra_ac> http://paste.ubuntu.com/529317/
[12:47] <ogra_ac> oh
[12:47] <cjwatson> maybe executing natty binaries directly from whatever your host system is is not in fact a recipe for glorious success?
[12:48] <ogra_ac> running "run -l 2>&1 | tee ~/gdb-dpkg.txt" gets me proper output
[12:48] <cjwatson> in which case, copy your gdb binary into your chroot and hope it doesn't need too much else :-)
[12:48] <ogra_ac> same command but 2>&1 | tee ~/gdb-dpkg.txt added
[12:49] <ogra_ac> hmm, weird, that seems to have run on the host
[12:49] <ogra_ac> and now it works every time
[12:49]  * ogra_ac doesnt get that
[12:51] <ogra_ac> yeah, it now seems to access the hosts database etc
[12:52] <ogra_ac> now it doesnt anymore
[12:52] <ogra_ac> hrm, whats up here
[12:52] <ogra_ac> using run -l one time accesses the host and the next time it doesnt
[12:52] <ogra_ac> and its not reliable reproducable
[12:54] <ogra_ac> i guess i better build a maverick chroot, upgrade that and run all that stuff fully chrooted
[12:54]  * ogra_ac tries that
=== dendro-afk is now known as dendrobates
[13:11] <roxdragon> hi
[13:12] <bilalakhtar> pitti: Speaking about bug #323815, I fixed it long ago in bug #616569 but it appeared that the patch modified the UI file, and a subroutine later set the title back to "" . Do you think I am right? I have a fix ready in a branch
[13:12] <ubottu> Launchpad bug 323815 in jockey (Ubuntu) "Install progress window has no title" [Low,In progress] https://launchpad.net/bugs/323815
[13:12] <ubottu> Launchpad bug 616569 in jockey (Ubuntu) "hardware drivers shows window called untitle windows at scaning/download drivers (dup-of: 323815)" [Low,Fix released] https://launchpad.net/bugs/616569
[13:14] <ogra_ac> cjwatson, so upgrading a mavercik chroot to natty i dont get any issues and given that dpkg under gdb with a half debootstrapped chroot behaves differently at every run i'm inclined to suspect a race
[13:16] <pitti> bilalakhtar: I saw your MP, will follow up there after lunch; thanks!
[13:16] <bilalakhtar> pitti: you're welcome
[13:16] <cjwatson> ogra_ac: it could be something that only breaks with certain status files
[13:17] <ogra_ac> well, i can run it under gdb and get different results every run, do the status files change every time ?
[13:17] <ogra_ac> i would have assumed its the same one
[13:18]  * ogra_ac tries another debootstrap to monitor the status file 
[13:19] <cjwatson> you're the one best placed to figure out what the problem is I suspect
[13:20] <cjwatson> but it happened to every armel debootstrap attempt in today's livefs builds, as far as I can see, so if it's a race then we normally lose it
[13:20] <ogra_ac> right, its reliably failing in debootstrap, just not in gdb
=== seb128_ is now known as seb128
[13:26] <ogra_ac> cjwatson, got it !
[13:26] <ogra_ac> cjwatson, the status file in natty misses a final newline
[13:27] <ogra_ac> err, no, sorry to many chroots around, i looked at the wrong one
[13:29] <roxdragon> !bug
[13:29] <ubottu> If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
=== jelmer_ is now known as jelmer
[13:31] <cjwatson> roxdragon: were you talking to ogra_ac?  he and I are discussing this problem, it's fine for it to stay here
[13:32] <ogra_ac> wow
[13:32] <ogra_ac> copying the status file from the host makes it not segfault
[13:33] <ogra_ac> so i guess you are right
[13:33] <roxdragon> yes cjwatson  ;)
[13:34] <ogra_ac> copying the old one back gets me the segfault back
[13:35] <ogra_ac> copying the one from the upgraded maverick chroot works too
=== MacSlow|lunch is now known as MacSlow
[13:42] <roxdragon> hi 11.04 testing?
=== jorge is now known as jcastro
[13:47] <ogra_ac> cjwatson, soo ... weird but true, the segfault vanishes if i manually add Maintainer and (short) Description to the status file
[13:48] <cjwatson> that's interesting, because there was a change in that area in 1.15.8.5 - but we'd already backported it to maverick as 1.15.8.4ubuntu2 a few months ago
[13:48] <ogra_ac> http://paste.ubuntu.com/529332/
[13:48] <ogra_ac> well, did we bootstrap any images since ?
[13:48] <cjwatson> every livefs build, yes
[13:48] <ogra_ac> weird
[13:49] <ogra_ac> it reliably fails if i remove either of the fields
[13:49] <cjwatson> can you tar up the broken /var/lib/dpkg (without your workaround) and put it somewhere for me?
[13:49] <cjwatson> I can see if I can reproduce it on kakadu, for instance
[13:50] <ogra_ac> i can just bootstrap a fresh one one sec
[13:53] <stgraber> Is it possible that icedtea6-plugin as been deprecated in favour of icedtea-plugin ? it's making the edubuntu daily build to fail because icedtea-plugin is pulled by something and conflicts against icedtea6-plugin (which is explicitly seeded)
[13:54] <stgraber> from what I see in the seeds, it should affect all DVD builds, not only Edubuntu
[13:54] <cjwatson> yes, but it's a bug that it fails this way
[13:54] <cjwatson> the Conflicts in icedtea-plugin should be versioned to less than the version where it became a transitional package - could you make sure that there's a bug filed on icedtea-web about this?
[13:55] <cjwatson> shows up in http://people.canonical.com/~ubuntu-archive/testing/natty_probs.html too
[13:56] <stgraber> ok, I'll quickly check if someone already reported it and if not, will file a new one
[13:57] <stgraber> should the seeds be changed to icedtea-plugin anyway ?
[13:57] <cjwatson> yeah
[14:05] <stgraber> bug 673524
[14:05] <ubottu> Launchpad bug 673524 in Ubuntu "Unversioned conflict between icedtea-plugin and icedtea6-plugin making transitional icedtea6-plugin uninstallable" [Undecided,New] https://launchpad.net/bugs/673524
[14:05] <stgraber> argh, forgot to open against icedtea ... fixing that
[14:05] <stgraber> (was doing an ubuntu-wide bug search before, so "File a bug" opened it against ubuntu ...)
[14:13] <ogra_ac> cjwatson, natty-cjwatson-dpkg.tgz in /home/ogra on kakadu
[14:14] <cjwatson> I really did just need /var/lib/dpkg, but thanks :)
[14:14] <ogra_ac> heh
[14:14] <ogra_ac> note that chroot is using my local mirror
[14:15] <ogra_ac> well, approx instance
[14:15] <ogra_ac> so sources.list and apt lists might differ
[14:15] <cjwatson> I removed everything except /var/lib/dpkg so it doesn't matter
[14:15] <ogra_ac> k
[14:16] <cjwatson> building a debug dpkg now
=== dendrobates is now known as dendro-afk
[14:29] <lool> doko, cjwatson: Hey, how much do you two care about lp:~ubuntu-core-dev/eglibc/eglibc-2.12-pkg ? I currently can't branch from it (some bzr error when doing on the fly format conversion) so I was about to upgrade it, but I wonder whether we should just abandon it and move to lp:ubuntu/eglibc instead
[14:32] <cjwatson> lool: I haven't touched it for some time
[14:33] <doko> it works for me
[14:43]  * lool upgrades the old packaging branch to see if anything needs to be rescued fro mthere
[14:44] <ScottK> ogra_ac: I'm catching up on yesterday's IRC logs and saw the discussion you had with Riddell/NCommander on arm status.  Currently none of the arm FTBFS are due to the qreal issue, they are all due to the CXXFLAGS issue that doko is looking into.
[14:45] <ScottK> ogra_ac: Upstream KDE accepts that the qreal issues we see are valid bugs that they shouldn't cause.  I'm working on an upstream KDE arm buildbot so they can discover this stuff before we get it here and the amount of rework we need to do in the future will be reduced.
[14:46] <ogra_ac> ScottK, upstream QT agrees that it should be fixed in QT though
[14:46] <ScottK> ogra_ac: Yes, but in Qt5.
[14:46] <ogra_ac> they just cant do that atm for historical reasons
[14:47] <ScottK> We can't either for the same reasons.
[14:47] <ogra_ac> and asked us a year ago to carry it as a distro patch for armel only
[14:47] <ogra_ac> its just insane that we spend several mandays every release to adjust the application patches
[14:47] <ogra_ac> and i really expect that to hit us again once the flags are fixed
[14:48] <ScottK> ogra_ac: It's not adjusting application patches.  The ones we find are all upstreamed, the problem is new occurences.
[14:48] <ScottK> That's why I hope that if we can build the upstream source regularly, before we get it, the amount of trouble we see will go down.
[14:49] <ogra_ac> right, still i would like us to fix the core of the prob if thats possible
[14:49] <ogra_ac> and according to linaro it isnt to hard
[14:50] <ScottK> Isn't hard to fix and maintain ABI?
[14:50] <ogra_ac> it would break the ABI on arm
[14:50] <ogra_ac> but only there
[14:50] <ogra_ac> and given that we rebuild the world anyway i doubt it matters much
[14:51] <ScottK> Not all software lives in the Ubuntu archive.
[14:51] <ogra_ac> as ?
[14:52] <ogra_ac> for binary compatibility you have to rebuild anyway
[14:52] <ScottK> I don't intend to get into a debate about how which apps that aren't in Ubuntu are used on arm.  Use of third party repositories is quite normal and supported.
[14:52] <ogra_ac> and ISVs dont offer any ubuntu arm stuff
[14:53] <ScottK> And vendors are all we care about?
[14:53] <ogra_ac> no
[14:54] <ScottK> ogra_ac: I think we will have to agree to disagree on the importance of maintaining ABI.
=== virtuald_ is now known as virtuald
[14:54] <ogra_ac> well, asac is tasked to talk to thiago next week in person aboout it
[14:54] <ogra_ac> lets see what comes out of that
[14:54] <ScottK> I did want to let you know that I'm working on getting these qreal problems more visibility in upstream KDE so there is some reason to expect it to get better.
[14:54] <ScottK> OK.
[14:55] <doko> ScottK, Riddell: the current CXXFLAGS "problem" is one in qt
[14:55] <ogra_ac> i want to follow what upstream suggests here
[14:55] <ogra_ac> (who were first in suggesting the change to us initially)
[14:56] <ScottK> doko: Right, the question is what to do about working around it.  Do we have to modify debian/rules for several dozen packages or will it go back in defaults.
[14:56] <doko> pitti: why the limitation to 10 changelog entries? I would prefer to keep the entries of the current and the last release
[14:58] <doko> ScottK: so when would you change it?
[14:58] <ScottK> doko: You are asking when we'd stop carrying the work around?
[15:01] <pitti> doko: well, you can define an arbitrarily complex condition which ones to keep; 10 should be quite enough to see the recend development?
=== achiang` is now known as achiang
=== bigon is now known as fred2kboulot_
=== fred2kboulot_ is now known as bigon
[15:07] <doko> pitti: well, make it the maximum of 10 and what I propose.
[15:07] <doko> apt-listchanges should still work
[15:07] <doko> for distro upgrades
[15:07] <ebroder> pitti: thanks for the sponsorship. i'll be sure to forward the patch on
[15:09] <doko> pitti: do you re-join the MIR team?
[15:21] <apachelogger> jcastro: ping, do you happen to know whether the audio streams from uds got recorded?
[15:21] <jcastro> I don't think they did
[15:21] <ogra_ac> oh, that will make NCommander cry
[15:22] <ogra_ac> he lost his notes
[15:22] <jcastro> gobby accident?
[15:22] <ogra_ac> no idea
[15:22] <ogra_ac> gobby doc is empty
[15:22] <ogra_ac> so might well be
[15:22] <ogra_ac> or notes were taken locally and lost
[15:23] <apachelogger> having recordings would be very useful indeed, notes can be too limiting on complex matters ^^
[15:24] <tumbleweed> apachelogger: I have recordingns of the second half, http://mirrors.tumbleweed.org.za/uds-n/
[15:24] <jcastro> apachelogger: someone from IS would be the best to ask
[15:25] <apachelogger> tumbleweed: groovy, cheers
[15:26] <barry> mvo: hi!  have you seen: https://code.launchpad.net/~barry/update-manager/673297-py27/+merge/40510
[15:26] <apachelogger> jcastro: something to look into for next UDS for sure
=== dendro-afk is now known as dendrobates
[15:30] <mvo> barry: no, looking now
=== zyga is now known as zyga-lunch
=== bjf[afk] is now known as bjf
[15:39] <pitti> doko: fixing apt-listchanges is on the TODO list
[15:39] <pitti> ebroder: thanks
[15:39] <pitti> doko: wasn't planning to actually; SRU kills too much of my time already
=== bilalakhtar_ is now known as bilalakhtar
[15:43] <jcastro> mvo: we're so close, all you need to do now is enable the apt zeroconfing bits by default!
=== ssweeny_ is now known as ssweeny
[15:52] <ScottK> doko: I know the proper fix for the Qt IT issue is to implement it upstream, but in the mean time, do you want us to modify all the affected packages or will you put it back in the GCC defaults?  We can do either, we just need to know.
[15:59] <psusi> pitti: weren't you working on auto mount of esata drives?  I did some digging and it seems that AHCI has the ability to report that a port is external, but the kernel driver doesn't bother checking that bit
[16:02] <pitti> psusi: "working" is a bit too much; I looked at it back then, and found that there's currently no way to tell
[16:02] <pitti> if this can be exported in /sys, that'd help much, of course
[16:11] <highvoltage> doko: hey, are you around?
=== dendrobates is now known as dendro-afk
=== beuno is now known as beuno-lunch
[16:18] <micahg> pitti: is there a problem w/SRUing new binaries either through -updates or -security?
[16:19] <pitti> micahg: not a technical one, but we try to avoid it if at all possible
[16:19] <ScottK> pitti: It's for new translations (why he's asking)
[16:19] <micahg> pitti: the case is newer thunderbird translations when we move to Thunderbird 3.1
[16:19] <micahg> * extra languages
[16:20] <pitti> that sounds fine
[16:20] <micahg> pitti: ok, thanks
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[16:42] <cjwatson> barry: gnome-python and dbus-python uploaded
[16:45] <cjwatson> Keybuk: so, watching with dbus-monitor - am I right in believing that there are dbus signals for job instances being added and removed, but that that doesn't really necessarily correspond to jobs being started and stopped (for plymouth integration)?
[16:45] <cjwatson> Keybuk: maybe a signal for each state change or something would be best?
[16:45] <Keybuk> right, that might be the "missing piece"
[16:45] <psusi> pitti: that is what I thought... the external bit should be exported somehow in /sys so you can tell it should be auto mounted... but I also thought even if the hardware can't tell us the port is external, if a sata drive appears after boot, maybe we could pop up and ask the user if that port is external, and set a persistant storage rule to set the extern flag anyhow for future use
[16:46] <Keybuk> state is a property, so it'd be a property changed signal
[16:46] <cjwatson> one of these days I must learn dbus properly
[16:46] <cjwatson> slightly embarrassing
[16:47] <ogra_ac> use dfeet :)
[16:47] <cjwatson> is property-changed a standard thing?
[16:47] <cjwatson> I know about d-feet; my comprehension hole is a bit more general
[16:48] <cjwatson> hm, PropertyChanged ought not to require specific upstart support from what I'm seeing
[16:49] <cjwatson> PropertiesChanged that is
=== zul_ is now known as zul
[16:53] <slangasek> could someone here who writes better German than me fix http://wiki.ubuntuusers.de/Plymouth to not include made-up "noplymouth" boot options?
[16:57] <cjwatson> actually maybe it does need a bit of upstart support
=== zyga is now known as zyga-gone
=== beuno-lunch is now known as beuno
[17:06] <Keybuk> cjwatson: huh?
[17:06] <Keybuk> yeah it needs libnih-dbus support or upstart support or something
[17:06] <Keybuk> as I said at UDS, I couldn't remember whether I put it in there or not
[17:06] <Keybuk> and if I didn't, it's literally a one-line patch
[17:08] <cjwatson> Keybuk: wouldn't it need everything that does job->state or equivalent to be converted to using a setter function of some kind?
[17:09] <Keybuk> fortunately I am a kick-ass, stellar programmer
[17:09] <Keybuk> one of the best in the known universe
[17:09] <Keybuk> and there is only one place in all of Upstart that changes job->state
[17:09] <Keybuk> job_change_state()
[17:09] <cjwatson> ./init/job.c:108:       job->state = JOB_WAITING;
[17:09] <cjwatson> ./init/job.c:289:               job->state = state;
[17:09] <Keybuk> which is pretty much the core function as far as jobs go, in fact
[17:09] <cjwatson> oh, you meant one function :-)
[17:09] <Keybuk> the first one of those is job_new() so doesn't count
[17:10] <cjwatson> fair point
[17:10] <cjwatson> and I don't think we need to know about goal changes
[17:10] <Keybuk> no, indeed
[17:10] <cjwatson> in that case I concede your self-aggrandisement ;-)
[17:11] <Keybuk> all you should need to do is add a signal tag to dbus/com.ubuntu.Upstart0_6.Instance.xml
[17:11] <Keybuk> then add a function call in job_change_state
[17:12] <Keybuk> err, dbus/com.ubuntu.Upstart.Instance.xml
[17:12] <Keybuk> something like
[17:12] <cjwatson> dbus 1.4 made PropertiesChanged a standard signal on org.freedesktop.DBus.Properties
=== dendrobates is now known as dendro-afk
[17:13] <cjwatson> do you want to follow that?  since if so it shouldn't be in com.ubuntu.Upstart0_6.Instance.xml AIUI
[17:13] <Keybuk> yeah, but that would need teaching libnih-dbus about it
[17:13] <Keybuk> which would be ... harder
[17:13] <Keybuk> for 0.6, may as well just add a custom signal
[17:13] <cjwatson> ok, fair enough
[17:13] <cjwatson> I should be able to manage the rest of that then, thanks
[17:13] <Keybuk> so if you have
[17:13] <Keybuk> <signal name="StateChanged">
[17:14] <Keybuk>   <arg name="state" type="s">
[17:14] <Keybuk> </signal>
[17:14] <Keybuk> or sometihng
[17:14] <Keybuk> then the matching function call in job_change_state() would be
[17:15] <Keybuk> NIH_LIST_FOREACH (control_conns, iter) {
[17:15] <Keybuk>   NihListEntry *entry = (NihListEntry *)iter;
[17:15] <Keybuk>   DBusConnection *conn = (DbusConnection *)entry->data;
[17:15] <Keybuk>   job_emit_state_changed (conn, job->path, job_state_name (job->state);
[17:15] <Keybuk> }
[17:15] <Keybuk> ok
[17:16] <Keybuk> a bit more than one line to cope with the multiple connections
[17:16] <cjwatson> and I get to write the boring test case, right? :)
[17:16] <Keybuk> yup :p
=== elmo_ is now known as elmo
[17:35] <bilalakhtar> doko: there? It appears that you recently NMUed a change to package libtuxcap in Debian. Yet, the change wasn't made, could you please check?
[17:38] <cjwatson> Keybuk: would you prefer separate tests for the case where a dbus connection is open, or shall I just extend test_change_state to check signal emission in each test along the way?
[17:38] <cjwatson> I started with the former but I think the latter might be less wordy
[17:38] <Keybuk> there's a *LOT* of test cases in test_change_state
[17:39] <Keybuk> it depends whether you want to "test that a signal is emitted for a state change"
[17:39] <bilalakhtar> How do I try and find out the changes made to a debian package in a particular version?
[17:39] <Keybuk> or "test the specific set of signals are emitted for each given state change"
[17:39] <Keybuk> e.g. in test_change_state you're going to have to deal with the cases where a job undergoes multiple state changes in any one test
[17:39] <bilalakhtar> its difficult to navigate through Debian packages as they don't have something like LP for all packages
[17:39] <Keybuk> so check for multiple signals
[17:39] <cjwatson> the interaction between StateChanged and InstanceRemoved seems slightly worth testing
[17:40] <cjwatson> bilalakhtar: packages.qa.debian.org/<package> may be helpful
[17:40] <Keybuk> I've tended so far (iirc) to just test the signals are emitted independantly of the state mechanics
[17:40] <bilalakhtar> cjwatson: but it doesn't show the debdiff between versions
[17:40] <Keybuk> but icbw, haven't looked at those tests in a while
[17:41] <tumbleweed> bilalakhtar: snapshot.debian.org
[17:41] <dannf> bilalakhtar: if you need to compare actual source (not trusting the changelog) you can pull versions from snapshot.debian.org & debdiff 'em
[17:41] <bilalakhtar> thanks tumbleweed and dannf
[17:41] <bilalakhtar> dannf: yes, I am sure a changelog entry is misleading
[17:41] <cjwatson> bilalakhtar: or http://patches.ubuntu.com/by-release/atomic/debian/, or bzr get lp:debian/<package>
[17:45] <lool> doko: I started reviewing the Debian -> Ubuntu eglibc diff, and I'm now trying to minimize it to ease merges and be in a position to document what changes we carry over Debian; do you mind if I drop lpia support in the next natty eglibc upload?
=== robbiew is now known as robbiew-lunch
[17:57] <kees> hallyn: say, where is the code in the kernel for "if both fscaps and setuid, ignore setuid"?
[18:01] <kees> hallyn: ah, found it: b5f22a59c0356655a501190959db9f7f5dd07e3f
[18:01] <bilalakhtar> doko: so the libtuxcap debdiff between your NMU and the previous one doesn't contain the B-d change
[18:01] <hallyn> kees: why, has that been accidentally undone?
=== Ian__ is now known as Ian_Corne
[18:02] <bilalakhtar> please look at it, since the patch is now made to modify the thing according to 2.6, but the package doesn't b-d on 2.6
[18:07] <kees> hallyn: no, I just wanted to point it out to someone (oss-security mailing list discussion on filesystem capabilities)
=== al-maisan is now known as almaisan-away
[18:18] <psusi> pitti: is it /sys/block/sda/removable that is checked to see if the drive should be auto mounted?
[18:23] <pitti> psusi: yes
[18:23] <pitti> psusi: that and the drive type (USB/firewire are removable)
[18:24] <psusi> hrm... looking at the scsi layer code, it seems that removable really means that the MEDIA can be removed... but what we're dealign with is really hot plugging the hole drive, so flagging it as removable doesn't really seem correct
[18:25] <pitti> psusi: ah, right
[18:25] <pitti> psusi: we need a new flag for that then
[18:25] <pitti> psusi: so far udisks considers the bus type for the "hotpluggable" property
[18:26]  * pitti -> Taekwondo and off for the night, see you tomorrow
[18:26] <psusi> o/
[18:33] <lool> doko: Similary, do you care to keep the sparc flavors?
[18:34] <mdz> tkamppeter, around?
[18:42] <tkamppeter> mdz, hi
[18:45] <mdz> tkamppeter, I've brought home an HP DeskJet 3050 which requires hplip 3.10.9. do you know when the new version will be available in Debian and Ubuntu?
[18:51] <mdz> tkamppeter, or maybe in a ppa?
[20:16] <ScottK> ogra_ac: Someone hand built the rest of KDE on Natty with implicitIT=thumb and they didn't hit any qreal porting issues, so at least so far that doesn't seem to be an issue in Natty.
=== zyga-gone is now known as zyga
=== Pendulum_ is now known as Pendulum
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
[22:20] <arek_deepinit> can anyone tell me what is default version of glib installed with 10.04?
[22:21] <arek_deepinit> please
=== dendro-afk is now known as dendrobates
[22:29] <ajmitch> arek_deepinit: from the look of things, 2.24.0 in lucid, 2.24.1 in lucid-updates
[22:30] <cjwatson> ~.
[22:30] <cjwatson> ~.
[22:30] <arek_deepinit> great, thx ajmitch
=== dapal is now known as [dapal]
[22:32] <ion> cjwatson: It’s beneficial to switch to something like the status window first, otherwise that’s bound to happen sooner or later. ;-)
[22:42] <cjwatson> ion: drat
[22:44] <cjwatson> (for the record, that was the fault of https://bugs.maemo.org/show_bug.cgi?id=6009, which still isn't fixed ...)
[22:44] <ubottu> bugs.maemo.org bug 6009 in X Terminal ""Enter" key sends wrong keycode to console applications" [Normal,New]
[22:48] <NCommander> ogra: I already told you that yesterday ;_P
=== bjf is now known as bjf[afk]
=== dendrobates is now known as dendro-afk
[23:28] <Drakeson> is appmenu broken with emacs ?
[23:30] <Drakeson> Where should I discuss issues with Unity?
[23:35] <mwhudson> Drakeson: it works ok for me i think?
[23:36] <mwhudson> not that ever actually use the menu in emacs at all ever
[23:36] <Drakeson> mwhudson: oh, mine has a serious problem leading to segfault
[23:36] <Drakeson> for example, if I switch to another buffer the menu does not change
[23:37] <mwhudson> ah yeah, seems you're right there
[23:37] <mwhudson> doesn't segfault for me though
[23:37] <Drakeson> It doesn't segfault immediately
[23:38] <Drakeson> it does after a while of usage
[23:38] <Drakeson> I depend on emacs, so that is serious for me
[23:40] <Drakeson> are Super+S and Super+M gone for good?
[23:41] <Drakeson> Anything other than Super+1,2,...,Super+0 doesn't seem to work with Super.
[23:43] <Drakeson> I have already tried #ubuntu-unity and #unity.  Where else should I seek the culprit(s)? :p
[23:45] <kklimonda> I've reported one bug on appmenu-gtk where some emacs menus are empty
[23:46] <kklimonda> Drakeson: I'd report a bug
[23:48] <Drakeson> kklimonda: sure, only if I know which package is the faulty.  I cannot figure out the relation between appmenu, appmenu-gtk, libfamd, and a couple more.
[23:49] <Drakeson> could you please direct me to the unity channel?
[23:50] <kklimonda> Drakeson: when it crashes it should generate a report (if it doesn't enable apport and recreate it) and you can send it to launchpad