=== _salem is now known as salem_ === fisted_ is now known as fisted === salem_ is now known as _salem === slank is now known as slank_away [02:33] tjaalton: when you get a chance would you be able to let me know if you are still in a position to get bug 1012900 uploaded to -proposed so that we can get it started with an SRU? [02:33] Launchpad bug 1012900 in sssd (Ubuntu Precise) "Using SSSD, PAM error when exiting su session" [High,Confirmed] https://launchpad.net/bugs/1012900 === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha === chilicuil_away is now known as chilicuil [03:09] stokachu: more or less done with adapting the patch, if it builds ;) [03:10] Does anyone know what files the ubuntu software center reads to determine the category an app is placed in? Anyone have any documentation? [03:13] israeldahl: check apt-cache show for whatever package you're ciurious about; see if the Task: header matches the software center task [03:15] israeldahl: the .desktop files [03:15] well, my problem is an app in the software center doesn't appear in the correct category, and I need to set it to the correct category (there is no Task: header when I ran your command) [03:17] the desktop file is in the source code, but it doesn't get installed (or at least not in the /usr/share/applications directory) [03:17] israeldahl: I think it uses the files from app-install-data* [03:18] app-install-data... sorry what is that? any docutmentation or explaination is much appreciated [03:19] it's a package [03:21] oh sorry... [03:22] there's a doc explaining all this somewhere I think, don't remember where offhand [03:24] micahg: Well, it doesn't have a man or help.... I guess I'll search a bit.. [03:30] micahg: do you have any idea how to use it? I am not finding anything that explains much about it. thanks for your help [03:33] israeldahl: looking quickly I think you want to update the package itself first, then rebuild app-install-data or something [03:34] by the package itself I mean the application which isn't listed in the right category [03:35] israeldahl: perhaps ask mvo when he's around [03:36] mvo? Ok. is app-install-data something that works alongside bzr? or is it a local thing only... there is no documentation that I have found yet [03:37] sorry for my strange questions... and thanks for ayour patience with me [03:54] cyphermox: awesome man, was the dnsmasq binding code a pain or did it go pretty smoothly? [03:55] anyone around that could take a look at a package in the unapproved queue for lucid? its the portmap one for bug 688550 [03:55] Launchpad bug 688550 in portmap (Ubuntu Lucid) "portmap/statd can not be restarted" [High,In progress] https://launchpad.net/bugs/688550 [03:55] https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=portmap === chilicuil is now known as chilicuil_away [04:08] stgraber: got a minute to look at the portmap package in the unapproved queue for lucid? [04:09] stokachu: I have a minute, but not being on the SRU team, there's little I can do for you :) [04:10] i need it sponsored mainly [04:11] ah nm i see it was sponsored [04:50] stokachu: Hah. You emailed me about that just as I accepted it. [04:52] @pilot out === 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: [05:14] stokachu: yes, I think 1.8.5 has been sitting on the ppa long enough === attente is now known as attente_zzz [06:10] Good morning [06:10] morning pitti :) [06:12] hey sarnold [06:17] oh, whoever processed SRUs, thanks for catching up! [06:17] * pitti got a rather large bunch of accepted mails; I already forgot that I did most of those [06:18] oh, bdmurray apparently [06:45] hmm, apt-cacher-ng apparently has a nervous breakdown from time to time, causing it to continuously establish and reset connections to some servers. [06:45] very weird === Ursinha is now known as Ursinha-afk [07:59] good morning [08:00] slangasek: bug bug :P === Ursinha-afk is now known as Ursinha [08:15] tjaalton: 2:2.20.14-0ubuntu1 was meant to fix my sandybridge lockups, right? I may have just experienced another. Though, hard to say for sure, I got not apport telling me about it. :/ [08:19] infinity: did you try sna? I've been running with uxa (default) since the update, and it hasn't hung here (yet) [08:19] tjaalton: Not sure how to try SNA, but also wasn't keen on trading one set of issues for another. [08:20] tjaalton: (Plus, if the default doesn't work, we kinda want to know, surely...) [08:20] infinity: yeah but the default will change before too long [08:21] so we're close to the point where it'd be nice to know if the new one has or hasn't any regressions [08:21] tjaalton: Anyhow, in this case, since I have no apport crash thingee to backup my assertion, it's entirely possible that the freeze was something else. [08:21] true [08:21] how did it hang? [08:21] tjaalton: "Nothing on my screen except the cursor updates, and after I VT switch, it's okay again" doesn't mean much without some debugging info. [08:23] infinity: well that could be sna specific anyway [08:27] infinity: and upstream is getting less motivated to fix issues with uxa where sna is known to work :/ [08:29] hrw: Why did you drop multilib armel/armhf cross support? [08:29] hrw: We don't ship armel anymore, but it's still wildly handy to be able to cross-build soft-float stuff (our regular toolchain is still biarch) [08:36] infinity: I did that due to build problems [08:36] infinity: you can always install armel cross toolchain [08:37] hrw: Build problems? Curious. Our base toolchain builds multilib fine still. [08:37] hrw: Or was this for the brief period that I had glibc a bit broken, I wonder? [08:38] hrw: Anyhow, what you've done it make the gcc-4.6-cross stuff uninstallable, so either we need to re-multilib gcc-4.7-cross, or unmultilib gcc-4.6-cross, or drop gcc-4.6-cross entirely. [08:38] s/done it/done is/ [08:39] infinity: let me check then [08:40] pdebuild started [08:52] ARGH... [08:53] when the hell ARM will get promotion to be first class citizen in Ubuntu... [08:53] http://packages.ubuntu.com/raring/libc6-dev still lists only x86 [08:54] to check what is in package on armel/armhf I have to go to launchpad, dig there, fetch packages, check their contents. [08:55] ops, there is no armel anymore [08:59] infinity: armhf has gnu/stubs.h and gnu/stubs-hard.h, armel has gnu/stubs.h and gnu/stubs-soft.h but multilib compiler expects both at same place for both arches [09:01] hrw: Which is why multilib compilers need to depend on libc-dev-alt (ie: libc6-dev-armel if you're on armhf) [09:01] hrw: gcc-multilib and g++-multilib do this right. [09:02] infinity: I am tired of this toolchain stuff. [09:02] hrw: packages.ubuntu.com isn't run by us, the class of citizens has nothing to do with it. :/ [09:03] infinity: it is also not run by Oracle or other non-ubuntu-development company [09:03] *blink* [09:03] What? [09:03] packages.ubuntu.com has address 91.189.94.203 [09:03] 203.94.189.91.in-addr.arpa domain name pointer jubany.canonical.com. [09:04] Yeah, it's hosted by us. It's run by a community member and DD. [09:07] stokachu: infinity: slangasek: raid + luks, I had a recipe somewhere I think... [09:07] will mail ubuntu-devel ;) [09:07] hrw: ubuntu-devel has nothing to do with it. [09:07] "To report a problem with the web site, e-mail rhonda@ubuntu.com." [09:08] And, by all means, ask him to include all arches. [09:09] easier to go to #ubuntu-motu or /query [09:10] I just asked him about it on oftc. [09:10] ;) [09:16] hrw: I can look at all this cross stuff tomorrow, if you like. Or we can just drop or unmultilib 4.6, I'm not picky. [09:17] hrw: But it makes more sense (to me) to have one multilib-capable compiler, rather than building two that aren't. (So, just armhf, but make it do multilib again). I dunno, though. [09:17] infinity: issue probably exists in arm{el,hf}-cross-toolchain-base package === henrix_ is now known as henrix [09:52] cjwatson: doko_ : is binutils uploading soon to drop the ":any" from gettext? jenkins autopkgtest is sad because of this =) [09:52] https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ === Tonio_aw is now known as Tonio_ === Tonio__ is now known as Tonio_aw [11:06] I get the feeling this is a fantastically stupid question, but all the docs on running a Quantal kernel on Precise point to https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport yet the packge list there does not have any kernel packages (just x-org). Which part of my brain needs rearranging? [11:06] argg that was meant to be in ubuntu-kernel - sorry [11:06] @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: seb128 [11:25] * dholbach hugs seb128 [11:26] * seb128 hugs dholbach back === _salem is now known as salem_ [11:45] Anyone have guesses as to why compiz has a .desktop file? https://bugs.launchpad.net/apport/+bug/1048524 [11:45] Launchpad bug 1048524 in Apport "Compiz crash inappropriately presented as an application" [Low,Confirmed] [11:47] oh, NoDisplay=true === Tonio_aw is now known as Tonio__ === Tonio__ is now known as Tonio_aw [12:18] ev, because that's need for gnome-session to start it [12:18] seb128: ah, right. Already resolved though - apport needs to pay attention to the NoDisplay field [12:18] thanks! [12:18] ev, e.g /usr/share/gnome-session/sessions/ubuntu.session DefaultProvider-windowmanager=compiz [12:18] ev, it will look for a compiz.desktop [12:18] ev, ok ;-) [12:19] seb128: while I have you here, any idea why nautilus doesn't ship a desktop file? [12:20] ev, /etc/xdg/autostart/nautilus-autostart.desktop ? [12:20] ev, /usr/share/applications/nautilus.desktop [12:20] ev, or what do you mean? [12:20] ah, was looking in the wrong place there [12:21] but it sets NoDisplay=true - is that right? Wouldn't we want this to appear in menus? [12:21] in the applications list, that is [12:21] ev, which one? [12:21] nautilus [12:21] ev, /usr/share/applications/nautilus.desktop has no NoDisplay [12:22] ev, the etc one is the autostart, we do that to make gnome-session-properties' list "clean" by default, e.g not list system services but only user jobs === cpg is now known as cpg|away [12:23] right - for some reason I don't have /usr/share/applications/nautilus.desktop [12:23] ev, sudo apt-get install --reinstall nautilus [12:25] fixed. Very strange. I wouldn't have removed that myself. [12:25] Thanks seb128, and sorry for the noise. [12:25] ev, yw! [12:25] ev: can we tell how many .crash reports we get sent that don't have a SAS? or are these already rejected at the client side? [12:26] ev: I know what's wrong with these, but there's two different solutions and I'm not entirely sure which one is better [12:26] pitti: https://bugs.launchpad.net/daisy/+bug/1085004 - not yet, unfortunately [12:26] Launchpad bug 1085004 in Daisy "We should increment counters for each type of corrupted report received" [High,Triaged] [12:26] ev: ack [12:26] well, we can count them with a script [12:26] but that will take a while [12:26] Hadoop will fix that [12:27] we can write a job in Pig Latin that counts the total number of reports and the number without SAS fields [12:27] and it will be much quicker than what we have today [12:27] so, I think I'll go with the option that is 100% safe and plausible, and should catch most of those (if not all) [12:28] OdyX: I still don't see the VCS tag being removed from cups-files.conf...the regex is looking for "$Id:", but the cups-files.conf file has "$Id$" in it [12:29] okay [12:29] I've updated that bug to note that we should increment the counters by release/apport version so we can track fixes like these [12:29] OdyX: we should probably change it to "\$$Id[:\$$]" [12:30] mdeslaur: aww shit [12:30] mdeslaur: I'm working on the 1.5.3 and un-dpkgconffile'ing currently. [12:31] mdeslaur: /etc/cups/cupsd.conf shouldn't be a conffile. [12:31] mdeslaur: You missed a lively discussion in #debian-devel about cups's conffile abuses. [12:31] oh you here too :) [12:31] hrm? how is it not a conf file...now I regret missing that discussion :) [12:33] mdeslaur: It *is* a dpkg conffile, but it really shouldn't be, since cupsd modifies it during runtime, apparently. [12:34] mdeslaur: Which is just so many kinds of ewwww. [12:34] during runtime? [12:34] So I'm told. [12:35] @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: jdstrand, seb128 [12:35] It creates new ones based on cupsd.conf.default === Tonio_aw is now known as Tonio__ [12:35] So, THAT can be (and is) a conffile, but cupsd.conf shouldn't be,. [12:35] infinity: do you ever sleep? :P [12:35] pitti: PyGIDeprecationWarning: Calling io_add_watch with a file object is deprecated; call it with a GLib.IOChannel object [12:35] jdstrand: No. [12:35] wait a sec, no it doesn't [12:35] pitti: where file, is a socket. Any porting samples? [12:35] 'nuff said [12:36] mdeslaur: The web interface mangles cupsd.conf. (This is all second-hand from OdyX, but I'm not sure why he'd lie...) [12:36] yes, the admin can use the web interface to change settings in cupsd.conf [12:37] can the vlc-nox bug (no 81) on https://errors.ubuntu.com/ reassigned against libproxy? [12:37] infinity, mdeslaur : http://paste.debian.net/213533/ <- that would be the un-conffile'ification. Comments ? [12:37] mdeslaur: If they change a value and change it back, will the file end up identical to the original? [12:38] infinity: just tested, no. [12:39] Then yeah, that's not a conffile, it's a config setting cache, at best. :P [12:39] OdyX: Hrm, the compare-versions upgrade magic might be problematic if you're doing this to multiple releases. [12:41] OdyX: Though, I guess accidentally triggering the move around thing on more than one upgrade doesn't actually hurt anything either. [12:41] infinity: why ? in that case it would be moved back and forth without problems, no ? [12:41] Jinx. :) [12:43] infinity: oh, right...I see what you mean [12:43] infinity: although, it doesn't read the cupsd.conf.default file either [12:43] OdyX: It also needs an abort-upgrade case in postrm, if I'm nitpicking. === tkamppeter_ is now known as tkamppeter [12:44] mdeslaur: No? Curious. Then what's it for? :P === doko_ is now known as doko [12:44] mdeslaur: I think it does, but I might be wrong. [12:44] pitti: anyway pushed bzr-dbus branch for review. [12:44] =) [12:44] OdyX: in what circumstance? [12:46] - The web interface now pulls the default cupsd.conf file [12:46] from cupsd.conf.default in the CUPS config directory. [12:46] ^-- From the changelog. [12:46] But not sure where that happens in the code. [12:47] cgi-bin/admin.c:2077 [12:47] (In the raring version, anyway) [12:48] xnox, ? [12:48] doko: do you "maintain" binutils in raring? [12:48] He does, even without quotes. [12:49] doko: https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/job/raring-adt-binutils/ARCH=amd64,label=albali/18/artifact/results/log/*view*/ [12:49] mdeslaur: pushed some reverts and the cvs thing to master / git. [12:49] yeah, I'm just looking at that [12:49] xnox: Pretty sure Colin already poked him about it. [12:49] doko: dpkg-checkbuilddeps: Unmet build dependencies: gettext:any [12:49] doko: if you upload that soonish, QA will be happy to see a bulb go green on binutils. [12:50] infinity: doko: ack =) [12:50] It's not world-ending to wait for his next real upload. [12:50] The thing didn't even have an autopkgtest until 4 days ago, after all. :P [12:51] OdyX, infinity: it seems to load it, and not do anything with it...how odd... [12:51] mdeslaur: Yeah, cause that's the ONLY odd behaviour cups has. [12:51] hehe [12:51] :) [12:52] I keep waiting for "printing on Linux" to become a self-solving problem when people just stop buying printers. [12:53] infinity: hehe, good luck with that :) [12:53] I think my parents' generation needs to be collectively hit by a rather large number of busses to make that happen. [12:55] infinity: http://paste.debian.net/213538/ <- that way then ? [12:56] OdyX: I'm still waiting for upstream to decide what to do with DefaultAuthType === amitk is now known as amitk-afk [12:57] mdeslaur: I'm kinda disappointed by apple's reactiveness in this all affair. [12:58] yeah, well, they do only have a single developer working on it :P [12:58] isn't everyone root on OS X anyway? :)_ [12:59] OdyX: That looks better. [13:00] .oO(I should have stopped coding/debugging yesterday night earlier. when you start calling classes CopKiller its a bad sign ... [13:01] Sweetshark: I assume this relates to DCOP more than, say, police officers? [13:01] xnox: ah, I'm actually considering to revert the deprecation for python file-like arguments; it's just easier that way [13:02] pitti: well, I've wrapped it in a IOChannel object, but then the handler function was complaining that the source is no longer a file object & is missing some function. [13:02] pitti: sounds like a good idea. [13:03] xnox: as for the porting, if you have an fd, the canonical syntax is GLib.IOChannel.unix_new(fd) [13:03] or GLib.IOChannel.unix_new(f.fileno()) for a python-y file [13:04] pitti: hmm... I did GLib.IOChannel(mysocket.fileno()) [13:04] pitti: where mysocket is socket.socket() [13:04] infinity: neither, I was a test class that implemented a thread that should kill the libreoffice instance from the inside with vengeance. it didnt succeed. [13:06] xnox, infinity: does the world survive when I do this next week with another upload? if not, please go ahead and upload [13:06] xnox: right, that works too; I added overrides for the IOChannel ctor to accept an fd or a file object [13:06] pitti: ack. [13:06] infinity: so killer was approprioate, but I lacked the creativity to put something sensible infront of it. as it was testcode and that bodycount song crossed my mind, I used that. [13:07] pitti: is it ok to have a hanging red bulb in adt on binutils, or would you prefer for me to upload a trivial fix? [13:07] doko: It's not a big deal to toss it in your next upload, if QA's staring at jenkins results over the weekend and fretting about them, they need to find other things to do. :) [13:11] xnox: fine to keep the red bulb for a week or so [13:11] xnox: it will become a blocker for upload once we build autopkgtest results into britney, but we haven't yet [13:12] xnox, doko: so don't worry about uploading this now; we have more red dots which require real fixes [13:18] mvo: I was told you might be able to tell me what the software-center looks at to determine a category for an app [13:19] xnox: responded to https://code.launchpad.net/~xnox/bzr-dbus/pygi/+merge/137173, thanks! [13:19] infinity: still around? [13:20] pitti: thank you for review ;-) [13:20] henrix: Maybe. [13:20] infinity: :) [13:20] infinity: i'm seeing something odd: [13:20] henrix: 'sup? [13:20] $ rmadison --architecture=source linux-meta | grep precise [13:20] linux-meta | 3.2.0.23.25 | precise | source [13:20] linux-meta | 3.2.0.33.36 | precise-security | source [13:20] linux-meta | 3.2.0.34.37 | precise-updates | source [13:21] -security has a different -meta version [13:21] Huh. Weird. I didn't get a reject on that. [13:21] henrix: Launchpad claims it's right. rmadison could be lying. [13:21] and there was another pkg with similar prob (/me checks) [13:22] linux-meta-lts-quantal has the same prob [13:22] infinity: ok, so you believe this is something transitory? [13:22] henrix: I'm checking the archive itself. [13:23] infinity: cool, thanks [13:23] tjaalton: seems you were right, I updated bug 1081009 [13:23] Launchpad bug 1081009 in linux (Ubuntu) "[arrandale] GPU lockup IPEHR: 0x02000022" [High,Triaged] https://launchpad.net/bugs/1081009 [13:23] tjaalton: thanks for the hint! [13:23] Version: 3.2.0.34.37 [13:24] henrix: ftpmaster is right. Let me check security.u.c [13:24] henrix: security.u.c is also right, so rmadison's just lost the plot. === dholbach_ is now known as dholbach [13:25] infinity: ok [13:25] infinity: i found this issue because the bot was complaining about these 2 packages [13:25] Anyone know how software-center categorizes apps? What file does it read to categorize them? [13:26] pitti: nice :) [13:27] Hrm. madison-list on lillypilly gets it right. Perhaps the new caching for rmadison is a bit too agressive. :P [13:27] s/list/light/ [13:27] infinity: ok, so this is something that will eventually get fixed, right? [13:28] infinity: you checked both packages? [13:29] henrix: Both are fine, yeah. [13:29] infinity: cool, thanks! [13:32] Oh, bah, I'd clear rmadison's cache, but I can't write to it. Brilliant. [13:34] infinity: now, another question: if automagically migrating stuff to the new cups-files.conf shouldn't happen, then at least a NEWS.Debian is in order, right ? [13:35] ev: wow, you're on a bug triaging spree :) [13:36] OdyX: A NEWS.Debian might be in order. === popey_ is now known as popey [13:38] israeldahl: yeah, please check /usr/share/app-install/desktop/software-center.menu [13:40] mvo: thank you! If a program doesn't display in the correct category in software-center what file is it missing? [13:42] henrix: rmadison should be sane again. [13:42] israeldahl: it could be a bug, it could be that menu file there or it could be something in the desktop file of the application - what desktop file is this? [13:42] infinity: it is! cool! thanks [13:44] well, the program lmms doesn't install a desktop file (though the if I bzr branch it I find it present, I also find the menu file as well) which is another problem as well [13:44] mvo:not sure how to even fix it [13:47] israeldahl: hm, it looks like the binary package lmms does not contain a desktop, if that file would be present in the package it would show up in software-center [13:48] infinity: actually, migrating automatically might actually be harmful if one migrates an attack to the new file. [13:48] mvo: so is it the desktop file that contains the information to tell software center. Can lmms be patched to contain it, or does it need to be repackaged all together? === attente_zzz is now known as attente [13:50] mvo: also... a ppa exists with a valid desktop file in the binary which shows in the menus (dash, etc..), should users be able to see that in the software-center, because they report not being able to. [13:52] israeldahl: the software-center scans only he main archive packages (and the data from softwrae-center-agent.ubuntu.com), but not from PPAs [13:52] pitti: :) [13:53] israeldahl: so idally a update for the archive packages should fix it [13:54] mvo: oh, ok... that makes sense. So just merging the upstream source should work (Debian doesn't have a current real maintainer for this package)? So I can just do a bzr merge? [13:55] israeldahl: that sounds like a plan, you can probably bzr merge, I don't know the package in quesion, but there should be bzr branch for ubuntu and debian that you can use [13:57] mvo: I already have the branch on my computer, and I also already "sent" the newer version to merge in precise. Is there anyway to check on the status of this? I followed this guide http://developer.ubuntu.com/packaging/html/udd-merging.html#merging-a-new-upstream-version [14:05] israeldahl: except for important fixes precise is frozen, its best if you prepare it for the current development version (raring) [14:06] mvo: Ok! Can I at least patch it somehow? [14:06] israeldahl: for precise you mean? or for raring? [14:06] mvo: for precise and quantal [14:07] israeldahl: that is possible but a bit more involving, see https://wiki.ubuntu.com/StableReleaseUpdates - easiest is probably to just add it to "app-install-data-ubuntu" in both precise and quantal [14:09] mvo: I have a raring iso raring to go, I will try to merge through that (can I just do that in precise?) === scott-wokr is now known as scott-work [14:17] mvo: thanks so much you have definetly helped me!! [14:29] doko, infinity, do you have a packaging vcs for eglibc? could you commit https://code.launchpad.net/~bkerensa/ubuntu/raring/eglibc/depends-fix1/+merge/135995 in it so it gets out of the sponsoring queue? ;-) === slank_away is now known as slank [14:36] ev, bug 1084979 [14:36] Launchpad bug 1084979 in Apport "Submitting error report asks confounding questions" [Medium,Confirmed] https://launchpad.net/bugs/1084979 [14:40] xnox: orly? [14:43] stokachu: ha. got carried away. Yeah, I think I did help somebody to get it working a few months ago. [14:43] stokachu: should look it up again. [14:44] xnox: that would be sweet if there was a way to get it working [14:48] stokachu: so there is no "partman-method/auto cryptoraid" [14:48] stokachu: so one must use expert recipe with stacking. [14:49] Riddell: hey, could yes give owncloud in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages a quick spin? [14:49] i was reading up on expert recipe but wasn't able to figure out how to do the crypto portion [14:50] Riddell: then comment in bug #1084109 if it works for you. If it does, I'll push it today [14:50] Launchpad bug 1084109 in owncloud (Ubuntu Quantal) "quantal security update" [Undecided,Fix committed] https://launchpad.net/bugs/1084109 [14:50] jdstrand: oh interesting, one of those got rejected I think [14:51] mm, oneiric got rejected, I'll upload that with fixed changelog [14:51] Riddell: I couldn't really make heads or tails of the quantal package. I ended up up doing the simple merge with what is in Debian unstable [14:52] Riddell: are you planning updates for precise and oneiric to 4.0.8 too? === mcclurmc_away is now known as mcclurmc [14:54] Riddell: if so and there isn't anything special for backporting, I can just upload to the security proposed ppa and then you can test those too [14:55] jdstrand: actually those are SRUs and they just empty the package, so different team [14:55] ah, ok [14:55] stokachu: I think it should be possible to use partman-auto-raid to setup two raid devices, then use format method crypto & then allocate the partitions correctly. [14:55] they can't be backported alas [14:55] works for me :) [14:55] Riddell: icky [14:55] stokachu: I will push a few branches and then work on implementing this. [14:55] stokachu: might take a little bit of time. Anything else I can do for you? [14:55] Riddell: do you have the bug number for that? I'd like to subscribe so that I can update our CVE tracker when they are accepted [14:56] jdstrand: bug 1079150 [14:56] Launchpad bug 1079150 in owncloud (Ubuntu) "Remove obsolete versions of owncloud " [Undecided,Confirmed] https://launchpad.net/bugs/1079150 [14:56] Riddell: thanks [14:57] that's really a shame [15:03] Riddell: how does owncloud provide packages if it can't be backported? [15:05] micahg: they include about 20 third party modules as part of the source, but several of them don't have preferred modifiable form (only minified javascript) and several others the packages in quantal are too old and require several other new or updated dependencies to be backported which won't be API compatible [15:16] jdstrand: yep works with the new package ( http://ec2-54-234-63-47.compute-1.amazonaws.com/owncloud/ foo/bar ) [15:20] \o/ [15:20] Riddell: thanks! [15:23] Riddell: pushed to quantal-security [15:24] pitti, can you put https://code.launchpad.net/~stijnbrouwers/ubuntu/quantal/kamoso/fix-missing-icons/+merge/134772 "Work In progress"? [15:24] thnaks jdstrand [15:24] seb128: oui, je peux :) [15:25] pitti, merci ;-) [15:27] Riddell, ScottK: does https://code.launchpad.net/~stijnbrouwers/ubuntu/quantal/kamoso/fix-missing-icons/+merge/134772 seems fine to you? it's basically making an icon change "webcamreceive" -> "digikam" [15:28] seb128: kamoso's currently unbuildable due to KDE graphics library API changes they haven't ported to yet. [15:28] It should go upstream as we'll need an update from them before we can get a new kamoso in raring. [15:28] ScottK, ok, there are 2 sponsoring requests for it in the queue, I asked details/upstreaming on both [15:29] seb128: You can point them at afiestas on #kubuntu-devel if you want. He's upstream. [15:29] ScottK, https://code.launchpad.net/~stijnbrouwers/ubuntu/quantal/kamoso/fix-thumbnails/+merge/135728 ... do you have a wiki page which explain how to report upstream bugs for KDE? [15:30] seb128: http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs [15:30] ScottK, I will add a comment on the merge request about that, let's see if the contributor finds his way to IRC ;-) [15:30] Riddell, thanks [15:33] ogra-cb_, https://bugs.launchpad.net/ubuntu/+source/gmp/+bug/1079831 ... do you know if "arm64" support patches are useful for Ubuntu? [15:33] Launchpad bug 1079831 in gmp (Ubuntu) "arm64 support for gmp" [Undecided,New] [15:34] or somebody who has a clue about arm flavors ;-) [15:35] infinity: ^^^ [15:36] seb128: Yes. [15:37] infinity, can you have a quick look if the fix for that bug seems fine to you? [15:37] infinity, did you see my eglibc misc:Depends comment earlier btw? ;-) [15:37] seb128: I think Colin already sponsored that, unless it's an updated patch. I'll look. [15:38] seb128: And no, I missed the eglibc mention. [15:38] infinity, oh, yeah, Colin did, thanks [15:38] infinity, it failed to build on arm btw :p https://launchpadlibrarian.net/124371003/buildlog_ubuntu-raring-armhf.gmp_2%3A5.0.5%2Bdfsg-2ubuntu2_FAILEDTOBUILD.txt.gz [15:39] infinity, doko, infinity, do you have a packaging vcs for eglibc? could you commit https://code.launchpad.net/~bkerensa/ubuntu/raring/eglibc/depends-fix1/+merge/135995 in it so it gets out of the sponsoring queue? ;-) [15:39] seb128: Yeah, not because of the patch, though. [15:39] seb128: I'll look at the misc:Depends thing and merge it in Debian, if sane. [15:39] infinity, thanks! [15:39] The complete lack of explanation on the MP isn't promising... [15:41] misc:Depends usually ends up being shorthand for "debconf", doesn't it? [15:41] infinity, the guy has been filling a stack of "add ${misc:Depends}" to Depends [15:41] That would make debconf Essential. Pretty sure we don't want that. [15:41] Well, transitively Essential. [15:41] infinity, not only, dh_gconf adds gconf to ${misc:Depends} for packages that ship a schemas for example [15:42] seb128: Sure, but for libc6, I don't think I'd get gconf. :) [15:42] infinity, feel free to reject it ;-) I don't think the guy knows much of what it's doing, he has been adding misc:Depends to random packages, he probably thinks that any not having it needs to be "fixed" [15:43] Well, you'd get debconf if you use debconf. [15:43] But I get being wary about automagic depends on a package like eglibc. :P [15:43] Laney: I do, but it's also guarded specifically so libc doesn't NEED it. [15:43] Methinks I'll just reject this. [15:44] works for me ;-) [15:44] It's a 'new contributor' initiative [15:44] Here's a list of packages with this lintian tag. Go fix them. [15:44] Laney, not sure those initiatives are useful... [15:44] Laney, that typically create work more than it's useful [15:45] dholbach: ^^^ [15:45] It'd be better if the list was curated to packages that it might benefit [15:45] ScottK, well I asked for help with filling in the right lintian tags [15:46] dholbach: Just making sure you're aware of the discussion. [15:46] And the contributor won't get very much after the first one or two trivial fixes when they know how the tools and sponsoring process works === yofel_ is now known as yofel [15:46] Hrm. Do I need to delete the MP to get it off the sponsors radar, or is a "disapprove" review enough? [15:46] infinity, it needs to be rejected [15:46] Work In Progress... [15:46] dholbach: I don't see a reject option. [15:46] (MP status, not MP comment status) [15:46] I think WIP works [15:46] at the top [15:47] or WIP, yes [15:47] Yeah, I have WIP, Needs Review, or Merged. [15:47] But none of those is true. [15:47] Weird that I can't reject... [15:47] yeah, dunno what's up with that, it's annoying [15:47] Just one weird thing about UDD [15:47] infinity, only TB people can [15:47] stgraber: Want to reject https://code.launchpad.net/~bkerensa/ubuntu/raring/eglibc/depends-fix1/+merge/135995 for me? :P [15:48] so I'm happy to disable the lintian tag bits in Harvest [15:48] Perhaps restrict it to universe packages or something [15:48] but it'd be shame if I did and then nobody replied in the ubuntu-devel@ discussion with some feedback [15:48] infinity: there you go [15:48] To be fair, if lintian is bitching about that for eglibc, I should add an override. [15:49] * infinity runs lintian on his source... [15:49] infinity: most of the time it's empty expansion, but lintian bitches about it because it is valid for dh_* commands to add substitues in misc:Depends. [15:49] I don't see a lintian warning for that. [15:49] right, lintian warnings don't always mean add this here [15:49] infinity: and if your package breaks with knew dh, it would be maintainers fault for not having misc. [15:49] (base)adconrad@cthulhu:~/build/eglibc/ubuntu$ lintian eglibc_2.16-0ubuntu8.dsc [15:50] W: eglibc source: unknown-field-in-dsc testsuite [15:50] ^-- My only warning. [15:50]