| bdmurray | okay, I was / am considering a bug pattern | 00:00 |
|---|---|---|
| bdmurray | slangasek: 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 |
| bdmurray | ah, its me | 00:22 |
| slangasek | mmk | 00:22 |
| psusi | wait... when a package is synced from debian, it's just the source right, the binaries are still rebuilt for ubuntu right? | 00:49 |
| micahg | psusi: correct | 00:50 |
| === cyphermox_ is now known as cyphermox | ||
| YokoZar | slangasek: 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 |
| YokoZar | I'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 zsnes | 01:40 | |
| slangasek | YokoZar: I reserve judgement; we'd have to have a good long think about whether this is always the right thing to do | 02:02 |
| slangasek | YokoZar: 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 |
| infinity | YokoZar: 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 |
| YokoZar | slangasek: 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 on | 02:06 |
| YokoZar | slangasek: ~ 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 tracker | 02:07 |
| infinity | YokoZar: 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 |
| slangasek | YokoZar: tracker> ah, that'll be my fault for not getting the blueprint shoved along to "approved" state | 02:08 |
| slangasek | infinity: 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 change | 02:08 |
| slangasek | which isn't pleasant | 02:08 |
| YokoZar | infinity: 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 |
| infinity | YokoZar: 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 |
| YokoZar | The uglier solution is just a big manual hard-coded list in update-manager :/ | 02:09 |
| infinity | YokoZar: 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 |
| YokoZar | infinity: right, and then we'd have to rename zsnes to zsnes-i386 :/ | 02:09 |
| infinity | Yup. | 02:10 |
| infinity | I did note that it fails the elegance test. | 02:10 |
| infinity | But it's at least easy to spot-check for correctness. | 02:10 |
| YokoZar | infinity: you can look at the new wine1.4 package for a similar setup | 02:10 |
| infinity | The proposed apt change is immediately incorrect in several corner cases, without looking for weirder ones. | 02:10 |
| micahg | YokoZar: alternatively, you can fix the amd64 build so that it builds the arch specific parts if there are any | 02:10 |
| YokoZar | micahg: 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 past | 02:11 |
| infinity | (Out of curiosity, why would this be done to zsnes? Does the 64-bit build not work?) | 02:11 |
| infinity | Oh, there isn't a 64-bit build, I see. That seems odd, given that it's an emulator. :P | 02:11 |
| YokoZar | infinity: zsnes does not and will not build on amd64 ever, I think it's full of assembly code or some such. | 02:11 |
| infinity | Fair enough. | 02:12 |
| micahg | YokoZar: you can do what we did with flash, if you can get it to compile again :) | 02:12 |
| infinity | Still sounds like it should just be dealt with the same way flash is. | 02:12 |
| infinity | The same way we did flash in oneiric, that is. | 02:12 |
| infinity | Before we had a 64-bit one. | 02:12 |
| ScottK | Burn it with fire/ | 02:12 |
| ScottK | ? | 02:12 |
| ScottK | Oh, that's not what you meant. | 02:13 |
| micahg | zsnes:amd64 depends zsnes-i386 (i386 only) which depends on zsnes:i386 | 02:13 |
| infinity | micahg: Makes the packaging a bit more complex, since zsnes.install differs on the two arches. | 02:13 |
| infinity | micahg: 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 |
| YokoZar | micahg: 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 |
| micahg | infinity: that works too, but I hate the idea of having a zsnes-i386 package in perpetuity | 02:15 |
| YokoZar | infinity's solution is a bit better but leaves us with dumb names forever | 02:15 |
| infinity | micahg: Who cares? Package names are often weird. | 02:15 |
| micahg | it's a diff from Debian | 02:15 |
| infinity | So, convince the Debian maintainer to do the same thing. | 02:15 |
| infinity | But it's not actually a large diff. | 02:15 |
| YokoZar | OR, we could implement specific arch relationships in control fields... | 02:15 |
| micahg | well, now that Debian will soon have a multiarch capable dpkg, that might be possible :) | 02:16 |
| YokoZar | By 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 |
| infinity | There's a certain advantage in not having individual package maintainers, yes. | 02:18 |
| infinity | Downside: Lots of universe bugs go ignored. Upside: When we want to move on something, we MOVE. | 02:18 |
| ScottK | infinity: Lots of Main bugs go ignored too. | 02:25 |
| justgord | Any ubuntu dev working groups focussed on tablets and/or wayland ? | 02:29 |
| nidsub | hola, i hope there someone out there who could help me :) | 05:02 |
| nidsub | im sorry ,but im really new to irc | 05:02 |
| nidsub | should i just post my problem here? | 05:02 |
| nidsub | im trying to build linux kernel | 05:03 |
| nidsub | here is the error i get,please point out what did i do wrong | 05:03 |
| nidsub | -VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ make ARCH=arm | 05:04 |
| nidsub | mkdir: cannot create directory `include/generated': Permission denied | 05:04 |
| nidsub | make[2]: *** [silentoldconfig] Error 1 | 05:04 |
| nidsub | make[1]: *** [silentoldconfig] Error 2 | 05:04 |
| nidsub | make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop. | 05:04 |
| nidsub | nidhal@nidhal-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm | 05:04 |
| nidsub | scripts/kconfig/conf --silentoldconfig Kconfig | 05:04 |
| nidsub | CHK include/linux/version.h | 05:04 |
| nidsub | UPD include/linux/version.h | 05:04 |
| nidsub | CHK include/generated/utsrelease.h | 05:04 |
| nidsub | UPD include/generated/utsrelease.h | 05:04 |
| nidsub | Generating include/generated/mach-types.h | 05:04 |
| nidsub | CC kernel/bounds.s | 05:04 |
| nidsub | cc1: error: unrecognized command line option ‘-mlittle-endian’ | 05:04 |
| nidsub | cc1: error: unrecognized command line option ‘-mno-thumb-interwork’ | 05:04 |
| nidsub | kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch | 05:04 |
| nidsub | kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch | 05:04 |
| nidsub | make[1]: *** [kernel/bounds.s] Error 1 | 05:04 |
| nidsub | make: *** [prepare0] Error 2 | 05:04 |
| nidsub | please :( | 05:04 |
| micahg | nidsub: first error is you didn't use a pastebin for that | 05:05 |
| micahg | as for the rest, is this on an arm system or are you cross compiling | 05:06 |
| nidsub | thank you :),yerp im trying to cross compile | 05:06 |
| nidsub | is on arm qemu | 05:07 |
| nidsub | here the detail on the step i took ..from this webpage | 05:08 |
| nidsub | http://wiki.xilinx.com/zynq-linux | 05:09 |
| micahg | well, this isn't a general support channel, #ubuntu-arm might be better suited | 05:12 |
| micahg | #ubuntu would be for general support, but I don't see this working out too well in there | 05:12 |
| nidsub | Thanks you so much for the tips | 05:15 |
| === yofel_ is now known as yofel | ||
| === tkamppeter_ is now known as tkamppeter | ||
| === ts2 is now known as tsimpson | ||
| goddard | I'm trying to use debuilder but it doesn't seem to be creating my deb file although i get no errors | 07:10 |
| pitti | Good morning | 07:32 |
| Sweetshark | Morning everyone! | 07:40 |
| Sweetshark | http://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_ | ||
| pitti | Daviey: mariadb> as it is 100% binary compatible, I think there is some good grounds for a FFE on this one | 10:00 |
| pitti | Daviey: 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 years | 10:00 |
| Daviey | pitti: need to discuss this in a bit. :) | 10:01 |
| seb128 | - /usr/lib/debug/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.0 | 10:13 |
| seb128 | + /usr/lib/debug/.build-id/5e/d483e11d8dbaff9929c94ad6b9b05a174c7685.debug | 10:13 |
| pitti | I noticed the new /usr/lib/debug/.build-id/ gibberish recently, too | 10:13 |
| seb128 | is that something which changed in our toolchain (it's libsoup2.4-dbg new version) | 10:13 |
| pitti | I have no idea what changed there | 10:14 |
| seb128 | hum, k | 10:15 |
| seb128 | well I will assume it's not a bug on my side then ;-) | 10:15 |
| debfx | seb128: it's a new debhelper 9 behavior | 10:17 |
| seb128 | debfx, ok, thanks | 10:17 |
| seb128 | * dh_strip: In v9, pass --compress-debug-sections to objcopy. | 10:18 |
| seb128 | I guess | 10:18 |
| seb128 | that source is v9 | 10:18 |
| pitti | so this stuff is actually valid? | 10:18 |
| seb128 | debian bug 631985 | 10:18 |
| ubottu | Debian bug 631985 in debhelper "dh_strip: add a possibility to compress debug sections" [Wishlist,Fixed] http://bugs.debian.org/631985 | 10:18 |
| pitti | it seems a ridiculously bad design to put this in a hidden directory | 10:18 |
| seb128 | with useless names... | 10:19 |
| === _salem is now known as salem_ | ||
| === Chipzz is now known as Chipzz_ | ||
| === Chipzz_ is now known as Chipzz | ||
| pitti | cking: FYI, I'm currently working on https://launchpad.net/fatrace | 12:06 |
| pitti | cking: as powertop seems to do a rather bad job at catching disk events (and even reports them wrongly, too) | 12:06 |
| pitti | cking: once it's ready and in the archive, I'll update https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues accordingly | 12:06 |
| cking | pitti, wow, this is excellent! | 12:06 |
| pitti | cking: fanotify is quite nice for this :) | 12:07 |
| pitti | cking: if you are interested in trying, it's in lp:fatrace; make && sudo ./fatrace | 12:08 |
| cking | yep, this is an excellent tool to track down these offending wakeups! | 12:08 |
| pitti | it has --time and --output options, and I'm going to add some filtering, too | 12:08 |
| pitti | cking: well, it's not process wakeups (that's powertop), just disk events | 12:08 |
| pitti | "f"ile "a"ccess trace | 12:09 |
| pitti | cking: if you want it to do something more (new option, etc.), please let me know | 12:09 |
| cking | pitti, does the -o option interfere with the results - i.e. it could write the output to disk and hence change the stats | 12:12 |
| pitti | cking: no, it ignores its own events | 12:13 |
| cking | sweet | 12:13 |
| pitti | cking: without -o, gnome-terminal touches a tempfile in /tmp/ with every output, and thus generates a feedback loop | 12:13 |
| pitti | -o avoids this, but I'm trying to add something more clever | 12:14 |
| cking | yep, I saw that and wonder what was happening | 12:14 |
| pitti | well /tmp tmpfs definitively helps | 12:14 |
| pitti | but we don't have that by default | 12:14 |
| pitti | cking: --ignore-pid could work | 12:14 |
| pitti | --ignore-path /tmp/ sounds a bit pointless | 12:15 |
| pitti | (but might make sense for other contexts) | 12:15 |
| pitti | by default it watches all "real" mounts | 12:15 |
| pitti | it could grow an option to only watch the mount of current cwd | 12:15 |
| cking | perhaps adding a timestamp to the output so we can figure out if events occur periodically may help | 12:16 |
| seb128 | pitti, bug #928212 hate gzip hate | 12:16 |
| ubottu | Launchpad 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/928212 | 12:16 |
| pitti | argh | 12:17 |
| pitti | cking: ah, good idea | 12:18 |
| cking | pitti, 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 too | 12:19 |
| pitti | cking: it's not supposed to be the preferred frontend | 12:20 |
| pitti | cking: I have another WI to write a script that calls powertop, fatrace, and generate a report out of it | 12:20 |
| pitti | with worst offenders, sorted, etc. | 12:20 |
| cking | pitti, ah, I understand - good idea! | 12:20 |
| pitti | cking: I really don't want to do all this in plain C :) | 12:21 |
| === zyga_ is now known as zyga | ||
| cking | pitti, 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 trustworthy | 12:28 |
| pitti | cking: yes, like the file accesses | 12:28 |
| pitti | wakeups seem to be quite reliable, though? | 12:28 |
| cking | and battery power consumption too | 12:28 |
| cking | wakeups 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 testing | 12:29 |
| pitti | cking: pushed --current-mount option; might be useful for some finer-grained debugging | 12:31 |
| pitti | cking: 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 tools | 12:32 |
| * cking nods - yep, makes sense | 12:33 | |
| MacSlow | seb128, 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-bubbles | 12:34 |
| seb128 | MacSlow, hey, let me have a look | 12:34 |
| MacSlow | seb128, it checks at runtime for the schema and key... if they are missing, it just falls back to the old behaviour/color | 12:34 |
| seb128 | MacSlow, that sounds good | 12:35 |
| seb128 | MacSlow, hum, launchpad gives and empty diff? | 12:35 |
| MacSlow | seb128, I'd be happy if you could review it | 12:35 |
| MacSlow | seb128, yeah... hold on a minute... I accidentally pushed to trunk instead of the correct branch *cough* | 12:35 |
| MacSlow | seb128, fixed/reverted it in trunk already... but needs some time to pick that up | 12:36 |
| seb128 | MacSlow, ok | 12:36 |
| === MacSlow is now known as MacSlow|lunch | ||
| lamont | Processing triggers for libc-bin ... | 12:43 |
| lamont | ldconfig deferred processing now taking place | 12:43 |
| lamont | sh: 1: /usr/bin/gdbus: not found | 12:43 |
| lamont | neat | 12:43 |
| pitti | cking: ok, timestamps available now; -t is now -s | 13:00 |
| cking | pitti, \o/ | 13:02 |
| jacekmigacz | how to prevent lightdm respawning Xorg session? | 13:03 |
| jacekmigacz | i'd like X once killed, stay killed | 13:03 |
| === Quintasan_ is now known as Quintasan | ||
| jacekmigacz | other words I'd like to kill,remove seat. | 13:07 |
| jacekmigacz | lightdm has SeatRemoved signal but no Remove seat method | 13: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 | ||
| pitti | cking: it's quite unbelievable how much disk activity chatter even my bash prompt uses.. | 14:23 |
| cking | bashing the oxide off the platter.. | 14:23 |
| pitti | well, my fault mostly, of course; it calls git, sed, and whatnot | 14:23 |
| cking | this is where we find most of the disk events are due to our tools | 14:24 |
| pitti | cking: I added an --ignore-pid option now, so gnome-terminal can be silenced | 14:25 |
| pitti | cking: from my POV this should be good enough for a first release; do you still see something major missing? | 14:25 |
| pitti | oh, I should document theh flags in the manpage | 14:25 |
| cking | pitti, lemme have one more look | 14:26 |
| cking | pitti, 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 |
| pitti | I'm not actually sure which capability that is | 14:30 |
| pitti | CAP_SYS_ADMIN? | 14:30 |
| pitti | cking: doing that properly is a bit nontrivial, so I didn't so far | 14:31 |
| pitti | cking: uid==0 is not quite sufficient, I think | 14:31 |
| pitti | apparmor might restrict it, and other systems might allow it even to non-root processes | 14:31 |
| cking | ah, true | 14:31 |
| cking | pitti, its surprising how much unity-panel-service is doing really | 14:34 |
| pitti | cking: I'll rename 'M' to 'W' and 'A' to 'R'; that's a bit clearer IMHO | 14:35 |
| cking | pitti, heh, I can't valgrind the fanotify_* calls | 14:35 |
| pitti | valgrind? | 14:35 |
| cking | yeah, I run valgrind on all apps to see if they are leaky | 14:36 |
| pitti | I don't use any dynamic memory allocation | 14:36 |
| pitti | in small C programs I try not to, both to guard against leaks and also because it's more efficient | 14:36 |
| pitti | (not copying stuff around, etc.) | 14:37 |
| pitti | well, there's one strdup() for the --output argument | 14:37 |
| pitti | that could be freed, but it's only a single allocation | 14:37 |
| cking | ..just me being anal ;-) | 14:37 |
| pitti | but I like my global variables to be valid all the time | 14:37 |
| pitti | cking: right, appreciated :) | 14:37 |
| pitti | cking: so, valgrind doesn't know about fanotify? | 14:38 |
| cking | so, as for features and functionality it looks most excellent | 14:38 |
| cking | pitti, well, valgrind on my precise box didn't like the fanotify_init() | 14:38 |
| cking | goodness knows how that's implemented | 14:40 |
| pitti | cking: manpage updated as well now | 14:46 |
| jamespage | micahg, OK if I merge maven-repo-helper? a couple of bug fixes only... | 14:50 |
| cking | pitti, looks all good to me | 15:01 |
| pitti | Cannot initialize fanotify: Operation not permitted | 15:01 |
| pitti | You need to run this program as root. | 15:01 |
| pitti | cking: ^ slightly more friendly now | 15:01 |
| cking | pitti, yay | 15:02 |
| pitti | cking: ok, thanks; off to a 0.1, and packaging :) | 15:02 |
| pitti | cking: https://launchpad.net/fatrace -> gotta love how LP says that I released the 0.1 tarball 15 hours ago :) | 15:04 |
| cking | pitti, LP now a time machine too? | 15:05 |
| smoser | superm1, around ? i've some questions about dkms. | 15:09 |
| dholbach | if 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 |
| pitti | dholbach: they all wait | 15:23 |
| dholbach | (I'm asking because of fcitx) | 15:23 |
| dholbach | ah ok | 15:23 |
| smoser | superm1, never mind. i think i got it sorted. | 15:24 |
| pitti | otherwise we'd end up with broken dependencies very often | 15:24 |
| dholbach | yeah, I guess | 15:24 |
| === dendrobates is now known as dendro-afk | ||
| dholbach | stupid question, but I just wanted to be sure ;-) | 15:24 |
| pitti | cking: uploaded; now I need to bribe an archive admin to process it :) | 15:24 |
| dholbach | pitti, have you bribed yourself before? ;-) | 15:25 |
| pitti | I 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" himself | 15:26 | |
| pitti | dholbach: nice "sponsorship Friday" idea | 15:26 |
| * dholbach hugs pitti | 15:26 | |
| * dholbach just dealt with a bunch of sync requests - we were up to 80+ earlier :) | 15:27 | |
| * pitti hugs dholbach | 15:27 | |
| dholbach | that'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 | |
| dholbach | seb128, 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 |
| Laney | are these parallel installable? | 15:47 |
| seb128 | dholbach, thanks! | 15:47 |
| Laney | also NICE | 15:47 |
| seb128 | dholbach, will you do gdamm5 as well? ;-) | 15:47 |
| === dendro-afk is now known as dendrobates | ||
| dholbach | seb128, on it | 15:50 |
| seb128 | dholbach, you rock, you make me want to spend some time on the sponsoring queue ;-) | 15:50 |
| dholbach | seb128, uploading it right now | 15:50 |
| dholbach | there's something funny with a devhelp file | 15:51 |
| seb128 | dholbach, I will not wait friday though, I'm concerned that too many people hitting on it together will lead to duplication ;-) | 15:51 |
| dholbach | but I think it's more important we get glom up and running and fix the other stuff later | 15:51 |
| Laney | has the sover changed? shver is still the same | 15:51 |
| dholbach | seb128, if you want to do a bit of sponsoring before - do it :) | 15:51 |
| dholbach | Laney, hm? it seems like no goocanvasmm-2.0 is available right now at all? | 15:52 |
| seb128 | dholbach, right | 15:52 |
| Laney | well, indeed, but I think it probably wants to be 1.90 | 15:54 |
| Laney | anyway I will have a proper look later | 15:54 |
| Laney | glom depends on this version now? | 15:54 |
| dholbach | yes | 15:54 |
| Laney | grand | 15:54 |
| dholbach | it's all in the openismus ppa | 15:55 |
| dholbach | I just had to make a few very very small changes | 15:55 |
| Laney | this neatly steps around jsogo | 15:55 |
| Laney | would anyone be interested in maintaining? | 15:55 |
| dholbach | seb128, and I are in discussions with the openismus people | 15:56 |
| dholbach | they maintain it in their ppa already | 15:56 |
| dholbach | and some time further down the line, it'd be nice if they could maintain the whole stack in ubuntu | 15:56 |
| * Laney will sponsor to Debian if they want it (and would consider DM at some point) | 15:57 | |
| kelemengabor | mvo: hi, do you have time a slightly offtopic question? How does one submit a translation for upstream apt? | 16:25 |
| kelemengabor | I tried the BTS, without much success: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655238 | 16:26 |
| ubottu | Debian bug 655238 in apt "[INTL:hu] Updated Hungarian translation for apt" [Wishlist,Open] | 16:26 |
| mvo | kelemengabor: sure, always! the debian bts is the right place, if noone has merged it yet I can do that | 16:28 |
| mvo | kelemengabor: fwiw, its in debians bzr already | 16:29 |
| mvo | kelemengabor: just not released or taged in the bug | 16:29 |
| slangasek | pitti: fatrace> very nice :) | 16:29 |
| mvo | kelemengabor: sorry for that, there should be anohter upload to stable I guess | 16:30 |
| pitti | slangasek: I have a half-written blog post about it, will finish after our meeting | 16:30 |
| pitti | slangasek: thanks :) | 16:30 |
| slangasek | pitti: 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 idle | 16:30 |
| pitti | slangasek: it's indeed quite surprising what enormous disk chatter we have during a normal session | 16:30 |
| pitti | slangasek: 10 mins sounds fine | 16:30 |
| slangasek | well, it doesn't surprise me :/ | 16:30 |
| slangasek | because we know we have a longstanding bug about parking cycles destroying disks | 16:30 |
| kelemengabor | mvo: oh, that's nice. I should read bzr logs more :). Thanks! | 16:31 |
| mvo | kelemengabor: well, someone should have simply told you :) so no worries | 16:33 |
| === shadeslayer is now known as shadeslayer_ | ||
| === shadeslayer_ is now known as shadeslayer | ||
| pitti | directhex: hey! do you know thhe status of the banshee gtk3 port? | 16:37 |
| directhex | pitti, i saw it demonstrated at fosdem this weekend. i'm not sure what release blockers there are, if any | 16:38 |
| tkamppeter | pitti, hi | 16:40 |
| tkamppeter | pitti, 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 |
| pitti | directhex: ah, thanks; nice to hear that there's good progress | 16:43 |
| === kentb_ is now known as kentb_dell | ||
| micahg | jamespage: sure, wasn't sure if we needed it | 16:54 |
| tjaalton | slomo: more quiet here, so http://paste.ubuntu.com/832840/ | 16:56 |
| tkamppeter | pitti, I have pushed up CUPS 1.5.2-2 now, can you upload it to Debian and Ubuntu? Thanks. | 16:57 |
| pitti | tkamppeter: ok, thanks | 16:57 |
| bdmurray | pitti: with regards to bug 856975 that traceback shows up in almost all ubiquity syslog files | 17:03 |
| ubottu | Launchpad 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/856975 | 17:03 |
| pitti | it seems dbus is not running in that environment | 17:03 |
| pitti | I think we need to fix that | 17:04 |
| slangasek | pitti: 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 started | 17:06 |
| pitti | anyway, I'll have a closer look in the live session (and ubiquity-only) | 17:06 |
| pitti | put on my todo list | 17:06 |
| bdmurray | thanks | 17:07 |
| cr3 | hi 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 |
| slangasek | cr3: no autoconf? | 17:11 |
| pitti | tkamppeter: uploaded | 17:11 |
| slangasek | cr3: I'm not sure one way is better than the other, anyway; both will have rough spots | 17:12 |
| cr3 | slangasek: no autoconf, there's very little C++ and it's actually Qt code so the process is qmake + make in a small subdirectory | 17:14 |
| * slangasek nods | 17:14 | |
| tkamppeter | pitti, thanks. | 17:18 |
| jamespage | micahg, ta | 17:24 |
| micahg | do 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-java | 17:52 |
| SpamapS | @pilot in | 18: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 | ||
| slangasek | micahg: I wouldn't keep transitional code from release-1-ε, no | 18:35 |
| micahg | slangasek: well, the rest of the code said drop after oneiric, that's part of why I'm asking | 18:36 |
| slangasek | not 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 first | 18:36 |
| micahg | the other part is, do we assume upgrade to release packages before upgrading to the next release | 18:36 |
| slangasek | *I* certainly assume that :) | 18:36 |
| micahg | ok, yeah, it's the only diff | 18:36 |
| micahg | mvo: BTW, synaptic still FTBFS in Ubuntu | 18:39 |
| === joshua__ is now known as tobin | ||
| mvo | micahg: meh, thanks! let me look | 19:38 |
| micahg | mvo: it seems weird, the patch applied in Debian, but not Ubunut | 19:39 |
| micahg | *Ubuntu | 19:39 |
| mvo | micahg: I also wonder why I did not get the ftbfs mail :/ | 19:40 |
| mvo | micahg: at least I can reproduce it here, I work on it now | 19:43 |
| doko | micahg, did you already care about all gnat related packages? | 19:59 |
| SpamapS | smoser: just reviewed your patch for bug 915215 | 20:12 |
| ubottu | Launchpad bug 915215 in sysvinit (Ubuntu) "rc.local should support a runparts of rc.local.d" [Low,In progress] https://launchpad.net/bugs/915215 | 20:12 |
| TiMiDo | man this sucks, | 20:13 |
| slangasek | SpamapS, smoser: eew? this is rc.local, it's *supposed* to be edited by the admin | 20:15 |
| slangasek | packages should *never* be adding anything to it | 20:15 |
| SpamapS | slangasek: welcome to the world of automation | 20:15 |
| slangasek | why would you use *that* interface for automating anything? | 20:16 |
| SpamapS | slangasek: 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 |
| SpamapS | slangasek: 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 | ||
| slangasek | SpamapS: so why not just *clobber* /etc/rc.local? | 20:19 |
| slangasek | it's rc.local | 20:19 |
| slangasek | why worry about its default contents at all? | 20:20 |
| slangasek | also, 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 |
| jtaylor | doko: do you have an opinion on getting numpy 1.6 into precise before the feature freeze? | 20:21 |
| jtaylor | it is backward compatible with 1.5, and only 18 packages that need rebuild | 20:22 |
| jtaylor | debian is going to transition very soon too but probably after feature freeze | 20:22 |
| doko | jtaylor, no. do you want to prepare packages? | 20:22 |
| jtaylor | doko: I'm currently just looking for helpers and getting an overview, if people approve I'll prepare packages | 20:23 |
| slangasek | hallyn: bug #928432 says spice should only be enabled on 64-bit builds; can you confirm? | 20:23 |
| ubottu | Launchpad bug 928432 in Linaro QEMU "spice backend fails to build on i386 with -Werror" [Undecided,New] https://launchpad.net/bugs/928432 | 20:23 |
| doko | jtaylor, I don't see a reason not to do that. so if you have packages for numpy, scipy, and maybe others, let me know | 20:24 |
| jtaylor | doko: great, I'll let you know on the progress | 20:27 |
| smoser | SpamapS, thank you. i dont mind it being upstart. | 20:29 |
| smoser | i actually went looking for you one day to read the suggested upstart script htat i put int he bug | 20:29 |
| micahg | doko: 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 point | 20:29 |
| SpamapS | slangasek: 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 |
| smoser | i backed away as it was just more intrusive. | 20:29 |
| smoser | i agree with SpamapS . | 20:30 |
| SpamapS | slangasek: and its still simpler than using /etc/init.d + update-rc.d or upstart (though upstart *does* help a lot) | 20:30 |
| slangasek | SpamapS: 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 |
| hallyn | slangasek: hm, http://spice-space.org/faq.html | 20:30 |
| hallyn | says only server isnt supported on 32bit, client is | 20:30 |
| smoser | slangasek, well, rc.local is back to being "relatively" late in boot | 20:30 |
| smoser | wel... | 20:31 |
| hallyn | slangasek: d'oh, so yeah | 20:31 |
| smoser | err.. anyway i think that is a separate issue entirely. | 20:31 |
| SpamapS | but 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/dbdaemon | 20:31 |
| micahg | doko: 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 not | 20:31 |
| SpamapS | slangasek: most people define it as late in boot.. evidence that we have not documented its new place in the boot very effectively. :-/ | 20:32 |
| smoser | well, if its not "late in boot", then really, thats a bug. | 20:32 |
| smoser | we re-defined it | 20:32 |
| smoser | (yes, i realize we did, but currenlty its *so* much better than it was in 10.04) | 20:33 |
| doko | micahg, there are no diffs, just a bootstrap is needed | 20:33 |
| micahg | doko: ah, Debian has a patch in 4.4 that lets it bootstrap from 4.6 which is built now | 20:35 |
| smoser | so 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 |
| smoser | i 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 |
| doko | micahg, neither 4.4 nor 4.6 are built on armhf | 20:36 |
| micahg | gnat | 4.6ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc | 20:36 |
| micahg | ah, it's empty :) | 20:36 |
| micahg | doko: ok, I don't know how to bootstrap that offhand | 20:36 |
| broder | SpamapS, 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 |
| smoser | broder, no. unless by coincidence | 20:40 |
| SpamapS | broder: I'm sure thats one reason people use it, because it is ubiquitous, elminating the need for chkconfig users to learn update-rc.d | 20:43 |
| smoser | SpamapS, wel... commented on post there. | 21:03 |
| slangasek | smoser: udev redefined it; we just made that redefinition manifest :) | 21:04 |
| slangasek | hallyn: 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 |
| slangasek | SpamapS, smoser: so fundamentally, I think that having an rc.local /framework/ is something that's not the sysvinit package's job to solve | 21:05 |
| slangasek | rc.local is "the admin can edit it" | 21:06 |
| smoser | admins dont edit things any more | 21:06 |
| slangasek | and that editing could very well include dropping in a copy of some template that looks at /etc/rc.local.d | 21:06 |
| slangasek | the admin can edit it in as automated a fashion as they wish, but either way, it's not the package's problem :) | 21:07 |
| smoser | if rc.local.d is not the packages problem, then really, rc.local is not either. they are the same problem. | 21:07 |
| smoser | one is just older. | 21:07 |
| slangasek | yes, rc.local is an interface from the package | 21:07 |
| smoser | i really think that it adds a large usefulness at the cost of 2 forks in the boot | 21:08 |
| slangasek | any interfaces beyond that, such as a hypothetical rc.local.d, are not the problem of sysvinit | 21:08 |
| smoser | with, extremely low mantainence issues. | 21:08 |
| hallyn | slangasek: 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-bit | 21:08 |
| smoser | slangasek, so is that a definitive "NO" ? | 21:12 |
| smoser | i'm willing to accept that it is. | 21:12 |
| slangasek | smoser: nothing is ever settled and I don't have the last word; but my opinion is firm :) | 21:12 |
| slangasek | this is something that's easy to design and implement without ever touching the sysvinit package | 21:13 |
| slangasek | because *by definition* the package won't mess with whatever changes you make to rc.local - including tweaking it to use rc.local.d | 21:13 |
| smoser | right. and thats fine. | 21:14 |
| smoser | so its easy to add | 21:14 |
| smoser | but its not easy to determine if modifying rc.local is going to stomp on someone else's already modified rc.local | 21:14 |
| smoser | so you have to assume that youc an't do that if you're trying to be a good tenant. | 21:14 |
| slangasek | mkdir /etc/rc.local.d; mv /etc/rc.local /etc/rc.local.d/reallylocal; echo > /etc/rc.local <<EOF.. :) | 21:15 |
| slangasek | and besides, I thought admins didn't edit files anymore, so why would there be anything in /etc/rc.local to preserve ;) | 21:15 |
| mbiebl | slangasek: /etc/rc.local.d, really? Isn't that what /etc/init.d is for... | 21:16 |
| hallyn | slangasek: i'm not sure offhand what the best place is to tell the pkg not to build for 32-bit... | 21:16 |
| slangasek | mbiebl: 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 |
| slangasek | hallyn: debian/control + debian/rules - build-dependencies, architecture fields, and the target can all be annotated by architecture | 21: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 |
| mbiebl | from a package pov or sysadmin? | 21:17 |
| mbiebl | and no, I don't think it's a good idea, fwiw | 21:18 |
| SpamapS | slangasek: 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 |
| slangasek | mbiebl: /etc/rc.local.d obviously wouldn't belong in a package | 21:21 |
| slangasek | since it extends /etc/rc.local, which is not for packages | 21:21 |
| slangasek | SpamapS: again, how late is late | 21:22 |
| slangasek | I think this is underspecified at the moment | 21:22 |
| smoser | slangasek, i dont think that arguing "rc.local is unknown" is really relevant. | 21:23 |
| slangasek | hmm? | 21:24 |
| slangasek | if you want to define something that extends rc.local with rc.local.d, then obviously you'll get the same semantics | 21:24 |
| smoser | you 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 |
| slangasek | but 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 systems | 21:25 |
| slangasek | smoser: 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 deliver | 21:25 |
| hallyn | slangasek: ok thanks, i'll try and get a fix for qemu-linaro | 21:25 |
| smoser | slangasek, then we should use rc.local.d because that invents nothing new. | 21:25 |
| smoser | it re-uses a broken definition with the same definition | 21:26 |
| smoser | :) | 21:26 |
| slangasek | smoser: if you wish :) I'm not opposed to /etc/lateboot.d, I just think it has a prereq | 21:26 |
| slangasek | hallyn: I'm already elbow-deep in the package - I can take care of it if you want | 21:27 |
| SpamapS | Or 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 |
| SpamapS | But 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 |
| smoser | SpamapS, i agree with that (bug so is the transition to upstart ;) | 21:29 |
| SpamapS | Though 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 |
| mbiebl | SpamapS: 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 |
| mbiebl | but I better just shut up now... | 21:31 |
| * micahg is syncing ca-certificates and crossing his fingers | 21:31 | |
| mbiebl | SpamapS: that is rc.boot all over again... | 21:33 |
| hallyn | slangasek: oh, missed that - that'd be terrific, and i'll look at how you did it and learn :) thanks | 21:34 |
| SpamapS | mbiebl: 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 |
| slangasek | SpamapS, 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 case | 21:37 |
| slangasek | but that's not actually a material difference from what we currently do | 21:37 |
| mbiebl | SpamapS: that's the crux, what exactly is "late"? imho that just makes it easier for admins to shoot themselves in the foot | 21:38 |
| slangasek | mbiebl, SpamapS: right; as more jobs move to upstart, rc.local is likely to be running *before* most services have started | 21:43 |
| SpamapS | slangasek: indeed, thats basically a wait() call later. ;) | 21:43 |
| SpamapS | slangasek: 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 |
| SpamapS | actually.. hm | 21:46 |
| SpamapS | this is where the 'network-services' job comes in handy | 21:46 |
| SpamapS | if 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 |
| SpamapS | something to think about for 12.10 (assuming the systemd flying monkies don't carry us away) | 21:47 |
| slangasek | SpamapS: so jobs would be 'start on starting network-services', and rc.local would be 'start on started network-services'? | 21:47 |
| SpamapS | slangasek: and stopped rc RUNLEVEL=[2345] | 21:50 |
| * slangasek nods | 21:51 | |
| quadrispro | eh-ehy! hi all! | 22:18 |
| soren | Is there anything about the (PPA) buildd's that might prevent me from readlink()ing /proc/<PID>/exe ? | 22:23 |
| soren | infinity: You'd probably know? ^ | 22:24 |
| hallyn | SpamapS: perhaps i could get you to pick a good start on for libvirt? bc i've not followed this whole conversation | 22:38 |
| SpamapS | start on (runlevel [2345] and stopped networking RESULT=ok) | 22:39 |
| SpamapS | hallyn: thats a bit explicit given 11.10+'s guarantee that all of /etc/network/interfaces will be up | 22:39 |
| SpamapS | hallyn: until we have the network-services job in place, runlevel [2345] is good | 22:40 |
| hallyn | SpamapS: so to be clear, you're saying make it jsut "start on runlevel [2345]" ? | 22:40 |
| SpamapS | hallyn: yes if all it requires is all network interfaces and filesystems to be up and mounted. | 22:41 |
| hallyn | SpamapS: thanks, put that in my "to do on next push" list | 22:41 |
| infinity | soren: Nope, should work fine. | 22:51 |
| bdmurray | um, how do you start an ssh server? | 22:52 |
| StevenK | sudo start ssh ? | 22:52 |
| infinity | (after installing it) | 22:52 |
| bdmurray | right and I'm still seeing 'Unknown job: ssh' | 22:53 |
| bdmurray | on a precise live cd | 22:53 |
| infinity | bdmurray: It's not on the livecd. | 22:53 |
| infinity | bdmurray: apt-get install ssh | 22:53 |
| infinity | (or openssh-server, which ssh depends on) | 22:53 |
| bdmurray | yes when I said right I meant I've installed openssh-server | 22:54 |
| bdmurray | and I see ssh in /etc/init.d/ | 22:54 |
| infinity | So start it from init.d | 22:54 |
| soren | infinity: Ok, cool. Thanks. | 22:54 |
| infinity | Though installing it should have started it. | 22:55 |
| infinity | Unless you had/have no interfaces up. | 22:55 |
| bdmurray | how could I have installed it then? | 22:55 |
| infinity | Fair point. :P | 22:55 |
| StevenK | Via a USB key and dpkg -i :-P | 22:56 |
| bdmurray | with /etc/init.d/ssh start I see use service and then 'start: Unknown job: ssh' again | 22:57 |
| broder | "service ssh start" | 22:57 |
| broder | oh, on lucid you still needed to do "initctl reload-configuration" | 22:57 |
| broder | whenever something changed /etc/init | 22:57 |
| bdmurray | this is just a precise live cd | 22:57 |
| broder | yes, you've installed the server, but because /etc/init/ssh.conf wasn't there at bootup, upstart doesn't know about it | 22:58 |
| broder | so run "initctl reload-configuration" to pick up the changes | 22:58 |
| infinity | ... really? | 22:58 |
| broder | that was definitely the case with upstart for some number of releases | 22:58 |
| infinity | Oh, wait, does upstart rely on inotify to scan for new services? | 22:58 |
| RAOF | I'm *pretty* sure upstart watches /etc/init with inotify. | 22:59 |
| bdmurray | broder: okay that worked thanks | 22:59 |
| infinity | If so, overlayfs's lack of inotify support would break that. | 22:59 |
| broder | infinity: hahaha. yes, yes it does | 22:59 |
| bdmurray | great | 22:59 |
| bdmurray | does anybody know of a bug about that being reported yet? | 22:59 |
| infinity | apw: Say, have we ever escalated the important of inotify in overlayfs? :P | 23:00 |
| infinity | bdmurray: I think Andy has a bug, no idea what sort of movement it has. | 23:00 |
| infinity | apw: s/important/importance/ | 23:00 |
| bdmurray | bug 882147 right? | 23:01 |
| ubottu | Launchpad bug 882147 in linux (Ubuntu Precise) "overlayfs does not implement inotify interfaces correctly" [High,Triaged] https://launchpad.net/bugs/882147 | 23:01 |
| infinity | bdmurray: Should do. | 23:02 |
| === dduffey is now known as dduffey_afk | ||
| === dendrobates is now known as dendro-afk | ||
| slangasek | hallyn: pushed my qemu-linaro changes to the UDD branch, if you want to have a gander | 23:39 |
| hallyn | slangasek: fetching | 23:40 |
| hallyn | slangasek: 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 |
| slangasek | hallyn: 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 used | 23:59 |
| slangasek | so this DTRT in the sense that once it's published, I'll yank the i386 binary out of the archive with my AA hat on | 23:59 |
| hallyn | slangasek: cool :) thanks | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!