bdmurrayokay, I was / am considering a bug pattern00:00
bdmurrayslangasek: I noticed there is no update-manager apport hook in Lucid and thought the best way to get it in there would be an SRU of update-manager.  However, I'm confused about how far behind the lucid bzr branch for update-manager is.00:21
bdmurrayah, its me00:22
psusiwait... when a package is synced from debian, it's just the source right, the binaries are still rebuilt for ubuntu right?00:49
micahgpsusi: correct00:50
=== cyphermox_ is now known as cyphermox
YokoZarslangasek: What do you think of apt automatically transitioning users of amd64 packages to i386 packages on dist-upgrade if 1) the i386 is higher version, and 2) the currently used architecture is not available in any pool ?01:36
YokoZarI'm thinking of issues where we, say, delete zsnes:amd64 from the archive and the amd64 lucid user needs to be migrated to zsnes:i386.01:37
* micahg debates taking an axe to zsnes01:40
slangasekYokoZar: I reserve judgement; we'd have to have a good long think about whether this is always the right thing to do02:02
slangasekYokoZar: btw, are you planning to complete the work item from https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default that you accepted at UDS? (announce intentions to move to 64-bit by default)02:04
infinityYokoZar: That would fail pretty spectacularly if Packages-amd64.gz got corrupted in transit or something, leaving you with "no amd64 packages in the pool".02:06
YokoZarslangasek: infinity: Yeah I suspect we'll run into questions about manually installed debs and what if we can't figure out the "available pool" properly and so on02:06
YokoZarslangasek: ~ work items, thank you for reminding me.  I was trying to check on the work items I might have missed and for some reason I wasn't coming up in the work item tracker02:07
infinityYokoZar: I think the saner (for some value of "sane") option for now is to take it case-by-case and provide cross-arch transitional packages.02:07
slangasekYokoZar: tracker> ah, that'll be my fault for not getting the blueprint shoved along to "approved" state02:08
slangasekinfinity: but you can't have a transitional package depending of a foreign package of a *specific* architecture presently, so each one of those would require a package name change02:08
slangasekwhich isn't pleasant02:08
YokoZarinfinity: but we can't have specific arch dependencies, so the transitional package would have to be a different name than the existing package....02:08
infinityYokoZar: Not that I find the cross-arch deps particularly elegant, but they're much more fool-proof.  And the corner cases surrounding how dpkg and apt determine "availability" are many.02:08
YokoZarThe uglier solution is just a big manual hard-coded list in update-manager :/02:09
infinityYokoZar: Well, the transitional package would be the old name, and it would depend on zsnes-i386, I guess?02:09
YokoZar(which doesn't work for dist-upgrade, which is why I suggested modifying the apt resolver)02:09
YokoZarinfinity: right, and then we'd have to rename zsnes to zsnes-i386 :/02:09
infinityI did note that it fails the elegance test.02:10
infinityBut it's at least easy to spot-check for correctness.02:10
YokoZarinfinity: you can look at the new wine1.4 package for a similar setup02:10
infinityThe proposed apt change is immediately incorrect in several corner cases, without looking for weirder ones.02:10
micahgYokoZar: alternatively, you can fix the amd64 build so that it builds the arch specific parts if there are any02:10
YokoZarmicahg: but there aren't any, zsnes is a good example because it's an i386 only package that we had a fake ia32-libs solution for in the past02:11
infinity(Out of curiosity, why would this be done to zsnes?  Does the 64-bit build not work?)02:11
infinityOh, there isn't a 64-bit build, I see.  That seems odd, given that it's an emulator. :P02:11
YokoZarinfinity: zsnes does not and will not build on amd64 ever, I think it's full of assembly code or some such.02:11
infinityFair enough.02:12
micahgYokoZar: you can do what we did with flash, if you can get it to compile again :)02:12
infinityStill sounds like it should just be dealt with the same way flash is.02:12
infinityThe same way we did flash in oneiric, that is.02:12
infinityBefore we had a 64-bit one.02:12
ScottKBurn it with fire/02:12
ScottKOh, that's not what you meant.02:13
micahgzsnes:amd64 depends zsnes-i386 (i386 only) which depends on zsnes:i38602:13
infinitymicahg: Makes the packaging a bit more complex, since zsnes.install differs on the two arches.02:13
infinitymicahg: I don't see the point in the last dependency.  Just put the binaries in zsnes-i386 and have it replace zsnes (<< pre-split-version).02:14
YokoZarmicahg: yeah that would work, I suppose, but then we're left carrying two dummy packages for an indeterminate amount of time.  Especially because there's no way for zsnes:i386 to declare that it replaces and obsoletes zsnes:amd64 (and indeed apt will try to keep them in sync at the same version and complain about any change that removes empty zsnes:amd64)02:14
micahginfinity: that works too, but I hate the idea of having a zsnes-i386 package in perpetuity02:15
YokoZarinfinity's solution is a bit better but leaves us with dumb names forever02:15
infinitymicahg: Who cares?  Package names are often weird.02:15
micahgit's a diff from Debian02:15
infinitySo, convince the Debian maintainer to do the same thing.02:15
infinityBut it's not actually a large diff.02:15
YokoZarOR, we could implement specific arch relationships in control fields...02:15
micahgwell, now that Debian will soon have a multiarch capable dpkg, that might be possible :)02:16
YokoZarBy the way I didn't really appreciate how far ahead we were with multiarch than Debian until now.  I had been waiting for multiarch for a long time to make a proper wine64 package, and it finally got accepted today :)02:17
infinityThere's a certain advantage in not having individual package maintainers, yes.02:18
infinityDownside: Lots of universe bugs go ignored.  Upside: When we want to move on something, we MOVE.02:18
ScottKinfinity: Lots of Main bugs go ignored too.02:25
justgordAny ubuntu dev working groups focussed on tablets and/or wayland  ?02:29
nidsubhola, i hope there someone out there who could help me :)05:02
nidsubim sorry ,but im really new to irc05:02
nidsubshould i just post my problem here?05:02
nidsubim trying to build linux kernel05:03
nidsubhere is the error i get,please  point out what did i do wrong05:03
nidsub-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ make ARCH=arm05:04
nidsubmkdir: cannot create directory `include/generated': Permission denied05:04
nidsubmake[2]: *** [silentoldconfig] Error 105:04
nidsubmake[1]: *** [silentoldconfig] Error 205:04
nidsubmake: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'.  Stop.05:04
nidsubnidhal@nidhal-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm05:04
nidsubscripts/kconfig/conf --silentoldconfig Kconfig05:04
nidsub  CHK     include/linux/version.h05:04
nidsub  UPD     include/linux/version.h05:04
nidsub  CHK     include/generated/utsrelease.h05:04
nidsub  UPD     include/generated/utsrelease.h05:04
nidsub  Generating include/generated/mach-types.h05:04
nidsub  CC      kernel/bounds.s05:04
nidsubcc1: error: unrecognized command line option ‘-mlittle-endian’05:04
nidsubcc1: error: unrecognized command line option ‘-mno-thumb-interwork’05:04
nidsubkernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch05:04
nidsubkernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch05:04
nidsubmake[1]: *** [kernel/bounds.s] Error 105:04
nidsubmake: *** [prepare0] Error 205:04
nidsubplease :(05:04
micahgnidsub: first error is you didn't use a pastebin for that05:05
micahgas for the rest, is this on an arm system or are you cross compiling05:06
nidsubthank you :),yerp im trying to cross compile05:06
nidsubis on arm qemu05:07
nidsubhere the detail on the step i took ..from this webpage05:08
micahgwell, this isn't a general support channel, #ubuntu-arm might be better suited05:12
micahg#ubuntu would be for general support, but I don't see this working out too well in there05:12
nidsubThanks you so much for the tips05:15
=== yofel_ is now known as yofel
=== tkamppeter_ is now known as tkamppeter
=== ts2 is now known as tsimpson
goddardI'm trying to use debuilder but it doesn't seem to be creating my deb file although i get no errors07:10
pittiGood morning07:32
SweetsharkMorning everyone!07:40
Sweetsharkhttp://twitter.com/#!/gregkh/status/166644258831478784 <- yay, gregkh -- of kernel fame -- contributing to LibreOffice ...07:44
=== smb` is now known as smb
=== jodh is now known as jhunt`
=== jhunt` is now known as jhunt_
pittiDaviey: mariadb> as it is 100% binary compatible, I think there is some good grounds for a FFE on this one10:00
pittiDaviey: my bigger concern there would be how much commercial backing mariadb has, i. e. whether there are stakeholders which we can believe are still active in 5 years10:00
Davieypitti: need to discuss this in a bit. :)10:01
seb128- /usr/lib/debug/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.010:13
seb128+ /usr/lib/debug/.build-id/5e/d483e11d8dbaff9929c94ad6b9b05a174c7685.debug10:13
pittiI noticed the new /usr/lib/debug/.build-id/ gibberish recently, too10:13
seb128is that something which changed in our toolchain (it's libsoup2.4-dbg new version)10:13
pittiI have no idea what changed there10:14
seb128hum, k10:15
seb128well I will assume it's not a bug on my side then ;-)10:15
debfxseb128: it's a new debhelper 9 behavior10:17
seb128debfx, ok, thanks10:17
seb128  * dh_strip: In v9, pass --compress-debug-sections to objcopy.10:18
seb128I guess10:18
seb128that source is v910:18
pittiso this stuff is actually valid?10:18
seb128debian bug 63198510:18
ubottuDebian bug 631985 in debhelper "dh_strip: add a possibility to compress debug sections" [Wishlist,Fixed] http://bugs.debian.org/63198510:18
pittiit seems a ridiculously bad design to put this in a hidden  directory10:18
seb128with useless names...10:19
=== _salem is now known as salem_
=== Chipzz is now known as Chipzz_
=== Chipzz_ is now known as Chipzz
pitticking: FYI, I'm currently working on https://launchpad.net/fatrace12:06
pitticking: as powertop seems to do a rather bad job at catching disk events (and even reports them wrongly, too)12:06
pitticking: once it's ready and in the archive, I'll update https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues accordingly12:06
ckingpitti, wow, this is excellent!12:06
pitticking: fanotify is quite nice for this :)12:07
pitticking: if you are interested in trying, it's in lp:fatrace; make && sudo ./fatrace12:08
ckingyep, this is an excellent tool to track down these offending wakeups!12:08
pittiit has --time and --output options, and I'm going to add some filtering, too12:08
pitticking: well, it's not process wakeups (that's powertop), just disk events12:08
pitti"f"ile "a"ccess trace12:09
pitticking: if you want it to do something more (new option, etc.), please let me know12:09
ckingpitti, does the -o option interfere with the results - i.e. it could write the output to disk and hence change the stats12:12
pitticking: no, it ignores its own events12:13
pitticking: without -o, gnome-terminal touches a tempfile in /tmp/ with every output, and thus generates a feedback loop12:13
pitti-o avoids this, but I'm trying to add something more clever12:14
ckingyep, I saw that and wonder what was happening12:14
pittiwell /tmp tmpfs definitively helps12:14
pittibut we don't have that by default12:14
pitticking: --ignore-pid could work12:14
pitti--ignore-path /tmp/ sounds a bit pointless12:15
pitti(but might make sense for other contexts)12:15
pittiby default it watches all "real" mounts12:15
pittiit could grow an option to only watch the mount of current cwd12:15
ckingperhaps adding a timestamp to the output so we can figure out if events occur periodically may help12:16
seb128pitti, bug #928212 hate gzip hate12:16
ubottuLaunchpad bug 928212 in gtk+2.0 (Ubuntu) "Cannot install ia32-libs due to libgtk2.0-0_2.24.10-0ubuntu1_i386.deb conflicts with libgtk2.0-0_2.24.10-0ubuntu1_amd64.deb" [Undecided,New] https://launchpad.net/bugs/92821212:16
pitticking: ah, good idea12:18
ckingpitti, it does generate quite a bit of data on a busy machine - perhaps producing a summary sorted on the worse behaving process could be handy too12:19
pitticking: it's not supposed to be the preferred frontend12:20
pitticking: I have another WI to write a script that calls powertop, fatrace, and generate a report out of it12:20
pittiwith worst offenders, sorted, etc.12:20
ckingpitti, ah, I understand - good idea!12:20
pitticking: I really don't want to do all this in plain C :)12:21
=== zyga_ is now known as zyga
ckingpitti, if we are going to use tools like powertop perhaps we need to ensure they work correctly - anecdotal evidence seems to tell me that some of the data may not be trustworthy12:28
pitticking: yes, like the file accesses12:28
pittiwakeups seem to be quite reliable, though?12:28
ckingand battery power consumption too12:28
ckingwakeups work well as it does cater for a wide range - I looked at a specific case of wakeups and wrote eventstat to do the more focused monitoring for my testing12:29
pitticking: pushed --current-mount option; might be useful for some finer-grained debugging12:31
pitticking: I'll add timestamps and an --ignore-pid option still to avoid this gnome-terminal loop, but I think the rest of the filtering/reporting should happen with higher level tools12:32
* cking nods - yep, makes sense12:33
MacSlowseb128, hey there... I think you'll be happier with https://code.launchpad.net/~macslow/notify-osd/fix.810325-2/+merge/91807 regarding the avg. color-tinting of the notification-bubbles12:34
seb128MacSlow, hey, let me have a look12:34
MacSlowseb128, it checks at runtime for the schema and key... if they are missing, it just falls back to the old behaviour/color12:34
seb128MacSlow, that sounds good12:35
seb128MacSlow, hum, launchpad gives and empty diff?12:35
MacSlowseb128, I'd be happy if you could review it12:35
MacSlowseb128, yeah... hold on a minute... I accidentally pushed to trunk instead of the correct branch *cough*12:35
MacSlowseb128, fixed/reverted it in trunk already... but needs some time to pick that up12:36
seb128MacSlow, ok12:36
=== MacSlow is now known as MacSlow|lunch
lamontProcessing triggers for libc-bin ...12:43
lamontldconfig deferred processing now taking place12:43
lamontsh: 1: /usr/bin/gdbus: not found12:43
pitticking: ok, timestamps available now; -t is now -s13:00
ckingpitti, \o/13:02
jacekmigaczhow to prevent lightdm respawning Xorg session?13:03
jacekmigaczi'd like X once killed, stay killed13:03
=== Quintasan_ is now known as Quintasan
jacekmigaczother words I'd like to kill,remove seat.13:07
jacekmigaczlightdm has SeatRemoved signal but no Remove seat method13:12
=== dendro-afk is now known as dendrobates
=== MacSlow|lunch is now known as MacSlow
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
=== dduffey_afk is now known as dduffey
pitticking: it's quite unbelievable how much disk activity chatter even my bash prompt uses..14:23
ckingbashing the oxide off the platter..14:23
pittiwell, my fault mostly, of course; it calls git, sed, and whatnot14:23
ckingthis is where we find most of the disk events are due to our tools14:24
pitticking: I added an --ignore-pid option now, so gnome-terminal can be silenced14:25
pitticking: from my POV this should be good enough for a first release; do you still see something major missing?14:25
pittioh, I should document theh flags in the manpage14:25
ckingpitti, lemme have one more look14:26
ckingpitti, perhaps it should check it needs to be run with suitable root privilege rather than just failing with "fanotify_init: Operation not permitted"14:30
pittiI'm not actually sure which capability that is14:30
pitticking: doing that properly is a bit nontrivial, so I didn't so far14:31
pitticking: uid==0 is not quite sufficient, I think14:31
pittiapparmor might restrict it, and other systems might allow it even to non-root processes14:31
ckingah, true14:31
ckingpitti, its surprising how much unity-panel-service is doing really14:34
pitticking: I'll rename 'M' to 'W' and 'A' to 'R'; that's a bit clearer IMHO14:35
ckingpitti, heh, I can't valgrind the fanotify_* calls14:35
ckingyeah, I run valgrind on all apps to see if they are leaky14:36
pittiI don't use any dynamic memory allocation14:36
pittiin small C programs I try not to, both to guard against leaks and also because it's more efficient14:36
pitti(not copying stuff around, etc.)14:37
pittiwell, there's one strdup() for the --output argument14:37
pittithat could be freed, but it's only a single allocation14:37
cking..just me being anal ;-)14:37
pittibut I like my global variables to be valid all the time14:37
pitticking: right, appreciated :)14:37
pitticking: so, valgrind doesn't know about fanotify?14:38
ckingso, as for features and functionality it looks most excellent14:38
ckingpitti, well, valgrind on my precise box didn't like the fanotify_init()14:38
ckinggoodness knows how that's implemented14:40
pitticking: manpage updated as well now14:46
jamespagemicahg, OK if I merge maven-repo-helper? a couple of bug fixes only...14:50
ckingpitti, looks all good to me15:01
pittiCannot initialize fanotify: Operation not permitted15:01
pittiYou need to run this program as root.15:01
pitticking: ^ slightly more friendly now15:01
ckingpitti, yay15:02
pitticking: ok, thanks; off to a 0.1, and packaging :)15:02
pitticking: https://launchpad.net/fatrace -> gotta love how LP says that I released the 0.1 tarball 15 hours ago :)15:04
ckingpitti, LP now a time machine too?15:05
smosersuperm1, around ? i've some questions about dkms.15:09
dholbachif a new binary package gets added, do the existing packages get published after the new upload or do they all wait until the binary new package is processed?15:23
pittidholbach: they all wait15:23
dholbach(I'm asking because of fcitx)15:23
dholbachah ok15:23
smosersuperm1, never mind. i think i got it sorted.15:24
pittiotherwise we'd end up with broken dependencies very often15:24
dholbachyeah, I guess15:24
=== dendrobates is now known as dendro-afk
dholbachstupid question, but I just wanted to be sure ;-)15:24
pitticking: uploaded; now I need to bribe an archive admin to process it :)15:24
dholbachpitti, have you bribed yourself before? ;-)15:25
pittiI can't review my own stuff :)15:25
* dholbach can totally see pitti go back and forth between "ok, how about I have some beer later after reviewing this stuff?", "yeah, beer would make the pain go away", "yeah, why not", "ok, deal" himself15:26
pittidholbach: nice "sponsorship Friday" idea15:26
* dholbach hugs pitti15:26
* dholbach just dealt with a bunch of sync requests - we were up to 80+ earlier :)15:27
* pitti hugs dholbach15:27
dholbachthat's also why I asked about the fcitx one :)15:27
=== sergio_ is now known as Guest33596
* Sweetshark should lurk more, to be able to make grow the casual hugs into grouphugs ....15:37
dholbachseb128, Laney: to move forward with the glom story, I just uploaded a new goocanvasmm-2.0 package to https://launchpad.net/~dholbach/+archive/ppa - if you could take a look and just sponsor if it's good enough for you, I'd appreciate it :)15:46
Laneyare these parallel installable?15:47
seb128dholbach, thanks!15:47
Laneyalso NICE15:47
seb128dholbach, will you do gdamm5 as well? ;-)15:47
=== dendro-afk is now known as dendrobates
dholbachseb128, on it15:50
seb128dholbach, you rock, you make me want to spend some time on the sponsoring queue ;-)15:50
dholbachseb128, uploading it right now15:50
dholbachthere's something funny with a devhelp file15:51
seb128dholbach, I will not wait friday though, I'm concerned that too many people hitting on it together will lead to duplication ;-)15:51
dholbachbut I think it's more important we get glom up and running and fix the other stuff later15:51
Laneyhas the sover changed? shver is still the same15:51
dholbachseb128, if you want to do a bit of sponsoring before - do it :)15:51
dholbachLaney, hm? it seems like no goocanvasmm-2.0 is available right now at all?15:52
seb128dholbach, right15:52
Laneywell, indeed, but I think it probably wants to be 1.9015:54
Laneyanyway I will have a proper look later15:54
Laneyglom depends on this version now?15:54
dholbachit's all in the openismus ppa15:55
dholbachI just had to make a few very very small changes15:55
Laneythis neatly steps around jsogo15:55
Laneywould anyone be interested in maintaining?15:55
dholbachseb128, and I are in discussions with the openismus people15:56
dholbachthey maintain it in their ppa already15:56
dholbachand some time further down the line, it'd be nice if they could maintain the whole stack in ubuntu15:56
* Laney will sponsor to Debian if they want it (and would consider DM at some point)15:57
kelemengabormvo: hi, do you have time a slightly offtopic question? How does one submit a translation for upstream apt?16:25
kelemengaborI tried the BTS, without much success: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=65523816:26
ubottuDebian bug 655238 in apt "[INTL:hu] Updated Hungarian translation for apt" [Wishlist,Open]16:26
mvokelemengabor: sure, always! the debian bts is the right place, if noone has merged it  yet I can do that16:28
mvokelemengabor: fwiw, its in debians bzr already16:29
mvokelemengabor: just not released or taged in the bug16:29
slangasekpitti: fatrace> very nice :)16:29
mvokelemengabor: sorry for that, there should be anohter upload to stable I guess16:30
pittislangasek: I have a half-written blog post about it, will finish after our meeting16:30
pittislangasek: thanks :)16:30
slangasekpitti: as far as a tool to collect the information and report it, I think 1 minute is a little too short... for me the goal is to have the disk to wake up no more than once per 10 minutes when idle16:30
pittislangasek: it's indeed quite surprising what enormous disk chatter we have during a normal session16:30
pittislangasek: 10 mins sounds fine16:30
slangasekwell, it doesn't surprise me :/16:30
slangasekbecause we know we have a longstanding bug about parking cycles destroying disks16:30
kelemengabormvo: oh, that's nice. I should read bzr logs more :). Thanks!16:31
mvokelemengabor: well, someone should have simply told you :) so no worries16:33
=== shadeslayer is now known as shadeslayer_
=== shadeslayer_ is now known as shadeslayer
pittidirecthex: hey! do you know thhe status of the banshee gtk3 port?16:37
directhexpitti, i saw it demonstrated at fosdem this weekend. i'm not sure what release blockers there are, if any16:38
tkamppeterpitti, hi16:40
tkamppeterpitti, I will push CUPS 1.5.2 in some minutes, can you upload it then? Forgot to update the debian/patches/series file and so the new patches are not applied.16:41
pittidirecthex: ah, thanks; nice to hear that there's good progress16:43
=== kentb_ is now known as kentb_dell
micahgjamespage: sure, wasn't sure if we needed it16:54
tjaaltonslomo: more quiet here, so http://paste.ubuntu.com/832840/16:56
tkamppeterpitti, I have pushed up CUPS 1.5.2-2 now, can you upload it to Debian and Ubuntu? Thanks.16:57
pittitkamppeter: ok, thanks16:57
bdmurraypitti: with regards to bug 856975 that traceback shows up in almost all ubiquity syslog files17:03
ubottuLaunchpad bug 856975 in language-selector (Ubuntu) "fontconfig-voodoo crashed with DBusException in __new__(): org.freedesktop.DBus.Error.FileNotFound: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory" [Low,Confirmed] https://launchpad.net/bugs/85697517:03
pittiit seems dbus is not running in that environment17:03
pittiI think we need to fix that17:04
slangasekpitti: seems more likely to me that this would be some sort of /run transition issue... not sure how we would've gotten that far with dbus not being started17:06
pittianyway, I'll have a closer look in the live session (and ubiquity-only)17:06
pittiput on my todo list17:06
cr3hi folks, if I have a project mostly in Python with some C++, is it reasonable to have setup.py call make? or, should I use a Makefile instead that calls setup.py?17:08
slangasekcr3: no autoconf?17:11
pittitkamppeter: uploaded17:11
slangasekcr3: I'm not sure one way is better than the other, anyway; both will have rough spots17:12
cr3slangasek: no autoconf, there's very little C++ and it's actually Qt code so the process is qmake + make in a small subdirectory17:14
* slangasek nods17:14
tkamppeterpitti, thanks.17:18
jamespagemicahg, ta17:24
micahgdo I have to worry about an upgrade from a non-release version of a package in oneiric to precise?  I'm looking at ca-certificates and the only possible thing left is the conflicts on the pre-release ca-certificates-java17:52
SpamapS@pilot in18:29
=== udevbot changed the topic of #ubuntu-devel to: Alpha 2 released! Archive: open | Development of Ubuntu (not support, not app development) | build failures -> http://bit.ly/or6CHJ | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: SpamapS
slangasekmicahg: I wouldn't keep transitional code from release-1-ε, no18:35
micahgslangasek: well, the rest of the code said drop after oneiric, that's part of why I'm asking18:36
slangaseknot if there's a question of being in sync or something - if it's cheap to keep then meh, but in general users shouldn't expect things to work if they don't at least upgrade to the release first18:36
micahgthe other part is, do we assume upgrade to release packages before upgrading to the next release18:36
slangasek*I* certainly assume that :)18:36
micahgok, yeah, it's the only diff18:36
micahgmvo: BTW, synaptic still FTBFS in Ubuntu18:39
=== joshua__ is now known as tobin
mvomicahg: meh, thanks! let me look19:38
micahgmvo: it seems weird, the patch applied in Debian, but not Ubunut19:39
mvomicahg: I also wonder why I did not get the ftbfs mail :/19:40
mvomicahg: at least I can reproduce it here, I work on it now19:43
dokomicahg, did you already care about all gnat related packages?19:59
SpamapSsmoser: just reviewed your patch for bug 91521520:12
ubottuLaunchpad bug 915215 in sysvinit (Ubuntu) "rc.local should support a runparts of rc.local.d" [Low,In progress] https://launchpad.net/bugs/91521520:12
TiMiDoman this sucks,20:13
slangasekSpamapS, smoser: eew?  this is rc.local, it's *supposed* to be edited by the admin20:15
slangasekpackages should *never* be adding anything to it20:15
SpamapSslangasek: welcome to the world of automation20:15
slangasekwhy would you use *that* interface for automating anything?20:16
SpamapSslangasek: if not rc.local.d , something with a .d makes sense so users can comfortably put things there without worrying about conflicting w/ system level startup scripts.20:16
SpamapSslangasek: people use rc.local all the time in automation because it is reliable and simple to implement.20:19
=== salem_ is now known as _salem
slangasekSpamapS: so why not just *clobber* /etc/rc.local?20:19
slangasekit's rc.local20:19
slangasekwhy worry about its default contents at all?20:20
slangasekalso, why is using /etc/init.d + /etc/rcN.d, or /etc/init, a practical concern?  dpkg won't overwrite any local files in these directories on package install without prompting, so even if someone does mistakenly install a package that overlaps something local, it shouldn't blow up?20:21
jtaylordoko: do you have an opinion on getting numpy 1.6 into precise before the feature freeze?20:21
jtaylorit is backward compatible with 1.5, and only 18 packages that need rebuild20:22
jtaylordebian is going to transition very soon too but probably after feature freeze20:22
dokojtaylor, no. do you want to prepare packages?20:22
jtaylordoko: I'm currently just looking for helpers and getting an overview, if people approve I'll prepare packages20:23
slangasekhallyn: bug #928432 says spice should only be enabled on 64-bit builds; can you confirm?20:23
ubottuLaunchpad bug 928432 in Linaro QEMU "spice backend fails to build on i386 with -Werror" [Undecided,New] https://launchpad.net/bugs/92843220:23
dokojtaylor, I don't see a reason not to do that. so if you have packages for numpy, scipy, and maybe others, let me know20:24
jtaylordoko: great, I'll let you know on the progress20:27
smoserSpamapS, thank you. i dont mind it being upstart.20:29
smoseri actually went looking for you one day to read the suggested upstart script htat i put int he bug20:29
micahgdoko: well, I think I've got the ada related failures fixed/sync'd, gnat is still and issue on armhf, but I was going to look at the diffs with Debian at some point20:29
SpamapSslangasek: clobbering rc.local makes sense if you have one thing influencing rc.local, but not if you have multiple things that you want to start late in the boot...20:29
smoseri backed away as it was just more intrusive.20:29
smoseri agree with SpamapS .20:30
SpamapSslangasek: and its still simpler than using /etc/init.d + update-rc.d or upstart (though upstart *does* help a lot)20:30
slangasekSpamapS: rc.local is not defined as "late in boot", it's defined as "last thing run via sysvinit" which is no longer the same thing ;)20:30
hallynslangasek:  hm,  http://spice-space.org/faq.html20:30
hallyn says only server isnt supported on 32bit, client is20:30
smoserslangasek, well, rc.local is back to being "relatively" late in boot20:30
hallynslangasek: d'oh, so yeah20:31
smosererr.. anyway i think that is a separate issue entirely.20:31
SpamapSbut the 'start on stopped rc RUNLEVEL=[2345]' is still a lot more obscure than 'echo /usr/local/sbin/dbdaemon' > /etc/rc.local.d/dbdaemon && chmod +x /etc/rc.local.d/dbdaemon20:31
micahgdoko: also, wanted to ask you about the icedtea-plugin situation, it seems that there should be a breaks/replaces instead of a conflict/replaces there, just wanted to know if you did that on purpose or not20:31
SpamapSslangasek: most people define it as late in boot.. evidence that we have not documented its new place in the boot very effectively. :-/20:32
smoserwell, if its not "late in boot", then really, thats a bug.20:32
smoserwe re-defined it20:32
smoser(yes, i realize we did, but currenlty its *so* much better than it was in 10.04)20:33
dokomicahg, there are no diffs, just a bootstrap is needed20:33
micahgdoko: ah, Debian has a patch in 4.4 that lets it bootstrap from 4.6 which is built now20:35
smoserso anyway, i only proposed it and didn't upload it because i wanted to give people like slangasek the opportunity to say "yuck, no way"20:35
smoseri only decided to try it because i came across a need/desicre to run something late in boot without screwing up someone's changs to rc.local.20:35
dokomicahg, neither 4.4 nor 4.6 are built on armhf20:36
micahg      gnat | 4.6ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc20:36
micahgah, it's empty :)20:36
micahgdoko: ok, I don't know how to bootstrap that offhand20:36
broderSpamapS, smoser: i always thought people liked rc.local because it was cross-distro. that wouldn't be the case with rc.local.d, no? it'd be ubuntu-specific? or are other distros picking it up too?20:40
smoserbroder, no. unless by coincidence20:40
SpamapSbroder: I'm sure thats one reason people use it, because it is ubiquitous, elminating the need for chkconfig users to learn update-rc.d20:43
smoserSpamapS, wel... commented on post there.21:03
slangaseksmoser: udev redefined it; we just made that redefinition manifest :)21:04
slangasekhallyn: I don't know which end of spice is the client or server ;)  Does that mean we need to not be building qemu-spice on 32-bit archs?21:04
slangasekSpamapS, smoser: so fundamentally, I think that having an rc.local /framework/ is something that's not the sysvinit package's job to solve21:05
slangasekrc.local is "the admin can edit it"21:06
smoseradmins dont edit things any more21:06
slangasekand that editing could very well include dropping in a copy of some template that looks at /etc/rc.local.d21:06
slangasekthe admin can edit it in as automated a fashion as they wish, but either way, it's not the package's problem :)21:07
smoserif rc.local.d is not the packages problem, then really, rc.local is not either. they are the same problem.21:07
smoserone is just older.21:07
slangasekyes, rc.local is an interface from the package21:07
smoseri really think that it adds a large usefulness at the cost of 2 forks in the boot21:08
slangasekany interfaces beyond that, such as a hypothetical rc.local.d, are not the problem of sysvinit21:08
smoserwith, extremely low mantainence issues.21:08
hallynslangasek: yeah i confused myself at first too :)  but yes qemu is the server, spicec or spicy is the client, so qemu-kvm-spice should not be built for 32-bit21:08
smoserslangasek, so is that a definitive "NO" ?21:12
smoseri'm willing to accept that it is.21:12
slangaseksmoser: nothing is ever settled and I don't have the last word; but my opinion is firm :)21:12
slangasekthis is something that's easy to design and implement without ever touching the sysvinit package21:13
slangasekbecause *by definition* the package won't mess with whatever changes you make to rc.local - including tweaking it to use rc.local.d21:13
smoserright. and thats fine.21:14
smoserso its easy to add21:14
smoserbut its not easy to determine if modifying rc.local is going to stomp on someone else's already modified rc.local21:14
smoserso you have to assume that youc an't do that if you're trying to be a good tenant.21:14
slangasekmkdir /etc/rc.local.d; mv /etc/rc.local /etc/rc.local.d/reallylocal; echo > /etc/rc.local <<EOF.. :)21:15
slangasekand besides, I thought admins didn't edit files anymore, so why would there be anything in /etc/rc.local to preserve ;)21:15
mbieblslangasek: /etc/rc.local.d, really? Isn't that what /etc/init.d is for...21:16
hallynslangasek: i'm not sure offhand what the best place is to tell the pkg not to build for 32-bit...21:16
slangasekmbiebl: not my idea :-)21:16
mbiebl(I probably miss the context, so feel free to ignore me)21:16
hallyn(and i frankly find it disturbing...)21:16
slangasekhallyn: debian/control + debian/rules - build-dependencies, architecture fields, and the target can all be annotated by architecture21:16
smoser"I just want to run something late in boot". we've all come across that. mbiebl . wanting to deal with upstart or sysv init scripts and symlinks and run levels is something entierly different.21:17
mbieblfrom a package pov or sysadmin?21:17
mbiebland no, I don't think it's a good idea, fwiw21:18
SpamapSslangasek: admins don't modify files.. but they do work collaboratively on automation .. and having to first agree on the framework for rc.local.d is a barrier to system usage. If we called it '/etc/lateboot.d' and just made it a convenience dir, would that make more sense?21:19
slangasekmbiebl: /etc/rc.local.d obviously wouldn't belong in a package21:21
slangaseksince it extends /etc/rc.local, which is not for packages21:21
slangasekSpamapS: again, how late is late21:22
slangasekI think this is underspecified at the moment21:22
smoserslangasek, i dont think that arguing "rc.local is unknown" is really relevant.21:23
slangasekif you want to define something that extends rc.local with rc.local.d, then obviously you'll get the same semantics21:24
smoseryou stated that the time frame in which rc.local runs is unknown, which is true. but implying that something that runs right after that is therefore less valuable is i think not relevant.21:25
slangasekbut I don't think rc.local is actually defined with a guarantee that it happens "at the end of boot", and if it is defined that way, the definition itself is broken thanks to event-based systems21:25
slangaseksmoser: I'm saying that we shouldn't create something called "/etc/lateboot.d" without first definining what we actually mean by "late boot" and ensuring we can deliver21:25
hallynslangasek: ok thanks, i'll try and get a fix for qemu-linaro21:25
smoserslangasek, then we should use rc.local.d because that invents nothing new.21:25
smoserit re-uses a broken definition with the same definition21:26
slangaseksmoser: if you wish :)  I'm not opposed to /etc/lateboot.d, I just think it has a prereq21:26
slangasekhallyn: I'm already elbow-deep in the package - I can take care of it if you want21:27
SpamapSOr fix rc.local to be truly "after runlevel 2 is fully started" by trying to define an event which is emitted after all things started by the transition to runlevel 2 have either changed goals back to stop or emitted 'started'21:27
SpamapSBut really, I think thats orthogonal to the desire to make it easier to have non-conflicting rc.local modifications by putting in a .d directory.21:28
smoserSpamapS, i agree with that (bug so is the transition to upstart ;)21:29
SpamapSThough I have to agree that the *right* way is to have an upstart job that is start on stopped rc RUNLEVEL=[2345] .. user education on that may be harder than "look at shiny new /etc/rc.local.d"21:29
mbieblSpamapS: the rc.local concept is broken (especially with an event based init), so I don't get why you want to extend a broken concept.21:30
mbieblbut I better just shut up now...21:31
* micahg is syncing ca-certificates and crossing his fingers21:31
mbieblSpamapS: that is rc.boot all over again...21:33
hallynslangasek: oh, missed that - that'd be terrific, and i'll look at how you did it and learn :)  thanks21:34
SpamapSmbiebl: its crap. I agree. But its not going away. rc.local *is not* going away, ever.. busy admins without time to learn the intricate event interactions will always want to run something "late".21:35
slangasekSpamapS, mbiebl: we could certainly do away with /etc/init.d/rc.local in favor of an /etc/init/rc.local that's 'start on stopped rc [...]', in any case21:37
slangasekbut that's not actually a material difference from what we currently do21:37
mbieblSpamapS: that's the crux, what exactly is "late"? imho that just makes it easier for admins to shoot themselves in the foot21:38
slangasekmbiebl, SpamapS: right; as more jobs move to upstart, rc.local is likely to be running *before* most services have started21:43
SpamapSslangasek: indeed, thats basically a wait() call later. ;)21:43
SpamapSslangasek: so how do we simplify their life. Could we have a job which lists all of the expected events a system will receive and have that be the sync point..21:45
SpamapSactually.. hm21:46
SpamapSthis is where the 'network-services' job comes in handy21:46
SpamapSif we make all things follow that, instead of runlevel 2, then we can say when it transitions to 'started', all normal network services are ready.21:46
SpamapSsomething to think about for 12.10 (assuming the systemd flying monkies don't carry us away)21:47
slangasekSpamapS: so jobs would be 'start on starting network-services', and rc.local would be 'start on started network-services'?21:47
SpamapSslangasek: and stopped rc RUNLEVEL=[2345]21:50
* slangasek nods21:51
quadrisproeh-ehy! hi all!22:18
sorenIs there anything about the (PPA) buildd's that might prevent me from readlink()ing /proc/<PID>/exe ?22:23
soreninfinity: You'd probably know? ^22:24
hallynSpamapS: perhaps i could get you to pick a good start on for libvirt?  bc i've not followed this whole conversation22:38
SpamapSstart on (runlevel [2345] and stopped networking RESULT=ok)22:39
SpamapShallyn: thats a bit explicit given 11.10+'s guarantee that all of /etc/network/interfaces will be up22:39
SpamapShallyn: until we have the network-services job in place, runlevel [2345] is good22:40
hallynSpamapS: so to be clear, you're saying make it jsut "start on runlevel [2345]" ?22:40
SpamapShallyn: yes if all it requires is all network interfaces and filesystems to be up and mounted.22:41
hallynSpamapS: thanks, put that in my "to do on next push" list22:41
infinitysoren: Nope, should work fine.22:51
bdmurrayum, how do you start an ssh server?22:52
StevenKsudo start ssh ?22:52
infinity(after installing it)22:52
bdmurrayright and I'm still seeing 'Unknown job: ssh'22:53
bdmurrayon a precise live cd22:53
infinitybdmurray: It's not on the livecd.22:53
infinitybdmurray: apt-get install ssh22:53
infinity(or openssh-server, which ssh depends on)22:53
bdmurrayyes when I said right I meant I've installed openssh-server22:54
bdmurrayand I see ssh in /etc/init.d/22:54
infinitySo start it from init.d22:54
soreninfinity: Ok, cool. Thanks.22:54
infinityThough installing it should have started it.22:55
infinityUnless you had/have no interfaces up.22:55
bdmurrayhow could I have installed it then?22:55
infinityFair point. :P22:55
StevenKVia a USB key and dpkg -i :-P22:56
bdmurraywith /etc/init.d/ssh start I see use service and then 'start: Unknown job: ssh' again22:57
broder"service ssh start"22:57
broderoh, on lucid you still needed to do "initctl reload-configuration"22:57
broderwhenever something changed /etc/init22:57
bdmurraythis is just a precise live cd22:57
broderyes, you've installed the server, but because /etc/init/ssh.conf wasn't there at bootup, upstart doesn't know about it22:58
broderso run "initctl reload-configuration" to pick up the changes22:58
infinity... really?22:58
broderthat was definitely the case with upstart for some number of releases22:58
infinityOh, wait, does upstart rely on inotify to scan for new services?22:58
RAOFI'm *pretty* sure upstart watches /etc/init with inotify.22:59
bdmurraybroder: okay that worked thanks22:59
infinityIf so, overlayfs's lack of inotify support would break that.22:59
broderinfinity: hahaha. yes, yes it does22:59
bdmurraydoes anybody know of a bug about that being reported yet?22:59
infinityapw: Say, have we ever escalated the important of inotify in overlayfs? :P23:00
infinitybdmurray: I think Andy has a bug, no idea what sort of movement it has.23:00
infinityapw: s/important/importance/23:00
bdmurraybug 882147 right?23:01
ubottuLaunchpad bug 882147 in linux (Ubuntu Precise) "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/88214723:01
infinitybdmurray: Should do.23:02
=== dduffey is now known as dduffey_afk
=== dendrobates is now known as dendro-afk
slangasekhallyn: pushed my qemu-linaro changes to the UDD branch, if you want to have a gander23:39
hallynslangasek: fetching23:40
hallynslangasek: so will simply not building a new i386 package DTRT?  ( I was expecting to have to create an empty package to invalidate the last one)23:57
hallyn(or does it just not matter bc we're still in alpha)23:57
slangasekhallyn: oh, I would never do a transitional package for a case where the package was never meant to exist on an arch and can't be used23:59
slangasekso this DTRT in the sense that once it's published, I'll yank the i386 binary out of the archive with my AA hat on23:59
hallynslangasek: cool :)  thanks23:59

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!