=== glebihan_ is now known as glebihan === cpg|away is now known as cpg [00:19] whats the Ubuntu software centre written in?? [00:23] sorry was that a bad question?? [01:41] Whoo! Chroot tarball corruption on armel raring. :( [02:18] TheMuso: It's not the tarball, it's the buildd. Let me go abuse it. === cpg is now known as cpg|away === cpg|away is now known as cpg [05:36] Good morning [05:40] hi pitti === morphis is now known as morphis|away [07:22] good morning === morphis|away is now known as morphis [08:44] doko_, maybe you can help me? with the new libxml2 in experimental we should be able to get back in sync again, but it FTBFS in raring (http://paste.ubuntu.com/1334247/). it seems to build in debian, also using binutils-gold - I'm not quite sure where to go from here - is this something we should fix in debian/ubuntu or something which should be forwarded upstream? Do you know which compiler version or flag might be responsible for the erro [08:44] r so they know how to reproduce it? === Tonio_aw is now known as Tonio__ [08:54] ^ or anyone else really :) === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ [09:30] dholbach, a verbose build log maybe would already help ... [09:30] doko_, the normal raring build log? [09:30] hi cjwatson [09:31] ScottK thinks we should re-add essential flag to python-minimal [09:31] (which was reverted by you): https://code.launchpad.net/~mitya57/ubuntu/raring/python-defaults/resync/+merge/131193 [09:31] mitya57: why that? I thought it was spelt "python3" now [09:31] pitti: "You can't remove essential until it's been verified nothing in the archive assumes it's present." [09:32] dholbach, no, that silent too ... === doko_ is now known as doko [09:32] I hope cjwatson will now say he has verified that somehow :) [09:33] doko, can you help me understand what you'd need? [09:35] dholbach, compiler flags, linker flags, ... [09:35] hi dholbach, doko [09:35] hi mitya57 [09:35] maybe one of you can sponsor the new sphinx? [09:36] (I mean my debdiff at bug 1070336) [09:36] Launchpad bug 1070336 in sphinx (Ubuntu) "Sphinx FTBFS in raring (again)" [High,In progress] https://launchpad.net/bugs/1070336 [09:41] mitya57: I'd be happy to argue with ScottK about this directly; it seems a bit daft to do so by proxy [09:42] mitya57: I'll follow up in the MP [09:42] cjwatson: thanks [09:59] * cjwatson finally moves auto-sync from cron.cjwatson to an actual crontab entry [09:59] only about eight years late [10:07] cjwatson: is syncpackage use into raring-proposed safe? I see the minor thread on ubuntu-devel ML but it was unclear to me whether the log changelog was OK or not? [10:07] log/long [10:08] jamespage: there's some problem on the LP side; if you have ubuntu-dev-tools << 0.143ubuntu0.1 then it'll produce wrong output in your terminal, but that doesn't really matter [10:09] bug 1073492 is the LP bug [10:09] Launchpad bug 1073492 in Launchpad itself "Sync changelog doesn't include all changelogs between release version and new Debian version" [High,Triaged] https://launchpad.net/bugs/1073492 [10:09] I wouldn't block on that for now if I were you; go ahead and sync stuff where appropriate [10:09] cjwatson, great - thanks [10:10] dholbach: doko is after a build with VERBOSE=1 set, such that the build-log is about 3-4 times longer than the current one. The information as to why it is failing, is currently hidden. [10:13] isn't it V=1? [10:13] looks like automake at least [10:14] (cf. Debian #680686) [10:14] Debian bug 680686 in debhelper "pass --disable-silent-rules to configure by default" [Important,Open] http://bugs.debian.org/680686 [10:18] cjwatson: yes, it's V=1 & VERBOSE=1 in CMake..... [10:18] cjwatson: yes, it's V=1 for autotools & VERBOSE=1 in CMake..... [10:29] xnox, in http://paste.ubuntu.com/1334398/ I used --disable-silent-rules now [10:31] dholbach: I like how make is in Deutsch and gcc in English in that build log =) [10:31] haha [10:32] doko: here is a verbose log for you http://paste.ubuntu.com/1334398/ I don't see anything suspicious and -fPIC is used..... [10:44] xnox: sorry I didn't manage to make the bibisect session. Have you considered the apt by-hash stuff? Then you'd just need to keep the hash of InRelease (when we have it) and alter expiry of old files. Perhaps with a (possibly internal) redirect to take you from a "dated" URL to the correct InRelease by-hash, and then apt should Just Work with it [10:44] (and debootstrap too) [10:44] although that would add a dependency on the by-hash stuff, so perhaps that's a reason not to use it [10:44] rbasak: I was not at the bibisect, nor at the apt-hash session. I was at the "keep the snapshot" session only. [10:45] (on me completing the by-hash stuff) [10:46] rbasak: I am not sure what the by-hash stuff is =) the current "implementation" I have for the snapshots I have is to simply rsync-snapshot the dists/ & proxy redirect pool/ to launchpadlibrarian. [10:46] rbasak: is there anything concise I can read about the by-hash stuff? [10:46] xnox: https://wiki.ubuntu.com/AptByHash [10:47] xnox: I'm hoping to have it done by Raring FF [10:47] xnox: progress so far is a PoC that works with a patched apt in a PPA [10:49] rbasak: interesting stuff. If the hashes are kept for the past month with a proxy to launchpad librarian beyond that horizon we are golden for full snapshots archive. [10:50] xnox: exactly - snapshot capability just falls out of the design. I'm not sure about the proxy to launchpad librarian for > one month though. What would be doing about the index files? [10:50] rbasak: are you running a PoC mirror anywhere with this stuff already on continuous basis? or just locally. [10:50] xnox: I was running one but I turned it off when it got postponed last cycle [10:50] * rbasak looks [10:51] Argh [10:51] * rbasak reinstalled his phone today, and just realised that he's lost all his Google Authenticator setups [10:51] rbasak: well we need to keep dists/ snapshots in by-hash/ or by-date/ dirs. But the files in pool/ are expired and redirected to launchpadlibrarian via smart proxy upon request. [10:51] No AWS for me today then :-/ [10:51] =( [10:52] There was a mirror in S3. Let's assume it's not there right now, but I'll get it going again soon [10:52] Ah OK. Yeah - as long as we keep the indexes around that'll work. I like the idea of deferring to launchpadlibrarian instead of keeping the packages around forever [10:53] launchpadlibrarian isn't guaranteed to keep all files around forever [10:53] no, but it does keep them for the lifetime of the release [10:53] not guaranteed by code but guaranteed by process [10:58] rbasak: and if dists will keep on growing forever, but we can implement round-robin expiry e.g. similar to how pnp4nagios does it. Keep dists 0.5 for the past 2 weeks, keep dailes after that for 3 months, then weeklies... etc. And redirect expired dists to the closes new one. [10:58] where "0.5" is "0.5 hour" [11:00] although we might not want to play with time that much. === mcclurmc is now known as mcclurmc_away [11:03] Sure. Just decide what the expiry algorithm is and we can implement it :) [11:04] rbasak: I like the "wait until we are running out of disk space and see how can we expire the least amount of stuff while maximizing usefulness" [11:05] you might also consider proxying large objects in dists/ such as installer uploads somehow [11:05] the custom tarballs that are unpacked into that should be somewhere in the librarian [11:05] that would require a somewhat more intelligent proxy though === dendro-afk is now known as dendrobates [11:13] xnox: my PoC is in S3. I'm not sure if we can detect when S3 is running out of disk space :-P [11:14] rbasak: hmm... yeah expiring a bucket may be drastic if we are not careful what we put in it. === Tonio__ is now known as Tonio_aw === Tonio_aw is now known as Tonio__ === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates === mcclurmc_away is now known as mcclurmc === Tonio__ is now known as Tonio_aw === MacSlow is now known as MacSlow|lunch === Tonio_aw is now known as Tonio__ === cpg is now known as cpg|away === attente_zzz is now known as attente [13:14] nobuto: Would you mind merging mozc? uim is stuck in raring-proposed because it makes versions of uim-mozc earlier than 1.5.1090.102-4 uninstallable. [13:15] nobuto: (Or let me know if you don't have time and I can do it) [13:18] cjwatson: if syncing from debian experimental, no merge will be needed. the patch has been upstreamed. but I will contact the maintainer in Debian to confirm it's OK. [13:18] cjwatson: No need to argue about python-minimal. You dropping it with intent is different than it being dropped in an upload that I was considering sponsoring. === MacSlow|lunch is now known as MacSlow [13:26] nobuto: OK, either way is fine by me, though I know nothing about the safety of mozc in experimental [13:26] ScottK: cool [13:27] * cjwatson grumbles in the general direction of bison [13:27] DFSG-cleaning that breaks autoreconf considered annoying [13:41] cjwatson: OK, I will double check that. [14:12] doko: hm, I'm slightly puzzled by https://launchpadlibrarian.net/121262133/buildlog_ubuntu-raring-i386.ubuntu-drivers-common_1%3A0.2.71build1_FAILEDTOBUILD.txt.gz [14:12] doko: "/bin/sh: 1: python3.2: not found", how can that be? it depends on python3-all, and fails with that on i386 and armhf only (works on other arches) [14:13] doko: is/was that something transient? [14:13] pitti: I don't see it depending on python3-all [14:13] oh sorry, looked at the wrong version [14:14] doko did add the -all dep in https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.71ubuntu1 [14:14] and that built fine [14:14] pitti, I do love these shell script style makefiles :-/ [14:14] ack. [14:15] doko: yeah; if only debhelper supported py3 properly.. [14:16] so, that leaves the question of what failed in ubuntu1 [14:16] it doesn't try to install python2 [14:17] doko: as I said, I was looking at the wrong log; you already fixed this error in ubuntu1 [14:17] ahh, ok === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem === _salem is now known as salem_ [14:37] ev: btw, I was talking to seb128 about sending crashes to daisy only -- he says that he depends a lot on having direct submitter contact/feedback, so I think we shouldn't do this just yet [14:38] Hi. I want to apply this patch to chromium-browser in local build. http://code.google.com/p/webrtc/issues/detail?id=512 [14:38] But I don't know how to apply patch. [14:39] pitti: okay, at what point would you like to re-evaluate that? When we have the server-side hooks implemented? [14:39] @pilot in === udevbot changed the topic of #ubuntu-devel to: Ubuntu 12.10 released | Archive: Open | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and dicussion of hardy -> quantal | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber [14:39] Or perhaps taken from a different angle, why do we want direct submitter contact? [14:39] chromium-browser's sorce code is compressed and [14:39] and can we eliminate the need for that over the medium term [14:39] ev: yes, I think having the extra scripts feature is a minimum requirement for that [14:40] okay, cool [14:40] ev: which might be sufficient in a lot of cases, but due to the nature of GUI bugs even those might not be sufficient in a lot of cases [14:40] seb128: ^ was there anything else? [14:40] I think so, but I might have forgotten (post-party morning..) [14:41] ev, pitti, mpt: was there any consideration to have an text entry on the dialog? to let user optionally put a description of what they were doing when the issue happened [14:41] that's what firefox is doing [14:41] yes === salem_ is now known as _salem [14:41] seb128: it's on the list of work items for 13.04 === _salem is now known as salem_ [14:42] ok [14:42] well I guess we should reconsider once that happens [14:42] if you hit "show details" you'll have an optional box to add some details [14:42] without description it's just too hard to figure how to reproduce issues [14:42] hum, hidden in "show details"? I'm not sure anyone will go find it there :-( [14:43] * didrocks doubts about it too [14:43] well, we've only briefly talked about the UI for this. But the belief is that technical people, the kind who you'd want to provide a description, would be hitting show details anyway [14:43] at least the one time it would take them to realise it was there [14:44] and do recall we're operating at scale [14:44] out of 800 instances of a crash, someone is bound to enter something there [14:44] speculation, of course [14:44] we can always see how it goes [14:44] well, firefox has it in the main ui [14:44] looking through some of their bug, 90% of descriptions are useless but you get infos from the other 10% [14:44] but I'm worried about putting it in the main UI as I think anything that makes the dialog look more complex is going to scare away some people from hitting submit [14:45] well, people don't need to hit submit [14:45] mpt: you might be interested in this conversation :) [14:45] seb128: why don't they? [14:45] the way it's currently designer it sends the report even if you close the dialog [14:45] you would need to uncheck the checkbox to not send it [14:45] and I guess users who get scared by the dialog just close [14:45] oh I see your point [14:46] by the way, the fact that the dialog has a close button at all is a bug [14:46] it's supposed to just be minimise [14:46] well, any of the buttons at the bottom would send the report [14:46] so even if users don't read the content and click on any of those it would send the report [14:46] indeed, that was just an aside [14:47] to go back to the topic, I think we need to keep launchpad submit by default until we get useful descriptions from e.u.c [14:47] yes - I don't want to rip out anything that you find useful [14:47] I will let mpt and you figure the ui that leads us there ;-) [14:48] but hopefully we'll get those useful descriptions soon [14:48] seb128: cheers :) [14:48] I guess the server and foundation guys will/should be happier with the "run extra scripts" possibility [14:48] pitti, the extra script thing will be useful without doubt [14:48] it's a bit orthogonal to the description though [14:49] can these be interactive? [14:49] so for desktop we could use a dialog which asks for more information, or some messages like "now reproduce the problem and click ok", or something such? [14:49] ev: ^ I think I already asked you taht [14:49] but it might have been rejected in design already [14:50] no [14:50] as in no I really don't want them to be interactive [14:50] for a number of reasons which I'm happy to enumerate [14:50] but lets see where we get without them being interactive first [14:50] it's a bit tricky, I doubt you will be able to get some infos without those being interactive [14:51] like you can't really go and fetch private infos without asking the user [14:51] the interactivity we currently have is confusing at best for non-technical people [14:51] ev: can we not kill all the close buttons? some users get really annoyed when we do that (like in Software Updater) [14:51] count me in the "hate that I can't close the "you need to reboot"" [14:51] seb128: fetching private information will be covered by the text in the initial dialog, though admittedly we don't have a mock up for that yet [14:51] I right click the unity launcher icon to do it but it's a workaround [14:52] but we're definitely going to have implied consent there [14:52] jbicha, seb128: what if we mapped escape to "dismiss this dialog with the default action (send report)" ? [14:53] I also think that a lot of these changes layer on top of each other. When we fix the system errors so they get collected into a single dialog, hopefully the frequency you'll see this will go down and your need for a quick dismiss action will decrease [14:53] equally so when we add the "don't bother me again with this - just send the damn reports" ;) checkbox [14:56] mterry: does pcreate recognize raring yet? [14:56] ev: not sure about that, I would expect esc to "undo" the action, e.g exit without submitting anything [14:57] hmm, yeah [14:57] stokachu, it relies on underlying tools, it doesn't know about code names itself [14:58] mterry: ah, so debootstrap needs some modification [14:59] ev: during the devel cycle we can/have to assume some degree of "technical people", though [14:59] stokachu, yeah, I don't think quantal debootstrap is updated yet... [14:59] pitti: sure - how does that fit into the current conversation? Sorry, I'm just not making a clear connection there. [14:59] mterry: yea i dont even see it in devel branch [15:00] what about if we had different modes: 1. send crash reports automatically without getting asked every time (but with the ability to click a button to view the reports you've sent); 2. Ask me first so I can include additional info or decline to send the report 3. Don't send crash reports & don't notify me of crashes [15:00] it's in the q-proposed queue [15:00] ev: that was re "ev | the interactivity we currently have is confusing at best for non-technical people" [15:00] (debootstrap) [15:00] Laney: does this require a sru for precise as well? [15:01] if it's to be updated there, yes [15:01] pitti: oh, I see. Well, the intent is to have these server-side hooks on post-release. [15:01] and I think we end up with a lot of complexity if we're trying to maintain two sets - one for before release and one for after [15:01] stokachu: it's trivial if you want to do it; just adding a symlink raring→gutsy [15:01] Laney: ok, would it be a good idea to just update all scripts across the releases? [15:01] Laney: ok i can do that [15:02] I'd really like to get them implemented without interactive UI and see what the remaining cases are where we need some human interaction, then address those specifically [15:02] ev: people expect pre-release to be "buggy"; I hear regularly about people that think precise is more buggy than oneiric because of the popups [15:02] use bug #1068707 [15:02] Launchpad bug 1068707 in debootstrap (Ubuntu Quantal) "Add raring as a symlink to gutsy" [Undecided,Confirmed] https://launchpad.net/bugs/1068707 [15:02] Laney: awesome thanks ill get that updated [15:02] ev: *nod* [15:02] jbicha: I don't think people should ever expect our software to be of poor quality. Our whole push at the moment is towards a rolling release [15:03] something that's stable throughout [15:03] sorry, I don't think we should ever settle for people expecting it to be buggy [15:03] I also think we make things harder for ourselves if we let things slide towards instability with the promise that we'll clean up the mess eventually [15:04] ev: people interpret those popups as "buggy"; I think defaulting from 2 to 1 closer to release is a good thing === dendrobates is now known as dendro-afk [15:04] jbicha: I did not understand the second half of your sentence. Can you elaborate, please? [15:04] and we can't make promises about Ubuntu being stable during the Alpha phase [15:05] ev: yeah, that was the "old" mode indeed, and we haven't been good at it given the constant feature pressure [15:05] why can't we make promises about it being stable during development (there are no more alphas) [15:05] ev: see my previous 3-mode comment [15:05] pitti: *nods* [15:05] but now that pressure has shifted around, and we have a lot more machinery in place to avoid regressions; I'm hopeful we can improve that enough to really make the dev release "stable" [15:05] yeah, me too [15:05] really excited as well [15:05] there's so much potential and good ideas here [15:06] ev: because then we land features at the last possible minute because we are too paranoid about regressions which makes the releases *worse* because they didn't get time to be tested in the actual repositories [15:06] well, they land two weeks after the last possible minute right now [15:06] there definitely is an Alpha stage still as long as we have autosyncs from Debian [15:06] jbicha: so the dialogs serve two purposes [15:06] that can't possibly get any worse [15:06] one is to let the user report the issue to us, and that's great [15:06] but the other and equally important need is that they actually explain what just happened === dendro-afk is now known as dendrobates [15:07] there are a lot of non-technical people out there who don't know what an application disappearing means [15:07] they need some further explanation [15:07] and that's what the dialog does [15:07] jbicha: putting those through -proposed is already making a rather big difference [15:07] plus turning on automatic reporting requires some sort of initial consent anyway [15:08] ev: like the Amazon integration requires initial consent? ;) [15:08] zing! [15:08] jbicha: pretty sure you at least get a link of some legal text to read there [15:09] checkbox in the installer "Help us make your Ubuntu experience better" :) [15:09] and for the millions who are already using Ubuntu? :) [15:09] believe me [15:09] checkbox in the upgrader :) [15:09] I'd love to see lots of machines automatically sending us reports [15:10] but I think there is a real need here for some explanation [15:10] and for the technical people who don't want to see these dialogs, we'll have a very easy way to turn on automatic reporting in 13.04 [15:10] it doesn't automatically send kernel dumps though right [15:10] it doesn't automatically send anything right now [15:10] everything puts up a dialog that carries with it your implied consent to send us the information [15:11] we're reducing the number of dialogs as well, for those of you who weren't in the plenary or were watching at home as I crashed the live stream [15:11] sorry, wearing that like a badge of honour, but I'm most amused [15:12] ev, is there something that detects if it is a kernel dump and explains possible security implications? [15:12] maybe we should keep track of how many turn on automatic crash reporting so that we can get an actual sample size for our bugs/install ratio [15:12] stokachu: https://wiki.ubuntu.com/ErrorTracker#kernel-crash [15:12] jbicha: we will [15:13] Laney: is debootstrap out of sync with bzr and whats being released? [15:13] I'm all about measuring, and you can rest assured that we'll have a percentage of systems that report crashes which have done so automatically [15:13] stokachu: it would not surprise me; I didn't use bzr myself [15:13] debootstrap has never been maintained in bzr [15:14] UDD bzr presumably [15:14] any resemblance there is probably coincidental [15:14] so when im doing patch work i was under the impression i always pull from latest bzr in launchpad [15:14] it often doesn't work desperately well for SRUs ... [15:14] you should always double-check versions against rmadison output or LP [15:15] if UDD bzr is in sync, great, otherwise do something else [15:15] cjwatson: thats kind of confusing dont you think? [15:16] Yes [15:16] I'm stating current reality [15:16] lol ok [15:16] If we had any resource to polish UDD properly, it'd be different [15:16] no problem ill just adjust my workflow [15:18] ev: this dialog just says it experienced an internal error, but doesn't say anything about if its a kernel dump that could be 50 gigs and that you are sending what was currently dumped in memory [15:18] i dont think financial instituations would want that whether it be desktop or server [15:18] or governments.. or ninjas [15:19] How long should it take for UDS-R tasks to show up on status.ubuntu.com/ubuntu-raring/people.html ? [15:19] mfisch: status.u.c should be mostly up to date after FeatureDefinitionFreeze [15:19] stgraber: thanks [15:21] stokachu: you may not be sending the dump if we already have one for that signature. Institutions can completely disable error reporting if they don't want sensitive information leaking out (Google and Ericsson do this). === salem_ is now known as _salem [15:24] ev: but that disables for everything, couldnt we have a blacklist? [15:25] and maybe have kernel set as a default [15:26] stokachu: we want kernel crashes. [15:26] ev: oh is it just stack traces sent and not actual core dumpes [15:26] dumps* [15:26] no - a subset of the systems are sending us core dumps. [15:26] ev: but not kernel? [15:27] sensitive information is possible in an application crash too [15:27] disabling crashes system wide is the right thing to do if you're a company that cares about these sorts of things [15:28] we don't have kernel crashes full wired up yet. When they are, a subset of the systems out there will be sending the full dumps, yes. [15:28] do note that we don't even get a lot of those === _salem is now known as salem_ [15:29] the conditions for actually being able to write a kernel crash to disk mean that they're not going to ever approach the frequency of regular application crashes [15:30] ok [15:31] bah, hard disk shows I/O errors again ... [15:31] ev, I'm looking at a stack trace @ errors.ubuntu.com. The error is present in several versions of pulseaudio - from which version are the actual stack trace - line numbers differ between releases? [15:32] diwic_: oh interesting [15:33] so we don't currently track that [15:33] give me one moment to just see if we can easily grab it given the information we have [15:33] ok [15:43] Laney: ok i uploaded a debdiff to that debootstrap bug [15:43] cool cheers [15:43] can you subscribe the sponsors? [15:43] i'll try to look in a bit anyway [15:44] Laney: yea i got sponsors and sru subscribed so it should be int he queue [15:44] <_val_> Hey guys. When are you going to release a spice-xpi package? Compiling this the source of spice-xpi gives me head ache. Someone? [15:44] Laney: thanks :D [15:46] <_val_> the xulrun-embedder.. not found... etc.. is not solveable. [15:54] _val_: did you see this https://launchpad.net/spice-xpi [15:55] _val_: spice-client in quantal? [15:59] <_val_> stokachu: looking at it [16:00] what's the status of autosyncs for r? [16:00] <_val_> jpds: I meant the precise [16:00] seb128: enabled [16:00] <_val_> I need the precise build [16:01] seb128: in fact they're now fully automatic rather than in cron.cjwatson [16:02] seb128: are you looking for something in particular? [16:02] cjwatson, no, just not being fully awake, I was looking at http://people.canonical.com/~platform/desktop/desktop.html but we didn't change the serie so it's listing quantal versions ... [16:03] heh, ok [16:03] sorry for the noise ;-) [16:03] cjwatson, good to read that syncs are fully automatic now though ;-) [16:03] indeed [16:03] cjwatson: btw, my anxiety is gone: http://people.canonical.com/~ubuntu-archive/testing/raring-proposed_probs.html actually is non-empty :) [16:04] heh, yeah, it is occasionally [16:04] that one should clear shortly [16:05] my hands are itching to graphviz-ify http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html [16:05] but that's not straightforward, one needs more info than on that page to get the dependencies apparently [16:05] oh, I should proposedify ben really [16:05] * Laney slots that into the todo [16:06] or there just are not any excuses due to uninstallability [16:08] _val_: you can get the source from launchpad and rebuild for precise and fix any errors there [16:09] Laney: qu'est-ce que c'est "ben"? [16:09] another magic archive status tool? [16:09] transition tracker [16:27] stgraber: could i get bug 423252 put under the libgcrypt11 package it is currently set to sudo [16:27] Launchpad bug 423252 in sudo (Kairos Linux) "NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd" [High,Confirmed] https://launchpad.net/bugs/423252 [16:28] stokachu: hmm, I see it already has a libgcrypt11 task, what exactly do you mean with "put under"? [16:30] stokachu: when only accessing by bug number instead of the full URL LP seems to be taking some random task (or maybe the first?), but accessing the bug with https://bugs.launchpad.net/ubuntu/+source/libgcrypt11/+bug/423252 should give you the right view [16:30] Launchpad bug 423252 in sudo (Kairos Linux) "NSS using LDAP+SSL breaks setuid applications like su, sudo, apache2 suexec, and atd" [High,Confirmed] [16:31] stgraber: ok i just didnt know b/c it says in "sudo" [16:31] stgraber: i guess it doesn't matter? [16:31] stokachu: apparently somebody added a sudo task for Debian to that bug and ubottu is using that one when you mention the bug on IRC, that's all [16:32] stgraber: ok no worries then [16:37] are auto-syncs from testing, unstable, or experimental? [16:37] #ubuntu-devel, I submitted a merge proposal for lp 967229, just wanted to confirm that someone can review it [16:37] Launchpad bug 967229 in plymouth (Ubuntu) "Text mode shown briefly with various "cryptic" texts when logging out or shutting down" [High,Triaged] https://launchpad.net/bugs/967229 [16:38] achiang: unstable [16:40] ta [16:41] achiang: we may go back to testing for the next LTS cycle (14.04); OTOH we may not if our own stability protections are working out well enough by then [16:41] achiang: experimental is right out :) [16:42] cjwatson: heh, ok. i'll ask motu to sync a small package of mine from experimental. :) [16:42] sure - with syncs being self-service there isn't much reason to put lots of effort into selective auto-syncing from experimental or what-have-you [16:43] cjwatson, did you ever try that raring update on your nexus you asked about ? [16:43] ah, that makes sense. [16:44] * ogra_ is curious if it survived [16:44] 14:32 ogra_: I upgraded my nexus7 to raring (after pinning the ubuntu-nexus7 PPA) and found that Unity failed to start because the runtime linker failed to find libnvwsi.so for [16:44] /usr/lib/nux/unity_support_test, even though /usr/lib/nvidia-tegra still seems to be in ld.conf.d and that library is there. I worked around it for now by symlinking that library into [16:44] /usr/lib/arm-linux-gnueabihf/, but I assume that's wrong. Is this known? [16:44] 14:32 (There was also an onboard regression with python3.3, and I just uploaded a backport of the upstream fix for that) [16:45] ogra_: ^- results [16:45] oh, thx ! [16:45] so the verdict is "almost" [16:45] yeah, thats a bug in the nvidia package the libs have no SONAMEs [16:46] i guess the linker ges confused by that [16:46] *gets [16:46] um, right, but I didn't notice those packages changing from quantal to raring [16:46] ogra_: i thought there was a fix for that? [16:46] achiang, only for tegra2 [16:46] unless glibc 2.16 is stricter [16:46] I didn't try to narrow it down much further [16:46] ogra_: do you have a bug for tegra3? i can escalate to nvidia [16:47] achiang, nope, i'll create one but ebroder is fully aware of the issue [16:47] he was the one who got me the tegra2 rebuild, and promised me tegra3 would be fixed in their next release [16:48] cjwatson, i'm pretty sure you simply got the tegra3 package from raring, the PPA one has a .links file to work around the issue ... linking all libs to /usr/lib, i was a bit reluctant to push that into the official archive [16:48] ogra_: got it, thanks [16:49] ogra_: i think you meant e. brower, not ebroder :) [16:49] err, yesw [16:49] heh [16:49] ogra_: let me unpack my nexus7 and check [16:50] downgrading to the PPA package would fix it in that case [16:50] cjwatson: you mean it's not your primary dev machine yet? [16:50] what's the full package name? [16:50] i should probably just upload the hack to raring ... as ugly as it is it helps atm [16:50] nvidia-graphics-drivers-tegra3? [16:50] Laney, yep [16:50] ogra_: I pinned the entire PPA, so I'm sceptical about that answer [16:50] I don't have that installed at all [16:51] binary is nvidia-tegra3 [16:51] ah [16:51] achiang: :-P [16:51] ubuntu@nexus7-bisquicks:/usr/lib/arm-linux-gnueabihf$ dpkg -L nvidia-tegra3 | grep libnvwsi [16:51] /usr/lib/nvidia-tegra/libnvwsi.so [16:51] /usr/lib/1libnvwsi.so [16:51] EEEK ! [16:51] * Laney giggles [16:52] oh dyslexia ! [16:52] lol "bisquicks" [16:52] haha, yeah [16:52] * Laney is quite pleased with that [16:54] sadly, we are going to roll the image again to change that due to http://goo.gl/826tPall and http://pad.lv/1072086 [16:54] Launchpad bug 1072086 in ubuntu-nexus7 "Having random hostnames can result in offensive hostnames" [High,Fix committed] [16:55] well, we probably want a fix for that typo above as well :) [16:55] achiang: first one doesn't work [16:55] though i dont get why that would affect release upgrades [16:56] * Laney reboots hopefully into R ... [16:56] Laney: someone out there got nexus7-m*****f***** [16:59] oh, the correct link was http://goo.gl/826tP [16:59] aha [17:00] I was going to suggest a wind-up, but the phrasing there makes me think it is not [17:03] achiang: lol [17:06] ogra_: for the record, "tegra" appears nowhere in dpkg.log for the day I did the upgrade [17:06] ok [17:06] ogra_: also, I wonder if there's a general robustness problem here; it seems kind of odd for a failure in unity_support_test on a system with no non-unity fallback to result in a blank screen rather than some attempt at a usable desktop [17:06] cjwatson, well, libnvwsi.so is fixed now, just uploaded to the PPA [17:07] great, thanks [17:07] oh, there definitely is [17:07] and i think that was also discussed in some desktop session [17:08] so i think i should upload the same "fix" to raring for now [17:19] stgraber: could i get bug 1013798 nomination approval? [17:19] Launchpad bug 1013798 in libgcrypt11 (Ubuntu) "Blink SIP client segfaults with libgcrypt11 1.5.0-3ubuntu0.1" [Critical,Confirmed] https://launchpad.net/bugs/1013798 === dendrobates is now known as dendro-afk === dendro-afk is now known as dendrobates [17:21] stokachu: done [17:21]