| === attente is now known as attente_zzz | ||
| hallyn | SpamapS: hey - looking at http://upstart.ubuntu.com/cookbook/#kill-signal , i'm not sure i'm reading it right. | 00:30 |
|---|---|---|
| hallyn | will it first send the signal specifid in 'kill signal', then wait 'kill timeout' seconds, then send sigterm? | 00:30 |
| hallyn | or does it wait 'kill timeout' seconds after pre-stop, then send the 'kill signal' signal then consider itself done? | 00:31 |
| * hallyn out - bbl | 00:39 | |
| achiang | is there someone available to review SRUs? | 00:40 |
| * RAOF is today's SRU victim. | 00:43 | |
| achiang | RAOF: better than fixing nux bugs! :) | 00:43 |
| achiang | RAOF: i believe cyphermox uploaded network-manager-gnome into precise-proposed for me, was wondering how to get someone to review it. (lp: #780602) | 00:44 |
| ubot93 | Launchpad bug 780602 in network-manager-applet (Ubuntu Precise) "nm-applet leaks memory and stops functioning after a while" [High,In progress] https://launchpad.net/bugs/780602 | 00:44 |
| RAOF | That seems pretty sub-optimal. | 00:45 |
| cyphermox | yup | 00:45 |
| achiang | RAOF: there are a bunch of other fixes that will need backporting to fully fix that one, nm-applet is just the first of several | 00:45 |
| RAOF | I'm currently wading through the compiz/unity stack SRUs in precise. I may not get to nm today. In which case, feel free to ping tomorrow's SRU vanguard, SpamapS ( https://wiki.ubuntu.com/StableReleaseUpdates#Publishing ) | 00:46 |
| achiang | RAOF: ah, ok. makes sense, thanks | 00:46 |
| troll` | Hi, I am looking for a development job | 00:53 |
| troll` | in Canonical/Ubuntu | 00:53 |
| === chilicuil_away is now known as chilicuil | ||
| cjwatson | Argh. I ended up as TIL for both emacs24 and xemacs21? This is some kind of penance, right? | 01:26 |
| sarnold | "TIL" == "touched it last" ? | 01:32 |
| lifeless | cjwatson: and for your next trick... | 01:33 |
| lifeless | sarnold: yes | 01:33 |
| sarnold | .. and thus The Expert? :) | 01:35 |
| cjwatson | The person who touched a package last is by default responsible for merging newer changes to it from Debian | 01:36 |
| cjwatson | i.e. you diverge, you get to eat the costs of divergence | 01:36 |
| sarnold | strong penalty for oddball packages.. | 01:36 |
| cjwatson | It really is touched-it-last though, not anything more sophisticated, so if like me you do lots of rebuild-only uploads for library transitions, you tend to get bitten a bit :) | 01:37 |
| cjwatson | sarnold: Penalty for not putting the effort in to make them less oddball, yes :) | 01:37 |
| cjwatson | Plus, you know, if they're that odd then maybe they do actually need an expert to merge them | 01:38 |
| lifeless | cjwatson: penalty for not teaching TIL to be smarter. | 01:38 |
| * sarnold fears for whoever touched hardy and lucid perl, those have been eating my brain for the last week now :/ | 01:38 | |
| cjwatson | We don't do merges in stable releases | 01:38 |
| cjwatson | lifeless: Or that | 01:39 |
| lifeless | cjwatson: maybe this is your incentive ;) | 01:39 |
| cjwatson | (I'm used to it, complaints are non-serious) | 01:39 |
| cjwatson | lifeless: I'm not sure it would save enough time over my working life :) | 01:40 |
| micahg | stgraber: ah, right | 01:43 |
| lifeless | cjwatson: clearly you need to work longer hours for more years | 01:47 |
| === fisted_ is now known as fisted | ||
| === jasoncwarner_ is now known as jasoncwarner | ||
| === fisted_ is now known as fisted | ||
| robertzaccour | My new laptop's wireless card doesn't work in Ubuntu its a Realtek RT8723AE any suggestions? | 04:07 |
| robertzaccour | Also I can't connect to the internet when wired neither. | 04:08 |
| tjaalton | ideas how to disable the braindead sbuild default to put the link to the build logs to $PWD? | 05:40 |
| tjaalton | didn't have it on 12.04 | 05:40 |
| robertzaccour | My wireless and wired internet don't work in Ubuntu. My wireless card is a Realtek RT8723AE | 05:41 |
| robertzaccour | any suggestions? | 05:41 |
| === doko_ is now known as doko | ||
| RAOF | tjaalton: I believe there's a build log location variable in ~/.sbuildrc | 05:48 |
| RAOF | tjaalton: man sbuild.conf - LOG_DIR is what you're after. | 05:50 |
| tjaalton | RAOF: I had both set for 12.04, now it broke with 12.10 | 05:50 |
| RAOF | Fair enough. I didn't set that last time I rebuilt, so I didn't notice. | 05:51 |
| tjaalton | also, the logs do go there, just that the symlink used to go to $build_dir | 05:51 |
| tjaalton | and $build_dir is "deprecated", but no idea what replaces it | 05:53 |
| tjaalton | guess it's just a bug then | 05:53 |
| pitti | Good morning | 05:54 |
| pitti | meh, the SRU queues are really long | 05:54 |
| * pitti rejects mvo's pygobject upload, I already uploaded that fix two weeks ago | 05:54 | |
| pitti | slangasek, ev: I cannot participate in the sprint prep meeting at 1700 UTC; earlier works | 06:01 |
| pitti | or tomorrow | 06:01 |
| pitti | apw, infinity: bah, https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-proposed-adt-linux/3/ARCH=amd64,label=albali/ | 06:18 |
| pitti | apw, infinity: it's again that "apt-get source linux does not download linux" trap/bug/misfeature | 06:18 |
| tjaalton | since debhelper compat v9 uses multiarch path for libexecdir, it's ok to install support binaries under <triplet>/<pkgname>? the debian policy is a bit vague about it, only talks about /usr/lib/<pkgname> | 06:19 |
| === chilicuil is now known as chilicuil_away | ||
| infinity | pitti: You want --only-source on that commandline. | 06:28 |
| pitti | infinity: ah, thanks; I was just committing -o APT::Get::Only-Source=yes | 06:29 |
| pitti | but that's easier | 06:29 |
| infinity | pitti: Apparently, appending exact versions also forces only-source mode. | 06:30 |
| infinity | pitti: And if you're autotesting based on specific versions, maybe you want that anyway? | 06:30 |
| pitti | we don't currently pass a version | 06:30 |
| infinity | (ie: apt-get source linux=3.7.0-4.12) | 06:30 |
| pitti | but yeah, this behaviour is irritating | 06:30 |
| infinity | You're not currently passing versions, but we probably want to if we're tying (some of) this into proposed migration. | 06:31 |
| infinity | Since we want to know we're testing the right thing. :P | 06:31 |
| infinity | Oh, though this is for rdep testing, I guess, which is different. | 06:31 |
| infinity | pitti: The behaviour is wildly unintuitive to developers who think in terms of source packages, but the inverse is true for people who want "apt-get source libc6" to work, so... | 06:32 |
| infinity | pitti: I think we just need to live with typing --only-source occasionally. :P | 06:33 |
| pitti | mappign binaries to source packages does not require to prefer the binary packages' source | 06:33 |
| pitti | yeah, but I need it so seldomly that I keep forgetting about it | 06:33 |
| infinity | pitti: It's unintiutively broken either way. Either it doesn't always get the binary's source, or it doesn't always fetch the source you thought it would. I'm not sure there's a right answer at this point. | 06:34 |
| infinity | (There may have been a right answer 10 years ago, but now the behaviour's a bit set in stone) | 06:34 |
| infinity | And I'd argue the right answer 10 years ago would have been to try source names first, then binary mapping, without a --map-binary option, but whatever. | 06:35 |
| didrocks | pitti: hey, due to the default score of the ubuntu-unity ppa behind lower than distro, and the powerpc pb, even the build started 30 hours ago are still not in. So no automated upload :/ Can you please bump the score for today's upload so that it doesn't happen again? | 06:35 |
| didrocks | only for now: | 06:35 |
| didrocks | https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4017572 | 06:35 |
| didrocks | https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4017828 | 06:35 |
| didrocks | https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4018003 | 06:36 |
| didrocks | https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/4018013 | 06:36 |
| didrocks | and that's it :) | 06:36 |
| infinity | didrocks: Is it world ending if it doesn't get in right away? | 06:36 |
| pitti | didrocks: done | 06:36 |
| pitti | yeah, with one buildd being out and the other building libo there's not much capacity left | 06:36 |
| * infinity isn't entirely sure why a daily build would need priority... | 06:36 | |
| didrocks | infinity: well, we start to have daily landing and trying to check everything does work indeed. It's been 2 days that my uploads are piling up | 06:36 |
| didrocks | thanks pitti | 06:36 |
| pitti | 63 jobs (9 hours 40 minutes) | 06:36 |
| didrocks | infinity: so I think at least, they should have the same score than distro has | 06:37 |
| infinity | Err, we plan to land unity in the distro daily? Really? | 06:37 |
| infinity | Maybe I should have attended this meeting. :P | 06:37 |
| didrocks | infinity: from yesterday, it started with "start in 8 hours" and was never released | 06:37 |
| didrocks | infinity: yeah | 06:37 |
| infinity | This seems like a strange step backward from when we were previously asking people to not do daily builds. | 06:39 |
| infinity | Now we've just decided that "oh, it's okay, cause we're doing daily build to push them to the archive"? | 06:39 |
| didrocks | pitti: did you for overlay-scrollbar and notify-osd? I didn't see the bumping | 06:39 |
| pitti | didrocks: ah, sorry | 06:39 |
| didrocks | infinity: no, there is an autopilot step before to validate | 06:39 |
| infinity | didrocks: That doesn't address the resource usage... | 06:40 |
| didrocks | infinity: it does, this will remove the commit-build staging ppa | 06:40 |
| infinity | s/remove/replace/ | 06:41 |
| didrocks | thanks pitti :) | 06:41 |
| infinity | A daily build is a daily build... | 06:41 |
| didrocks | infinity: the other is per commit | 06:41 |
| didrocks | not per day | 06:41 |
| pitti | didrocks: was that also a devirt PPA? i. e. with powerpc | 06:41 |
| didrocks | so no a commit build != daily build | 06:41 |
| didrocks | pitti: it was, but powerpc was blacklisted | 06:42 |
| pitti | didrocks: ah, I was wondering how you did not fall into the powerpc bottleneck with that | 06:42 |
| didrocks | pitti: we did at start, but then, removed it :) | 06:42 |
| infinity | *sigh* | 06:43 |
| infinity | There are so many things about this I don't like. | 06:43 |
| infinity | Automated testing can't check the diff against the previous version before upload to see that it's sane. | 06:43 |
| didrocks | infinity: the UDS session was a good start to attend | 06:43 |
| infinity | Nor can an automated uploader. | 06:43 |
| infinity | didrocks: I was double/triple booked all week. | 06:43 |
| infinity | didrocks: I *was*, however, at the buildd usage session, where this didn't come up. :P | 06:43 |
| infinity | Besides, "it passes the test suite" is not actually an indicator that it's ready for release. | 06:44 |
| * didrocks would like to avoid reiterate again all the discussion we had at UDS… | 06:44 | |
| didrocks | infinity: we have 400 tests per config | 06:45 |
| didrocks | for autopilot, most of them being integration tests | 06:45 |
| infinity | And if someone's in the middle of landing a new feature that lacks test coverage? | 06:45 |
| didrocks | infinity: first, this will be reverted | 06:45 |
| didrocks | infinity: second, distro is looking at all merges | 06:46 |
| didrocks | infinity: third, PS agreed that shouldn't happen and we have explicit rules/people to contact in PS if it happens | 06:46 |
| infinity | If there's human auditing, then why use automated uploading? | 06:46 |
| didrocks | infinity: it's an audit, not doing the heavy lifting everyday | 06:46 |
| infinity | (There's still no auditing of the source package itself) | 06:46 |
| didrocks | infinity: you should try to do unity at some point | 06:47 |
| infinity | But, ultimately, I can come up with reasons I think it's a lousy idea all day, and you'll just say "let's not discuss this again, even if it's your job to do so". | 06:47 |
| didrocks | we'll see if you can audit the whole stack, 60+ packages alone :) | 06:47 |
| infinity | So, whatever. | 06:47 |
| infinity | Ultimately, I don't think we ship a single piece of software that actually needs to build/update every day. | 06:47 |
| didrocks | and maybe you will have another view of "I have time to review every line changed in a new upstream version" | 06:47 |
| infinity | Auditing source uploads doesn't imply necessarily reading every single line. | 06:48 |
| didrocks | infinity: I have nothing against discussion, but reiterating the whole process explanation every time someone not at the session is a little bit a waste of time | 06:48 |
| infinity | It does mean checking the diff against the previous version uploaded. | 06:48 |
| didrocks | infinity: this is what we do pro-actively looking at upstream merge request | 06:48 |
| infinity | didrocks: Yes, discussion is a waste of time, I'm arguing that the current state of affairs is a misallocatoin of resources. So, a different waste of time. | 06:49 |
| infinity | didrocks: Reviewing merges is not reviewing the source that gets uploaded. | 06:49 |
| * infinity should go to bed instead. | 06:49 | |
| didrocks | infinity: it's juts about reviewing the changes in a more manageable manner | 06:49 |
| doko | didrocks, pitti: definitely the buildd session was the place to mention this. it's no good to just use resources without announcing this ... | 06:53 |
| didrocks | doko: it was announced before, the session was in conflict with other settle by fundations where I was required | 06:54 |
| didrocks | doko: and again we trade a commit-build ppa for a daily-build one | 06:54 |
| didrocks | so I see that more as a resource gain as hilighted in the session | 06:54 |
| doko | that's your view | 06:54 |
| infinity | didrocks: Unless no one ever committed to unity before, it can't have actually been commit level. | 06:54 |
| infinity | didrocks: Cause it didn't trigger 30 builds per day or anything. | 06:55 |
| doko | didrocks, I didn't see it in the whiteboard for the session either | 06:55 |
| didrocks | infinity: https://launchpad.net/~unity-team/+archive/staging/+packages?field.name_filter=unity&field.status_filter=&field.series_filter=quantal | 06:56 |
| didrocks | infinity: look at unity | 06:56 |
| didrocks | unity - 6.12.0bzr2935pkg0quantal0 | 06:57 |
| didrocks | rev 2935 | 06:57 |
| didrocks | unity - 6.12.0bzr2934pkg0quantal0 | 06:57 |
| didrocks | rev 2934 | 06:57 |
| didrocks | unity - 6.12.0bzr2933pkg0quantal0 | 06:57 |
| didrocks | rev 2933 | 06:57 |
| didrocks | … | 06:57 |
| didrocks | I put it in place, I know what is pushed to the ppa | 06:57 |
| infinity | Fair enough. | 06:58 |
| infinity | Of course, there are also large spans there between uploads sometimes. | 06:59 |
| pitti | well, it is what it is; it doesn't seem fruitful to argue about it now | 07:00 |
| didrocks | infinity: yeah, most of PS is working on other things than unity these days, you can look back at quantal/precise release cycle and you will see a high commit activity (~15 per day for unity alone) | 07:00 |
| infinity | pitti: Hrm? Is this some sort of "nothing changes once a solution is implemented, nyah nyah"? :P | 07:01 |
| pitti | if ppc keeps being a bottleneck for this, the answer cannot be to ask developers to upload less really | 07:01 |
| infinity | pitti: If the kubuntu guys uploaded KDE daily snapshots every day, we'd just drop their entire packageset and tell them to find another distro. | 07:01 |
| infinity | pitti: I realise that PS/unity get to be unique snowflakes here, to a point, but I don't actually see the value in daily snapshot uploads. | 07:02 |
| pitti | infinity: that's not a canonical project; if they would pay for the extra resources.. | 07:02 |
| infinity | A real human can say "yeah, a bunch of stuff has been fixed and some new features have landed, let's upload" once or twice a week, at most, I'm sure. | 07:02 |
| infinity | pitti: Excellent. If Canonical would pay for resources for unity daily builds, I'd be fine with it. :) | 07:02 |
| * pitti didn't really intend to get pulled into this, and goes back to other stuff | 07:02 | |
| pitti | infinity: (C does, and nobody else does..) | 07:03 |
| pitti | cjwatson: ok, all rdepends of pygobject check out now and are green; can you please remove the britney block? | 07:15 |
| pitti | cjwatson: thanks again for setting it, it was helpful; and also a nice trial run what would happen once that's automatic | 07:15 |
| infinity | pitti: I can kill the block. | 07:16 |
| pitti | infinity: ah, thank you | 07:16 |
| infinity | pitti: Done. | 07:16 |
| * pitti sticks fingers in ears and closes eyes while it lands | 07:17 | |
| dholbach | good morning | 07:20 |
| pitti | hey dholbach | 07:20 |
| dholbach | hi pitti | 07:20 |
| didrocks | hey dholbach | 07:22 |
| dholbach | salut didrocks | 07:22 |
| dholbach | do we have some more folks interested in signing up for https://wiki.ubuntu.com/UbuntuDeveloperWeek? | 07:25 |
| pitti | infinity: on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, the bits without "Section:" are main, or is Section: only shown sometimes for other reasons? | 07:26 |
| infinity | pitti: No section would mean main, yeah. Not the most intuitive way to display it, I suppose. | 07:27 |
| pitti | good to know, thanks | 07:27 |
| === Logan_ is now known as Guest76402 | ||
| === Logan__ is now known as Logan_ | ||
| === smb` is now known as smb | ||
| zyga | good morning | 08:51 |
| === pitti is now known as universal_tb_pri | ||
| === universal_tb_pri is now known as pitti | ||
| === stan_ is now known as stan | ||
| === yofel_ is now known as yofel | ||
| === Tonio_ is now known as Tonio_aw | ||
| === Sweetsha1k is now known as Sweetshark | ||
| Sweetshark | bdrung: I agree with infinity -- no separate SRU for bug 585910. And for quantal 3.6.4rc2 has been tagged yesterday and was build locally containing the fix: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/585910/comments/50 | 09:47 |
| ubot93 | Launchpad bug 585910 in libreoffice (Ubuntu Quantal) "[Upstream] Impress Font fuzzy in presentation mode when Use hardware acceleration enabled" [Undecided,Triaged] | 09:47 |
| === mcclurmc_away is now known as mcclurmc | ||
| OdyX | SpamapS: php5 got uploaded as 5.4.9-1 to experimental fixing the orig.tar | 10:13 |
| didrocks | pitti: can you please reject https://code.launchpad.net/~vanvugt/ubuntu/quantal/compiz/upstream-expo-patch-quantal/+merge/136606? (the change is not SRUable) | 10:21 |
| pitti | didrocks: done | 10:22 |
| didrocks | thanks :) | 10:22 |
| bdrung | Sweetshark: why an rc version? | 10:36 |
| Sweetshark | bdrung: rc2 will most likely be final. hasnt declared as such though. | 10:55 |
| zyga | cjohnston: hi | 11:09 |
| zyga | cjohnston: sorry, wrong tab complete | 11:09 |
| zyga | cjwatson: hi | 11:09 |
| zyga | cjwatson: I'm interested in netbooting a uefi machine for hardware certification | 11:10 |
| zyga | cjwatson: I have some interesting material on the wiki (https://wiki.ubuntu.com/UEFI/PXE-netboot-install) | 11:11 |
| zyga | cjwatson: I wanted to ask if there is anything new in that area that is not on the wiki there and what is the secure boot story | 11:11 |
| cjwatson | tjaalton: It's a bug, and fixed in sbuild 0.63.2-1 | 11:13 |
| cjwatson | zyga: UEFI netbooting is known-broken right now due to a GRUB tftp handling bug, which slangasek has promised to distil down to a test case that I can debug | 11:14 |
| tjaalton | cjwatson: ah, thanks | 11:14 |
| cjwatson | zyga: in principle it ought to work with SB once that's fixed | 11:14 |
| zyga | cjwatson: ok, so I'll resort to non-secure path for now | 11:14 |
| cjwatson | zyga: provided that you do *not* generate your own GRUB image, but use the signed one | 11:15 |
| zyga | cjwatson: I don't own any uefi hardawre, can I perform experiments on this with any simulation or virtualization tools to get a feel of it? | 11:15 |
| cjwatson | (i.e. the procedure in the wiki page will never work with SB) | 11:15 |
| cjwatson | zyga: google OVMF | 11:15 |
| zyga | ok | 11:15 |
| zyga | thanks a lot :) | 11:15 |
| zyga | yay | 11:15 |
| cjwatson | zyga: you can build it with -D SECURE_BOOT_ENABLE (or possibly -D SECURE_BOOT_ENABLE=1, I forget) to add key handling support | 11:15 |
| zyga | you just saved me a lot of time reading the web :) | 11:15 |
| cjwatson | zyga: there's a PDF on the signing bits linked off http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF | 11:17 |
| zyga | cjwatson: my goal is not to dive too deep into the secure parts, just to see how uefi affects certification labs and our netbooting process | 11:17 |
| zyga | cjwatson: I'm actually tying to see if we can still pass a kernel command line the same way we did before | 11:18 |
| zyga | cjwatson: but since I'm not strong or either uefi or netboot in general I need to get some experience with just playing around with this | 11:18 |
| cjwatson | I don't know how you pass the command line right now | 11:20 |
| === _salem is now known as salem_ | ||
| === chilicuil is now known as chilicuil_away | ||
| ximion | hi! does something in Ubuntu change the GIO/GVfs settings for applications which are running as root? | 12:15 |
| ximion | my program needs to run as root and downloads some files via HTTP, but only the "file" GIO module is loaded | 12:16 |
| ximion | when running not as root, GVfs supports all mimes | 12:16 |
| cjwatson | mdeslaur: Would you care to merge sbuild from unstable? You're TIL, and it has a useful bug-fix to the log file location. | 12:17 |
| mdeslaur | cjwatson: sure, I'll try and do it today | 12:18 |
| zyga | cjwatson: I'm not entirely sure, that part of certification is incredibly dusty, we seem to use debian-installer and casper | 12:19 |
| zyga | cjwatson: I'm experimenting with qemu and tiano core so that part is good | 12:19 |
| cjwatson | zyga: I believe you pass a command line to d-i/casper in some way | 12:19 |
| cjwatson | possibly pxelinux append or something? | 12:19 |
| cjwatson | mdeslaur: thanks | 12:19 |
| zyga | cjwatson: yes, I'm just unfamiliar with all the tools so my answers are not precise | 12:24 |
| === amitk is now known as amitk-afk | ||
| === cpg is now known as cpg|away | ||
| === attente_zzz is now known as attente | ||
| === Tonio_aw is now known as Tonio_ | ||
| psivaa | i just reported a bug in network manager, bug 1084064. is this the right channel to indicate? | 13:28 |
| ubot93 | Launchpad bug 1084064 in network-manager (Ubuntu) "Can not ssh to raring VM's using hostname" [High,Confirmed] https://launchpad.net/bugs/1084064 | 13:28 |
| OdyX | psivaa: the people that need to know get notifications or mails automatically. | 13:32 |
| psivaa | OdyX: this bug is blocking the desktop testing, so it's kind of urgent | 13:34 |
| psivaa | s/the/our | 13:34 |
| cjwatson | cyphermox: ^- | 13:37 |
| cyphermox | cjwatson: thanks | 13:38 |
| OdyX | mdeslaur: that cups security bug is so depressing . | 14:10 |
| mdeslaur | OdyX: yes, it's never ending :( | 14:10 |
| mdeslaur | OdyX: ConfigFilePerm is pretty neat :) | 14:10 |
| OdyX | mdeslaur: I pointed out DocumentRoot too. Just set it to /etc/ or even / and you can read the whole system. :( | 14:11 |
| OdyX | mdeslaur: did you see the changes I pushed to git's master branch ? | 14:11 |
| mdeslaur | OdyX: no, one sec, I'll take a look | 14:11 |
| OdyX | http://anonscm.debian.org/gitweb/?p=pkg-cups/cups.git;a=shortlog;h=refs/heads/master <- mdeslaur | 14:11 |
| seb128 | hallyn, hey, seems like your ppa qemu-linaro upload failed but not due to the spice on 32b change? | 14:16 |
| mdeslaur | OdyX: this is going to be complicated for stable releases | 14:16 |
| OdyX | mdeslaur: yes. But as cupsd.conf is modified by users through a web interface, I don't really see another way forward that keeps their modification. Moving configuration stanzas around in the postinst before server restart would work but would be a hell to manage. | 14:17 |
| OdyX | mdeslaur: with my preinst, someone with clean pre-files-split would not get a prompt on upgrade. | 14:18 |
| OdyX | mdeslaur: moving to ucf has the advantage of easing such changes in the future afaIui | 14:19 |
| hallyn | seb128: yup, i can't quite figure out what's wrong | 14:19 |
| hallyn | do packages using python in raring now need to add python-minimal to build-deps or something? | 14:19 |
| cjwatson | Generally python rather than python-minimal, but yes | 14:19 |
| mdeslaur | OdyX: are you planning on simply dropping the config items that moved to the new config file? I wouldn't think they would be used very much on debian/ubuntu anyway... | 14:20 |
| seb128 | hallyn, btw is it ok if I backport http://libvirt.org/git/?p=libvirt.git;a=patch;h=efe6c8021146d046846ead5b5efc9828d97c1ceb ? | 14:20 |
| seb128 | hallyn, that should fix "virsh -c qemu:///session" (or gnome-boxes) being broken in quantal | 14:21 |
| hallyn | cjwatson: i see. it was pulled out of essential? | 14:21 |
| seb128 | hallyn, that issue is fixed in 1.0 already in raring | 14:21 |
| cjwatson | hallyn: Yes | 14:21 |
| OdyX | mdeslaur: the preinst only drops it if it is unmodified | 14:21 |
| cjwatson | hallyn: Ultimately we don't want to have Python 2 on images, and this was incompatible with python-minimal being Essential | 14:21 |
| hallyn | seb128: no objection from me on that, thanks | 14:21 |
| hallyn | seb128: is that for raring only? | 14:21 |
| cjwatson | Plus we hardly ever truly relied on it being Essential anyway, due to the structure of Python policy | 14:22 |
| mdeslaur | OdyX: right, but you aren't planning on attempting to move them yourself to the new file, are you? | 14:22 |
| seb128 | hallyn, no, quantal only, raring has it fixed (the patch is in libvirt 1.0) | 14:22 |
| hallyn | cjwatson: ok, thanks. i didn't want to blindly add that without making sure i wasn't papering over something | 14:22 |
| hallyn | seb128: cool. ok. lemme try another ppa build and then push qemu-linaro hopefully to r | 14:22 |
| seb128 | hallyn, excellent, I start a local build but it's running for over an hour, I start regretting it :p | 14:23 |
| seb128 | start->started | 14:23 |
| OdyX | mdeslaur: I'm thinking about fiddling with cups-files.conf in postinst to move stanzas from cupsd.conf to cups-files.conf . | 14:23 |
| seb128 | hallyn, I might just wait on your new ppa upload ;-) | 14:23 |
| hallyn | seb128: so this gnome-boxes thing is pretty cool? | 14:23 |
| OdyX | mdeslaur: the thing is that's probably not acceptable for Debian stable. disabling the whole webinterface is probably the only thing we would do. | 14:24 |
| seb128 | hallyn, I don't know but it looks nice, that's why I want to try it | 14:24 |
| OdyX | mdeslaur: that, or as pitti says, change uid to access files, for logfiles and webinterface. | 14:24 |
| seb128 | hallyn, it's the GNOME ui to deal with vms | 14:24 |
| seb128 | hallyn, http://blogs.gnome.org/mclasen/2012/09/07/a-look-at-gnome-boxes/ | 14:24 |
| mdeslaur | OdyX: it's more complicated than that...the cupsd daemon accept PUT requests for config files from the command line | 14:24 |
| cjwatson | hallyn: It's actually non-Essential in quantal, but it took us a while to remember to pull it out of buildd chroots | 14:24 |
| mdeslaur | OdyX: the web interface is just a little part of the ways to modify cupsd.conf | 14:25 |
| OdyX | mdeslaur: ah yeah, shit. | 14:25 |
| === amitk-afk is now known as amitk | ||
| hallyn | cjwatson: i notice you just uploaded a new libcap2. looking at bug 1084000, is the answer there to just copy in the capabilities.h from the kernel, or can we add linux-libc-dev to build-deps and not have libcap2 use its own file? | 15:09 |
| ubot93 | Launchpad bug 1084000 in libcap2 (Ubuntu) "libcap2: List of capabilities not in sync with the linux kernel" [Undecided,Confirmed] https://launchpad.net/bugs/1084000 | 15:09 |
| cjwatson | hallyn: Don't know anything about it, I'm afraid - I was just doing a monkey-see-monkey-do merge | 15:10 |
| cjwatson | linux-libc-dev is build-essential | 15:10 |
| cjwatson | adding it to build-deps will be a no-op ... | 15:10 |
| cjwatson | linux-libc-dev doesn't seem to have a capabilities.h, so perhaps you should indeed update libcap2's copy | 15:11 |
| hallyn | cjwatson: apt-cache tells me Priority: optional | 15:12 |
| hallyn | am i looking at the wrong thing? | 15:13 |
| cjwatson | hallyn: "Build-Essential: yes" | 15:13 |
| hallyn | dpkg -S tells me /usr/include/linux/capabilities.h came from linux-libc-dev though | 15:14 |
| cjwatson | hallyn: But, more to the point, you can't compile even a trivial hello.c without linux-libc-dev | 15:14 |
| cjwatson | Since libc6-dev depends on it | 15:14 |
| hallyn | ok | 15:14 |
| hallyn | my feeling was that copying in a new file just begs getting out ofsy nc again. seems like it should come straight from kernel source. but if that's the way, i'll copy in the new file... | 15:15 |
| hallyn | cjwatson: thanks | 15:15 |
| cjwatson | wait a sec | 15:15 |
| cjwatson | do you mean linux/capability.h? | 15:15 |
| cjwatson | yes, looks like you do | 15:16 |
| cjwatson | ok, so one reasonable approach might be to convince libcap2 to stop using its internal copies of the relevant headers in favour of the system ones | 15:17 |
| cjwatson | if you do that, you should confirm a couple of things: | 15:17 |
| cjwatson | * that it doesn't have any local patches applied to those headers | 15:17 |
| cjwatson | * that using the headers associated with a newer kernel doesn't e.g. cause the corresponding binaries to explode when run on top of an older kernel (such as is in use on the buildds) | 15:18 |
| cjwatson | you'll have to modify its build system though - it's not a matter of adding a build-dep | 15:18 |
| hallyn | i'll write the upstream author. | 15:19 |
| cjwatson | sometimes the path of least resistance is just to update the local copy, since it's not like kernel APIs are supposed to change *that* often | 15:19 |
| hallyn | i'd rather get the new version upstream first and take it from there than to reproduce myself | 15:19 |
| cjwatson | and from an upstream point of view, not all distros package them properly for userspace use | 15:19 |
| * cjwatson nods | 15:19 | |
| hallyn | thanks, ttyl | 15:20 |
| slangasek | pitti: figured you probably wouldn't make that meeting, don't worry about it; it's mostly for giving the other two their marching orders ;) | 15:31 |
| pitti | slangasek: ack :) | 15:32 |
| stgraber | jodh, barry: http://paste.ubuntu.com/1394693/ <- am I missing something? output appears identical under python2.7 and python3.3 with that change | 15:42 |
| barry | stgraber: http://docs.python.org/3/library/subprocess.html#frequently-used-arguments | 15:43 |
| mitya57 | barry, thanks for sponsoring :) | 15:44 |
| jodh | stgraber: 2to3 expects further changes - like removing has_key() and 'b' prefix for re.match strings. | 15:44 |
| barry | mitya57: np. just doing last few local tests before uploading | 15:44 |
| cjwatson | re.match doesn't have to take a byte string as the pattern - it should only do that if the string you're matching is also bytes | 15:45 |
| mitya57 | ok. by the way, do you know if "make unittests" is supposed to do anything? it doesn't work for me... | 15:45 |
| cjwatson | right, so in this case universal_newlines=True would mean that re.match would be operating on Unicode and you *don't* want a b prefix | 15:46 |
| stgraber | barry: yeah, was wondering if it really was that simple to port to python3 as the missing universal_newlines and the string.split were the only obvious issues. I still plan to do a PEP-8 pass afterwards and then look at whatever 2to3 complains about. But based on what I heard on mumble, I expect it to be significantly trickier | 15:46 |
| barry | stgraber: if you want to take point on that issue, that's cool with me (though please assign it to yourself). i'm happy to review, test, consult | 15:47 |
| ogra_ | slangasek, are you aware of any rotation support in plymouth (despite doing a rotated theme) ? it always comes up in portrait on the nexus7 here | 15:49 |
| cjwatson | seb128: do you suppose somebody desktopy might be able to take over the libgksu merge from me? I'm TIL due to a no-change rebuild upload I did, but it has a huge pile of patches | 15:49 |
| ogra_ | (the tty is rotated on kernel level at initialization time) | 15:49 |
| cjwatson | and I'm not too sure I can merge it competently | 15:49 |
| seb128 | cjwatson, I can do it yes | 15:49 |
| cjwatson | lovely, thanks | 15:49 |
| slangasek | seb128: fwiw I'm rejecting your appmenu-gtk precise SRU for bug #1077095 because it crossed mid-flight with a series of SRUs for bug #932860; can you rebase and re-upload? | 15:50 |
| ubot93 | Launchpad bug 1077095 in appmenu-gtk (Ubuntu Quantal) "Please blacklist "IBM Notes"" [Low,In progress] https://launchpad.net/bugs/1077095 | 15:50 |
| ubot93 | Launchpad bug 932860 in appmenu-gtk (Ubuntu Quantal) "Broken (or missing) multiarch support" [High,In progress] https://launchpad.net/bugs/932860 | 15:50 |
| cjwatson | if you have any foundationsy merges you want to inflict on me, I'm happy to swap :) | 15:50 |
| stgraber | barry: ok, will do. Should be pretty easy as I've been doing a fair bit of that lately :) | 15:51 |
| slangasek | ogra_: plymouth didn't do any rotation last I looked, no | 15:51 |
| ogra_ | hmm, k | 15:51 |
| barry | stgraber: awesome! feel free to take on xapian next <wink> | 15:51 |
| ogra_ | i wonder why it doesnt pick it up from the console though | 15:51 |
| stgraber | barry: hehe, you can keep that one, I don't want to steal all your work ;) | 15:52 |
| * barry mumbles curses under his breath | 15:52 | |
| mitya57 | barry: oops | 15:52 |
| mitya57 | missing b-d I guess | 15:52 |
| barry | mitya57: uh oh | 15:52 |
| barry | mitya57: what? | 15:53 |
| seb128 | cjwatson, yw | 15:53 |
| seb128 | slangasek, ok, will do, thanks | 15:53 |
| mitya57 | barry: https://launchpadlibrarian.net/124325279/buildlog_ubuntu-raring-amd64.python-defaults_2.7.3-3ubuntu1_FAILEDTOBUILD.txt.gz | 15:53 |
| cjwatson | oh, blast, I think I need an ubuntu-meta upload to get a signed kernel onto 12.04 images | 15:53 |
| barry | mitya57: how odd. i wonder if my source chroot already has that installed or something | 15:54 |
| mitya57 | I'm sure it was building in chroot when I tried it, but it was a month ago or so | 15:54 |
| seb128 | cjwatson, thanks for the offer but I don't see anything foundationish on my TIL list atm so I think I'm good ;-) | 15:54 |
| barry | mitya57: i *just* built it in an updated raring chroot, successfully | 15:54 |
| barry | mitya57: huh. yeah, my sbuild definitely found rst2man :/ | 15:56 |
| DX099 | hello | 15:56 |
| DX099 | is someone here responsible for "Privacy" settings ? | 15:56 |
| mitya57 | barry: python-docutils *is* in build-depends | 15:57 |
| mitya57 | but it does some postinst trick to add /usr/bin/rst2* links, maybe that didn't work? | 15:57 |
| tumbleweed | barry: it built on i386, so presumably you need to do a -B build | 15:58 |
| barry | mitya57: look higher up: | 15:58 |
| barry | /bin/bash: lsb_release: command not found | 15:58 |
| mitya57 | what is -B? | 15:58 |
| mitya57 | ah, dpkg-buildpackage -B? | 15:59 |
| barry | which i think is the default for sbuild | 16:00 |
| cjwatson | Normally, yes; -A/--arch-all and --no-arch-all change this | 16:02 |
| === Tonio_ is now known as Tonio_aw | ||
| mitya57 | barry: so I don't need to do anything, right? | 16:03 |
| barry | mitya57: not yet ;) | 16:04 |
| * barry reproduces the failure with --no-arch-all | 16:04 | |
| barry | mitya57: i'll come back to this after the meeting, though if you want to keep working on it in the meantime, i won't complain :) | 16:05 |
| cjwatson | you might have $build_arch_all = 1; in .sbuildrc or something | 16:05 |
| mitya57 | barry: the only thing I can do is a new changelog entry, what else? | 16:06 |
| barry | cjwatson: indeed, i do | 16:06 |
| * mitya57 prefers pbuilder, it built here without any configuration change | 16:07 | |
| === fisted_ is now known as fisted | ||
| barry | cjwatson: `sbuild --arch-all tox_1.4.2-1.dsc` succeeds in a raring chroot. then there's this: https://launchpad.net/ubuntu/raring/+source/python-tox/+builds?build_state=all | 16:21 |
| cjwatson | I'm not going to debug LP at the same time :) | 16:22 |
| cjwatson | Trying here - it may well depend on your chroot | 16:22 |
| barry | :) | 16:22 |
| cjwatson | oh, "python-tox" is not a source package | 16:23 |
| cjwatson | s/python-tox/tox/ there | 16:23 |
| barry | d'oh | 16:23 |
| barry | ew | 16:24 |
| cjwatson | oh my, I just noticed why it works for you | 16:24 |
| cjwatson | there is some insanity here that downloads dependencies from the network if they aren't already installed | 16:24 |
| mitya57 | dholbach, did you notice that external links work now? now it's your turn to enable es translation :) | 16:24 |
| cjwatson | firewall off pypi.python.org or some such and you should see the same thing | 16:25 |
| barry | cjwatson: yep. that's icky | 16:25 |
| dholbach | mitya57, we might have to backport sphinx in our ppa | 16:25 |
| barry | i'm sure there's some magical setup to prevent sbuild chroots from doing that | 16:25 |
| cjwatson | something involving lxc | 16:25 |
| mitya57 | dholbach: should I do it (thanks for sponsoring btw)? | 16:25 |
| barry | cjwatson: yeah. it's bitten me before. oh well. better to fix that in debian first | 16:26 |
| dholbach | mitya57, sure, if you want, that'd be awesome | 16:26 |
| mitya57 | ok, so I'll now upload it to my test ppa and then copy if it builds | 16:27 |
| dholbach | mitya57, I won't get around to enable 'es' today | 16:27 |
| dholbach | but it'll be great to do it! | 16:27 |
| mitya57 | do you mean I should do that? | 16:27 |
| cjwatson | barry: indeed, it's technically an RC bug in Debian too | 16:27 |
| cjwatson | even if nobody's noticed yet :) | 16:27 |
| mitya57 | won't it blow up when we enable it? | 16:27 |
| barry | cjwatson: ;) | 16:28 |
| dholbach | mitya57, I can enable it tomorrow if you prefer | 16:29 |
| dholbach | mitya57, and also make sure we get it on developer.u.c properly | 16:29 |
| mitya57 | ok, that would be better | 16:29 |
| SpamapS | OdyX: thanks for the heads up, I'll do that merge today :) | 16:33 |
| SpamapS | OdyX: (re php) | 16:33 |
| seb128 | hallyn, that ppa upload of your is buggy | 16:46 |
| seb128 | hallyn, you updated the control it seems but rules still has | 16:47 |
| seb128 | ifeq ($(DEB_HOST_ARCH),amd64) | 16:47 |
| seb128 | # spice build | 16:47 |
| seb128 | hallyn, or am I overlooking something? | 16:47 |
| hallyn | seb128: gah. i caught another entry in rules but certainly believe i missed another. thanks, will look in a minute. <sigh> | 16:50 |
| hallyn | seb128: the right thing is to replace that with | 16:53 |
| hallyn | fneq (,$(findstring $(DEB_HOST_ARCH), amd64 i386)) | 16:53 |
| hallyn | right? | 16:53 |
| hallyn | (i always worry i'm inverting in my head or something) | 16:54 |
| seb128 | hallyn, I'm not convinced if you shouldn't add another if block for i386 | 16:55 |
| cjwatson | I prefer $(filter) | 16:55 |
| seb128 | hallyn, --target-list="x86_64-softmmu i386-softmmu x86_64-linux-user i386-linux-user" | 16:55 |
| seb128 | the target x86_64 is likely wrong in the i386 case | 16:55 |
| cjwatson | ifneq (,$(filter amd64 i386,$(DEB_HOST_ARCH))) | 16:56 |
| cjwatson | satisfies my inner (OK, not really) pedant wondering what would happen if somebody created an amd64notreally arch | 16:56 |
| hallyn | seb128: that shouldn't be any different with -spice than without though right? | 17:01 |
| hallyn | cjwatson: then that's what i'll use :) | 17:02 |
| seb128 | hallyn, you mean? that block seems to be the "build spice" and it exists only for amd64 at the moment | 17:02 |
| seb128 | hallyn, if you enable spice for i386 I guess you need to drop the x86_64 targets from the i386 case | 17:03 |
| seb128 | hallyn, you also have 2 blocks further in the rules to install the files from the spice target which are for amd64 only atm | 17:03 |
| leighman | hi all, any chance of getting glade 3.14.2 into raring (/SRUd into quantal) due to a fix for https://bugzilla.gnome.org/show_bug.cgi?id=685816 | 17:03 |
| ubot93 | Gnome bug 685816 in general "Widget attributes editing broken" [Major,Resolved: fixed] | 17:03 |
| seb128 | leighman, that fix is already in raring? | 17:04 |
| leighman | oh, maybe | 17:04 |
| leighman | I haven't tested on raring | 17:05 |
| leighman | tried 3.14.1 from git and it doesn't work | 17:05 |
| seb128 | or maybe not | 17:05 |
| seb128 | mvo, what happened to your glade update to fix the button edition bug? | 17:05 |
| hallyn | stgraber: ok new lxc pushed to raring which refuses read/write under efivars | 17:05 |
| seb128 | leighman, is there a bug in launchpad about this issue? | 17:06 |
| seb128 | leighman, I will do the update | 17:06 |
| leighman | not that I've seen | 17:06 |
| leighman | seb128: thanks | 17:07 |
| leighman | seb128: would it be eligible for an SRU to quantal | 17:08 |
| leighman | seb128: http://git.gnome.org/browse/glade/commit/?h=glade-3-14&id=a56908fbb4668354904f0020f3e5de1627d9b39b also applies onto 3.14.0 and fixes the problem | 17:09 |
| seb128 | leighman, is there a bug in launchpad about the issue? | 17:09 |
| xnox | leighman: I use glade every day. If that's the bug, that I think it is..... i'll be all over sponsoring it. | 17:09 |
| stgraber | barry: have fun: https://code.launchpad.net/~stgraber/upstart/upstart-initctl2dot-python3/+merge/136721 :) | 17:09 |
| stgraber | hallyn: thanks | 17:10 |
| leighman | seb128: not that I can see - you want me to file one? | 17:10 |
| barry | stgraber: thanks. i'll take a look after lunch-ish :) | 17:10 |
| seb128 | leighman, yes please, we need one if we want to SRU | 17:10 |
| leighman | xnox: good to hear :P | 17:10 |
| xnox | leighman: that's the bug that was killing me =)))) | 17:10 |
| stgraber | jodh: btw, initctl2dot has been broken for months/years as the .dot format doesn't allow dots and so any job with a dot in its name would make the graph generation fail (we have a dozen of those) :) | 17:11 |
| cjwatson | That's ironic | 17:11 |
| jodh | stgraber: yay for testing | 17:11 |
| stgraber | jodh: for now I just changed the code to replace those by underscores, that fixed it for me at least :) | 17:11 |
| stgraber | there may be some way of properly escaping the dot, not sure, I really don't know anything about graphviz :) | 17:12 |
| xnox | leighman: did you file a bug yet, or do you want me to file bug & upload the patches? | 17:12 |
| xnox | leighman: there is a workaround you know, add an action the select not to use action appearance, then remove the action, then change the properties you want =) | 17:13 |
| leighman | xnox: not yet, ubuntu-bug is just blooping away, if you are happy to do it you will probably do a better job :D | 17:14 |
| leighman | xnox: yeh, thanks, I know the workaround | 17:15 |
| xnox | leighman: well if it's blooping away, give me the bug-number and I will do the rest. | 17:15 |
| seb128 | xnox, you handle those fixes then? want to handle the glade 3.14.2 update to raring as well? ;-) | 17:16 |
| mvo | seb128: rejected iirc, need to look | 17:16 |
| xnox | seb128: ack. | 17:16 |
| seb128 | xnox, thanks | 17:16 |
| jodh | stgraber: speaking of dot remind me - try running 'sysctl -a' on a FreeBSD system... :) | 17:16 |
| xnox | seb128: basically ubiquity is done with glade and it sucks when glade is broken. I guess I am stuck fixing it now. | 17:16 |
| seb128 | xnox, GNOME uses quite some glade as well ;-) | 17:16 |
| mvo | seb128: let me re-upload | 17:17 |
| seb128 | mvo, don't bother, xnox is on a followup SRU which should fix that as well | 17:17 |
| seb128 | mvo, I just though you already handled the issue so I was surprised | 17:17 |
| mvo | even better: https://bugs.launchpad.net/ubuntu/+source/glade/+bug/1075957 | 17:17 |
| ubot93 | Launchpad bug 1075957 in glade (Ubuntu Quantal) "3.14.0 can not edit a GtkButton label" [Medium,In progress] | 17:17 |
| seb128 | xnox, leighman: ^ | 17:18 |
| mvo | seb128: I did, then I was traveling and had no access to the original upload when it got rejected | 17:18 |
| xnox | seb128: well some of the gnome's gtkbuilder files are hand-written including placeholders and includes, which brekas horibly if that hand-crafted file is loaded in glade and saved again. | 17:18 |
| seb128 | mvo, use the queue luke :p | 17:18 |
| seb128 | mvo, https://launchpad.net/ubuntu/quantal/+queue?queue_state=4&queue_text=glade | 17:18 |
| xnox | mvo: in the ubuntu-archive-tools there is a queue script that can download the source package out of any queue, including rejected. | 17:19 |
| seb128 | mvo, just as a trick for next time, you can browse the rejected queue for the web ui | 17:19 |
| xnox | Kind of like dget for the queue =) | 17:19 |
| === bitshuffler_ is now known as bitshuffler | ||
| hallyn | seb128: <sigh> new pkg pushed. hopefully i've caught all the instances this time | 17:24 |
| hallyn | thanks for pointing out the others | 17:24 |
| seb128 | hallyn, thanks, I was trying to work on a diff for the rules, let me look at what you came with ;-) | 17:24 |
| mvo | seb128, xnox: nice, good to know | 17:24 |
| seb128 | hallyn, I had something around those lines: http://paste.ubuntu.com/1394946/ | 17:25 |
| seb128 | hallyn, that's quite similar to what you did ;-) | 17:26 |
| === Sweetshark is now known as Sweetsharl | ||
| === Sweetsharl is now known as Sweetshark | ||
| hallyn | seb128: would the --target-list like that work? I would expect amd64 to end up without i386 binaries, but maybe misunderstand | 17:28 |
| leighman | seb128: xnox: duped my bug to that one then :P | 17:28 |
| seb128 | hallyn, is amd64 including i386 binaries a feature? | 17:28 |
| leighman | so the fix will go into proposed? | 17:28 |
| seb128 | leighman, yes, I think we should just SRU glade 3.14.2 | 17:28 |
| seb128 | xnox, ^ | 17:28 |
| hallyn | seb128: qemu-system-i386 exists on amd64 | 17:28 |
| seb128 | since that's a GNOME component it has a MRE | 17:28 |
| seb128 | hallyn, ok, so yeah my way is buggy | 17:28 |
| hallyn | (but that's not quite the same as what you're saying) | 17:28 |
| hallyn | seb128: ok, the rest do look the same - thanks! now let's hope it builds :) | 17:29 |
| seb128 | hallyn, fingers crossed ;-) | 17:29 |
| leighman | seb128: xnox: thanks | 17:32 |
| seb128 | leighman, yw | 17:33 |
| seb128 | slangasek, so, appmenu-gtk... want a new update on top (e.g for after that one), or one including both changes? | 17:34 |
| Ursinha | hi cjwatson | 17:35 |
| Ursinha | cjwatson, in ubuntu-archive-tools, do we have a preferred templating system to use? or am I free to choose? | 17:35 |
| jodh | stgraber: I've added an initctl2dot autopkgtest to the test branch lp:~jamesodhunt/ubuntu/raring/upstart/autopkgtest. See bug 1075976. | 17:36 |
| cjwatson | I don't think we have any templating system right now; we just write HTML directly | 17:36 |
| ubot93 | Launchpad bug 1075976 in upstart (Ubuntu) "test-suite fails in autopkgtest environment" [Medium,In progress] https://launchpad.net/bugs/1075976 | 17:36 |
| cjwatson | If you want to choose one you're free to do so, but it would be nice if it were simple enough for standalone scripts (e.g. TAL seems kind of massively over the top) and ideally already installed on lillypilly so that we have no deployment headaches | 17:37 |
| === rickspencer3_ is now known as rickspencer3 | ||
| cjwatson | I'd prefer not to get to the point where we have to run buildout over u-a-t, for example | 17:37 |
| slangasek | seb128: if you can do an upload of 0.3.92-0ubuntu1.1 today with both fixes, I'm happy to take that instead of the one that's there now | 17:38 |
| stgraber | jodh: cool, thanks | 17:38 |
| cjwatson | Ursinha: are you writing something that generates entirely new reports then? | 17:38 |
| Ursinha | cjohnston, not really, I was looking at nbs-reports and I saw that's hardcoded | 17:39 |
| Ursinha | I find it easy to break/harder to maintain or change | 17:39 |
| cjohnston | :-P | 17:39 |
| Ursinha | as using templates is fairly easy, I decided to ask :) | 17:39 |
| cjwatson | Yeah, they all are right now, partly because we didn't want to deal with the headaches of deploying a templating system, and partly because some of them started as skunkworks things run out of people's home directories | 17:39 |
| Ursinha | I thought so | 17:40 |
| cjwatson | so if it's a simple packaged thing that you can just import and go, that kind of thing would be a good idea I think | 17:40 |
| cjwatson | you're right it's a bit easy to break right now | 17:40 |
| Ursinha | there are a few simple templating systems that I can use, if we're not using any right now, I'll pick one up that's easy to deploy | 17:41 |
| cjwatson | sounds good, thanks | 17:41 |
| seb128 | slangasek, there you go: http://launchpadlibrarian.net/124332006/appmenu-gtk_0.3.92-0ubuntu1.1_source.changes, rejected the previous upload | 17:46 |
| slangasek | seb128: ta | 17:51 |
| === patr|ck_ is now known as patr|ck | ||
| === mcclurmc is now known as mcclurmc_away | ||
| marga | Is there some interface like packages.qa.debian.org that says _when_ a package was accepted in precise after an SRU and that kind of stuff? | 18:18 |
| cjwatson | https://launchpad.net/ubuntu/+source/SOURCEPACKAGENAME | 18:19 |
| cjwatson | .../+publishinghistory in particular is often handy | 18:19 |
| marga | tnx | 18:19 |
| ogra-cb | and there are the $release-changes mailing lists | 18:19 |
| seb128 | marga, you have the unapproved/waiting for review list on https://launchpad.net/ubuntu/precise/+queue?queue_state=1 | 18:21 |
| cjwatson | -changes tells you about one of -proposed or -updates but not both, and I can never remember which | 18:21 |
| ogra-cb | oh ? | 18:21 |
| ogra-cb | i thought i saw both | 18:21 |
| cjwatson | (the mail subjects say -proposed, but I have a feeling they're only actually sent when something hits -updates) | 18:21 |
| cjwatson | I generally find +publishinghistory more explicit and thus clearer | 18:21 |
| seb128 | cjwatson, -changes tells you about both | 18:22 |
| marga | That's fine, I just wanted to check one particular package, not subscribe to all of them :) | 18:22 |
| marga | Thanks! | 18:22 |
| seb128 | marga, http://people.canonical.com/~ubuntu-archive/pending-sru.html also as the active list | 18:22 |
| ogra-cb | cjwatson, i see both for all packages here | 18:23 |
| seb128 | ogra-cb, ^ yeah, what I just said as well ;-) | 18:23 |
| ogra-cb | oh, seb128 already said so | 18:23 |
| seb128 | the behaviour changes quite recently though, like during the precise or quantal cycle, it didn't use to do that | 18:23 |
| ogra-cb | yes | 18:23 |
| ogra-cb | i think at the end of quantal it changed | 18:24 |
| seb128 | I think that changed with the introduction of the scripts to do copies, etc | 18:24 |
| cjwatson | huh, OK, so it does | 18:24 |
| cjwatson | I keep forgetting :) | 18:24 |
| === attente is now known as attente_zzz | ||
| === dpb_ is now known as Guest46508 | ||
| bryce | slangasek, heya. mlankhorst and I want to give you heads up on some of the LTS rename work that we need your eyes on at some point soonish | 18:39 |
| bryce | slangasek, I know Friday is your usual SRU day, but since we'll be at OPB, are you still planning on working on SRU admin then? | 18:39 |
| === henrix_ is now known as henrix | ||
| slangasek | bryce: I am | 18:41 |
| bryce | slangasek, so the first pieces required for the X stack are llvm-3.1 (a new package), and updates to a few x11proto-* libs. All are uploaded and in the SRU admin queue now. | 18:42 |
| mlankhorst | not sure about llvm-3.1 being uploaded | 18:42 |
| mlankhorst | I asked raof to look into getting llvm-3.1 but he's been so busy lately :( | 18:43 |
| bryce | mlankhorst, I am seeing 3.1-2ubuntu1~12.04 there | 18:43 |
| mlankhorst | ok great | 18:43 |
| mlankhorst | that package is only used during building mesa, I don't think anything is needed at runtime | 18:43 |
| mlankhorst | apart from the stuff statically linked into mesa itself | 18:43 |
| * slangasek nods | 18:44 | |
| mlankhorst | however after that I should be able to do a ~precise0 of the entire lts-quantal stack, I don't expect my scripts to be perfect so I expect having to do a manual audit and a ~precise1 before making it leave -proposed, however it should work for testing purposes still.. | 18:46 |
| mlankhorst | s/^however.// | 18:46 |
| bryce | slangasek, so, happy to chat with you more on Friday, although I suspect all of this is going to be pretty straightforward. If you happen to want to bump these through today or tomorrow I'm sure mlankhorst would be thrilled. ;-) | 18:47 |
| dobey | when did 'dch' start defaulting to increment? | 18:48 |
| xnox | dobey: depends on your multimaintainer settings, UNRELEASED changelog line and command-line args. | 18:53 |
| xnox | but I think -i is doing something funny with UNRELEASED changelog entries. | 18:53 |
| xnox | dch -a doesn't increment | 18:53 |
| dobey | xnox: this isn't UNRELEASED (has raring in the changelog), and such. but i only noticed this behavior of incrementing by default today. i've done the exact same thing plenty of times before now and just plain 'dch' didn't increment. i'd always had to add the -i to increment | 18:58 |
| xnox | dobey: for me it used to always increment, hence i have switched to dch -a, a long time ago | 18:59 |
| dobey | weird | 19:00 |
| === Tonio_aw is now known as Tonio_ | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| dobey | ugh; dch -a doesn't bump the date for the current changelog entry though it seems :( | 19:07 |
| stgraber | dobey: you're supposed to do "dch -a" to add the entries, then "dch -r" when you're done. The latter will bump the timestamp | 19:10 |
| xnox | stgraber: dobey: what I find weird is that dch -i & dch -r can sometimes use "previous" maintainer instead of my name. | 19:10 |
| dobey | stgraber: just plain 'dch' used to do both of those for me | 19:11 |
| dobey | hrmm, is there some file i can poke at to see when exactly ubuntu was installed on a machine? | 19:15 |
| slangasek | dobey: /var/log/installer or bust | 19:16 |
| dobey | ah thanks | 19:17 |
| ogra-cb | the media/info file in that dir shows the timestamp of the install media if that helps | 19:17 |
| ogra-cb | (not actually the installation, i know) | 19:17 |
| dobey | ogra-cb: i'd guess the mtime of the file shows the install time :) | 19:18 |
| ogra-cb | well, roughly, yes | 19:18 |
| mdeslaur | infinity: vlc just got pocket-copied to precise-proposed. Do you have an SRU script that does a mass update of the bugs? | 19:21 |
| dobey | so i guess devscripts changed in this respect between precise and quantal | 19:21 |
| mdeslaur | dobey: yes, that changed...you can change the default back in /etc/devscripts.conf | 19:22 |
| mdeslaur | dobey: DEBCHANGE_RELEASE_HEURISTIC=log | 19:23 |
| dobey | mdeslaur: thanks; though changing that file doesn't seem to result in dch changing back to how i expected it to be. and from the debchange man page it seems 'changelog' there is more the former behavior than 'log' is. but neither one seems to change anything for me :-/ | 19:29 |
| mdeslaur | dobey: changelog is the new default | 19:30 |
| mdeslaur | dobey: what is the behaviour you're expecting? | 19:30 |
| mdeslaur | oh, 'dch' without options? I'm not sure about that | 19:31 |
| mdeslaur | 'dch -a' gets changed back to incrementing the date, etc. when you use 'log' though | 19:31 |
| dobey | mdeslaur: plain 'dch' without options used to do the same as combining -a and -r right now would do (but i can't do -a -r at the same time) | 19:32 |
| mdeslaur | ah | 19:33 |
| === henrix is now known as henrix_ | ||
| seb128 | hallyn, shrug, the qemu-kvm-spice.install/.links also need updating | 19:52 |
| seb128 | either .install.in -> .install generation or .install.<arch> | 19:53 |
| seb128 | same for the links | 19:53 |
| hallyn | seb128: ok, i'll d that tonight (or if you want to pls feel free) | 19:55 |
| === attente_zzz is now known as attente | ||
| slangasek | hallyn: just to clarify on bug #1075717, /dev in your container is not devtmpfs because the kernel only exports one devtmpfs view to all mount points, so doing it that way would prevent you from making the device nodes different in the container vs. the host? | 20:05 |
| ubot93 | Launchpad bug 1075717 in mountall (Ubuntu) "mounted-dev must not re-create consoles in a container" [High,Triaged] https://launchpad.net/bugs/1075717 | 20:05 |
| hallyn | slangasek: yes, or more precisely the container ends up corrupting the host's devices | 20:07 |
| slangasek | right | 20:07 |
| hallyn | ability in kernel to support multiple devtmpfs's would be neat, but wouldn't supplant the need to change mountall | 20:08 |
| slangasek | hallyn: what do you think about changing MAKEDEV to not remove the nodes, rather than having mounted-dev not call MAKEDEV console? Are you manually setting up *all* the nodes that are handled by MAKEDEV console? (tty0, vcs*) | 20:09 |
| slangasek | hallyn: no, mounted-dev only calls MAKEDEV if /dev is *not* a devtmpfs mount | 20:09 |
| slangasek | so supporting multiple devtmpfs would also make this a non-issue | 20:09 |
| hallyn | ah i see | 20:10 |
| hallyn | sadly that would take a few upstream kernel cycles :) | 20:10 |
| slangasek | yeah, not saying we should wait for that :) | 20:11 |
| hallyn | slangasek: yes, changing MAKEDEV woudl also work | 20:11 |
| hallyn | and actually might prevent a whole slew of other upcomgin bugs | 20:11 |
| slangasek | do you think it would be more correct? | 20:11 |
| hallyn | thinking outside of containers, i'm afraid it could be considered broken | 20:11 |
| hallyn | though it seems to me like MAKEDEV ought to take a flag saying do or don't remove fi it exists... | 20:12 |
| slangasek | if mknod $1- $2 $3 $4 && | 20:13 |
| slangasek | chown $5:$6 $1- && | 20:13 |
| slangasek | chmod $7 $1- && | 20:13 |
| slangasek | mv $1- $1 | 20:13 |
| slangasek | there's the critical bit... creates a temp file and moves it over | 20:13 |
| slangasek | hmm | 20:13 |
| hallyn | that's bitten us before as well, when we had /dev/console as a direct bind mount from /dev/pts/N, the mv would fail | 20:14 |
| hallyn | I just don't know how to make an educated guess about "sane" behavior for this | 20:14 |
| slangasek | hallyn: yeah, I'm thinking through it; I should have something resembling an informed opinion shortly :) | 20:18 |
| hallyn | awesome :) | 20:18 |
| slangasek | hallyn: ok, so I think it comes down to whether you need mountall to create /dev/tty0, /dev/vcs* for you or not | 20:24 |
| slangasek | if you're happy creating these yourself (perhaps by calling MAKEDEV console directly before launching the container and fixing up /dev/console?), then I officially Don't Care about makedev and am happy to take your solution | 20:25 |
| hallyn | slangasek: we always manually create them for containers | 20:25 |
| hallyn | not the /dev/vcs* though | 20:26 |
| hallyn | not even sure what those are | 20:26 |
| hallyn | slangasek: are you saying you want lxc to create them all before doing configuration? Or that so long as containers do what htey need it's ok? | 20:27 |
| slangasek | hallyn: I think given that these are all fairly basic devices, if we decide mounted-dev is no longer responsible for them, we should at the same time make sure that something else (lxc) is | 20:29 |
| slangasek | best way to do that without too many layering violations is to have lxc call "MAKEDEV console" as part of the setup, then override the bits it doesn't like | 20:30 |
| hallyn | slangasek: lxc's flexibility wihth respect to mounting complicates that a bit. It could just run the host's MAKEDEV inside $chroot/dev before starting, | 20:32 |
| hallyn | or it could call the guest's MAKEDEV (if it exists, might not) after mounting /dev | 20:32 |
| barry | stgraber: could i get a bump? https://launchpad.net/~barry/+archive/experimental/+build/4019944 | 20:33 |
| stgraber | barry: done | 20:34 |
| barry | thanks! | 20:34 |
| slangasek | hallyn: oh. that brings another question... if $chroot/dev isn't devtmpfs, why is it a separate mount point at all? | 20:34 |
| hallyn | slangasek: because sometimes the container rootfs has empty dev. FOr instance the ubuntu-cloud images at times had that (it was an error, but didn't need to break lxc and by extention juju altogether like it did) | 20:35 |
| slangasek | hallyn: ok, but why does /dev being empty mean that you should make it a mountpoint? | 20:36 |
| slangasek | clearly you're doing some fix-ups here to create devices under it anyway | 20:37 |
| slangasek | I don't understand why that's done as a separate (presumably tmp)fs rather than just on the container rootfs | 20:37 |
| slangasek | is it *because* you want to leverage mounted-dev for the node creation? | 20:37 |
| hallyn | you know i'm not sure if we need some of it or not. not using a mount might still be sufficient. Mostly it was bc staying close to a regular system seemed useful in itself. | 20:38 |
| hallyn | oh, | 20:38 |
| slangasek | mounting something that's not devtmpfs on /dev is not at all close to a regular system ;) | 20:38 |
| hallyn | some ppl use read-only roots, so in that case a separate /dev would be needed | 20:38 |
| slangasek | ah, ok | 20:39 |
| slangasek | then in that case, yes, I think your change is the reasonable path forward | 20:39 |
| hallyn | there i disgree - devtmpfs is... well lemme not go there :) | 20:39 |
| slangasek | as long as there's a corresponding change to lxc to call 'MAKEDEV console' itself for this case | 20:39 |
| slangasek | devtmpfs is auto-mounted by the kernel, how much more regular can you get ;) | 20:39 |
| hallyn | it can be compiled out :) | 20:40 |
| slangasek | irregularly | 20:40 |
| slangasek | ;) | 20:40 |
| hallyn | so should I call the contaienr's MAKEDEV after lxc has done all its mounting? | 20:40 |
| slangasek | I think you should call it before you create /dev/console | 20:41 |
| slangasek | (whenever that is) | 20:41 |
| hallyn | but after mounting /dev | 20:41 |
| slangasek | yep | 20:41 |
| hallyn | which would require splitting up the existing create_autodev() function, but that's ok | 20:41 |
| hallyn | i'll mount first, finish all other mounting, do MAKEDEV<, then create the rest of the devices if needed | 20:41 |
| hallyn | slangasek: thanks | 20:42 |
| slangasek | sure :) | 20:42 |
| infinity | mdeslaur: Yeah, sru-accept. Did you find someone to do that yet? | 20:43 |
| mdeslaur | infinity: no, could you please? | 20:43 |
| * infinity looks at a bug. | 20:43 | |
| infinity | mdeslaur: Bah, none of these bugs have precise tasks. | 20:45 |
| mdeslaur | infinity: argh :( | 20:45 |
| infinity | bdrung: Naughty man, doing SRUs without appropriate paperwork. | 20:46 |
| infinity | mdeslaur: I'll just add the tasks. People can dream up testcases as they verify. | 20:46 |
| slangasek | hallyn: I am going to drop the path from the invocation of running-in-container, FWIW | 20:47 |
| slangasek | I'm not sure why this is /sbin/MAKEDEV everywhere, I think that's just a reflex | 20:48 |
| bdrung | infinity: vlc has a preliminary point release exception. so less paperwork is allowed | 20:48 |
| slangasek | hallyn: oh, ah, race condition | 20:48 |
| hallyn | no pls keep that :) | 20:49 |
| infinity | bdrung: Less paperwork doesn't mean not having tasks for bugs referenced in changelogs, etc. | 20:49 |
| infinity | bdrung: It just means not having to justify every line of code in the update. | 20:49 |
| slangasek | hallyn: running-in-container works only after /run is mounted (set up via /etc/init/container-detect.conf); this is not guaranteed to happen before /dev is mounted | 20:49 |
| hallyn | drat | 20:49 |
| infinity | mdeslaur: Bugs spammed. Have a nice day. | 20:49 |
| mdeslaur | infinity: hehe, thanks | 20:49 |
| hallyn | slangasek: then we'll need to do it more directly i guess? | 20:49 |
| infinity | mdeslaur: Want to join the SRU team? :) | 20:50 |
| slangasek | hallyn: yep | 20:50 |
| slangasek | hallyn: "pls keep that" -- the hard-coded path? why+ | 20:50 |
| mdeslaur | infinity: want to help with security updates? :) | 20:50 |
| infinity | mdeslaur: I used to... | 20:50 |
| mdeslaur | infinity: hehe, I know...I'm just kidding...I wouldn't mind, but I'm afraid I wouldn't find time to actually do any SRU work | 20:51 |
| hallyn | slangasek: no, i misread your earlier comment, i thought you said i'd introduced a race condition, i was saying pls keep that | 20:51 |
| slangasek | ah | 20:52 |
| hallyn | slangasek: you've got the manual running-in-container under control, or did you wnat me to try a new patch? | 20:52 |
| slangasek | hallyn: would appreciate a new patch from you | 20:52 |
| bdrung | infinity: sorry. i just had a open task for the first bug closed by this upload. | 20:53 |
| hallyn | slangasek: ok | 20:53 |
| === cpg|away is now known as cpg | ||
| === salem_ is now known as _salem | ||
| hallyn | stgraber: so for the mountall fix to not MAKEDEV console in containers, i will have it do so only for libvirt and lxc, not openvz. sound right? | 21:22 |
| stgraber | hallyn: yep. I have no idea how OpenVZ will behave anyway, so if someone has a problem with it, they can send us a patch. | 21:24 |
| hallyn | k | 21:25 |
| === lifeless_ is now known as lifeless | ||
| slangasek | hallyn: does 'env LIBVIRT_LXC_UUID' also need to be passed? | 21:58 |
| slangasek | (it is in container-detect, but not in your patch) | 21:59 |
| slangasek | hallyn: AFAICS, without setting it, [ -z "$LIBVIRT_LXC_UUID" ] will always be true | 21:59 |
| SpamapS | what I want: sbuild --cloud | 22:06 |
| SpamapS | somebody do that for me | 22:06 |
| SpamapS | please! | 22:06 |
| barry | SpamapS: and me! | 22:07 |
| barry | (and ppas and buildds...) | 22:07 |
| SpamapS | Hah yeah, I'd love to be able to just hand Launchpad my HP Cloud creds and be like "bill me for the hour of usage, just get it done FAST" | 22:08 |
| sarnold | juju deploy sbuild ; juju deploy ccache -n 10 | 22:09 |
| SpamapS | distcc you mean? | 22:10 |
| SpamapS | juju deploy sbuild --constraints cpu=4 seems to give me a fast enough machine to build quite quickly. Its the test suites that kill me | 22:11 |
| sarnold | SpamapS: ah yes, distcc and ccache always hash-collide in my brain.. | 22:12 |
| hallyn | slangasek: gah, yes it does | 22:13 |
| sarnold | SpamapS: and the one-at-a-time xz or gz or bz2... | 22:13 |
| SpamapS | yeah | 22:13 |
| SpamapS | I actually created a multi-threaded bz2 a long, long time ago | 22:13 |
| SpamapS | but, all that did was allow bz2 to be as fast as single threaded gzip by using all 4 CPU's at once | 22:14 |
| hallyn | slangasek: thanks, re-pushed. almost done with an lxc candidate running MAKEDEV... needs som etesting of course | 22:15 |
| sarnold | haha | 22:15 |
| === cpg is now known as cpg|away | ||
| mlankhorst | wee MAKEDEV, back to the 90s! | 22:31 |
| === Todd__ is now known as Todd | ||
| hallyn | happy times | 22:42 |
| soind | I was logging in to ask something. I think I read that HUD will replace global menu in future versions. Is this the case, or will they continue to exist side-by-side? | 22:48 |
| hallyn | this isn't the place for that question, perhaps ubuntu-desktop. | 22:52 |
| xnox | soind: #ubuntu-desktop or #ubuntu-design | 22:54 |
| soind | ok thx | 22:55 |
| slangasek | kenvandine: the auto-landed upload of appmenu-gtk has clobbered the fixes for multiarch that had been in the distro. How do we get this fixed? (bug #1084266) | 23:09 |
| ubot93 | Launchpad bug 1084266 in appmenu-gtk (Ubuntu) "Broken multiarch support: /etc/X11/Xsession.d/80appmenu-gtk3 differs" [Undecided,New] https://launchpad.net/bugs/1084266 | 23:09 |
| slangasek | kenvandine: is this simply a matter of the distro patch not having landed on the documented Vcs-Bzr branch? Does everyone who has upload rights to the package also have commit rights to the branch? | 23:10 |
| slangasek | seems not | 23:12 |
| hallyn | can I use ${DEB_HOST_ARCH} in debian/package.install? | 23:13 |
| hallyn | (or rather .links, but presumably same answer) | 23:14 |
| slangasek | alesage: ^^ we have a bit of a workflow problem with the current "master" branch for appmenu-gtk (and possibly others) as it's being managed | 23:14 |
| slangasek | hallyn: if you use 'dh-exec', yes | 23:15 |
| hallyn | cool | 23:15 |
| hallyn | actually i guess that won't work for me anyway, but cool. thanks | 23:15 |
| alesage | slangasek, do tell | 23:19 |
| alesage | slangasek, how can I help? | 23:19 |
| slangasek | alesage: so I'm kicking off a mail to didrocks and popey, I think they might be the ones to actually deal with this | 23:19 |
| slangasek | alesage: I was pinging you because you're the admin on the appmenu-gtk branch in question, but I think maybe that's not where I need fixing done :) | 23:19 |
| alesage | slangasek, we might involve cyphermox in this | 23:20 |
| slangasek | alesage: basically, it seems that the package autolanding is *supposed* to notice changes that are made in the distro for these packages and automatically ensure that they get merged | 23:21 |
| alesage | or you might cc him | 23:21 |
| slangasek | but this didn't happen for distro patches to the upstream source | 23:21 |
| slangasek | ah, is this cyphermox's code? | 23:21 |
| slangasek | cyphermox: ping | 23:21 |
| xnox | hallyn: with compat level 9, you can use variables in the .install file. | 23:21 |
| slangasek | xnox: incorrect | 23:22 |
| alesage | slangasek, if it concerns packaging he'll have a better ideer than will I :) | 23:22 |
| slangasek | xnox: the only variable expansion is done by dh-exec | 23:22 |
| slangasek | alesage: well, it concerns whatever bit of magic is synthesizing the package from the branch | 23:22 |
| alesage | slangasek, I think I'm understanding, hmm | 23:23 |
| slangasek | alesage: anyway, I think you're off the hook - thanks :) | 23:23 |
| alesage | slangasek, Jenkins may still be on the hook, so pls cc me :) | 23:23 |
| slangasek | ok | 23:24 |
| xnox | slangasek: ack. | 23:24 |
| cyphermox | slangasek: pong | 23:26 |
| slangasek | cyphermox: hi - see bug #1084266 :) | 23:27 |
| ubot93 | Launchpad bug 1084266 in appmenu-gtk (Ubuntu Raring) "Broken multiarch support: /etc/X11/Xsession.d/80appmenu-gtk3 differs" [High,Triaged] https://launchpad.net/bugs/1084266 | 23:27 |
| slangasek | distro patch to upstream sources magically disappeared | 23:27 |
| slangasek | cyphermox: also, this is a wrong use of the Vcs-Bzr field because the pointed-at branch contains no packaging | 23:27 |
| cyphermox | slangasek: err what? | 23:27 |
| cyphermox | that makes no sense, it should contain it | 23:27 |
| slangasek | really? | 23:28 |
| slangasek | https://code.launchpad.net/~indicator-applet-developers/appmenu-gtk/trunk.13.04 ? | 23:28 |
| cyphermox | ah, I see | 23:28 |
| cyphermox | the branch wasn' t properly moved to what it should be | 23:29 |
| slangasek | cyphermox: which is the right branch? | 23:30 |
| cyphermox | slangasek: afaik should all be https://code.launchpad.net/~indicator-applet-developers/appmenu-gtk/trunk.13.04 | 23:31 |
| cyphermox | why this is still in https://code.launchpad.net/~canonical-dx-team/appmenu-gtk/trunk.13.04 I don' t know | 23:32 |
| cyphermox | anyway, not relevant for fixing that multiarch issue | 23:32 |
| === cpg|away is now known as cpg | ||
| infinity | cyphermox: It seems like a fatal flaw that either (a) changes from the archive don't get automerged back in before the next automagic upload, and/or (b) ubuntu-core-dev can't commit to your branch. | 23:35 |
| infinity | cyphermox: And since (despite claims to the contrary) the archive is authoritative, (a) probably needs to happen somehow. | 23:35 |
| infinity | cyphermox: All of this comes down to the argument I had last night with people about how automated uploads without human intervention/auditing/button-pressing are probably a bad thing. | 23:36 |
| cyphermox | infinity: *shrugs* I did not design that autolanding stuff. I can only agree with you and say that we need to bring this up with didrocks and alesage | 23:36 |
| infinity | cyphermox: Cause a human could have checked the previous archive versions and said "no, wait, this is missing a merge". | 23:36 |
| alesage | yeah this does seem "structural" in some way infinity, slangasek, cyphermox | 23:36 |
| alesage | ultimately you might need a distro representative to monitor and merge, e.g. | 23:36 |
| cjwatson | Mm, I was assured that the autolanding mechanism would notice changes outside of it | 23:37 |
| cyphermox | alesage: it would need to somehow notice automatically that there is a difference between the ubuntu: branch and itself and block autolanding in that case | 23:37 |
| alesage | else Jenkins might have to account for | 23:37 |
| cjwatson | Apparently that's busted | 23:37 |
| alesage | cyphermox, hmm | 23:37 |
| slangasek | cjwatson: it notices changes, but seems confined to the debian/ directory | 23:37 |
| slangasek | that, or someone mismerged | 23:37 |
| alesage | if any correspondence results from this we should probably involve mmrazik | 23:37 |
| infinity | cyphermox: Well, this also makes an assumption that the ubuntu: branch will always match the archive (which isn't necessarily true) | 23:37 |
| cyphermox | infinity: you know what I mean | 23:38 |
| infinity | cyphermox: Yeah, I know. I'm just pointing out that people really need to check the archive first, not trust automated imports blindly. | 23:38 |
| cyphermox | tthere is that | 23:38 |
| cyphermox | alesage, can you first block any kind of autolanding for now until didrocks fixes this? | 23:38 |
| alesage | cyphermox, I'll discuss with mmrazik tomorrow, and yes I can disable these jobs if that's what's needed | 23:39 |
| cyphermox | then we fix the archive so that things are good, and then work on making sure the upstream branch has all it should | 23:39 |
| infinity | This could be as simple as "bzr diff last_uploaded_tag current_proposed_head" and compare with "debdiff current_archive_dsc automated_source_package_of_head". | 23:39 |
| infinity | Or sometihng. | 23:39 |
| cyphermox | alesage: I' d rather things be disabled now, so that no other such occurences happen until didrocks shows up again | 23:40 |
| cjwatson | I've disabled the autolander on lillypilly | 23:40 |
| alesage | very well cyphermox | 23:40 |
| infinity | But I'd still prefer to see a real human do the final check-and-audit. I've had concerns about this a few times for different reasons now. :/ | 23:40 |
| alesage | exciting times :) | 23:40 |
| cyphermox | cjwatson: thanks | 23:40 |
| slangasek | alesage, cyphermox: you've got mail | 23:40 |
| cyphermox | k | 23:40 |
| cjwatson | with an IRC reference whose timestamp hopefully isn't too far off (working from phone about to run out of battery) | 23:40 |
| cjwatson | I'm not in principle opposed to it being automatic - after all auto-sync is fully automatic. But it needs to have a rather similar set of safeguards - auto-sync is *very* careful. | 23:44 |
| slangasek | on the plus side, the autopackaging is cdbs-free ;) | 23:45 |
| cjwatson | (We ran it and its predecessor on manual for eight years before trusting it to cron ...) | 23:45 |
| cyphermox | slangasek: yes | 23:45 |
| infinity | cjwatson: autosync isn't actually uploading any packages that someone else hasn't already vetted. | 23:46 |
| cjwatson | (OK, some of that was because its predecessor had a painful interface, but even so it did in part actually require manual supervision, especially for new packages) | 23:46 |
| infinity | cjwatson: I'm not opposed to automated VCS->archive magic (like I've often described at Maemo), but even when I did it in the past, there was a real human step of "tag a release" before uploading. | 23:46 |
| infinity | cjwatson: Which means there was a pre-upload (or pre-tag) point for due diligence in making sure the source was sane. | 23:47 |
| infinity | I'm not convinced that any amount of automated testing, attempting to diff against branches, etc, can ever make up for just having one person look at the current HEAD and say "yes, this is ready to release". | 23:48 |
| infinity | But I dunno. Maybe one can build enough machinery to replace (un)common sense. | 23:48 |
| cyphermox | infinity: I think that' s why didrocks initially wanted to publish to a ppa then do another run of builds and such | 23:53 |
| slangasek | ok, er, why does bzr bd -S keep ignoring my changes to the upstream code? | 23:57 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!