| RoAkSoAx | dobey: still downloading the tar.gz | 00:03 |
|---|---|---|
| RoAkSoAx | :S | 00:03 |
| dobey | oh | 00:04 |
| dobey | RoAkSoAx: i need to get dinner, but let me know if you find anything; thanks | 00:32 |
| RoAkSoAx | dobey: will sure do... though, is the dsc in launchpad somewhere as this seems will take for ever | 00:33 |
| dobey | RoAkSoAx: no; i am trying to set up daily builds of rhythmbox to test with for precise development, while trying to preserve the ubuntu patches to it; the error happens when building the source package in the recipe builder, but doesn't happen locally. so i'm not even sure a dsc will help really | 00:36 |
| dobey | RoAkSoAx: you can bzr branch lp:rhythmbox, then inside the rhythmbox dir "bzr branch lp:~ubuntuone-control-tower/rhythmbox/packaging-dailies debian" and debuild -S to get one | 00:36 |
| dobey | the only difference between that and the dsc i built, is the version number in debian/changelog. | 00:37 |
| dobey | maybe it's a launchpad issue, but it doesn't immediately strike me as one. | 00:42 |
| dobey | anyway, need to get some food | 00:42 |
| RoAkSoAx | dobey: cool, will take a look as soon as I get back | 00:53 |
| micahg | bdmurray: kerneloops is up for adoption in Debian if you have an interest in it | 00:55 |
| micahg | or anyone else so inclined :) | 00:56 |
| RAOF | dobey: You're aware that you can do the recipie build locally, right? Install bzr-builder and you get a ‘bzr dailydeb $RECIPIE’ command, which does the same thing as launchpad does. | 01:00 |
| RAOF | @pilot out | 01:17 |
| === udevbot changed the topic of #ubuntu-devel to: 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: | ||
| RAOF | ...for lunch. | 01:17 |
| RAOF | :) | 01:17 |
| === Ursinha-lunch is now known as Ursinha | ||
| adam_g | are there any d-i tricks to redirect syslog to serial console? | 02:05 |
| dobey | RoAkSoAx: oh, hrmm; i see something else in the log now, that might be why; it appears that maybe quilt is crashing when applying the patch for some reason? | 02:11 |
| dobey | and so when it tries to un-apply, it fails because it's not actually applied | 02:11 |
| dobey | Now at patch 05_hide_on_quit.patch | 02:12 |
| dobey | (2.2881429999999998, 0.56403499999999995, 0, 0, 0, 0, 62025, 30, 0, 8280, 68960, 0, 0, 0, 5806, 174) | 02:12 |
| dobey | i don't know what all those numbers mean, but surely not good | 02:12 |
| broder | slangasek: http://lintian.ubuntuwire.org/tags/data.tar.xz-member-without-dpkg-pre-depends.html | 02:17 |
| broder | "This tag has not been emitted in any package tested by Lintian" | 02:17 |
| RoAkSoAx | adam_g: what seems to be the problem | 02:25 |
| RoAkSoAx | dobey: just got back gonna look at it now | 02:25 |
| slangasek | broder: hmm, that's the one we have an archive accept-time check for; did we get signals crossed somewhere? The one we're missing info on is use of dpkg-maintscript-helper in preinst without pre-depends | 02:25 |
| broder | ok, i see | 02:26 |
| broder | yeah, lintian isn't checking for that currently | 02:27 |
| broder | that'll take writing a new check. i'll look into it | 02:29 |
| dobey | RoAkSoAx: i refreshed some more of the patches again, and am trying another build now. | 02:31 |
| slangasek | broder: cool, thanks :) | 02:31 |
| RoAkSoAx | dobey: ok, i;m building here too | 02:34 |
| dobey | RoAkSoAx: ok, thanks | 02:34 |
| RoAkSoAx | dobey: its building just fine in a PPA for oneiric | 02:38 |
| RoAkSoAx | s/PPA/pbuilder | 02:38 |
| RoAkSoAx | dobey: didn't even refreshed the patches | 02:39 |
| dobey | RoAkSoAx: right; the problem isn't that. the problem is that building the source package is failing, and refreshing the patches didn't seem to help me either :( | 02:42 |
| RoAkSoAx | dobey: in my case the source package builds on my pbuilder | 02:43 |
| RoAkSoAx | dobey: i didn't have to refresh the patches | 02:43 |
| RoAkSoAx | for it to build | 02:43 |
| dobey | RoAkSoAx: yes, here too. i don't mean build in that sense though. i mean dpkg -S is what's failing in the recipe builder on the server | 02:45 |
| RoAkSoAx | dobey: I'll upload to my PPA | 02:47 |
| dobey | i guess those numbers are meaningless, and are actually coming from bzr-builder plug-in | 02:48 |
| dobey | but why oh why is quilt applying-but-not-applying the patch :( | 02:49 |
| RoAkSoAx | dobey: ok, so in my cause, it seems to be building https://launchpad.net/~andreserl/+archive/ppa/+build/2976892 | 03:07 |
| RoAkSoAx | dobey: though, since I did everything manually, that might be it. Maybe there's something wrong in your recipe for the daily builds | 03:08 |
| RoAkSoAx | dobey:there are the steps I followed: http://pastebin.ubuntu.com/756702/ | 03:09 |
| dobey | no, it's not the recipe. it's quilt | 03:09 |
| dobey | yes, debuild -S -sa works fine here | 03:10 |
| RoAkSoAx | s/cause/case | 03:10 |
| RoAkSoAx | anyways, I gotta go sorry I could not be of further sassitance | 03:15 |
| RoAkSoAx | maybe tomorrow that I'm fresh I could help more | 03:15 |
| RoAkSoAx | cheers | 03:15 |
| dobey | thanks anyway | 03:15 |
| dobey | cheers | 03:15 |
| === bladernr_ is now known as bladernr_afk | ||
| hallyn | if debian/rules has override_dh_install with a line 'dh_install -pXYZ', and debian/control lists XYZ as only for i386. Will that line be ignored on an arm build? | 04:11 |
| infinity | apw: linux fails the same way, BTW. kernel-wedge dies. | 04:12 |
| ScottK | SpamapS: Around? | 04:12 |
| ScottK | SpamapS: It looks like language-pack-kde-en got copied to oneiric-updates, but language-pack-kde-en-base didn't, so language-pack-kde-en is now uninstallable. | 04:12 |
| ScottK | I don't know if any other languages are affected. | 04:13 |
| ScottK | (or any other ubuntu-sru person) | 04:13 |
| ScottK | OK, we'll do it this way ... | 04:14 |
| ScottK | !regression-alert | 04:14 |
| ubottu | cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive | 04:14 |
| ScottK | Regression is above the alert .... | 04:15 |
| ScottK | Nothing needs to be blacklisted, just need to copy over language-pack-kde-en-base to oneiric-updates. | 04:15 |
| ScottK | It would also be good if someone could check if other languages are affected (I'm on an airplane that's 20 minutes from landing, so I'll have to shut down shortly) | 04:17 |
| lifeless | StevenK: ^ do you have the perms ? | 04:21 |
| kees | slangasek: around? can you fix the langpack issue above? | 04:23 |
| StevenK | I can look. pitti probably can too. | 04:23 |
| StevenK | ScottK, lifeless: Copied. | 04:31 |
| pitti | Good morning | 04:50 |
| pitti | lool: ah, probably just copy&paste error from a previous merge | 04:51 |
| pitti | ScottK, StevenK: uh, we didn't mean to do a -base refresh; I'll check the other ones, thanks for pointing out | 04:54 |
| pitti | aah, this was still from the previous round | 04:54 |
| StevenK | pitti: So I've copied the wrong thing, or it's okay? | 04:55 |
| pitti | StevenK: no, it's fine | 04:55 |
| pitti | StevenK: it just explains why -base was needed | 04:55 |
| pitti | in the previous update round we did do a -base refresh, but not in this one | 04:55 |
| pitti | Daviey: thanks for moving over the milestone bugs | 05:19 |
| pitti | jamespage, wendar: FYI, fixed current software-center/ubuntu-desktop uninstallability and CD build failure, needed a binNEW | 05:31 |
| pitti | jamespage, wendar: now looking at edubuntu uninstallability due to nautilus-python | 05:32 |
| wendar | pitti: I had one merge proposal and one archive admin task from my work today (dropped you an email) | 05:33 |
| pitti | wendar: saw it, thank you! will get to it | 05:35 |
| pitti | but I'll work on the uninstallability first, as this is our first "red alert" priority | 05:35 |
| wendar | pitti: very much so | 05:36 |
| pitti | wendar: how did your first day go? | 05:36 |
| pitti | on our TODO list for tools improvements: http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html | 05:36 |
| pitti | "pretty please say WHY the package isn't installable" | 05:36 |
| wendar | pitti: good, it was great to focus | 05:37 |
| pitti | wendar: yeah, I find that as well; there's so many things I always wanted to get around to, like component-mismatches etc. | 05:37 |
| wendar | hah, yes that would be useful :) | 05:37 |
| pitti | and now there's theh time | 05:37 |
| wendar | the more information the better | 05:38 |
| pitti | gr_vmcircbuf_createfilemapping: createfilemapping is not available | 05:38 |
| pitti | hmm | 05:38 |
| pitti | wendar: our buildds run the lucid kernel, so maybe it's relying on some kernel features that only newer versions provide | 05:39 |
| pitti | wendar: other differences are: no network, building with DEB_BUILD_OPTIONS=parallel=4 | 05:39 |
| pitti | wendar: you could try tossing the package in a PPA and see whether it makes a difference | 05:39 |
| pitti | wendar: as a next step I'd try to upload a no-change rebuild to see whether the failure reproduces | 05:40 |
| pitti | wendar: we have two FTBFS in main on armel, do you want to look into these, too? | 05:41 |
| wendar | pitti: ruby and telepathy? sure I can break out the pandaboard tomorrow | 05:42 |
| pitti | wendar: we have porter boxes | 05:42 |
| wendar | pitti: I can try those too | 05:42 |
| pitti | wendar: but yeah, it might be an opportunity to set them up and get them running; yay for new toys :) | 05:42 |
| wendar | pitti: actually, I'll try logging in now, in case I need UK support before my day tomorrow | 05:43 |
| pitti | infinity: oh, look! http://ddebs.ubuntu.com/dists/precise/main/binary-armhf/Packages | 05:44 |
| micahg | wendar: did you join the +1 team? | 05:44 |
| infinity | pitti: Oooo. | 05:44 |
| micahg | * +1 maintenance | 05:44 |
| pitti | infinity: now, if we actually had a retracer running on arm :) | 05:44 |
| infinity | pitti: They're still valuable for local debugging. | 05:45 |
| wendar | pitti: I get "Permission denied (publickey)." so I must not be set up for the porter boxes | 05:45 |
| pitti | infinity: it's actually rather easy to set it up, just waiting for that RT ticket to give me a real psql db for duplicates | 05:45 |
| infinity | pitti: (Which was our original use-case before the magical retracer happened) | 05:45 |
| wendar | micahg: yah, I'm a December +1-er | 05:45 |
| pitti | infinity: right, if you install apport-retrace, the crash notifications will grow an "examine locally" button | 05:45 |
| pitti | which will give you a fancy stack trace or toss you into a gdb session with full symbols | 05:46 |
| pitti | wendar: ah, that sounds worth an RT; you can CC: me so that I can send my +1 (also for powerpc) | 05:46 |
| micahg | wendar: awesome, is there a list somewhere of the current members? | 05:46 |
| pitti | micahg: jamespage, wendar, me | 05:46 |
| pitti | micahg: https://wiki.ubuntu.com/PlusOneMaintenanceTeam | 05:47 |
| pitti | has the roster | 05:47 |
| micahg | pitti: cool, thanks for the info, is that channel worth idling in? | 05:48 |
| pitti | micahg: TBH, I'm not planning to use it much; I can't follow another channel, so rely on getting pinged there; and most issues should be fine to discuss here or in /msg | 05:49 |
| pitti | but let's see how much it actually gets used | 05:50 |
| infinity | pitti: I'm kinda hoping the channel can die. | 05:59 |
| infinity | pitti: Given that -devel is +1-centric, almost by definition, I hate having conversations about problems/solutions split over channels. | 05:59 |
| infinity | pitti: (And I really hate duplicating work because I didn't see the conversation about someone else working on it) | 06:00 |
| pitti | infinity: that's my feeling | 06:00 |
| * infinity realises the irony of the above statement, where most of his armhf conversations have been happening in linaro-armhf and debian-arm, but... | 06:00 | |
| pitti | wendar, jamespage: opinions? ^ shall we try using #u-devel until people complain? | 06:00 |
| wendar | pitti: works for me | 06:01 |
| ScottK | StevenK: Thanks. All better now. | 06:18 |
| pitti | wendar: hm, just followed up to your RT. Your user account exists, and you are in porting_team | 06:46 |
| pitti | wendar: so maybe ssh after all? not sure | 06:46 |
| pitti | wendar: but I guess IS will figure it out | 06:47 |
| wendar | pitti: yup, not sure. It could be that they don't have all the right ssh keys propagated over | 06:48 |
| === TeTeT_ is now known as TeTeT | ||
| === tkamppeter_ is now known as tkamppeter | ||
| tkamppeter | pitti, hi | 07:36 |
| micahg | infinity: out of curiosity are there any new tricks for armhf porting vs armel porting for FTBFS fixes? | 07:36 |
| infinity | micahg: Not really. There's the general "watch out for upstream thinking they know better than us about default compiler flags", but that's true for every arch. | 07:37 |
| infinity | micahg: Mostly, it's business as usual. | 07:38 |
| micahg | sounds good | 07:38 |
| infinity | micahg: Care to figure out why libicudata appears to not be a valid shared object on armhf? :P | 07:40 |
| micahg | infinity: nah, I've got my own build failures to figure out over the weekend :) | 07:41 |
| micahg | I got 2 so far | 07:41 |
| infinity | Hrm. icu is build with -O0 on armel for entirely unrelated reasons. I wonder if that also makes the library not broken. :P | 07:46 |
| * infinity settles in for some testing. | 07:46 | |
| dholbach | good morning | 08:07 |
| === jibel_ is now known as jibel | ||
| pitti | jibel: we got a bunch of server failures this morning, like https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-amd64_dns-server/lastBuild/ | 08:31 |
| pitti | jibel: the previous ones were marked as "pass", but I can't see an obvious difference in the log files | 08:31 |
| pitti | jibel: for example, the four DNS resolution tests at https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-amd64_dns-server/lastSuccessfulBuild/artifact/2/test-results/dns-server.stderr already failed before | 08:32 |
| pitti | jibel: oh, perhaps they have just been yellow yesterday? | 08:35 |
| pitti | so far I interpreted yellow as "last build succeeded, but some previous ones didn't" | 08:35 |
| pitti | oh, https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-amd64_lvm/lastBuild/console says "No test report files were found. Configuration error? | 08:36 |
| pitti | is that the reason for the failure? | 08:36 |
| jibel | pitti, yellow is 'tests partly failed' | 08:37 |
| jibel | pitti, no the reason is that the installation didn't finish | 08:37 |
| jibel | some package failed to install and the installation hanged at some point. I'm on it | 08:37 |
| pitti | jibel: ah, red == installation failed, yellow == install succeeded, but post-install tests failed? | 08:38 |
| pitti | jibel: where do you see that a package failed to install? | 08:38 |
| jibel | pitti, right | 08:38 |
| jibel | pitti, from syslog, the installation didn't reach the end | 08:38 |
| pitti | I really hate to ping you about all these, I'd like to learn where to get that info from myself | 08:38 |
| jibel | pitti, we are working on this doc https://wiki.ubuntu.com/QATeam/AutomatedTesting/UnderstandingJenkins | 08:39 |
| pitti | Nov 29 08:06:39 grub-installer: Installation finished. No error reported. | 08:39 |
| pitti | and then a bunch of more debconf | 08:40 |
| === gema_afk is now known as gema | ||
| jibel | pitti, I'll rerun a server job, there's nothing obvious in the log it just stops at "Dec 2 07:00:58 debootstrap: Setting up libc6 (2.13-20ubuntu8) ..." | 08:43 |
| pitti | jibel: which syslog are you looking at in particular? | 08:45 |
| jibel | pitti, https://jenkins.qa.ubuntu.com/view/Precise/job/precise-server-amd64_default/lastFailedBuild/ | 08:45 |
| pitti | jibel: ah, I was looking at the lvm/dns ones | 08:46 |
| jibel | attachment d-i-syslog.log | 08:46 |
| pitti | jibel: ah, thanks | 08:47 |
| jibel | pitti, same error for all, you were looking at the log from Nov 29 | 08:47 |
| pitti | ok | 08:48 |
| jibel | pitti, jenkins' UI is confusing because when you click on a job it shows the artefacts of the last successful build, not the last build | 08:48 |
| pitti | jibel: another question (sorry), there are no desktop/alternate tests for today's dailies in the "planned builds" queue | 08:48 |
| pitti | jibel: right, I guess that tricked me a couple of times | 08:49 |
| jibel | pitti, they are running, I'll see with patrickmw how we can keep the list of running jobs between the private and public instance of jenkins in sync. | 08:50 |
| pitti | jibel: ah, good to know, thanks! | 08:50 |
| === jodh is now known as jodh_ | ||
| pitti | rickspencer3: ^ FYI | 08:51 |
| doko | infinity: what went wrong with qt4-x11? | 08:56 |
| jibel | pitti, the VMs don't reboot after install, that sounds bad. | 09:00 |
| pitti | jibel: that's the desktop ones? | 09:05 |
| jibel | pitti, nope, server. desktop are still queued | 09:06 |
| pitti | ah, ok | 09:06 |
| infinity | doko: I killed it to move it to a Panda. 11 hour build time versus a day and a half. | 09:13 |
| jibel | pitti, jamespage that's interesting, the VM reboots in the middle of the installation. That's why the logs are truncated and hard to understand. | 09:18 |
| jamespage | jibel: that was my guess | 09:19 |
| infinity | doko: Did you give-back pyicu? | 09:19 |
| infinity | doko: It's just going to fail again. As will several other icu-related failures. Trying to figure out why everything hates libicudata.so.48 so much. | 09:19 |
| pitti | jibel: urgh; invalidly triggered reboot by our test code, or happening "by itself"? | 09:20 |
| jibel | pitti, by itself | 09:20 |
| jibel | just after setting up libc6 | 09:20 |
| jibel | I'll mount the image and try to find more information. | 09:21 |
| pitti | kern.log might have some bits | 09:21 |
| pitti | hopefully | 09:21 |
| infinity | doko: Also, is that lsb-release change the beginning of a python3 transition? | 09:28 |
| rickspencer3 | pitti, jibel am I surmising correctly that the problems seem to be with the test rig, and not the ISOs themselves, or have you not determined that yet? | 09:32 |
| doko | infinity, pyicu, yes. lsb-release: as in oneiric, to get it on the CD first | 09:32 |
| jibel | rickspencer3, the problem seems to be with the ISO. | 09:33 |
| infinity | doko: Yeah, ICU is being misbuilt somehow. Nothing can link/load the libraries. | 09:33 |
| infinity | doko: I'm going to look more in the morning. | 09:34 |
| rickspencer3 | aha | 09:34 |
| pitti | ah, that explains why today's images are still oversized | 09:34 |
| rickspencer3 | so, "daily quality" kick in :) | 09:34 |
| rickspencer3 | thanks jibe | 09:34 |
| pitti | libicu44 was removed (-7.1 MB), but python3.2 was added (+5.9 MB) | 09:34 |
| rickspencer3 | thanks jibel | 09:34 |
| pitti | cjwatson: what generates http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html ? | 09:39 |
| jibel | jamespage, nothing in the log. on the console is displays 'setting up debconf' and reboots | 09:40 |
| infinity | pitti: britney. | 09:41 |
| pitti | infinity: ah, thanks; I was getting confused because bin/run-britney just outputs to www/precise_outdate_all.txt | 09:47 |
| pitti | I now see the testing/www output dir | 09:48 |
| pitti | lots of uncommitted changes in testing/ bzr, hmm | 09:49 |
| pitti | cjwatson: is that something we can hack on, or do we need to keep it in sync with Debian somehow? | 09:49 |
| pitti | cjwatson: I'd love to integrate (1) links to pending builds (which explain most of the current problems) and (2) the reason _why_ the package is uninstallable | 09:50 |
| infinity | cjwatson: We're not even remotely in sync with Debian. Our britney is an 8-year-old fork. | 09:50 |
| infinity | Err. | 09:50 |
| pitti | ah, ok | 09:50 |
| infinity | s/cjwatson/pitti/ | 09:50 |
| pitti | so that at least resolves that question | 09:50 |
| infinity | cjwatson: Disregard my poor tab-completion. :P | 09:51 |
| pitti | I refuse getting cjwatson replaced with me | 09:51 |
| pitti | we so much need him! | 09:51 |
| jamespage | jibel: I just re-produced as well - rebooted during install of base system | 09:53 |
| pitti | jamespage: that's with today's server ISO? | 09:54 |
| jamespage | pitti: yep - thats the symptom see in the automated testing as well | 09:54 |
| jibel | jamespage, ack. I'm filing a bug | 09:54 |
| pitti | jamespage: I'm now downloading the desktop alternate to see whether it happens there as well | 09:54 |
| pitti | seems jenkins didn't get to alternate/desktop testing yet | 09:55 |
| jamespage | jibel, pitti; I'm going to manually terminate the precise-server tests currently running - they are just spinning and holding up the desktop and alternate tests. | 09:56 |
| jibel | jamespage, bug 899049, could you please confirm it ? | 09:57 |
| ubottu | Launchpad bug 899049 in debian-installer (Ubuntu Precise) "Ubuntu Server reboots during installation" [Critical,New] https://launchpad.net/bugs/899049 | 09:57 |
| jamespage | jibel: confirmed | 09:58 |
| jamespage | @pilot in | 09:59 |
| === udevbot changed the topic of #ubuntu-devel to: 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: jamespage | ||
| jibel | jamespage, pitti there is this error during install | 09:59 |
| jibel | Dec 2 07:00:46 base-installer: chroot: can't execute 'debconf-set-selections': No such file or directory | 09:59 |
| jibel | Dec 2 07:00:46 base-installer: warning: /usr/lib/base-installer.d/20console-setup returned error code 127 | 09:59 |
| doko | infinity, so just linux-libc-dev is missing for the buildd variant? | 10:00 |
| jamespage | jibel: it looks like a requested reboot; normal Sending SIGTERM message stuff | 10:00 |
| jibel | jamespage, could it be that it doesn't set the debconf values and after the base install it reboots because there's nothing left to do ? | 10:02 |
| infinity | doko: Should be just that. I think. | 10:02 |
| cjwatson | pitti: it's in ~ubuntu-archive/testing/ on lillypilly | 10:03 |
| cjwatson | pitti: also ~ubuntu-archive/testing-ports/ (sorry, code kept in sync rather than common) | 10:03 |
| cjwatson | pitti: there might be a few outstanding uncommitted changes, mainly from the cocoplum->lillypilly move | 10:03 |
| jamespage | jibel: those server jobs have now cleared through | 10:04 |
| cjwatson | pitti: if you can figure out how to add that kind of information to its output, be my guest :-) | 10:04 |
| jamespage | pitti: the alternate automated test is currently running | 10:04 |
| pitti | cjwatson: ok, so ok for hacking on it | 10:04 |
| cjwatson | pitti: how about I go through and sort out uncommitted stuff first | 10:04 |
| pitti | cjwatson: there's also changes to update_out/dpkg.c, the rest of bzr diff is just config diff; it doesn't get in my way, I'd like to touch different files | 10:05 |
| pitti | cjwatson: thanks! | 10:05 |
| jamespage | jibel, pitti: think alternate is doing the same | 10:06 |
| pitti | 6 minutes to go for downloading | 10:07 |
| pitti | jamespage: do you want to look into this? I'm also looking at bug 897680, so maybe better if we don't overlap there | 10:07 |
| ubottu | Launchpad bug 897680 in ubiquity (Ubuntu Precise) "Precise Desktop 64Bit: libc6 fails to install if "install 3rd party software" is selected" [High,In progress] https://launchpad.net/bugs/897680 | 10:07 |
| jibel | jamespage, yes, you can cancel the jobs | 10:07 |
| jamespage | pitti: sure | 10:07 |
| cjwatson | jibel,jamespage: so this is reproducible outside jenkins? | 10:08 |
| jamespage | cjwatson: yes | 10:09 |
| cjwatson | jamespage: OK, I'll look at it then | 10:09 |
| jamespage | cjwatson: thanks | 10:09 |
| pitti | . o O { yay for daily automatic tests! } | 10:09 |
| jamespage | cjwatson, jibel; I'm struggling to see an specific step causing this looking at the d-i logs in jenkins | 10:15 |
| cjwatson | jamespage: I have a guess based on prior experience but I'd rather see it for myself first | 10:15 |
| cjwatson | pitti: all merged up now | 10:19 |
| pitti | cjwatson: thanks! | 10:21 |
| * cjwatson videos the installer to try to track this down | 10:31 | |
| jamespage | jibel, pitti, cjwatson: all of the alternate installs failed with the same issue | 10:33 |
| cjwatson | jamespage: yeah, they would have done | 10:36 |
| cjwatson | there's no room for anything flavour-specific here | 10:36 |
| cjwatson | jibel,jamespage: fix uploaded | 10:58 |
| cjwatson | I would suggest a rebuild of all d-i images after libselinux has built everywhere | 10:59 |
| pitti | thanks cjwatson | 10:59 |
| pitti | I need to catch a train this afternoon, but I should have enough bandwidth to trigger new builds; unless someone else can do that | 11:00 |
| cjwatson | I probably can | 11:00 |
| pitti | I'll be online at 1300 UTC (in 2 hours), I'll check IRC/nusakan then | 11:00 |
| pitti | cjwatson: ah, upstart is now working too well in a chroot? | 11:01 |
| cjwatson | pitti: not a new class of problem; see my reference to the eglibc change, which was in natty | 11:04 |
| cjwatson | sysvinit telinit u sends SIGHUP to pid 1, upstart telinit u sends SIGTERM to pid 1 | 11:05 |
| cjwatson | the latter causes busybox init to reboot | 11:05 |
| cjwatson | it's a semantic difference we need to account for | 11:05 |
| cjwatson | I knew I'd seen this kind of thing before :) | 11:06 |
| === _salem is now known as salem_ | ||
| pitti | dholbach: sorry, missed my patch pilot shift today; I'll do that on Monday instead | 11:09 |
| dholbach | pitti, no worries | 11:09 |
| dholbach | whatever suits you better - you should also be able to just move the events in the google cal | 11:10 |
| * dholbach hugs pitti | 11:10 | |
| pitti | dholbach: nevermind, I just can't read my mobile; it already _is_ on Monday :) | 11:12 |
| dholbach | haha | 11:12 |
| dholbach | great | 11:12 |
| dholbach | diwic, hello. I just upgraded to 12.04 - so far so good, the only problem I get is http://paste.ubuntu.com/756958/ - did you see anything similar somewhere else already? | 11:46 |
| ogra_ | dholbach, your production machine ? | 11:46 |
| dholbach | ogra_, yep | 11:46 |
| ogra_ | wow, brave | 11:46 |
| diwic | dholbach, hmm, not recognising | 11:50 |
| diwic | dholbach, does it happen every time you plug it in? | 11:50 |
| dholbach | diwic, it looks like it - I tried twice, but I can try again if you like | 11:50 |
| dholbach | diwic, yes, just tried again | 11:51 |
| diwic | dholbach, my gut feeling is that this is a generic USB problem rather than a sound card problem, does it happen to other usb devices as well? | 11:51 |
| === funkyHat2 is now known as funkyHat | ||
| diwic | dholbach, given that the first sign of trouble is "usb 1-1.2: string descriptor 0 malformed (err = -61), defaulting to 0x0409" from the USB driver rather than the sound card driver | 11:52 |
| dholbach | diwic, usb-storage seems to work | 11:52 |
| diwic | ok | 11:52 |
| dholbach | let me see how it works with the scanner | 11:53 |
| dholbach | diwic, uvcvideo: Failed to submit URB 0 (-28). - that's for the webcam, but it's not USB - just thought I'd test it as well | 11:54 |
| diwic | "URB 0" sounds very much like USB | 11:55 |
| diwic | webcams are often connected with USB internally | 11:55 |
| dholbach | ah ok | 11:55 |
| * ogra_ always thought uvd even means Usb Video Connector | 11:56 | |
| ogra_ | *uvc | 11:56 |
| dholbach | diwic, the scanner seems to be happy AFAICS | 11:57 |
| diwic | dholbach, so, my gut feeling says "USB driver failure" rather than "sound driver failure", so see if you can find an USB expert, if (s)he tells you that it's a sound driver problem, I guess I'll have to take a deeper look. Makes sense? :-) | 11:59 |
| === dendro-afk is now known as dendrobates | ||
| dholbach | diwic, I think I can try the oneiric kernel to see if that makes it work again and then file a bug on linux? | 11:59 |
| diwic | ok | 12:00 |
| dholbach | cool | 12:00 |
| diwic | you can also try oneiric kernel + alsa dkms packages to further try to rule out (or in) ALSA | 12:00 |
| === MacSlow is now known as MacSlow|lunch | ||
| diwic | dholbach, you can also try oneiric kernel + alsa dkms packages to further try to rule out (or in) ALSA | 12:04 |
| diwic | or rather | 12:05 |
| diwic | alsa backports | 12:05 |
| diwic | dkms is for snd-hda-intel only | 12:05 |
| dholbach | diwic, just going back to the oneiric kernel worked: http://paste.ubuntu.com/756964/ | 12:05 |
| diwic | hmm ok | 12:05 |
| soren | Once upon a time, there would be a popup when my mouse was running out of battery. /me misses that thing | 12:06 |
| diwic | #define ENOSPC 28 /* No space left on device */ | 12:07 |
| dholbach | diwic, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/899099 | 12:10 |
| ubottu | Launchpad bug 899099 in linux (Ubuntu) "snd-usb-caiaq fails to load" [Undecided,New] | 12:10 |
| dholbach | diwic, who could be close to being the "USB expert" you mentioned? :) | 12:12 |
| diwic | dholbach, guess why I wrote "USB expert" instead of a specific name? :-) | 12:14 |
| diwic | at least I've found the line where your error message comes from | 12:14 |
| dholbach | diwic, I know this is going to sound vague - mostly because I have little idea of the internals, but if the string descriptor is malformed, is the device still being brought up? (can anything be read at all?) | 12:17 |
| diwic | dholbach, I think you should try to talk to Daniel Mack, (zonque on freenode) he wrote that caiaq driver and seems to know quite a bit about USB audio drivers | 12:19 |
| dholbach | ok, will do | 12:20 |
| geser | cjwatson: do you plan to sync reiser4progs (you're TIL for it) for precise? see also bug #889991 | 12:21 |
| ubottu | Launchpad bug 889991 in reiser4progs (Ubuntu) "reiser4progs (main) should be synced from Debian testing (main)" [Undecided,New] https://launchpad.net/bugs/889991 | 12:21 |
| * Daviey wonders why NEW sync's from Debian require AA approval. | 12:22 | |
| geser | do they? that's new to me | 12:22 |
| Daviey | geser: source NEW. | 12:23 |
| geser | I know that AA have to accept them, but not that AA need to approve before it can be synced (uploaded) | 12:24 |
| ogra_ | Daviey, license review etc | 12:24 |
| quadrispro | tumbleweed, thank you! | 12:24 |
| cjwatson | geser: yes, although it requires a fakesync | 12:24 |
| Daviey | ogra_: right, but if it got into Debian, the licence is probably good :) | 12:25 |
| cjwatson | Daviey: because in some cases we blacklist classes of packages from Ubuntu (e.g. all xul extensions) | 12:25 |
| cjwatson | or freebsd packages, or ... | 12:25 |
| int_ua | zyga_: ping | 12:25 |
| cjwatson | although that's a post-hoc justification; the real reason is that the condition on NEW is simply "haven't seen this before" | 12:25 |
| Daviey | cjwatson: Ah, makes sense | 12:25 |
| zyga_ | int_ua, pong | 12:25 |
| zyga_ | how can I help you | 12:26 |
| tumbleweed | talking of AA syncs, can we have the sync request bugs processed, please | 12:26 |
| int_ua | zyga_: I'm from https://bugs.launchpad.net/command-not-found/+bug/880616 :) | 12:26 |
| ubottu | Launchpad bug 880616 in command-not-found "Add an option to install the package right away ( + draft patch )" [Undecided,Confirmed] | 12:26 |
| tumbleweed | quadrispro: np | 12:26 |
| zyga_ | int_ua, hi, welcome :) | 12:27 |
| zyga_ | int_ua, so how can I help you with c-n-f work? :-) | 12:27 |
| int_ua | zyga_: I did't have experience with merges yet, so I wanted to ask you some questions. I need to create a new branch, yes? | 12:27 |
| zyga_ | int_ua, ok, I'll walk you through this | 12:28 |
| zyga_ | int_ua, I assume you branched lp:command-not-found, did your patch there | 12:28 |
| zyga_ | int_ua, did you commit your change yet? | 12:28 |
| int_ua | zyga_: yes, commited | 12:29 |
| int_ua | zyga_: locally | 12:29 |
| zyga_ | int_ua, excellent, since you have a launchpad account that part is also done, do you have any ssh keys registered on launchpad? You will need that to put your branch up in the system | 12:29 |
| int_ua | zyga_: (I'd like to do some additional work, but it's tested now) | 12:29 |
| int_ua | zyga_: yes, I have two 8-) | 12:30 |
| zyga_ | excellent | 12:30 |
| zyga_ | then just do something like that | 12:30 |
| zyga_ | bzr push lp:~yourlaunchpadusername/command-not-found/add-install-support | 12:30 |
| zyga_ | where the last part is anything you like obviously, it does not matter that much for a short lived branch | 12:31 |
| int_ua | Don't i need to create a new branch in the web interface? | 12:31 |
| zyga_ | int_ua, nope | 12:32 |
| int_ua | ok, doing it :) | 12:32 |
| int_ua | zyga_: Done. https://code.launchpad.net/~xintx-ua/command-not-found/add-install-support | 12:34 |
| int_ua | but I want to add root installation too before submitting | 12:35 |
| zyga_ | int_ua, ok, from the same directory do this: bzr lp-propose-merge | 12:35 |
| zyga_ | int_ua, that's okay, you can commit more changes | 12:35 |
| zyga_ | int_ua, and just push them again | 12:35 |
| zyga_ | int_ua, the branch and the merge request will automatically update | 12:35 |
| int_ua | zyga_: Ok, what should I write to the log file that has just opened? What is it for? | 12:37 |
| zyga_ | int_ua, it's the description of the merge request, you don't need to write anything but I usually write a short description of what the branch is about, if the branch is very small (few patches) I just ask people to look at the patches instead | 12:38 |
| `-` | #ubuntu ops are nazi fags. please remember to use your brain not that other bit of the anatomy the #ubuntu team appears to think is best. | 12:38 |
| int_ua | zyga_: and should I change bug status to "In Progress" if I'm working on it? | 12:39 |
| zyga_ | int_ua, if you want, go for it :-) | 12:39 |
| zyga_ | int_ua, much of the tools are defined by how we use them, if you like a particular way of working just work like that | 12:39 |
| int_ua | ok, looks like submitted from here :) https://code.launchpad.net/~xintx-ua/command-not-found/add-install-support/+merge/84257 | 12:40 |
| zyga_ | int_ua, the good thing about this is that anyone can easily see the diff as both your branch and trunk change and anyone can easily take your branch without having to fiddle with the patch | 12:41 |
| int_ua | zyga_: great :) | 12:41 |
| dholbach | diwic, ignore my question about the malformed string descriptor - I got the same message with oneiric and it didn't matter :) | 12:41 |
| int_ua | zyga_: And now I have to link this branch to bug, am I? | 12:42 |
| zyga_ | int_ua, there's a button for that in the sidebar | 12:42 |
| zyga_ | (of the bug actually | 12:42 |
| int_ua | zyga_: yeah, got it | 12:42 |
| int_ua | But "Loading suggestions..." is all that it does | 12:43 |
| zyga_ | int_ua, you need to give the name of your branch | 12:43 |
| zyga_ | just paste lp:~xintx-ua/command-not-found/add-install-support | 12:43 |
| int_ua | done | 12:44 |
| zyga_ | I added some comments there | 12:44 |
| int_ua | ~xintx-ua/command-not-found/add-install-support worked too :) | 12:44 |
| zyga_ | int_ua, you are using some cyrlic-based locale, correct? | 12:44 |
| int_ua | yes, uk_UA | 12:45 |
| zyga_ | int_ua, I've seen a ton of bugs about c-n-f crashing on various non-ansi characters. I'm pretty sure that is not happening when you are using .UTF-8 encoding (LC_MESSAGES and LC_CTYPE end in .UTF-8) | 12:45 |
| zyga_ | int_ua, have you seen any of those crashes yourself? | 12:45 |
| int_ua | no, but mine is .UTF-8 | 12:46 |
| zyga_ | right | 12:46 |
| int_ua | also, the regexp doesn't work as expected in uk | 12:46 |
| zyga_ | I suspect that's CJK | 12:46 |
| int_ua | but that's another problem | 12:46 |
| zyga_ | oh? | 12:46 |
| zyga_ | btw, I'm dumb | 12:47 |
| zyga_ | forgive my question about LC_ALL, '' | 12:47 |
| zyga_ | locale is such a mess in the stdlib I rarely use it directly | 12:47 |
| zyga_ | I know what you meant now | 12:47 |
| int_ua | zyga_: it matches only cyrillic а | 12:47 |
| int_ua | while it has to match "так" | 12:48 |
| zyga_ | int_ua, I guess that's locale bug then | 12:48 |
| int_ua | one moment | 12:48 |
| zyga_ | int_ua, in my opinion the locale is hopeless (insane separation, insane encoding options, oddball cases) and I usually use other tools for that | 12:48 |
| zyga_ | int_ua, I'd just allow users to answer.tolower() in (_("yes"), _("y")) | 12:49 |
| zyga_ | int_ua, then each translator can ensure the response is sane and works as expected for the user of that language/region | 12:49 |
| zyga_ | int_ua, anyway | 12:50 |
| int_ua | ^([Yy+]|[Тт][Аа][Кк]?)$ is the regexp | 12:50 |
| zyga_ | int_ua, it looks good to me | 12:50 |
| zyga_ | it matches 'tak' | 12:50 |
| int_ua | yeah | 12:50 |
| zyga_ | but you said it was broken for you? | 12:50 |
| int_ua | but not in practice | 12:50 |
| zyga_ | oh? | 12:50 |
| zyga_ | encoding issues! | 12:50 |
| zyga_ | lovely | 12:50 |
| zyga_ | so | 12:50 |
| int_ua | it matches only "а" for me | 12:50 |
| zyga_ | this is the same problem I had with the input | 12:50 |
| zyga_ | input depends on LC_CTYPE | 12:51 |
| zyga_ | the stuff you get on command line | 12:51 |
| zyga_ | currently I assume it's utf8 | 12:51 |
| zyga_ | which is broken | 12:51 |
| zyga_ | but everything else is more broken so that's a compromise until I get better ideas | 12:51 |
| zyga_ | try this | 12:51 |
| zyga_ | raw_inupt().decode('utf-8') | 12:51 |
| zyga_ | match on unicode | 12:51 |
| int_ua | ok | 12:51 |
| zyga_ | not on bytestrings | 12:51 |
| zyga_ | I suspect the pattern is equally at fault | 12:52 |
| zyga_ | what is the return type of locale.YESEXPR for you? | 12:52 |
| zyga_ | unicode or str? | 12:52 |
| zyga_ | for me it's str | 12:52 |
| zyga_ | and that's just not good | 12:52 |
| zyga_ | because it matches each byte of the (probably) utf-8 encoded value, I bet that cyrlic 'k' and 't' use multibyte strings for their representation | 12:53 |
| zyga_ | try to decode both the input and the pattern as a single encoding | 12:53 |
| zyga_ | and then match both | 12:53 |
| zyga_ | it ought to work | 12:53 |
| zyga_ | and you only reduced the problem to knowing what the right encoding is | 12:53 |
| zyga_ | (which we currently have so it's not worse) | 12:53 |
| int_ua | trying | 12:54 |
| int_ua | zyga_: hey, that worked :) | 12:55 |
| zyga_ | cool | 12:55 |
| zyga_ | ok | 12:55 |
| zyga_ | another comment then | 12:55 |
| int_ua | cleaning prints | 12:55 |
| zyga_ | try moving the locale initialization to the common place where we do that (I don't remember, early before starting main) | 12:55 |
| zyga_ | is there a historic locale that was used in ukraine before each distro switched to utf8? | 12:56 |
| int_ua | zyga_: I'm not sure, because there was a lot of influence from KOI8-R, but when I started using linux four years ago it was UTF-8 everywhere IIRC | 12:58 |
| zyga_ | ok | 12:58 |
| zyga_ | I was hoping you could help me fix the grand locale bug :) | 12:58 |
| zyga_ | anyway awesome, commit your changes and push them back to the branch | 12:58 |
| pitti | cjwatson: libselinux is published everywhere except arm; I can trigger new builds now unless you already did? | 13:00 |
| int_ua | zyga_: but I'm not sure where to put locale init. Is line 17 ok? | 13:00 |
| zyga_ | int_ua, w8, let me chcek | 13:00 |
| zyga_ | check | 13:00 |
| cjwatson | pitti: I haven't yet - go ahead if you like | 13:00 |
| pitti | doing | 13:00 |
| cjwatson | zyga_: /usr/share/i18n/SUPPORTED indicates it was uk_UA which had KOI8-U encoding | 13:01 |
| zyga_ | cjwatson, thanks for the tip! | 13:01 |
| zyga_ | cjwatson, is there any way a default ubuntu install ends up with something else than utf8? | 13:01 |
| zyga_ | cjwatson, china perhaps/ | 13:01 |
| cjwatson | shouldn't be, not for several years | 13:01 |
| cjwatson | maybe one upgraded from warty ... | 13:02 |
| zyga_ | hmm, ok | 13:02 |
| zyga_ | int_ua, try in enable_i18n | 13:02 |
| zyga_ | (which should be called enable l10n but anyway) | 13:02 |
| cjwatson | :q | 13:02 |
| cjwatson | damn | 13:02 |
| ogra_ | better :wq | 13:02 |
| ogra_ | :P | 13:02 |
| * pitti uses :x | 13:03 | |
| int_ua | zyga_: after cnf.install(unicode=True) ? | 13:03 |
| zyga_ | int_ua, yeah, just see if that works as well as before :) | 13:04 |
| int_ua | BTW, what if I replace all added import * with from * import ? | 13:04 |
| int_ua | would anyone mind? | 13:04 |
| zyga_ | int_ua, huh? | 13:05 |
| int_ua | zyga_: I mean | 13:05 |
| === MacSlow|lunch is now known as MacSlow | ||
| int_ua | zyga_: What if I replace "import subprocess" with "from subprocess import call"? And others that I've just added | 13:06 |
| zyga_ | int_ua, ah, that | 13:06 |
| zyga_ | int_ua, as long as it's not from xxx import * I don't care much | 13:07 |
| zyga_ | I usually do subprocess.call | 13:07 |
| zyga_ | but I import using from when the thing is a nested module | 13:07 |
| zyga_ | or when I'm using it a lot | 13:07 |
| zyga_ | anyway, up to you | 13:07 |
| int_ua | zyga_: ok, thanks | 13:08 |
| int_ua | "from __future__ import absolute_import" import *everyting* or what? | 13:09 |
| zyga_ | int_ua, are you asking about what this does? | 13:10 |
| int_ua | yes | 13:11 |
| zyga_ | int_ua, it enables absolute imports http://www.python.org/dev/peps/pep-0328/ | 13:11 |
| zyga_ | int_ua, it's there to ensure the code does not break if there is a package module and a global module with the same name | 13:11 |
| zyga_ | int_ua, think inside foo package you have an utils module, import utils gets that in certain versions of python, with the future import you always get the global module unless you say from foo import utils | 13:12 |
| int_ua | zyga_: ok, got it, thanks a lot :) | 13:13 |
| int_ua | zyga_: another question: What is the best way to test it? I just made links to edited branch from actual locations, but I don't feel it's the right way | 13:17 |
| int_ua | ok, works | 13:19 |
| zyga_ | int_ua, don't do that, it can mess up your system | 13:23 |
| zyga_ | int_ua, the best way is to just call the new program and see how it works | 13:23 |
| zyga_ | int_ua, or | 13:23 |
| zyga_ | int_ua, you can do what I typically do while hacking on this | 13:23 |
| zyga_ | int_ua, I extend my path to include ~/.local/bin | 13:23 |
| zyga_ | int_ua, and I install it in development mode for my user | 13:24 |
| zyga_ | int_ua, try setup.py develop --user | 13:24 |
| zyga_ | (hmm, come to think of it, it's still using distutils so that might not work) | 13:24 |
| zyga_ | I should fix that one day, I really don't maintain it much anymore | 13:24 |
| int_ua | zyga_: ok, I've pushed new revision and now have to leave for hour or two. Will finish root installation later :) | 13:26 |
| zyga_ | int_ua, don't do root installs :) | 13:27 |
| zyga_ | int_ua, ok, talk to you later | 13:27 |
| dantti | cnd: hi, I've finally managed to build that thing, did you see my mail? if you can test your devices would be nice :) | 13:27 |
| int_ua | zyga_: I'm still here :) | 13:28 |
| int_ua | zyga_: what about root install? | 13:28 |
| zyga_ | int_ua, it's best not to do it, there is no need, it's better to test in isolation | 13:29 |
| int_ua | oh, ok | 13:29 |
| int_ua | zyga_: Then I think that the branch is ready to do some tests :) | 13:29 |
| int_ua | zyga_: How can I mark it as ready for review? Do I need to? | 13:30 |
| zyga_ | int_ua, I'm reviewing it now | 13:31 |
| int_ua | zyga_: merging request _is_ the mark. Got it :) | 13:32 |
| * int_ua going out | 13:32 | |
| === Guest69788 is now known as Zic | ||
| dholbach | diwic, I filed a separate bug about the webcam too | 14:00 |
| seb128 | slangasek, mvo, cjwatson: do we need a pre-depends on dpkg (>= 1.15.7.2) for packages using dpkg-maintscript-helper in precise for the lucid->precise upgrades? or will dpkg be updated first by the dist-upgrader? | 14:03 |
| dholbach | diwic, interestingly enough the error message for the webcam also has -28 in there, hum | 14:04 |
| pitti | rickspencer3, jamespage: so the server tests are happy again, alternates failed again, looking | 14:05 |
| zul | can someone from the techboard let my email go through to the techboard ml it seems to be stuck in the moderation queue | 14:06 |
| pitti | zul: looking | 14:08 |
| zul | pitti: thank | 14:08 |
| zul | thanks even | 14:08 |
| mvo | seb128: I have not done a backport for dpkg yet, I would like to hear the opinion of cjwatson or slangasek first. its not required as such, but I think it would make our life easier and we need to backport apt/python-apt too (mostly done now) | 14:09 |
| mvo | seb128: I guess you saw the bug I reported ;) ? | 14:09 |
| seb128 | mvo, yeah ;-) | 14:10 |
| mvo | jibel: hrm, the apt-clone lucid backport blocks currently on the dh-python2 backport that iirc barry was working on | 14:10 |
| seb128 | mvo, I've been reading http://lists.debian.org/debian-devel/2011/03/msg00290.html as well | 14:11 |
| jamespage | pitti: looks like something weird happened when d-i tried to install the packages for the test framework | 14:11 |
| seb128 | mvo, so I'm a bit not sure if adding one is correct or is just going to make the resolver job harder if we are sure dpkg is updated first by other means anyway | 14:11 |
| pitti | jamespage, jibel: so the alternates failed due to python-{couchdb,subunit,junitxml} missing | 14:11 |
| pitti | jamespage, jibel: that's not reflected on http://cdimage.ubuntu.com/daily/20111202.1/report.html though, that's clean | 14:12 |
| zyga_ | dh_python2 work for lucid will not be needed much once precise ships, I guess the whole point was LTS targetting server people | 14:12 |
| pitti | jamespage, jibel: are these three installed as part of the preseeding or so? python-junitxml isn't even in main | 14:12 |
| jamespage | pitti: those packages are overlaid by the test framework | 14:12 |
| === bladernr_afk is now known as bladernr_ | ||
| pitti | jamespage: ok, that's what I figured | 14:15 |
| pitti | jamespage: subunit was promoted from universe to main yesterday, I wonder whether that's related | 14:16 |
| jamespage | pitti: quite possibly - however the -server test do the same thing | 14:16 |
| * jamespage scratches his head | 14:17 | |
| pitti | jamespage, jibel: could it be that this is missing universe apt sources? | 14:17 |
| pitti | but couchdb has been in main all along | 14:17 |
| pitti | jamespage: oh, so that's just noise? | 14:17 |
| pitti | Dec 2 13:42:46 main-menu[1723]: WARNING **: Configuring 'pkgsel' failed with error code 100 | 14:17 |
| pitti | I had assumed that this was the result from those four package install failures | 14:18 |
| jamespage | pitti: I think that you are right - looking at why it failed on alternate but worked on server | 14:19 |
| jibel | jamespage, pitti Dec 2 13:35:02 in-target: W: Failed to fetch bzip2:/var/lib/apt/lists/partial/us.archive.ubuntu.com_ubuntu_dists_precise_universe_binary-i386_Packages Hash Sum mismatch | 14:26 |
| pitti | aah | 14:26 |
| jamespage | jibel: that will be it | 14:26 |
| pitti | so, just bad timing | 14:26 |
| pitti | that seems to happen quite often also in CD builds | 14:26 |
| jamespage | I'm just re-running one | 14:26 |
| jamespage | once that competed I'll submit the rest | 14:27 |
| pitti | is there any chance that we could grep for that in logs and abort/ignore the test then? | 14:27 |
| pitti | jamespage: universe is added only as part of the test rig, right? | 14:28 |
| pitti | jamespage: which means that these tests won't actually catch uninstallability due to main dependencies to universe packages | 14:28 |
| pitti | we already would know from the report.html, but it still skews the results a bit | 14:29 |
| pitti | I wonder if we should aim for having all packages that we need there to be in main | 14:29 |
| * jamespage goes to look how it works | 14:29 | |
| cjwatson | seb128: I think we should have a pre-depends regardless; it will reduce confusion for people who need to fall back to apt for whatever reason | 14:30 |
| seb128 | cjwatson, ok, is something adding the pre-depends for me if I use a .maintscript? | 14:31 |
| === Mortimus is now known as aladuca | ||
| cjwatson | seb128: it isn't going to make the resolver's job harder if it's already satisfied :-) | 14:31 |
| seb128 | cjwatson, I was trying to figure that but I'm not sure where to look | 14:31 |
| seb128 | (I guess not) | 14:31 |
| cjwatson | seb128: Pre-Depends: ${misc:Pre-Depends} and then dh_installdeb will do it | 14:31 |
| seb128 | cjwatson, thanks | 14:32 |
| cjwatson | but you do have to have that substvar in debian/control, it won't do it otherwise | 14:32 |
| seb128 | right, what I just figured when I asked, we usually have the Depends: equivalent but not the Pre-Depends one ;-) | 14:32 |
| === HOHOHaney is now known as Laney | ||
| jamespage | pitti, jibel: all alternates are now re-running | 14:37 |
| jamespage | first completed OK | 14:37 |
| pitti | jamespage: ah, good, amd64 default completed | 14:38 |
| pitti | I'm happy that it's not yet another regression | 14:38 |
| pitti | jamespage: thanks | 14:38 |
| jamespage | pitti: I can't see that universe is added explicitly in the preseeds | 14:44 |
| cjwatson | universe is used by default during installation | 14:45 |
| cjwatson | just not for CD builds and the like | 14:45 |
| pitti | ah, it's available within d-i already? I didn't know that, thanks | 14:52 |
| barry | mvo: actually doko was working on that, but i'm not sure what the status is | 14:52 |
| mvo | aha, ok | 14:53 |
| mvo | I guess I could change it to use pycentral | 14:53 |
| barry | mvo: or pysupport? that might be minimally better than pycentral | 14:56 |
| slangasek | seb128, mvo: I think *not* having to backport dpkg for the upgrader would be a win, and there are always some who don't use the upgrader; please use the versioned dpkg pre-depends when using dpkg-maintscript-helper, it's per se correct | 14:57 |
| seb128 | slangasek, thanks, that's what cjwatson said as well and what I'm doing ;-) | 14:57 |
| === Guest52012 is now known as Zic | ||
| * int_ua back | 15:02 | |
| pitti | jamespage: hm, wasn't precise-server-ec2 the one you added a few hours ago? I thought that succeeded back then, now it's fail at unknown time | 15:06 |
| pitti | jamespage: could you please restart precise-desktop-i386? I suppose it was just a victim of the EINVAL bug again | 15:06 |
| jibel | pitti, done | 15:10 |
| pitti | jibel: merci | 15:11 |
| jibel | pitti, I've an i386 VM ready with the pieces of ubiquity that trigger the EINVAL bug. 2 loops copying files with this code are enough to get the bug. | 15:12 |
| pitti | jibel: excellent! does apw have access to that one? | 15:15 |
| int_ua | zyga_: ping :) | 15:17 |
| * pitti waves good night and nice weekend everyone! | 15:17 | |
| zyga_ | here | 15:17 |
| zyga_ | pitti, have a nice weekend! | 15:17 |
| jibel | pitti, not sure he can reach this machine, I'll check with him on Monday. | 15:18 |
| int_ua | zyga_: I just read emails. About "if return_code not in (0,256)": I'm not sure that I understood you correctly. If user answers "no" to apt-get install we don't need to say him that there was an error, do we? | 15:20 |
| zyga_ | int_ua, sure I understand that now, I just don't like the syntax | 15:20 |
| zyga_ | int_ua, if 0 < return_code < 256: ... | 15:21 |
| zyga_ | int_ua, or explicit check against 0 and 256 with else section | 15:21 |
| int_ua | zyga_: Is 256 the maximum possible value? | 15:21 |
| zyga_ | int_ua, I don't know, check process exist status macro in wait(2) | 15:22 |
| zyga_ | int_ua, I think it's actually smaller but I did not check | 15:22 |
| int_ua | zyga_: "if return_code != 0 or return_code != 256:" ? | 15:22 |
| zyga_ | WEXITSTATUS(status) | 15:23 |
| zyga_ | returns the exit status of the child. This consists of the | 15:23 |
| zyga_ | least significant 8 bits of the status argument that the child | 15:23 |
| zyga_ | specified in a call to exit(3) or _exit(2) or as the argument | 15:23 |
| zyga_ | for a return statement in main(). | 15:23 |
| int_ua | oops | 15:23 |
| zyga_ | int_ua, TBH I'd just remove that part all together | 15:23 |
| zyga_ | int_ua, the user will have enought indication that installation has already failed from apt, right? | 15:23 |
| int_ua | zyga_: I wanted to add option to execute desired command after installation | 15:24 |
| zyga_ | int_ua, I see... hmm | 15:24 |
| zyga_ | int_ua, I'd start with this, let it land | 15:25 |
| zyga_ | int_ua, then work on subsequent features | 15:25 |
| int_ua | zyga_: so, I'll remove these lines for now? | 15:25 |
| zyga_ | yeah | 15:25 |
| int_ua | zyga_: Should I add fallback to utf-8 if getlocale fails? | 15:30 |
| zyga_ | int_ua, hmm, not sure, how can it fail? | 15:30 |
| zyga_ | int_ua, (you could try unsetting all LC_xxx LOCALE and LANG and checking) | 15:31 |
| int_ua | If setlocale was not executed | 15:31 |
| zyga_ | int_ua, in that case enable_i18n should abort with pure ascii error message | 15:31 |
| zyga_ | int_ua, well let's make sure we did execute setlocale early then | 15:31 |
| jamespage | pitti: I added precise-server-ec2 was the alpha1 milestone test | 15:35 |
| jamespage | sorry I added == the | 15:35 |
| int_ua | zyga_: ok, pyflakes returned 0 and pep8 showed only one my error and two present before. And it worked with cyrillic answer. So I guess it's ready. | 15:48 |
| zyga_ | +1 | 15:48 |
| zyga_ | int_ua, did you push all your changes? | 15:48 |
| int_ua | zyga_: yes | 15:49 |
| zyga_ | int_ua, what is the TODO line for? | 15:52 |
| int_ua | zyga_: sorry, forgot it :) | 15:53 |
| int_ua | zyga_: done | 15:59 |
| zyga_ | int_ua, I'm looking at it now | 15:59 |
| zyga_ | int_ua, I don't like one thing, the pattern displayed is not the one matched, I'm checking if there is a way to get a human-readable equivalent | 15:59 |
| int_ua | zyga_: I think it should be done in translation | 16:01 |
| hallyn | slangasek: so if qemu-kvm-spice comes from qemu-linaro, do i need to first push a new empty qemu-kvm-spice source package? or will that binary package get cleanly obsoleted? | 16:01 |
| zyga_ | int_ua, well it cannot be, the translator has no way to know what is expected without technical knowledge about the pattern that is coming from the locale system | 16:02 |
| int_ua | zyga_: that's true and I already noticed this problem in uk translation of apt-get. | 16:04 |
| int_ua | zyga_: But I've never noticed other options before. | 16:06 |
| zyga_ | int_ua, we can either try to be smart and parse it, be safe and not use it at all, or be correct by using something that provides the same pattern as a normal non-regexp string, I just don't think there is a safe option | 16:07 |
| zyga_ | s/safe/correct/ | 16:07 |
| cnd | dantti, great! I'll check it out today | 16:08 |
| int_ua | zyga_: Thinking about parsing result: "y(так)/n"? | 16:09 |
| zyga_ | int_ua, no, about parsing the pattern to match | 16:09 |
| zyga_ | [yY][tT][aA][kK]... etc | 16:09 |
| int_ua | zyga_: I meant s/parsing result/parsing result, shoud it be like this/ | 16:10 |
| zyga_ | int_ua, well I'm just saying that right now it's confusing and does not work, what if the locale says that 'y' is "no" :) ? | 16:11 |
| int_ua | zyga_: Actually it's exactly the case for [some] cyrillic locales. I think that was the reason why one-letter option was not added to regexp. | 16:12 |
| zyga_ | ha | 16:12 |
| int_ua | zyga_: Not that 'y' means 'no' | 16:13 |
| zyga_ | ah, I see | 16:14 |
| int_ua | zyga_: But 'н' for 'ні' that means 'no' is places on the latin 'y' | 16:14 |
| int_ua | *placed | 16:14 |
| int_ua | int_ua: And (the most interesting) vice versa | 16:15 |
| === beuno is now known as beuno-lunch | ||
| int_ua | zyga_: ^ 'т'/'n' | 16:16 |
| zyga_ | int_ua, ok, this is hopeless | 16:19 |
| zyga_ | int_ua, let's not use locale for that | 16:19 |
| zyga_ | int_ua, IMHO locale is utterly broken historic mess | 16:20 |
| * slangasek squints :) | 16:20 | |
| zyga_ | int_ua, let's match against translatable parts | 16:20 |
| zyga_ | slangasek, ? | 16:21 |
| int_ua | zyga_: how exactly do you want to do this? I mean current approach works and will not take 'y' in another locale for 'yes'. And it will match latin options correctly. | 16:22 |
| zyga_ | int_ua, let me show you | 16:23 |
| === beuno-lunch is now known as beuno | ||
| zyga_ | int_ua, current approach works but is confusing | 16:23 |
| jml | https://wiki.ubuntu.com/DebootstrapChroot looks like something that someone might have already automated | 16:28 |
| jml | is it? | 16:28 |
| int_ua | zyga_: I agree that it's not perfect, but it says 'y/N' and will take 'y' for 'yes' and Enter/'n'/'N' for 'no'. It just has undocumented feature to recognize native 'yes' as a word. Why 'confusing'? | 16:31 |
| zyga_ | int_ua, exactly because of that, I really don't like the fact that it cannot be fixed | 16:31 |
| zyga_ | int_ua, just one more moment | 16:31 |
| int_ua | ok | 16:32 |
| === dholbach_ is now known as dholbach | ||
| zyga_ | int_ua, it will crash if the answer is empty, python returns None in that case | 16:33 |
| int_ua | oh | 16:33 |
| int_ua | zyga_: wait, it doesn't crash for me | 16:35 |
| zyga_ | int_ua, hmm? w8 | 16:35 |
| zyga_ | o_O | 16:36 |
| zyga_ | sorry, my mistake | 16:37 |
| int_ua | zyga_: it just skips whole 'if re.match(pattern, answer):' thread | 16:37 |
| zyga_ | I got input_encoding to be None somehow | 16:37 |
| int_ua | zyga_: that means enable_i18n() was not executed, does it? | 16:38 |
| zyga_ | yeah, likely | 16:38 |
| zyga_ | I was messing around | 16:39 |
| zyga_ | let me recheck | 16:39 |
| int_ua | zyga_: what if I add ' encoding = (locale.getlocale(locale.LC_CTYPE)[1] or "utf-8" '? | 16:41 |
| zyga_ | I did something similar | 16:41 |
| zyga_ | w8, I'm adding a few things | 16:41 |
| zyga_ | the crash handler | 16:41 |
| int_ua | ok | 16:41 |
| * int_ua afk for 30 minutes | 16:44 | |
| hallyn | SpamapS: pitti: AFAICS SRUs for libvirt-bin in lucid..natty have all been verified. Can they be moved to -updates? (So I can push new SRUs :-) | 16:45 |
| jamespage | @pilot out | 16:45 |
| === udevbot changed the topic of #ubuntu-devel to: 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: | ||
| zyga_ | int_ua, ok, I'll merge this with the y/n change | 16:53 |
| zyga_ | int_ua, sorry to have kept you waiting | 16:53 |
| zyga_ | int_ua, ok, I'll merge this with the y/n change | 16:54 |
| SpamapS | hallyn: heh, verification-done-natty means nothing to the SRU tracking report | 17:16 |
| SpamapS | hallyn: its just something we use to track half-verified stuff. If the bug is actually verified, just 'verification-done' | 17:16 |
| SpamapS | hallyn: so the libvirt bugs weren't showing up as being done | 17:17 |
| hallyn | SpamapS: I only just this morning verified the natty one for the tty bug | 17:17 |
| SpamapS | hallyn: the partial verifiers from before should have added the 'verification-done' tag.. | 17:18 |
| SpamapS | hallyn: anyway, moving to -updates now | 17:18 |
| hallyn | SpamapS: sweet, thx | 17:18 |
| * SpamapS waits patiently for sru-release to return.. hoping that there is no timeout. :p | 17:20 | |
| Dominic | hi folks, I'm looking into #796296 from an upstream perspective. We see it's needed on Ubuntu kernels at least, but not on Fedora. Does anybody know if the readlink change is local to Ubuntu's kernel, or where I can pull a patch list to look? (Daviey?) | 17:24 |
| int_ua | zyga_: ok, so I can change bug status to 'Fix committed'? | 17:28 |
| int_ua | zyga_: P.S. I have to leave soon | 17:29 |
| SpamapS | hallyn: launchpad doesn't seem to want this to succeed.. has timed out twice already | 17:29 |
| === azeem_ is now known as azeem | ||
| === fisted_ is now known as fisted | ||
| hallyn | SpamapS: i guess it's kidn of a big one - several bugs over many releases. | 18:00 |
| === Quintasan_ is now known as Quintasan | ||
| Daviey | Dominic: hey, still around? | 18:08 |
| Dominic | Daviey: yes, hi | 18:09 |
| Daviey | Dominic: hey, sorry for the slow RTT | 18:09 |
| Daviey | Dominic: I believe that is an an upstream kernel change | 18:10 |
| Daviey | Dominic: IDebian is also carrying the patch btw | 18:10 |
| SpamapS | hallyn: all that reall matters is the binary package sizes IIRC | 18:10 |
| Dominic | Daviey: ok, have you seen something similar in other packages? It's part of gnulib which is a portability library, so we should probably have that updated to provide the portability if anything :) I haven't found any kernel changes yet that point to it, wondering if it might be libc related instead. | 18:11 |
| cjwatson | Dominic: the problem is probably that many of the Ubuntu builders run an old kernel - they build for multiple releases | 18:12 |
| cjwatson | oh, wait, now I actually read the bug that probably isn't it | 18:12 |
| Dominic | no, it's a newer issue | 18:12 |
| cjwatson | sorry, I'll go back to what I was doing :-) | 18:12 |
| Dominic | the oddity is that I don't see it on Fedora, so trying to work out what's different | 18:12 |
| Daviey | Dominic: Hmm, how odd | 18:16 |
| Daviey | Dominic: I'll re-research it :) | 18:17 |
| Dominic | thanks :) | 18:17 |
| Daviey | ... if i wasn't on rubbish 3g. | 18:19 |
| doko | apw, ogasawara: any chance to fix the linux-3.0 build failure on armhf before the weekend? | 18:19 |
| Daviey | Dominic: http://lists.gnu.org/archive/html/bug-gnulib/2011-03/msg00308.html | 18:21 |
| Daviey | Dominic: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/817187 | 18:22 |
| ubottu | Launchpad bug 817187 in linux (Ubuntu Oneiric) "change in readlink() errno in 2.6.39 and later kernels causes FTBFS for packages with older gnulib" [Undecided,In progress] | 18:22 |
| Daviey | Dominic: The change moght have been reverted upstream, but seems apw might know more. | 18:23 |
| Dominic | Daviey: ah those thread are handy, thanks very much | 18:24 |
| Daviey | np | 18:25 |
| slangasek | sigh, why does submittodebian now prompt for a message body before checking the bts? | 18:53 |
| tumbleweed | slangasek: because people were sending bug reports without a body | 19:00 |
| tumbleweed | I didn't think of the "before checking the bts" bit | 19:00 |
| tumbleweed | I suppose that's best fixed by using --query-only before editing the report | 19:03 |
| slangasek | tumbleweed: well, it would still have the problem of wanting me to compose the message first and the subject last, and it opens the editor twice? | 19:04 |
| tumbleweed | the query doesn't require a subject | 19:05 |
| tumbleweed | and I can add an expert flag, if you don't want it to make you edit the report before calling reportbug | 19:06 |
| slangasek | why is this "expert"? | 19:08 |
| slangasek | the current workflow is backwards - you should check for existing bugs before composing a new one | 19:08 |
| tumbleweed | slangasek: that's easy to solve (doing it now) | 19:09 |
| tumbleweed | but we can't enforce the user replacing the "<<< EDIT HERE >>>" bit with something more useful, unless we open an editor outside of reportbug | 19:09 |
| broder | tumbleweed: you could...override $EDITOR to something of your own choosing :) | 19:10 |
| slangasek | eew | 19:11 |
| * tumbleweed think that'd actually work, though | 19:11 | |
| broder | something like ORIGINAL_EDITOR=$EDITOR EDITOR=/usr/lib/ubuntu-dev-tools/loop-until-user-writes-a-frickin-bug-report reportbug :) | 19:12 |
| tumbleweed | simply using --query-only before doing anything gets us most of the way there (and lets you check for existing reports before you edit the debdiff) | 19:14 |
| slangasek | broder: oh, so wrapping the editor, I see | 19:15 |
| slangasek | yeah, that would work | 19:15 |
| tumbleweed | yeah, even in reportbug's mutt mode | 19:16 |
| l3on | Hi all :) ... someone of you know why I cannot download some packages here (1) using grab-merge ? | 19:21 |
| l3on | http://qa.ubuntuwire.com/bugs/rcbugs/ | 19:21 |
| l3on | The output error is: | 19:21 |
| l3on | Package not found on merges.ubuntu.com. | 19:21 |
| l3on | So question is: why they are not in mu.com ? :) | 19:22 |
| l3on | *m.u.c | 19:22 |
| tumbleweed | they're possibly sync-blacklisted | 19:22 |
| tumbleweed | which packages? | 19:22 |
| l3on | calibre for example | 19:22 |
| micahg | l3on: we have no diff for it | 19:23 |
| tumbleweed | rcbugs is showing oneiric | 19:23 |
| micahg | there's a link for precise | 19:23 |
| tumbleweed | you want http://qa.ubuntuwire.com/bugs/rcbugs/precise | 19:23 |
| l3on | ahhh ok :) | 19:23 |
| l3on | thanks :P | 19:23 |
| micahg | l3on: by the way, I'm sure you're asking, but just want to remind you that touched-it-last rules apply for rc-bugs at this point in the cycle as well (even later, it usually good to get a quick ACK from someone in IRC if possible) | 19:24 |
| l3on | ok micahg :) | 19:25 |
| l3on | thanks for info... | 19:25 |
| l3on | brb | 19:25 |
| micahg | l3on: BTW, you've been doing a lot of good work lately, thanks! | 19:32 |
| tumbleweed | micahg: I see his security bug hasn't landed in Ubuntu yet (poke poke) | 19:33 |
| tumbleweed | slangasek, broder: Just committed the easy approach (not messing with EDITOR) to u-d-t trunk. Is that enough? | 19:34 |
| slangasek | tumbleweed: IMHO no, I'm also annoyed by having the editor opened twice to edit a single message :) | 19:38 |
| tumbleweed | hrm, how about EDITOR=true for reportbug | 19:38 |
| slangasek | still means drafting the message and setting the subject afterwards? Why is it hard to wrap the editor? | 19:40 |
| tumbleweed | it's not that hard, just extra effort (and needs to handle running out of . correctly) | 19:41 |
| tumbleweed | actually, trivial to pass the subject to reportbug | 19:43 |
| slangasek | and then how do you handle the case when you want to follow up to an existing bug and send a patch, instead of reporting a new one? | 19:45 |
| micahg | tumbleweed: Friday afternoon is an unlikely time for a security fix to get in, but I can try to have someone look at it on Monday | 19:45 |
| tumbleweed | micahg: I can't see the security bugs, anyway, so I don't know what the progress is, just idly prodding | 19:46 |
| micahg | ok :) | 19:46 |
| tumbleweed | slangasek: fair enough | 19:46 |
| broder | tumbleweed: for the record, i have no investment in this problem; i just occasionally enjoy seeing how crazy of an idea i can get somebody else to take seriously :) | 20:09 |
| === EvilJackyAlcine is now known as JackyAlcine | ||
| fetova | Hi! | 21:03 |
| fetova | I've proposed a branch for merging, but i just changed one line on a file, and the changelog adding my fix, but.. i see a lot of changes maded by the previous revision... | 21:03 |
| fetova | I want to ask: is that a problem? | 21:03 |
| fetova | The proposal: https://code.launchpad.net/~fetova/ubuntu/oneiric/app-install-data-ubuntu/fix-for-886680/+merge/84328 | 21:03 |
| cjwatson | fetova: looks like you branched from precise but proposed it for merging into oneiric | 21:04 |
| cjwatson | the branch you start from and the branch you propose for merging into should be the same | 21:04 |
| fetova | cjwatson: oh, i see... so i have another related question: | 21:06 |
| fetova | this bug might be on some ubuntu versions (i should investigate). | 21:07 |
| fetova | What branch i should get, and how i should submit this? cjwatson :) | 21:07 |
| infinity | fetova: If the bug exists in precise, you should get it fixed there first, and then propose SRUs to any previous releases that you think legitimately need the fix. | 21:09 |
| fetova | ok, i will :) | 21:10 |
| fetova | Now... how i propose SRU? (a wiki link is fine) | 21:10 |
| infinity | fetova: Also, I'm pretty sure that app-install-data is mostly just auto-generated from .desktop files yanked from packages (I could be wrong), so this perhaps needs to be fixed in dia-common as well. | 21:10 |
| cjwatson | the correct branch to start with would be lp:~ubuntu-core-dev/app-install-data-ubuntu/ubuntu, as indicated in the package's Vcs-Bzr field | 21:11 |
| infinity | fetova: And if it gets fixed in dia-common, that may just magically fix it the next time app-install-data is refreshed (you probably want to confirm this suspicion with mvo) | 21:11 |
| cjwatson | that's certainly true in lots of cases. there are a few artifacts that are just in a-i-d-u | 21:11 |
| === salem_ is now known as _salem | ||
| cjwatson | SRU> https://wiki.ubuntu.com/StableReleaseUpdates | 21:12 |
| fetova | i think the same, and i really want to see why dia-common.desktop points to dia-gnome... how can confirm the idea? | 21:13 |
| fetova | cjwatson: thanks, reading :) | 21:13 |
| mvo | fetova: this maybe a override in this particular case | 21:19 |
| mvo | fetova: hm, actually that looks like a bug in the extraction code, doing a SRU with that is a good idea, but it would be interessting to see if more apps are affected or if its just this one issue | 21:20 |
| fetova | mvo: im really interested on finding if your fear is right :) | 21:21 |
| fetova | eventually, i want to try MOTU, i hope not in far future, but i'm doing the baby steps :) | 21:22 |
| fetova | it's not the end of this story but i want to say thanks, infinity :) | 21:23 |
| mvo | fetova: please keep me updated on this, but I need to call it a day, its late in my timezone ! | 21:28 |
| * mvo waves | 21:28 | |
| fetova | ok! :) | 21:30 |
| tumbleweed | broder: well, slangasek persuaded me that it wasn't a terrible idea, so I did it :) | 21:42 |
| slangasek | \o/ :) | 21:42 |
| tumbleweed | bleh, now you gave me another bug | 21:43 |
| slangasek | minor one though :) | 21:43 |
| tumbleweed | still, the curse of green code | 21:44 |
| tumbleweed | doesn't actually seem to work with reportbug's mutt mode. But we can assume some sanity in mutt users ;P | 21:46 |
| slangasek | what doesn't work in mutt mode? | 21:48 |
| tumbleweed | doesn't look like mutt is using $EDITOR | 21:48 |
| slangasek | oh, really? | 21:48 |
| slangasek | maybe it's using $VISUAL? | 21:48 |
| slangasek | you probably ought to divert both | 21:48 |
| tumbleweed | sounds sensible | 21:48 |
| slangasek | then for the real editor invocation, you should do 'EDITOR=$real_editor_variable VISUAL=$real_visual_variable sensible-editor' | 21:50 |
| slangasek | (if that wasn't obvious) | 21:50 |
| tumbleweed | (it was) | 21:50 |
| === EvilJackyAlcine is now known as JackyAlcine | ||
| fetova | a cuestion: how is generated the menu-data-(date).tar.gz on http://rookery.canonical.com/~mvo/gnome-app-install/ ? | 22:38 |
| fetova | i should ask mvo? | 22:38 |
| === JackyAlcine is now known as tenahc | ||
| === tenahc is now known as tenach | ||
| === tenach is now known as JackyAlcine | ||
| broder | slangasek (or anyone): sorry, i lost track of my example package that's missing the dpkg-maintscript-helper pre-depends. anybody know of one that i could test my lintian code on? (grabbing the bianry from debian is fine) | 23:14 |
| broder | the only one i could find by searching precise-changes was asound and it doesn't actually need it | 23:14 |
| slangasek | broder: usb-modeswitch? | 23:15 |
| slangasek | (just doing a grep -l dpkg-maintscript-helper /var/lib/dpkg/info/*.prerm here) | 23:15 |
| slangasek | alternatively: nautilus, kbd, gnome-screensaver | 23:16 |
| broder | oh, sure. i guess i can just edit the control file easily enough | 23:17 |
| slangasek | oh, these all have the pre-dep in unstable? sorry :) | 23:18 |
| broder | i only checked one | 23:19 |
| broder | then realized that i had no reason to be afraid of dpkg-deb --build | 23:19 |
| slangasek | :) | 23:20 |
| === funkyHat_ is now known as funkyHat | ||
| broder | ok, i appear to have a functioning check | 23:25 |
| broder | i'm starting to become deeply concerned that maintaining lintian.uw.o will cause me to learn perl | 23:26 |
| slangasek | occupational hazard | 23:32 |
| JackyAlcine | lol | 23:33 |
| infinity | broder: What have you got against Perl? :P | 23:37 |
| broder | infinity: you almost got me, but i prefer to protect my so-far perfect record of not starting flame wars in #ubuntu-devel :-P | 23:38 |
| infinity | broder: Spoil sport. | 23:38 |
| === JackyAlcine is now known as Tenach_ | ||
| === Tenach_ is now known as tenach_ | ||
| === tenach_ is now known as JackyAlcine | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!