| bluesabre | greeting sponsors! | 02:34 |
|---|---|---|
| bluesabre | Is anybody interested in uploading... | 02:35 |
| bluesabre | https://bugs.launchpad.net/ubuntu/+source/xubuntu-docs/+bug/1294932 | 02:35 |
| ubottu | Launchpad bug 1294932 in xubuntu-docs (Ubuntu) "[needs-packaging] xubuntu-docs 14.04.1" [Undecided,Confirmed] | 02:35 |
| bluesabre | and... | 02:35 |
| bluesabre | https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1294459 | 02:35 |
| ubottu | Launchpad bug 1294459 in shimmer-themes (Ubuntu) "[needs-packaging] shimmer-themes-1.7.2" [Undecided,Confirmed] | 02:35 |
| bluesabre | Please let me know if there are any questions or concerns | 02:36 |
| === OutOfControl is now known as benonsoftware | ||
| pitti | Good morning | 06:16 |
| doko | pitti, could you have a look at https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.91/+build/5827268 | 07:06 |
| pitti | doko: yes, will do; thanks | 07:07 |
| doko | thanks | 07:08 |
| dholbach | good morning | 07:24 |
| ion | that | 07:31 |
| === tkamppeter_ is now known as tkamppeter | ||
| YokoZar | Laney: Can I kindly trouble you to remerge p11-kit to fix https://bugs.launchpad.net/ubuntu/+source/p11-kit/+bug/1027299 :) Alternatively, lmk if I should do it and seek sponsorship. | 08:05 |
| ubottu | Launchpad bug 1027299 in p11-kit (Ubuntu) "Seperate out p11-kit-trust.so into a multiarch package to prevent errors in Wine" [Undecided,Confirmed] | 08:05 |
| pitti | RAOF: ah, I got umockdev-record --evemu working :) | 08:33 |
| pitti | RAOF: (mostly, need to fiddle with the "record device path" still) | 08:34 |
| dholbach | @pilot in | 08:41 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach | ||
| * pitti hugs dholbach | 08:41 | |
| * dholbach hugs pitti back :) | 08:41 | |
| dholbach | hey happyaron - how are you doing? did you see https://bugs.launchpad.net/indicator-keyboard/+bug/1290881? (just checking because I'm doing some sponsoring right now) | 08:54 |
| ubottu | Launchpad bug 1290881 in indicator-keyboard (Ubuntu) "indicator-keyboard suppresses IBus candidate window" [High,In progress] | 08:54 |
| happyaron | dholbach: haven't looked at the patch yet, will do it this night | 08:55 |
| dholbach | happyaron, thanks a lot! | 08:55 |
| happyaron | np, :) | 08:59 |
| seb128 | dholbach, hey, happy piloting ;-) | 09:00 |
| doko | mdeslaur, can you have a look at https://bugs.launchpad.net/ubuntu/trusty/+source/ca-certificates-java/+bug/1258286 ? | 09:02 |
| ubottu | Launchpad bug 1258286 in ca-certificates-java (Ubuntu Trusty) "CAcert should not be trusted by default" [High,Confirmed] | 09:02 |
| * dholbach hugs seb128 | 09:13 | |
| * seb128 hugs dholbach back | 09:13 | |
| dholbach | bluesabre, for bug 1294459 do you have a .orig.tar.gz file somewhere? | 09:17 |
| ubottu | bug 1294459 in shimmer-themes (Ubuntu) "[needs-packaging] shimmer-themes-1.7.2" [Undecided,Confirmed] https://launchpad.net/bugs/1294459 | 09:17 |
| tvoss | doko, good morning | 09:45 |
| tvoss | doko, could you have a look here: https://code.launchpad.net/~robru/dbus-cpp/fix-ppc64el/+merge/211820 | 09:45 |
| tvoss | ? | 09:45 |
| doko | tvoss, you don't need the b-d on gcc-4-x, g++-4.x depends on it. please don't add an explicit b-d on g++-4.8, but use g++ instead | 09:47 |
| tvoss | doko, ack | 09:48 |
| doko | tvoss, maybe just define something like v_ext=4.7, and then use g++$(v_ext) | 09:49 |
| doko | tvoss, ahh, and g++ is a dependency of build-essential, so you don't need it at all | 09:52 |
| tvoss | doko, okay, so I should be good with just g++-4.7 for non ppc64el, correct? | 09:52 |
| doko | yes | 09:53 |
| damianatorrpm | Hi all :-) | 10:03 |
| damianatorrpm | How are you doing? | 10:03 |
| tvoss | doko, https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-ppc64-el/+merge/211894 | 10:05 |
| doko | tvoss, 4.8 still hardcoded | 10:07 |
| doko | ifneq (,$(filter $(DEB_HOST_ARCH),ppc64el)) | 10:07 |
| doko | v_ext = -4.7 | 10:07 |
| doko | endif | 10:07 |
| doko | export CC=$(DEB_HOST_GNU_TYPE)-gcc$(v_ext) | 10:07 |
| doko | export CXX=$(DEB_HOST_GNU_TYPE)-g++$(v_ext) | 10:07 |
| damianatorrpm | tiny question: libdubsmenu & libdbusmenu-qt, in ubuntu 13.10 I can see only in the repos libdbusmenu-qt, before there was libdbusmenu-gtk2 and libdusmenud-gtk3 which required patched gtk2/gtk3 | 10:08 |
| damianatorrpm | are they now dropped and only libdubsmenu-qt is still there? | 10:08 |
| damianatorrpm | larsu: maybe you know ? :) :) | 10:08 |
| Laney | Mirv: hm, qtbase didn't get pushed back? | 10:16 |
| === FourDollars_ is now known as FourDollars | ||
| tvoss | doko, updated: https://code.launchpad.net/~thomas-voss/dbus-cpp/fix-ppc64-el/+merge/211894 | 10:30 |
| doko | tvoss, ok. still b-d's on gcc-4.7, but doesn't hurt | 10:32 |
| tvoss | doko, has to bd on gcc-4.7 until we update the papi to use > 4.7 | 10:33 |
| doko | tvoss, g++-4.7 depends on gcc-4.7, so it is not needed ... | 10:33 |
| tvoss | doko, sorry, got it now | 10:33 |
| cjwatson | damianatorrpm: "apt-cache search -n dbusmenu-gtk" still returns results on 14.04 for me | 10:38 |
| tseliot | directhex: in case the email didn't make it, thanks! :) | 10:46 |
| Mirv | Laney: it's not formally part of CI Train, so "the other CI" needs to merge it. trying that now. | 10:47 |
| bluesabre | dholbach: yeah, its in the branch: https://bazaar.launchpad.net/~smd-seandavis/xubuntu-artwork/shimmer-themes-1.7.2/files | 11:08 |
| dholbach | ah ok, thanks | 11:08 |
| bluesabre | occasionally, there is some confusion with this package since its a multiple upstream tarball package, previous note with previous upload https://bugs.launchpad.net/ubuntu/+source/shimmer-themes/+bug/1227402/comments/7 | 11:11 |
| ubottu | Launchpad bug 1227402 in shimmer-themes (Ubuntu) "Please update shimmer-themes to 1.6.2" [Undecided,Fix released] | 11:11 |
| bluesabre | thanks for taking a look :) | 11:11 |
| mdeslaur | doko: sure, I'll take a look....it ftbfs? | 11:22 |
| mdeslaur | doko: oh, nm, I see the test | 11:24 |
| doko | mdeslaur, ok, thanks | 11:34 |
| === MacSlow is now known as MacSlow|lunch | ||
| zequence | Laney: I see you are marked as janitor for ubuntustudio-live in the sponsors queue. Any more hinders in getting it through to universe? | 12:33 |
| Laney | zequence: I don't know what that means | 12:34 |
| zequence | Laney: From what I understand, it's uploaded, but needs approval from archive admins | 12:34 |
| Laney | All that means is that I made the last comment on the bug | 12:34 |
| zequence | Ah | 12:34 |
| Laney | It's been uploaded, yes, just waiting for approval | 12:35 |
| zequence | I have a habit of misreading things :P | 12:36 |
| bigon | doko: hi | 12:41 |
| bigon | I was wondering, about https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720545 | 12:42 |
| ubottu | Debian bug 720545 in src:bash "bash: Please consider removing privmode.diff" [Important,Open] | 12:42 |
| maxiaojun | why usb-creator is so buggy these days? | 13:13 |
| === _salem is now known as salem_ | ||
| === cmagina-away is now known as cmagina | ||
| miraiE | in Kubuntu, what app is similar with Password and Encryption Keys for uploading GPG key? | 13:43 |
| sladen | Riddell: ^^ | 13:46 |
| pitti | Laney, stgraber: this should be a formality, but I filed it nevertheless: bug 1295133 | 13:48 |
| ubottu | bug 1295133 in umockdev (Ubuntu) "FFE: record/replay of input devices using the evemu format" [Wishlist,New] https://launchpad.net/bugs/1295133 | 13:48 |
| Laney | already replying | 13:48 |
| pitti | Laney: wow, you're too fast :) | 13:49 |
| Laney | just happened to open the list :-) | 13:49 |
| pitti | Laney: yes, of course I'm reading incoming bugs, I watch the autopkgtest failures, and the Mir etc. guys know where I live :) | 13:51 |
| Laney | Got to say these things for completionism :P | 13:52 |
| barry | pitti: ping, re LP: #1272359 | 13:53 |
| ubottu | Launchpad bug 1272359 in aptdaemon (Ubuntu Trusty) "needs porting to Python 3.4" [High,In progress] https://launchpad.net/bugs/1272359 | 13:53 |
| pitti | barry: hey | 13:53 |
| barry | pitti: hi | 13:53 |
| pitti | barry: I see similar failures like you, also with current 3.3 | 13:54 |
| barry | pitti: there is no branch of aptdaemon that i can find that actually passes all its tests | 13:54 |
| pitti | barry: i. e. the "FAILED (failures=1, errors=2, skipped=4)" bits | 13:54 |
| pitti | barry: yes, that also happens in trunk | 13:54 |
| barry | pitti: while d/rules runs the test suite at build time, it doesn't ftbfs because the test failures are ignored ;) | 13:54 |
| pitti | barry: I guess trusty around it changed enough to now make it fail | 13:54 |
| barry | pitti: upstream test suite doesn't pass in any of 2.7, 3.3, or 3.4 | 13:55 |
| pitti | *nod* | 13:55 |
| barry | pitti: i am very much inclined to simply disable the dep8 tests for now and file an upstream bug about the test suite | 13:55 |
| pitti | barry: back then when I filed it it still did (and only failed with 3.4), but apparently it now fails with current 3.3, too | 13:55 |
| barry | pitti: 2.7 even ;) | 13:55 |
| pitti | barry: we can just retitle that bug | 13:55 |
| barry | pitti: yep, i'll take care of that. do you have any objections to disabling dep8 for now? | 13:56 |
| pitti | barry: there's no aptdaemon stuck in -proposed due to it, so no need to disable this | 13:56 |
| pitti | barry: yes; that causes more technical liabilities, and the next upstream update might just silently get in with actual regressions | 13:56 |
| barry | pitti: okay, i'm going to just fiddle with the bugs then and let upstream take it from here | 13:58 |
| pitti | barry: thanks | 13:58 |
| barry | pitti: cheers | 13:58 |
| arges | stgraber: hey looking at bug 1254120. trying to isolate problems with ifup/ifdown on bonds. do you know which part of ifupdown would be setting static ips (ip addr ...) ? | 13:58 |
| ubottu | bug 1254120 in ifenslave (Ubuntu) "Bonded interfaces don't come down with a ifdown -a" [High,In progress] https://launchpad.net/bugs/1254120 | 13:58 |
| stgraber | arges: looking | 14:02 |
| stgraber | there isn't really "parts" in ifupdown, it's a gigantic source file :) | 14:02 |
| arges | stgraber: yea, i noticed :) | 14:02 |
| stgraber | but the commands comme from the .defn files which are parsed and expanded at build time | 14:03 |
| stgraber | arges: so FWIW, I never expected my new package to fix bug 1254120 | 14:03 |
| ubottu | bug 1254120 in ifenslave (Ubuntu) "Bonded interfaces don't come down with a ifdown -a" [High,In progress] https://launchpad.net/bugs/1254120 | 14:03 |
| arges | stgraber: yea i've been trying to use strace and 'ifup -v' to figure out where the issues are | 14:03 |
| arges | stgraber: figured as much, I looked at the change and didn't think it woudl either but tested it to make sure | 14:03 |
| arges | i'll look through the .defn files. | 14:04 |
| stgraber | arges: let me update my network testing box to see if I can reproduce that issue easily here | 14:04 |
| arges | stgraber: yea, i'm doing this all in VMs and its pretty trivial to reproduce | 14:04 |
| stgraber | my test box is physical hardware with LACP but that shouldn't matter in this case | 14:05 |
| arges | yup | 14:06 |
| Riddell | sladen: you still into fonts? | 14:07 |
| stgraber | arges: I suspect something may be wrong somewhere in ifenslave which would explain why it's not obvious when running with -v but hopefully I can figure out what exactly once that box is done upgrading (I really should switch to something better than a single core 32bit Atom for that box :)) | 14:08 |
| Riddell | sladen: fancy seeing if this tar is sane and can be built and works? starsky.19inch.net/~jr/tmp/oxygen-fonts-0.4.tar.xz | 14:08 |
| darkxst | dholbach, I have to run, but re Bug 1294891 | 14:08 |
| ubottu | bug 1294891 in Ubuntu "Ubuntu GNOME community wallpapers" [Undecided,Incomplete] https://launchpad.net/bugs/1294891 | 14:08 |
| darkxst | we got permission from image authors to release work under cc-by-sa 3.0, so copyright file should be ok? | 14:08 |
| xnox | balloons: sergiusens: what can I help with to release calendar-app revision 205 or better? It's been blocking python2 removal for a while now. | 14:09 |
| arges | stgraber: yea something intiially is causing it to not create the proper files in /run/network and the ifstate file isn't updated correctly, so I think ifup needs to work. The other question is, do we expect 'ifup bond0' to bring up slave interfaces or that needs to be done before bringing up the bond? | 14:11 |
| sergiusens | xnox, just push balloons around | 14:11 |
| xnox | balloons: i'm prepared to be a slave for you =) calendar-app, please please please =))))) | 14:12 |
| stgraber | arges: ifup bond0 won't bring up slaves, it'll just sit and wait until slaves join. But slaves will bring up bond0, so "ifup eth0" should bring up eth0, bring up bond0 and then add eth0 to bond0 | 14:12 |
| arges | stgraber: gotcha. | 14:13 |
| arges | stgraber: so if i do 'ifup <slave if>' and the bond comes up, do we expect the ifstate file to have bond0=bond0 in it? | 14:14 |
| xnox | balloons: honestly changes from v201 to v205 are trivial, and are trivial to verify. We shouldn't need to wait on all the cool things to be developed and be ready. | 14:14 |
| stgraber | arges: we do, though I suspect that may be the problem | 14:15 |
| balloons | lol xnox | 14:15 |
| arges | stgraber i think so too | 14:16 |
| balloons | xnox, see my perhaps confusing mail on the list. We need to release calendar too. But trunk is broken. So I have a merge reverting the bad changes in trunk that we can land | 14:16 |
| balloons | alternatively, we could fix the trunk version of the app, then land the fixes for the test | 14:16 |
| xnox | balloons: do you want me to prepare v205 click, with diff of what changed is no code change. http://paste.ubuntu.com/7125444/ | 14:16 |
| xnox | balloons: you don't have to release trunk. | 14:16 |
| xnox | balloons: i'm asking to release revision 205. | 14:17 |
| xnox | balloons: which has _no code changes_ to the app. | 14:17 |
| xnox | balloons: merging back reverts is silly. It's a distributed version control system, checkout the revision you want to release, build the click for that revision # and upload to the store. | 14:17 |
| xnox | balloons: my changes were ready eon ages ago, why should i be blocked by broken trunk? i can trivially push current trunk to a staging branch and do push --override back to revision 205 if you wish. | 14:18 |
| xnox | balloons: then "release trunk" and push back the current trunk back in place. But it's silly if we need to do that. | 14:19 |
| xnox | balloons: am I missing something? | 14:19 |
| xnox | bzr branch lp:ubuntu-calendar-app -r205 is not broken, and is trunk. | 14:19 |
| balloons | https://bugs.launchpad.net/ubuntu-calendar-app/+bug/1294181 | 14:20 |
| ubottu | Launchpad bug 1294181 in Ubuntu Calendar App "Autopilot tests crashing in switch_to_tab helper" [Critical,Confirmed] | 14:20 |
| balloons | https://bugs.launchpad.net/ubuntu/+source/qtdeclarative-opensource-src/+bug/1294995 | 14:20 |
| ubottu | Launchpad bug 1294995 in qtdeclarative-opensource-src (Ubuntu) "qmlscene crashed with SIGSEGV in value() when running calendar-app" [Undecided,Confirmed] | 14:20 |
| balloons | xnox, it sounds like we're going to go ahead with landing my mp which reverts the offending changes: https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/revert-212/+merge/211813 | 14:21 |
| xnox | balloons: and? | 14:21 |
| xnox | balloons: dude, we need to fix packaging and metadata of the app. The app itself would be identical but the manifest revision number of where to fetch the tests from. | 14:22 |
| stgraber | arges: hmm, nope, that's not it. In my setup here with eth0+eth1 in bond0 and bond0 in br1000, I get the expect behavior, proper bring down and consistent ifstate | 14:22 |
| === MacSlow|lunch is now known as MacSlow | ||
| stgraber | arges: now trying with IP config directly on bond0 as you have | 14:22 |
| xnox | balloons: with normal packages, i would have done direct to the archive upload weeks ago. | 14:22 |
| maxiaojun | http://udisks.freedesktop.org/docs/latest/gdbus-org.freedesktop.UDisks2.Block.html#gdbus-method-org-freedesktop-UDisks2-Block.Format | 14:22 |
| maxiaojun | seems like erase: '' no longer works on trusty | 14:23 |
| balloons | xnox, I'm blocked on releasing anything unless tests pass | 14:23 |
| balloons | and tests fail in trunk because the app has some critical bugs | 14:23 |
| balloons | regardless, it sounds like we are going to be able to land something today that should solve your issue | 14:24 |
| balloons | so details aren't important | 14:24 |
| stgraber | arges: nope, things still get brought up correctly with "ifup eth0 && ifup eth1" and brought down correctly with "ifdown -a"... | 14:24 |
| stgraber | now trying with an exact copy of your config :) | 14:25 |
| xnox | balloons: "I'm blocked on releasing anything unless tests pass" that sounds really odd, can you ellaborate where this requirement is comming from? because that should be blocking merging and landing new features, this should be blocking any other no-change rebuilds. E.g. just like we did for qt5.2 landing and etc?! | 14:25 |
| arges | hmm | 14:25 |
| xnox | balloons: the details are important, as I have been blocked for about 4 weeks due to inability to do click uploads. | 14:25 |
| xnox | balloons: those that _do_ not match trunk. | 14:25 |
| arges | stgraber: it works if the bond is using dhcp, but not with a static ip | 14:26 |
| arges | stgraber: in fact it seems to affect any static interfaces... I just set eth1 to static and tried to ifdown it with no luck | 14:29 |
| roadmr | Hey folks, I see (https://launchpad.net/builders) that ppc64el builders are available for official distro but not for PPAs. How can I provide ppc64el packages on a PPA? | 14:30 |
| cjwatson | roadmr: that's only possible with devirtualised PPAs, which are only provided for special purposes | 14:31 |
| stgraber | arges: I don't use any dhcp here | 14:32 |
| stgraber | arges: here are the config I tried so far: http://paste.ubuntu.com/7125505/ | 14:33 |
| stgraber | arges: both come up fine with either "ifup eth0 && ifup eth1" or "ifup -a" and they get brought down cleanly with "ifdown -a" | 14:33 |
| arges | stgraber: let me adjust my config here | 14:34 |
| roadmr | cjwatson: devirtualized meaning native hardware? oh those must be scarce... who can help me decide if my purpose is special enough and maybe give us access to this? | 14:37 |
| mdeslaur | Laney: do we have a codesearch set up on the ubuntu somewhere? | 14:37 |
| maxiaojun | ask again, who takes care of usb-creator? | 14:37 |
| arges | stgraber: i also found another issue where if I have a bond my vm takes much longer to boot up because i get 'bonding: bond0: unable to update mode because interface is up' | 14:37 |
| arges | so i should file a separate bug for that | 14:37 |
| Laney | mdeslaur: ya: http://ubuntu-codesearch.surgut.co.uk/ | 14:38 |
| cjwatson | roadmr: #webops internal | 14:38 |
| Laney | be patient with it and refresh a couple of times if you get timeouts | 14:38 |
| maxiaojun | xnox: ping | 14:38 |
| mdeslaur | Laney: sweet, thanks! | 14:38 |
| roadmr | cjwatson: great, thanks so much for the info. I'll ask there | 14:38 |
| xnox | maxiaojun: hey! | 14:38 |
| arges | stgraber: i can still easily reproduce with http://paste.ubuntu.com/7125534/ | 14:39 |
| stgraber | arges: so even if your config (dropping the eth0 and replacing eth1 by eth0 and eth2 by eth1), I still get things to work here... | 14:39 |
| arges | if I change bond0 from static to dhcp it works | 14:39 |
| maxiaojun | xnox: usb-creator's "Erase Disk" seems totally broken in trusty | 14:40 |
| xnox | maxiaojun: yeah. I have seen patches posted to the bugs on usb-creator. But I didn't review / upload them yet. I was planning to do it today or tomorrow. | 14:40 |
| arges | stgraber: I'll try this on hardware. Mind reproducing this in a VM? (just to prove i'm not crazy) | 14:41 |
| stgraber | arges: if I can find a machine where I have some kind of VM technology installed :) | 14:42 |
| stgraber | (sorry, LXC maintainer here) | 14:42 |
| maxiaojun | xnox: i cannot fix it even if i traced to usb-creator-helper | 14:42 |
| arges | stgraber: ah. ok i'm testing on hw now | 14:42 |
| jdstrand | Laney: curious, is that just for the dev release? | 14:43 |
| Laney | jdstrand: ya | 14:43 |
| Laney | YokoZar: I uploaded that, thanks for pointing it out | 14:44 |
| Cimi | mterry, how do I test on the phone? branch and compile? | 14:44 |
| mterry | Cimi, the wizard? | 14:44 |
| Cimi | yup | 14:45 |
| mterry | Cimi, yeah you could do that, and run it manually... | 14:45 |
| Cimi | ok | 14:45 |
| mterry | Cimi, alternatively, you could use the upstart job that we don't actually ship in the deb, but is in the source tree | 14:45 |
| mterry | Cimi, place that in /usr/share/upstart/sessions | 14:45 |
| arges | stgraber: just to confirm you've been testing trusty right? | 14:46 |
| maxiaojun | xnox: call to UDisks2's format either error or timeout (cannot find a way to do 'quick format' and do not where the time limit is set) | 14:46 |
| stgraber | arges: yep, up to date trusty + ifupdown from my PPA | 14:46 |
| arges | stgraber: ok i'm using the same in my vm with your ppa, and still reproducing it | 14:47 |
| balloons | xnox, so we are landing a fix to the store right now. As far as what happened, well when qt 5.2 landed the trunk and supposed stable version of calendar stopped working due to the bugs I linked. I understand you are upset because you made only manifest changes, however I cannot release an old revision, it has to be current trunk | 14:48 |
| stgraber | arges: testing in a clean vm here now | 14:49 |
| arges | stgraber: ok... on hardware. ifdown -a; ifconfig (bond0 is gone!), ifup -a && ifdown -a (bond0 is still there) | 14:49 |
| stgraber | good, so I'm not insane :) | 14:49 |
| stgraber | oh no | 14:50 |
| stgraber | misread | 14:50 |
| xnox | balloons: that sounds very wrong that " we cannot release an old revision," | 14:50 |
| xnox | balloons: we do this all the time for all components in the archive, in main and the ubuntu-touch seeds, both click apps and .debs | 14:50 |
| xnox | balloons: we should fix that. | 14:50 |
| balloons | xnox, afaict releasing an old version would still have broken tests. So yes it would have fixed your issue, but not the issues with the landing team and wouldn't pass the store review | 14:51 |
| xnox | balloons: ?! dude didrocks himself uploads things to revert, or do no-change uploads without regressing beyond what was on the image already. | 14:52 |
| xnox | balloons: e.g. we go up and down broken versions all the time. | 14:52 |
| xnox | balloons: i'd love to hear comments from the landing team about this. | 14:52 |
| didrocks | xnox: can you stop trolling and start helping in the bazillion of regressions we have please? | 14:53 |
| balloons | xnox, I have things rejected all the time for the store.. | 14:53 |
| balloons | anyways, your pain is not just your own.. the calendar devs, landing team, everyone has felt the impact of calendar regressing. But it's fixed now | 14:54 |
| didrocks | xnox: and we do test the revert before uploading and ensuring we don't introduce regressions compared to latest promoted image FWIW | 14:54 |
| arges | stgraber: on hw: reboot interfaces are correct, ifdown -a - everything is down, ifup -a - I get a kernel message 'bonding: bond0: unable to update mode because interface is up' and I noticed in ifenslave it tries to set the bonding mode but that command fails... | 14:54 |
| balloons | well, fixed in the sense you'll get a new build | 14:54 |
| xnox | didrocks: correct. and ballons seems to think that this is not the case here. | 14:55 |
| arges | and on my vm, I get that kernel message right on boot every time (in fact it delays boot up by a minute or so) | 14:55 |
| xnox | didrocks: sure, what do you want me to fix in the fork of calendar-app form revison 201? | 14:56 |
| didrocks | xnox: I'm not sure about anything right now, calendar-app has no issue with balloons's fixes from what I know of | 14:57 |
| xnox | didrocks: it appears to have been accepted to have a certain baseline from way before qt5.2 uploads et.al. | 14:57 |
| xnox | didrocks: gallery-app? | 14:58 |
| didrocks | xnox: read #ubuntu-touch for the regressions | 14:58 |
| xnox | didrocks: dude calendar_app is 100% green with no crashes http://ci.ubuntu.com/smokeng/trusty/touch/mako/248:20140320:20140304/7277/calendar_app/ | 14:59 |
| didrocks | xnox: I know that link | 14:59 |
| xnox | didrocks: please explain how calendar-app is not in a releasible state up to revision 205. | 14:59 |
| didrocks | in case you wonder | 14:59 |
| didrocks | I don't know | 14:59 |
| didrocks | did I say that? | 14:59 |
| didrocks | did I write that? | 14:59 |
| xnox | didrocks: no. But balloons above claims landing team is blocking releasing calendar-app. | 15:00 |
| didrocks | xnox: so how do you want me to explain something I didn't write? | 15:00 |
| didrocks | balloons: what's about this? ^ | 15:00 |
| xnox | didrocks: balloons: so what do I need to do to release 205? do you want to execute full manual testing plan? | 15:00 |
| xnox | didrocks: well, I'm trying to find out what needs doing to release calendar app to revision 205 =)))) but i don't know who would know =)))) | 15:01 |
| balloons | xnox, ?? What do you need. We are releasing a build from today that contains everything up through rev211, which has your changes | 15:01 |
| pitti | barry: big +1 on dropping 3.3 | 15:01 |
| balloons | just wait for it to land and you should be set? | 15:01 |
| didrocks | xnox: yeah but please don't assume and start telling things that aren't written | 15:01 |
| didrocks | xnox: there is enough pressure and confusion on the real regression | 15:01 |
| didrocks | no need for noise on top of that | 15:02 |
| didrocks | that would be appreciated | 15:02 |
| barry | pitti: \o/ | 15:02 |
| xnox | balloons: what's special about today vs all the past 4 weeks. I mean fine, but what can I do to prevent 4week delays like this?! | 15:02 |
| pitti | barry: that's essentially "drop it from py3versions; rebuild $world; remove package", right? | 15:02 |
| xnox | didrocks: well i have spare cycles and time to test and release things, yet people who can release are over-worked with "the real regressions" | 15:03 |
| didrocks | xnox: yeah, and not sure why you are telling that I wrote we are blocking you | 15:03 |
| barry | pitti: yes, although $world only needs to include packages with extension modules (to be identified) | 15:03 |
| xnox | didrocks: i'm asking how to help. Can i have access to e.g. click packages releases? and be one more lander for that? | 15:03 |
| didrocks | xnox: I don't know, I can't release click package either | 15:03 |
| === qengho is now known as CardinalFang | ||
| === CardinalFang is now known as qengho | ||
| xnox | didrocks: cause i've checked all the ci-train stuff, but the click/core-apps are not listed. Who owns those? | 15:04 |
| xnox | balloons: is it only you who can release core-app clicks? | 15:04 |
| barry | pitti: doko is going to upload 3.4 final tomorrow or this weekend, so let's wait for that | 15:04 |
| pitti | barry: ack | 15:04 |
| didrocks | xnox: and sergiusens | 15:04 |
| didrocks | but you just started a mail on the ML | 15:04 |
| stgraber | arges: just for fun, can you comment out eth0 in both your setups and try again? | 15:04 |
| didrocks | if you want to discuss that on IRC, use IRC | 15:04 |
| didrocks | don't double the discussion | 15:04 |
| stgraber | arges: if that magically makes the issue disappear for you, that'd at least explain why I can't reproduce your problem | 15:05 |
| xnox | didrocks: well there is no resolution. i basically got told off, to sit and wait and do nothing it will be done "today". | 15:05 |
| arges | stgraber: sure i'll try it | 15:05 |
| didrocks | xnox: on the ML? You wrote the email 20 minutes ago and you already get one answer | 15:06 |
| arges | stgraber: wierd... without the extra eth0 interface ifdown -a && ifup -a works fine | 15:08 |
| arges | stgraber: i looped it about 10 times with no problems | 15:09 |
| arges | stgraber: i'm going to have to write some additoinal tests for ifupdown : ) | 15:09 |
| stgraber | arges: good, so that confirms what I'm seeing here. | 15:09 |
| stgraber | arges: now the question is wth is eth0 triggering the bond somehow... | 15:09 |
| stgraber | I guess diffing "ifup -a" with "ifup --exclude=eth0 -a" may point us in the righ direction | 15:11 |
| stgraber | well, both of those with -v obviously | 15:11 |
| arges | good idea. i'll give that a try | 15:12 |
| stgraber | just ifup/ifdown of eth0 doesn't seem to do anything wrong, so it's pretty confusing | 15:13 |
| === FJKong is now known as FJKong_afk | ||
| xnox | didrocks: no, i've emailed to the ML based on the conversations with balloons. After that, you, ballons and I continued talking about this topic. | 15:13 |
| didrocks | xnox: ack then, seems it's resolved now though, right? balloons is going to release it? | 15:14 |
| arges | stgraber: confirmed that ifdown -a && ifup -a --exclude=eth0 do the correct thing for 5 iterations | 15:14 |
| stgraber | arges: hmm, I'm getting an error from lockfile when doing ifup -a, I wonder if that could be the problem | 15:15 |
| xnox | didrocks: this landing is resolved, yes. the backlog in .click releases of core-apps is subpar and needs more people helping out. | 15:15 |
| dholbach | darkxst, if the content is all cc-by-sa - all the files should say so | 15:15 |
| xnox | sergiusens: balloons: can you train me up to prepare and help with releasing .click core-apps? | 15:15 |
| sergiusens | xnox, sure | 15:15 |
| didrocks | xnox: yeah, that was on the schedule to discuss this week to have one release process for debs and clicks, but regressions blocked to take the time for it | 15:16 |
| sergiusens | not much training needed; I'll ping back later today | 15:16 |
| sergiusens | ah, right | 15:16 |
| sergiusens | we can do it then as well | 15:16 |
| xnox | sergiusens: balloons: that would be appreciated and hopefully would free you up your development time on more urgent things. | 15:16 |
| didrocks | sergiusens: no time due to regression and not around tomorrow | 15:17 |
| arges | stgraber: are you only seeing this with -v? | 15:18 |
| sergiusens | didrocks, I'm not around tomorrow either | 15:18 |
| balloons | xnox, do you have a device? | 15:18 |
| stgraber | arges: that can be ignored, it was just the ntpdate hook being unhappy, I moved it away for now | 15:19 |
| Cimi | mterry, it's not optimal, takes ages | 15:19 |
| xnox | balloons: i have grouper and mako. | 15:20 |
| stgraber | arges: "ifup eth0 eth1 eth2" => missing bond0 in ifstate, "ifup eth1 eth2 eth0" => it's in there and everything works | 15:21 |
| xnox | didrocks: "that was on the schedule to discuss this week" where would this discussion be? | 15:21 |
| xnox | or did you mean last week / vUDS? | 15:22 |
| didrocks | xnox: this week | 15:23 |
| didrocks | didn't get room last wekk | 15:23 |
| didrocks | week | 15:23 |
| arges | stgraber: that's really wierd | 15:23 |
| didrocks | just a hangout | 15:23 |
| didrocks | xnox: you're welcome to organize it | 15:23 |
| didrocks | and promote it | 15:23 |
| xnox | didrocks: i wouldn't know full current release process of either debs or clicks, and even less on how to apply common policies/current practice to both. | 15:24 |
| xnox | didrocks: so i'm not at all the right person to drive that session. | 15:24 |
| didrocks | ok, so let's us driving it | 15:24 |
| didrocks | when we'll get time for that | 15:25 |
| Cimi | seb128, how you test on the phone? | 15:25 |
| Cimi | seb128, it takes light years to compile | 15:25 |
| xnox | didrocks: i wish to be an ad-hoc lander and help releasing things, but so far that was not possible. | 15:25 |
| seb128 | Cimi, light years is an unit of distance :p | 15:25 |
| seb128 | Cimi, you can cross compile on your desktop | 15:26 |
| Cimi | seb128, I know it is, but in my mind imples very far away with current speeds :) | 15:26 |
| seb128 | if you have a build tree it's not that slow to run make | 15:26 |
| seb128 | also often we work on qml | 15:26 |
| Cimi | seb128, I ran debuild | 15:26 |
| Cimi | on the phone | 15:26 |
| Cimi | after fifteen years I run wizard/test.sh | 15:27 |
| Cimi | and it aborts | 15:27 |
| Cimi | fantastic :D | 15:27 |
| Cimi | could not connect to display | 15:27 |
| seb128 | yeah, you don't get to run things by hand on the phone | 15:29 |
| seb128 | you need to --desktop_hint= if you do | 15:29 |
| seb128 | but I never tried the wizard on the phone, maybe mterry did | 15:29 |
| mterry | seb128, Cimi: I did, using the upstart job | 15:29 |
| mterry | seb128, Cimi: but really, integration with phone setup is a TODO (ideally, it will be launched by greeter if needed) | 15:30 |
| Cimi | mterry, how can I test sim card? | 15:30 |
| Cimi | mterry, I did make install | 15:30 |
| mterry | Cimi, try using the upstart job | 15:30 |
| mterry | Cimi, install your built deb | 15:31 |
| Cimi | how do I play with the upstart job? | 15:31 |
| mterry | then copy the upstart job from the source to /usr/share/upstart/sessions | 15:31 |
| mterry | then reboot | 15:31 |
| seb128 | you copy it in the init dir (system or user) | 15:31 |
| seb128 | reboot or just "start <job>" | 15:31 |
| seb128 | well, you might need to ack it for that | 15:31 |
| seb128 | tweak the start conditions | 15:32 |
| Cimi | mterry, job name? | 15:33 |
| mterry | Cimi, wizard/ubuntu-system-settings-wizard.conf | 15:34 |
| xnox | mterry: ~/.config/upstart is read by session upstart as well. | 15:34 |
| Cimi | mterry, start ubuntu-system-settings-wizard doesn't work | 15:34 |
| mterry | Cimi, did you manually copy the job to the upstart directory? | 15:35 |
| Cimi | mterry, /usr/share/upstart/sessions | 15:35 |
| xnox | Cimi: $ init-checkconf ubuntu-system-settings-wizard.conf | 15:36 |
| Cimi | mterry, but I cannot run others in anyway | 15:36 |
| xnox | Cimi: and $ initctl list | grep settings-wizard | 15:36 |
| mterry | Cimi, try rebooting? | 15:36 |
| Cimi | xnox, maybe rebooting | 15:36 |
| xnox | Cimi: sudo -u phablet -i, should setup the right environment and join the existing upstart user session of the currently running phablet user. | 15:36 |
| mterry | (just because then the job will launch itself) | 15:36 |
| dholbach | @pilot out | 15:37 |
| === udevbot changed the topic of #ubuntu-devel to: Trusty Beta 1 released! | Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> saucy | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| stgraber | arges: so I have an idea for at least part of the problem, looking into ifupdown's code to confirm that one now. | 15:38 |
| stgraber | arges: I suspect that ifup only writes ifstate in one shot at the end of the bring up which will then race with anything happening from upstart... | 15:38 |
| arges | stgraber: this is update_state in main.c? | 15:40 |
| stgraber | arges: yeah, though reading it now, it looks safe... | 15:41 |
| Cimi | mterry, xnox thanks works, and sim detection too | 15:44 |
| Cimi | mterry, seb128 simple one https://code.launchpad.net/~cimi/ubuntu-system-settings/wizard.sim-detection/+merge/211976 | 15:47 |
| seb128 | Cimi, looks good, thanks | 15:50 |
| stgraber | arges: so the reason why bond0 isn't in ifstate is because upstart fails to bring up bond0, I'm trying to figure out exactly why that is though | 15:54 |
| stgraber | arges: oh, hold on, I think I know | 15:55 |
| arges | stgraber: network-interface.conf or networking.conf? | 15:55 |
| arges | stgraber: : ) ok | 15:55 |
| stgraber | arges: yep, figured it out, your config has been wrong all along :) | 15:55 |
| stgraber | arges: you can't have multiple default gateways | 15:56 |
| stgraber | well, you can, but not with the same priority | 15:56 |
| YokoZar | Laney: Thanks! | 15:56 |
| stgraber | dhcp gives you a default gateway, you also have one in bond0, so bond0 fails to come up because ifupdown can't set the gateway | 15:56 |
| stgraber | however bond0 is also created at that point so the rest continues and blows up because bond0 was never initialized due to the failure | 15:57 |
| arges | stgraber: so two things : 1) how come this works on reboot? 2) do you think ifupdown should show a better error message? | 15:57 |
| stgraber | arges: it's a race. If for some reason bond0 comes up before eth0, then things appear to work because dhclient will just silently fail to set its gateway | 15:58 |
| stgraber | arges: ifupdown actually did log an error, just not anywhere where we were looking (it was in /var/log/upstart/network-interface-bond0.log) | 15:59 |
| arges | stgraber: well I just get things like 'Failed to bring up bond' | 15:59 |
| stgraber | arges: to confirm, can you try adding "metric 10" to your bond0 on both test machines and then confirm everything works as expected? | 15:59 |
| stgraber | arges: aren't you getting the netlink error for IP collisions? | 16:00 |
| stgraber | RTNETLINK answers: File exists | 16:00 |
| arges | stgraber: yes I get that error as well | 16:00 |
| arges | ah | 16:00 |
| arges | that's where ip addr sets that gateway and it fails | 16:00 |
| arges | ok | 16:00 |
| stgraber | yep, it fails saying there's already an entry for the default gateway | 16:01 |
| === TheMaster is now known as Guest62851 | ||
| arges | stgraber: ok metric 10 added to the bond0 entry works on the VM | 16:01 |
| stgraber | ok, good, so ifupdown and ifenslave work great, it's just my brain that doesn't, I should have noticed the conflict immediately... | 16:02 |
| arges | stgraber: so why can't we have different default gateways for two different interfaces? | 16:02 |
| arges | stgraber: and if we errored, why does bond0 still come up? and then we can't ifdown it again? | 16:04 |
| arges | so this clearly seems like a configuration error, but i'm wondering if there is something that can be done to make ifupdown more robust with this type of failure | 16:04 |
| stgraber | arges: the actual bond bringup is a bit special. Basically the first interface that's related to a bond (in our case, eth1) will do "echo bond0 > /sys/class/net/bonding_masters" which will create bond0. It'll then enter a loop waiting for ifenslave.bond0 | 16:06 |
| stgraber | the device creation emits a udev event which is picked up by upstart which then starts network-interface with INTERFACE=bond0 | 16:06 |
| stgraber | that in turns calls "ifup --allow=auto bond0" which is responsible for actually setting up all the parameters | 16:06 |
| stgraber | now the problem we had here is that this ifup failed right at the end in the ifupdown code, so not something we can do anything about from the ifenslave code | 16:07 |
| stgraber | and since the device isn't created by ifupdown, it doesn't know how to delete it | 16:07 |
| stgraber | and as everything is done in parallel, the initial ifenslave hook can't get a return code from upstart so can't know that bond0 actually failed to be brought up | 16:08 |
| stgraber | hmm, actually I suppose we could grep for bond0=bond0 in ifstate and try to abort if it's not in there | 16:09 |
| arges | stgraber: ok i think that woudl help rather than getting into this error state | 16:10 |
| arges | stgraber: the other question is why can I do something like "route add default gw 192.168.122.1 netmask 255.255.255.0 dev bond0" even if I have a default gw for eth0? But for some reason I need to change the metric to 10 to get it working with ifupdown/ifenslave/upstart | 16:11 |
| stgraber | arges: http://paste.ubuntu.com/7125986/ | 16:14 |
| stgraber | arges: you only get file exists if the entries are identical, any difference and it'll let you add it | 16:15 |
| arges | stgraber: so 'ip route add ' behaves differently than 'route add' | 16:16 |
| stgraber | arges: route add doesn't appear to set "proto static" | 16:17 |
| arges | stgraber: but isn't there a different in the dev used? | 16:22 |
| arges | what i'm saying is this feels like a workaround and not a fix. because if we're defining a gateway for bond0, it should be for that device and shouldn't conflict with eth0's default gw right? | 16:25 |
| stgraber | arges: there's no such thing as per-device gateway, the default gateway applies to all the trafic | 16:26 |
| arges | stgraber: ah. ok | 16:27 |
| stgraber | arges: so I guess you are only allowed one default gateway per metric and per scope/type | 16:28 |
| stgraber | the device isn't considered at all, so if you try to add the same route for two difference devices, you'll still get File exists (as was the case with your config) | 16:28 |
| arges | stgraber: so the 'real fix would be don't have multiple gateways defined for your network configuration | 16:29 |
| arges | this may explain another issue i'm looking at... | 16:30 |
| stgraber | arges: correct | 16:30 |
| arges | stgraber++ cool thank you so much for your help with this. | 16:30 |
| stgraber | multiple gateways is a nightmare to get right. You can do it with different metric and source based routing but that's a major pain | 16:30 |
| === NishanthMenon__ is now known as NishanthMenon | ||
| arges | stgraber: so looking at the configuration if I wanted eth0 to get an IP from dhcp but my routing table not create a default gw for eth0 how would I specify that? | 16:35 |
| stgraber | arges: I suspect you'd have to change your dhclient.conf | 16:37 |
| arges | stgraber: ok. so i have a couple of suggestions then. Thanks | 16:37 |
| stgraber | arges: hmm, so bad news, there isn't a good way to have bond0 commit suicide if ifupdown fails to set the gateway, that's because there isn't a good way to have ifup call a script on failure for something it does internally | 16:38 |
| stgraber | so I think the best we can do for 14.04 is make sure that we have a paragraph reminding people that this specific config isn't possible | 16:39 |
| arges | stgraber: that sounds good. Where would be the best place for this? ubuntu wiki? | 16:39 |
| arges | man pages? | 16:39 |
| stgraber | arges: probably in the serverguide or wherever caribou was planning on documenting that kind of stuff | 16:41 |
| arges | stgraber: ok i'll work with him on this | 16:41 |
| juliank | bdmurray: WRT the encoding stuff. Instead of hardcoding the encoding in python-apt, how about putting something like http://paste.debian.net/88736/ in front of all dbus daemons using it? | 16:48 |
| juliank | This tells daemons like aptdaemon or software-properties-dbus to use the system's default locale, rather than the C locale, and thus ensures correct encoding, even in non-UTF-8 environments. | 16:49 |
| juliank | Apparently Cyrillic and CJK use non-UTF-8 environments | 16:50 |
| bdmurray | juliank: I don't think I know enough to say one way or the other. | 16:54 |
| bdmurray | barry: are you about? | 16:55 |
| barry | bdmurray: yes | 17:17 |
| bdmurray | juliank: wanted a second opinion about some encoding issues... | 17:18 |
| * barry backscrolls | 17:19 | |
| barry | gosh, i don't know about that pastebin | 17:23 |
| mitya57 | ScottK: can I go ahead with sip/pyqt* update in Trusty? It doesn't add new features (except some new methods in sip) (so probably no FFe is needed), but it will require rebuilding some stuff. | 17:27 |
| tvoss | robru, ping | 17:46 |
| === bfiller is now known as bfiller_afk | ||
| juliank | barry: One of the problems is that dbus starts daemons without a locale, so Python chooses the ANSI_X3.4-1968 encoding. Which fails if the files we open contain non-ANSI stuff like UTF-8 or some other encodings (CJK, etc) | 18:12 |
| juliank | So we need some way to override the preferred encoding of Python. | 18:12 |
| juliank | But that does not seem possible without re-exec()ing | 18:13 |
| juliank | I do not want to force everyone to have their /etc/apt/sources.list in UTF-8. | 18:13 |
| sladen | juliank: python -S then sys.setdefaultencoding("utf-8") ? | 18:16 |
| barry | juliank: i generally prefer to open text files with an explicit encoding, which of course you have to know ahead of time. in py3, built-in open() has an encoding argument, which i almost always set to utf-8. but if the file contains non-utf8, you still have to be explicit (so how would you know what it contains if you don't already know, if you know what i mean ;) | 18:17 |
| juliank | sladen: setdefaultencoding() does not change the preferred encoding. | 18:17 |
| rsalveti | xnox: are you uploading a new android today still? | 18:18 |
| juliank | barry: The user edits the files with a text editor, which chooses whatever the locale tells him. So clients using python-apt should just use the same encoding, as the normal admin does. Which is probably what /etc/defaults/locale | 18:18 |
| juliank | says. | 18:18 |
| juliank | Python 3 automatically chooses the default file encoding from LANG, and I think that's a good idea, because things work in almost all cases. It only breaks for dbus services, because dbus starts services in a hyper-clean environment | 18:20 |
| sladen | is this not what is loaded via the 'site' module; which is disabled by python -S ? | 18:20 |
| doko | Laney, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5680438 | 18:20 |
| juliank | sladen: The defaultencoding in sys is different from the preferred encoding according to my tests. | 18:20 |
| doko | cjwatson, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5675877 | 18:21 |
| doko | zyga, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5673667 | 18:21 |
| cjwatson | doko: tomorrow | 18:22 |
| doko | infinity, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5673667 | 18:22 |
| doko | seb128, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5700287 ? | 18:24 |
| seb128 | doko, sure, I meant to do that last week and got sidetracked with other issues, adding to my todo for tomorrow | 18:24 |
| doko | Sweetshark, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5703951 ? | 18:24 |
| doko | cjwatson, seb128: thanks! | 18:25 |
| xnox | rsalveti: i'm still working on it. Let me check how far the build got to. | 18:25 |
| xnox | rsalveti: there were a couple of bugs when building in the chroot, vs just on my local machine. | 18:25 |
| xnox | rsalveti: ideally, yes i'd like it to be uploaded today. | 18:25 |
| seb128 | doko, yw! | 18:25 |
| Laney | doko: tomorrow too | 18:25 |
| rsalveti | xnox: ok, let me know if there's anything I can help you with that | 18:25 |
| Laney | doko: in return I'd appreciate it if you could see if you have any bright ideas about https://buildd.debian.org/status/fetch.php?pkg=webkitgtk&arch=armhf&ver=2.3.92-1&stamp=1395146394 | 18:25 |
| xnox | rsalveti: well, i'd want you to review the debdiff and test x86 emulator image shortly. | 18:26 |
| rsalveti | sure | 18:27 |
| doko | Laney, do you have the preprocessed source somewhere? | 18:28 |
| Laney | nope | 18:28 |
| doko | mlankhorst, could you have a look at https://launchpad.net/ubuntu/+archive/test-rebuild-20140307/+build/5735335 ? | 18:29 |
| Laney | I guess you could reproduce it locally ;-) | 18:29 |
| Laney | or I can, but again tomorrow | 18:29 |
| * Laney leaves for a bit, see you | 18:29 | |
| sladen | juliank: I'm don't dispute this: http://paste.ubuntu.com/7126580/ | 18:31 |
| arges | stgraber: fyi, bug 1295304 has the new ifdown -a / vlan/bonding issue we discussed earlier | 18:32 |
| ubottu | bug 1295304 in ifupdown (Ubuntu) "ifdown -a fails with vlans on bonded interface" [High,In progress] https://launchpad.net/bugs/1295304 | 18:32 |
| juliank | sladen: Right, if I run this with LC_CTYPE=C it shows that me "<module 'sys' (built-in)> None UTF-8" and then "UTF-8 ANSI_X3.4-1968" | 18:32 |
| juliank | And it does not even work in python3 which does not have reload. And we only care about Python 3, because Python 2 does not care about encoding at all | 18:33 |
| barry | juliank: sorry, multiple conversations going on. s/reload/imp.reload/ in py3 | 18:35 |
| juliank | barry: Thanks. | 18:36 |
| juliank | But this still won't work because we are missing some kind of setpreferredencoding() AFAICT | 18:36 |
| juliank | OK, seems I figured something out | 18:39 |
| juliank | barry: So, I got rid of that nasty exec() by calling locale.setlocale(locale.LC_CTYPE, "") after setting the environment variables from /etc/default/locale. http://paste.debian.net/88751/ | 18:42 |
| juliank | This changes the value returned by locale.getpreferredencoding() | 18:42 |
| juliank | and should thus change the default encoding of open() | 18:43 |
| barry | getdefaultencoding is pretty much hardcoded to utf-8 in py3 | 18:44 |
| barry | s/pretty much// even ;) | 18:44 |
| juliank | barry: Yes, but not getpreferredencoding() which is what open() uses. That uses the locale. | 18:44 |
| barry | juliank: yeah. it just makes me uncomfortable not give an explicit encoding to open() | 18:45 |
| barry | juliank: where do you propose that pastebin code would go? | 18:45 |
| juliank | barry: In aptd and software-properties-dbus (both D-Bus daemons) | 18:46 |
| juliank | Are the other d-bus daemons using python-apt? | 18:46 |
| barry | not sure. check reverse-depends python3-apt? | 18:48 |
| barry | juliank: so let me see if can summarize the problem (is there a bug?). user writes some non-utf8 text to a file in their possibly non-utf8 locale. some dbus daemon reads that file. dbus does not set a locale so there's no way to know what encoding is used in the file. boom. if so, would seem to affect any such dbus daemon. reading /etc/default/locale may get you closer, but could still not be perfect if user sets a different | 18:52 |
| barry | locale. | 18:52 |
| juliank | barry: Yes. But consider that the files are only writable by root and root configures the default locale. This is the closest we can get I think. | 18:53 |
| juliank | It does not affect most d-bus daemons, I think; because most are written in C, and they simply read things in bytes. | 18:54 |
| barry | i guess that would be another option, though probably not much fun (e.g. open in binary mode, read bytes and then decode according to best guess) | 18:55 |
| barry | i'm rather surprised dbus doesn't specify a locale | 18:55 |
| stgraber | arges: found the issue with the vlans, it's actually ifupdown being a bit too clever | 18:56 |
| arges | stgraber: wow | 18:56 |
| arges | that was fast | 18:56 |
| stgraber | arges: it notices that the device is a vlan and tries to destroy it, except the vlan hook did it already so you get the error | 18:56 |
| barry | anyway, it seems like a hack, but possibly one that will usually work, and "practicality beats purity" | 18:56 |
| stgraber | arges: I'm trying to disable the chunk of code in ifupdown that does that, that should fix some broken behaviours with bridges and vlans | 19:03 |
| arges | stgraber: cool let me know and i'll test it on this end | 19:04 |
| juliank | barry: I just noticed that aptdaemon has something similar already in its script, but it simply hardcodes C.UTF-8 | 19:07 |
| barry | juliank: i wonder if that's the cause of all the aptdaemon test failures ;) | 19:08 |
| barry | kidding, but still | 19:08 |
| juliank | barry: It seems that my approach without the exec()ing does not change the file system encoding of Python. | 19:11 |
| juliank | aptd re()execs itself if sys.getfilesystemencoding() == "ascii" and not "LANG" in os.environ | 19:11 |
| juliank | If we add the default locale loading in there, all things should just work in almost all cases. | 19:12 |
| juliank | The combined approach would be http://paste.debian.net/88755/ | 19:13 |
| juliank | It first sets LANG to C.UTF-8 and then reads /etc/defaults/locale to try to find something besser. | 19:13 |
| juliank | It would probably be easier to ship a wrapper script instead of re-exec()ing the script itself. | 19:15 |
| juliank | Although this should work. | 19:15 |
| arges | bdmurray: hi. i'm getting a few things done, then i'll have some time to help with sru queue | 19:16 |
| bdmurray | arges: sounds good | 19:16 |
| jtaylor | infinity: when are we getting a fixed libm? | 19:20 |
| stgraber | arges: fixed ifupdown uploaded to my ppa | 19:21 |
| stgraber | arges: this also contains xnox's change to prevent "restart networking" and "stop networking" | 19:21 |
| arges | stgraber: i'll give it a try. this is the experimental ppa? | 19:21 |
| stgraber | yep, just uploaded now so it'll be a few minutes before it's done building | 19:21 |
| arges | ok | 19:22 |
| stgraber | arges: done building, feel free to just grab the binary from LP | 19:24 |
| arges | stgraber: ok will do | 19:25 |
| zyga | doko: looking | 19:26 |
| zyga | doko: how can I reproduce that rebuild? was there anything special about it? | 19:26 |
| juliank | bdmurray: I reassigned the original bug to software-properties, could you reset it from fix released to new or triaged? | 19:28 |
| juliank | We should then sync python-apt 0.9.3.4 from sid tomorrow and close regression bug 1294531 | 19:29 |
| ubottu | bug 1294531 in python-apt (Ubuntu) "Unicode traceback saving empty SourcesList regression" [Undecided,Confirmed] https://launchpad.net/bugs/1294531 | 19:29 |
| arges | stgraber: it works! ifdown -a only leaves lo interfaces, and ifup -a brings back everything as expected . I did 5 iterations of it | 19:31 |
| bdmurray | juliank: yes, will do | 19:32 |
| juliank | Thanks. | 19:32 |
| stgraber | arges: good :) | 19:33 |
| bdmurray | juliank: Thanks for working on this. | 19:34 |
| bdmurray | barry: any ideas about the update-manager tests? | 19:34 |
| barry | bdmurray: no, sorry, i've yet to get a block of time to dig into it | 19:35 |
| juliank | bdmurray: I'm happy that I do not have to think about update-manager... Enough other packages too maintain for me over in Debian. | 19:39 |
| juliank | Which reminds me that I (or hopefully someone else) still need to write a PackageKit-based update-notifier replacement for Debian. | 19:40 |
| === bfiller_afk is now known as bfiller | ||
| stgraber | xnox: what's the status on changing lsb so that init scripts which have a matching upstart job exit immediately when called? | 20:20 |
| stgraber | xnox: I believe slangasek told me in London that it was on your todo for 14.04 | 20:21 |
| slangasek | not sure I said 14.04 | 20:22 |
| slangasek | I did say xnox did have a plan for fixing this | 20:23 |
| stgraber | ok, maybe you didn't say 14.04, though I'd argue we probably ought to fix this for 14.04, it's starting to be a bit rdiculous for half our init scripts to manually check for upstart and for the other half to just confuse you or break your system/service | 20:24 |
| stgraber | and it's going to be quite a surprise for people upgrading from 12.04 as they'll move from the upstart-job symlink to a potentially harmful init script | 20:25 |
| stgraber | (sure, they shouldn't be calling those scripts directly to begin with, but well, they do...) | 20:25 |
| xnox | stgraber: right, i do have an example patch, but i didn't submit it to the debian maintainer. | 20:26 |
| xnox | stgraber: i'll add it to my todo for tomorrow. | 20:26 |
| stgraber | xnox: awesome! thanks | 20:26 |
| xnox | stgraber: indeed it outght to be fixed, cause e.g. /etc/init.d/ssh start should start ssh server..... not exit zero without any output. | 20:27 |
| xnox | cause that would make everyone think it did start up. | 20:27 |
| xnox | stgraber: might get it done tonight after kids are asleep. | 20:27 |
| xnox | rsalveti: hm, shell scripts for the emulator got dropped?! http://paste.ubuntu.com/7127213/ | 20:45 |
| rsalveti | xnox: yes | 20:45 |
| xnox | rsalveti: cool. | 20:46 |
| rsalveti | xnox: but they were already removed from the android package | 20:46 |
| rsalveti | not sure why it tried to install them again | 20:46 |
| xnox | rsalveti: hm, weird. I'll check my debdiff carefully, maybe i'm working against something old =/ | 20:47 |
| rsalveti | the ubuntu-emulator package is doing the logic to download and setup the image | 20:47 |
| rsalveti | yeah | 20:47 |
| xnox | yet with a new tarball lol. | 20:47 |
| xnox | well it does build all flavours including x86 emulator so it's okish. | 20:47 |
| rsalveti | xnox: maybe the pkging bzr repo is not in sync with the src package | 20:48 |
| xnox | rsalveti: we have a pkging bzr repo? i'm working agains the archive .src packag.e | 20:48 |
| xnox | rsalveti: it really ought to be a git repo on phablet with the rest off the code to be honest | 20:48 |
| rsalveti | we have but yeah, not in sync | 20:48 |
| slangasek | stgraber: which "other half" are breaking the system/service? | 20:48 |
| rsalveti | just work against the src package | 20:48 |
| rsalveti | xnox: indeed | 20:49 |
| rsalveti | xnox: we might want to create another branch/repo in there for the packaging stuff | 20:49 |
| slangasek | stgraber: I thought the announcement I sent to u-d/u-d-a last summer was very clear about the migration requirements; have people been uploading packages with upstart jobs without properly transitioning the init scripts? | 20:49 |
| xnox | rsalveti: well i kicked off another build, and let me inspect the debdiffs so far. | 20:49 |
| xnox | slangasek: duh. | 20:50 |
| xnox | slangasek: not me, but i deffo seen just upstart jobs added with nothing done on sysvinit side at all. | 20:50 |
| slangasek | sigh | 20:50 |
| stgraber | slangasek: the usual breakage is a package having both an upstart and sysvinit job but not having both do the same thing, database servers and anything storing some kind of data in /var/lib may fall into that case | 20:50 |
| slangasek | stgraber: there aren't supposed to have been any such packages in Ubuntu; whoever uploaded those packages without fixing the init scripts was negligent | 20:51 |
| slangasek | and there's no guarantee that fixing this centrally in the lsb hooks will fix all of those packages, either | 20:52 |
| slangasek | because use of the lsb functions interface is optional | 20:52 |
| xnox | slangasek: sure but some of these came via syncs, not uploads direct into ubuntu | 20:52 |
| slangasek | xnox: so the Debian maintainer was the one violating Debian policy on use of upstart jobs? | 20:53 |
| stgraber | slangasek: sorry I don't remember what you sent last summer, but what were you advocating? for people to make sure the logic in the upstart job and the sysvinit script stays in sync so that if the service is started directly from init.d things don't blow up? | 20:53 |
| slangasek | stgraber: no; you should never be starting the service directly from init.d | 20:54 |
| xnox | stgraber: the policy says that initscript should check if there is upstart running as pid1, and in that case do nothing. | 20:54 |
| slangasek | and it was the responsibility of the maintainer to make sure the init script became a no-op | 20:54 |
| stgraber | slangasek: sure, I agree and indeed, I don't believe we have anything in the distro doing that | 20:54 |
| stgraber | slangasek: my problem is our users | 20:54 |
| xnox | slangasek: but that would also break, when systemd is pid1 and upstart is pid2, as the policy checks will succeed on upstart, yet it's not pid1 | 20:54 |
| xnox | slangasek: and systemd units should be used. | 20:54 |
| stgraber | all the bug reports I've seen with /etc/init.d/* breaking stuff isn't because of maintainer scripts or other distro tools but because of users directly poking those | 20:54 |
| stgraber | because, well, it used to work back in 12.04 | 20:55 |
| slangasek | xnox: that's a new problem, and not the problem in 14.04 | 20:55 |
| xnox | slangasek: ok. | 20:55 |
| stgraber | and yes, that's wrong, they shouldn't do that and our documentation tells them not to, but well, they still do and if we can catch a good chunk of those, we should | 20:55 |
| xnox | stgraber: "you fight for the user!" =))))) | 20:55 |
| slangasek | stgraber: yes, but the only places where this has regressed are maintainers uploading broken packages | 20:55 |
| stgraber | xnox: no, I fight for less bug reports :) | 20:55 |
| slangasek | stgraber: this is NOT about what the users are doing | 20:55 |
| xnox | stgraber: =)))))) _selfish_ ;-) | 20:56 |
| slangasek | this is about the *uploader* having done something broken | 20:56 |
| slangasek | "I ran /etc/init.d/foo start and it didn't start" -- "so don't do that then"; "I ran /etc/init.d/foo start and it trashed my database" -- "the maintainer did something very wrong" | 20:57 |
| stgraber | slangasek: not sure I understand you. If I have a package in 12.04 that ships an upstart job, I can do "/etc/init.d/service restart" and it'll restart the service. Now rebuilding the exact same thing on trusty will call theactual init.d job, not the upstart-job symlink, so now I'm going through an entirely different code path and potentially causing data corruption | 20:57 |
| slangasek | stgraber: who's "rebuilding the exact same thing on trusty"? | 20:57 |
| slangasek | I don't like talking about this in generalities | 20:58 |
| slangasek | what packages are broken? | 20:58 |
| slangasek | I think it's fine that xnox will try to fix it for the lsb case by having a common hook, which can either do a pass-through or make the init script a no-op (I don't have a strong preference between the two) | 20:58 |
| slangasek | but we need to sort out what packages are now shipping both initscript and upstart job without having been properly transitioned | 20:59 |
| stgraber | last example I heard was from rbasak with mysql | 20:59 |
| xnox | stgraber: slangasek: i have a branch / thing scanning all upstart jobs, i can add init.d scripts scanning to it and give you a quick way to check. | 20:59 |
| slangasek | (and make sure that we catch the non-LSB case) | 21:00 |
| stgraber | apparently both the upstart job and the sysvinit script in 14.04 do stuff, they just don't quite do the same thing and there is documentation out there pointing to /etc/init.d/mysql which used to work with 12.04 and now on 14.04 starts a second daemon or something | 21:00 |
| slangasek | stgraber: which is clearly neither a sync nor a no-change rebuild; the maintainer is at fault for uploading this package | 21:00 |
| xnox | slangasek: stgraber: we had a period of time with broken dh_installinit in debhelper. Can it be at fault here? | 21:01 |
| xnox | slangasek: especially if before on ubuntu it would override initd script with a symlink to upstart job, and we stopped doing that?! | 21:01 |
| slangasek | xnox: no, the expected new behavior of debhelper is to install both the init script and the upstart job from the package, so that the package works on either an upstart system or a sysvinit system. The expected behavior of the *maintainer* was to fix the init script before uploading to Ubuntu | 21:01 |
| stgraber | slangasek: what is the maintainer supposed to fix? both scripts are fine on their own, it's just if you start mixing both that things go wrong. | 21:02 |
| xnox | slangasek: how would maintainer find out about it? surely that's a debhelper compatibility level break. | 21:02 |
| slangasek | stgraber: it is *not* fine on its own, the init script is in violation of Debian Policy! | 21:03 |
| xnox | slangasek: one simply does not start generating broken packages, based on changed debhelper version =))))) | 21:03 |
| xnox | slangasek: and especially when one didn't bump the package to declare compliance with the new debian policy version number. | 21:03 |
| slangasek | stgraber: https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037150.html | 21:03 |
| xnox | let me check default installs here. | 21:03 |
| cjwatson | eh, standards-version is purely informational, please don't start getting the idea that things should be keying off it for build behaviour | 21:04 |
| slangasek | xnox: all packages must comply with the current version of the policy; the Standards-Version field is advisory | 21:04 |
| slangasek | xnox: the way forward here is to land your change in the upstart package to add the lsb hook; but I don't think there's any excuse for uploaders not following ubuntu-devel. | 21:06 |
| slangasek | this problem only happened as a result of maintainers uploading new versions of their packages without making the necessary changes to the init scripts | 21:06 |
| Noskcaj | mdeslaur, Are you going to update libyaml to the new bugfix release soon? If not, i can. Debian has an NMU fixing a regression too | 21:07 |
| stgraber | slangasek: I'd be interested to see an archive wide search for packages shipping both an /etc/init job and an /etc/init.d job of the same name looking for init_is_upstart or "initctl version | grep -q upstart". It's also unfortunate that the policy just says to exit 1 as that tends to confuse the users... | 21:07 |
| stgraber | slangasek: the example in the policy also only covers the "start" argument, so if people just started copy/pasting, "/etc/init.d/service restart" has a good chance to cause chaos... | 21:11 |
| stgraber | (your e-mail on the other hand properly covers all those cases, it's just unfortunate that this didn't make it to the policy) | 21:11 |
| slangasek | stgraber: policy covers that 'restart' must be the equivalent of stop && start | 21:11 |
| stgraber | ok, my bad, make that force-reload then | 21:13 |
| xnox | ok. | 21:15 |
| === seb128_ is now known as seb128 | ||
| mdeslaur | Noskcaj: which version are you referring to? AFAIK, I already have the regression fix in trusty... | 21:25 |
| xnox | rsalveti: the package builds and the debdiff is reasonable, i'll throught it into virtualised ppa to build as it's too late for me to upload. | 21:48 |
| rsalveti | sure | 21:53 |
| xnox | rsalveti: uploaded as https://launchpad.net/~ubuntu-toolchain/+archive/android/+build/5832660 | 21:57 |
| rsalveti | cool, thanks | 21:57 |
| xnox | rsalveti: debdiff is smallish - http://paste.ubuntu.com/7127592/ | 22:00 |
| rsalveti | xnox: yeah, looks fine | 22:03 |
| === cmagina is now known as cmagina-away | ||
| barry | bdmurray: so, the test error seems like a clear bug in the test suite. i can fix that. the others seem like a change in semantics somehow about package upgradability. it's difficult for me to tell why the test assumptions there are incorrect now, so i think i will file a bug (and assign to mvo to give him fun stuff to work on :) and attach my branch that fixes the one problem so far | 22:04 |
| bdmurray | barry: I've been digging at it and pkg.is_upgradable seems to be returning different results now | 22:05 |
| bdmurray | barry: so then updates_list is a different size | 22:06 |
| barry | bdmurray: yep, that's what i've seen too | 22:06 |
| bdmurray | barry: well, let me know the bug number | 22:07 |
| === kenvandine_ is now known as kenvandine | ||
| barry | bdmurray: LP: #1295392 | 22:12 |
| ubottu | Launchpad bug 1295392 in update-manager (Ubuntu) "test suite failures" [Undecided,New] https://launchpad.net/bugs/1295392 | 22:12 |
| bdmurray | barry: thanks | 22:15 |
| === marrusl is now known as marrusl_afk | ||
| === marrusl_afk is now known as marrusl | ||
| === salem_ is now known as _salem | ||
| juliank | python-apt 0.9.3.4 is imported in launchpad now. It does fix three other bugs apart from the unicode-revert-stuff (most importantly: pre-build.sh now fails if the mirror lists cannot be downloaded [e.g. if launchpad is overloaded which happens a lot] instead of simply writing empty files) | 22:50 |
| juliank | I'm still a bit unsure about how to request per-package upload permissions as a DD. If someone could enlighten me and tell me what the first step is, that would be helpful? | 22:55 |
| juliank | The dynamic-ppu-procedure.txt in Laney's is not well-worded.The first "step" seems to be 10 - aka send an email with list of packages; but 11 says you must have attended a meeting before this, so is there a step before this? | 22:58 |
| barry | juliank: probably best to start with an email to devel-permissions@lists.ubuntu.com. explain that you're a dd maintaining the packages you want upload rights to. it can *probably* be done over email, but then i'm no longer on the dmb :) | 22:58 |
| * barry thinks https://wiki.ubuntu.com/UbuntuDevelopers#PerPackage should really be updated to include laney's text | 22:59 | |
| infinity | https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess has a section for DDs. | 22:59 |
| barry | yep, which eventually links to laney's text | 23:00 |
| Laney | that is not a guide to be followed | 23:00 |
| Laney | I think I mith delete it | 23:00 |
| Laney | it was a proposal to the DMB | 23:00 |
| infinity | "To exercise this process, the DD should first be an existing Ubuntu developer ..." | 23:00 |
| infinity | So, it sounds like one needs to at least do PPU/MOTU/etc once first before getting additional PPU for freee. | 23:01 |
| Laney | yes | 23:01 |
| infinity | juliank: Anyhow, synced for you for now. | 23:02 |
| juliank | Laney: OK, thanks. The first paragraph in https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess linked to your text, and this confused me enough to not read the second one carefully | 23:02 |
| Laney | Let me see what it says there | 23:02 |
| infinity | juliank: Thanks for paying attention to bugs/patches in both distros. I know it's a pain sometimes. | 23:03 |
| Laney | Hrm | 23:03 |
| Laney | Yeah, I added that, lemme clarify | 23:03 |
| juliank | infinity: Thanks. | 23:04 |
| Laney | I just removed the link, it works without it | 23:05 |
| juliank | Laney: OK, yes, much better.. | 23:05 |
| juliank | ! | 23:05 |
| juliank | (sorry, the "..." were wrong) | 23:05 |
| juliank | When I tried to become a MOTU in 2008 (IIRC), it was rejected, maybe a PPU now works. I did not do that much, as I do most of my stuff on Debian side and have them sync automatically, I mostly appear active on the Ubuntu side during import freeze, to request syncs. | 23:11 |
| juliank | I'm trying to copy DeveloperApplication to a place below my user page, but all I get is "Please use the interactive user interface to use action CopyPage!" | 23:20 |
| juliank | Well, now it tells me that JulianAndresKlode/DeveloperApplication-PPU already exists. Stupid wiki | 23:25 |
| barry | bdmurray: that is very interesting | 23:37 |
| bdmurray | barry: yeah, there are lot of changes there though | 23:38 |
| barry | bdmurray: so apt 0.9.14.1ubuntu2 works. does 0.9.14.2 fail? probably can at least bisect the ubuntu uploads to see which one it starts to fail with | 23:39 |
| barry | bdmurray: or maybe even ping juliank :) | 23:40 |
| bdmurray | barry: it jumps from 0.9.14 to 0.9.15 | 23:40 |
| bdmurray | well with some .1s in there | 23:40 |
| bdmurray | https://launchpad.net/ubuntu/+source/apt/+changelog | 23:40 |
| juliank | There were some changes, APT now switches candidates if the normal one is not satisfiable. | 23:40 |
| juliank | I don't know when that was introduced, though. | 23:41 |
| juliank | In 0.9.15.1 | 23:41 |
| barry | bdmurray: i was looking at `bzr branch ubuntu:apt` | 23:41 |
| juliank | apt 0.9.15.1 has "discard impossible candidates in MarkInstall", was it in 0.9.15 itself or were you testing with 0.9.15.1 or newer | 23:42 |
| juliank | I don't know precisely which versions were synced. | 23:42 |
| bdmurray | 0.9.15.1 | 23:42 |
| * barry was looking at: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/apt/trusty/view/head:/debian/changelog | 23:43 | |
| juliank | Now, if you're trying to upgrade to something impossible, it will not produce an error, but rather switch back to the installed version | 23:44 |
| barry | juliank: so it would report pkg.is_upgradable == False? | 23:44 |
| juliank | barry: It depends on whether someone called mark_install() or mark_upgrade() on that package in the meantime. Assume: Before, it was true. Now you try to mark an impossible candidate as an upgrade. APT will switch to the installed version. So is_upgradable would be false. | 23:46 |
| barry | juliank: okay thanks. this is all in upgrade-manager's test suite. we narrowed the failures down to packages which were upgradable but now are not. it's all test data, so i suspect something there didn't keep up with these changes | 23:47 |
| barry | but anyway... it's dinner time for me! | 23:47 |
| juliank | OK, and it's time for me to sleep now. It's 50 minutes past midnight. | 23:48 |
| juliank | I'll be gone in about 15 minutes and back in about 11 to 12 hours. | 23:49 |
| === Mapley is now known as Mapleh | ||
| === Mapleh is now known as Mapley | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!