| === _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 | ||
| stokachu | 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 |
|---|---|---|
| ubottu | Launchpad bug 1012900 in sssd (Ubuntu Precise) "Using SSSD, PAM error when exiting su session" [High,Confirmed] https://launchpad.net/bugs/1012900 | 02:33 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === chilicuil_away is now known as chilicuil | ||
| cyphermox | stokachu: more or less done with adapting the patch, if it builds ;) | 03:09 |
| israeldahl | Does anyone know what files the ubuntu software center reads to determine the category an app is placed in? Anyone have any documentation? | 03:10 |
| sarnold | israeldahl: check apt-cache show for whatever package you're ciurious about; see if the Task: header matches the software center task | 03:13 |
| micahg | israeldahl: the .desktop files | 03:15 |
| israeldahl | 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:15 |
| israeldahl | 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 |
| micahg | israeldahl: I think it uses the files from app-install-data* | 03:17 |
| israeldahl | app-install-data... sorry what is that? any docutmentation or explaination is much appreciated | 03:18 |
| micahg | it's a package | 03:19 |
| israeldahl | oh sorry... | 03:21 |
| micahg | there's a doc explaining all this somewhere I think, don't remember where offhand | 03:22 |
| israeldahl | micahg: Well, it doesn't have a man or help.... I guess I'll search a bit.. | 03:24 |
| israeldahl | 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:30 |
| cyphermox | israeldahl: looking quickly I think you want to update the package itself first, then rebuild app-install-data or something | 03:33 |
| cyphermox | by the package itself I mean the application which isn't listed in the right category | 03:34 |
| cyphermox | israeldahl: perhaps ask mvo when he's around | 03:35 |
| israeldahl | 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:36 |
| israeldahl | sorry for my strange questions... and thanks for ayour patience with me | 03:37 |
| stokachu | cyphermox: awesome man, was the dnsmasq binding code a pain or did it go pretty smoothly? | 03:54 |
| stokachu | 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 |
| ubottu | Launchpad bug 688550 in portmap (Ubuntu Lucid) "portmap/statd can not be restarted" [High,In progress] https://launchpad.net/bugs/688550 | 03:55 |
| stokachu | https://launchpad.net/ubuntu/lucid/+queue?queue_state=1&queue_text=portmap | 03:55 |
| === chilicuil is now known as chilicuil_away | ||
| stokachu | stgraber: got a minute to look at the portmap package in the unapproved queue for lucid? | 04:08 |
| stgraber | stokachu: I have a minute, but not being on the SRU team, there's little I can do for you :) | 04:09 |
| stokachu | i need it sponsored mainly | 04:10 |
| stokachu | ah nm i see it was sponsored | 04:11 |
| infinity | stokachu: Hah. You emailed me about that just as I accepted it. | 04:50 |
| infinity | @pilot out | 04:52 |
| === 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: | ||
| tjaalton | stokachu: yes, I think 1.8.5 has been sitting on the ppa long enough | 05:14 |
| === attente is now known as attente_zzz | ||
| pitti | Good morning | 06:10 |
| sarnold | morning pitti :) | 06:10 |
| pitti | hey sarnold | 06:12 |
| pitti | 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:17 | |
| pitti | oh, bdmurray apparently | 06:18 |
| hyperair | 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 |
| hyperair | very weird | 06:45 |
| === Ursinha is now known as Ursinha-afk | ||
| dholbach | good morning | 07:59 |
| mlankhorst | slangasek: bug bug :P | 08:00 |
| === Ursinha-afk is now known as Ursinha | ||
| infinity | 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:15 |
| tjaalton | infinity: did you try sna? I've been running with uxa (default) since the update, and it hasn't hung here (yet) | 08:19 |
| infinity | tjaalton: Not sure how to try SNA, but also wasn't keen on trading one set of issues for another. | 08:19 |
| infinity | tjaalton: (Plus, if the default doesn't work, we kinda want to know, surely...) | 08:20 |
| tjaalton | infinity: yeah but the default will change before too long | 08:20 |
| tjaalton | 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 |
| infinity | 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 |
| tjaalton | true | 08:21 |
| tjaalton | how did it hang? | 08:21 |
| infinity | 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:21 |
| tjaalton | infinity: well that could be sna specific anyway | 08:23 |
| tjaalton | infinity: and upstream is getting less motivated to fix issues with uxa where sna is known to work :/ | 08:27 |
| infinity | hrw: Why did you drop multilib armel/armhf cross support? | 08:29 |
| infinity | 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:29 |
| hrw | infinity: I did that due to build problems | 08:36 |
| hrw | infinity: you can always install armel cross toolchain | 08:36 |
| infinity | hrw: Build problems? Curious. Our base toolchain builds multilib fine still. | 08:37 |
| infinity | hrw: Or was this for the brief period that I had glibc a bit broken, I wonder? | 08:37 |
| infinity | 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 |
| infinity | s/done it/done is/ | 08:38 |
| hrw | infinity: let me check then | 08:39 |
| hrw | pdebuild started | 08:40 |
| hrw | ARGH... | 08:52 |
| hrw | when the hell ARM will get promotion to be first class citizen in Ubuntu... | 08:53 |
| hrw | http://packages.ubuntu.com/raring/libc6-dev still lists only x86 | 08:53 |
| hrw | to check what is in package on armel/armhf I have to go to launchpad, dig there, fetch packages, check their contents. | 08:54 |
| hrw | ops, there is no armel anymore | 08:55 |
| hrw | 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 | 08:59 |
| infinity | hrw: Which is why multilib compilers need to depend on libc-dev-alt (ie: libc6-dev-armel if you're on armhf) | 09:01 |
| infinity | hrw: gcc-multilib and g++-multilib do this right. | 09:01 |
| hrw | infinity: I am tired of this toolchain stuff. | 09:02 |
| infinity | hrw: packages.ubuntu.com isn't run by us, the class of citizens has nothing to do with it. :/ | 09:02 |
| hrw | infinity: it is also not run by Oracle or other non-ubuntu-development company | 09:03 |
| infinity | *blink* | 09:03 |
| infinity | What? | 09:03 |
| hrw | packages.ubuntu.com has address 91.189.94.203 | 09:03 |
| hrw | 203.94.189.91.in-addr.arpa domain name pointer jubany.canonical.com. | 09:03 |
| infinity | Yeah, it's hosted by us. It's run by a community member and DD. | 09:04 |
| xnox | stokachu: infinity: slangasek: raid + luks, I had a recipe somewhere I think... | 09:07 |
| hrw | will mail ubuntu-devel ;) | 09:07 |
| infinity | hrw: ubuntu-devel has nothing to do with it. | 09:07 |
| infinity | "To report a problem with the web site, e-mail rhonda@ubuntu.com." | 09:07 |
| infinity | And, by all means, ask him to include all arches. | 09:08 |
| hrw | easier to go to #ubuntu-motu or /query | 09:09 |
| infinity | I just asked him about it on oftc. | 09:10 |
| hrw | ;) | 09:10 |
| infinity | 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:16 |
| infinity | 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 |
| hrw | infinity: issue probably exists in arm{el,hf}-cross-toolchain-base package | 09:17 |
| === henrix_ is now known as henrix | ||
| xnox | cjwatson: doko_ : is binutils uploading soon to drop the ":any" from gettext? jenkins autopkgtest is sad because of this =) | 09:52 |
| xnox | https://jenkins.qa.ubuntu.com/view/Raring/view/AutoPkgTest/ | 09:52 |
| === Tonio_aw is now known as Tonio_ | ||
| === Tonio__ is now known as Tonio_aw | ||
| alexbligh1 | 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 |
| alexbligh1 | argg that was meant to be in ubuntu-kernel - sorry | 11:06 |
| seb128 | @pilot in | 11:06 |
| === 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 | ||
| * dholbach hugs seb128 | 11:25 | |
| * seb128 hugs dholbach back | 11:26 | |
| === _salem is now known as salem_ | ||
| ev | Anyone have guesses as to why compiz has a .desktop file? https://bugs.launchpad.net/apport/+bug/1048524 | 11:45 |
| ubottu | Launchpad bug 1048524 in Apport "Compiz crash inappropriately presented as an application" [Low,Confirmed] | 11:45 |
| ev | oh, NoDisplay=true | 11:47 |
| === Tonio_aw is now known as Tonio__ | ||
| === Tonio__ is now known as Tonio_aw | ||
| seb128 | ev, because that's need for gnome-session to start it | 12:18 |
| ev | seb128: ah, right. Already resolved though - apport needs to pay attention to the NoDisplay field | 12:18 |
| ev | thanks! | 12:18 |
| seb128 | ev, e.g /usr/share/gnome-session/sessions/ubuntu.session DefaultProvider-windowmanager=compiz | 12:18 |
| seb128 | ev, it will look for a compiz.desktop | 12:18 |
| seb128 | ev, ok ;-) | 12:18 |
| ev | seb128: while I have you here, any idea why nautilus doesn't ship a desktop file? | 12:19 |
| seb128 | ev, /etc/xdg/autostart/nautilus-autostart.desktop ? | 12:20 |
| seb128 | ev, /usr/share/applications/nautilus.desktop | 12:20 |
| seb128 | ev, or what do you mean? | 12:20 |
| ev | ah, was looking in the wrong place there | 12:20 |
| ev | but it sets NoDisplay=true - is that right? Wouldn't we want this to appear in menus? | 12:21 |
| ev | in the applications list, that is | 12:21 |
| seb128 | ev, which one? | 12:21 |
| ev | nautilus | 12:21 |
| seb128 | ev, /usr/share/applications/nautilus.desktop has no NoDisplay | 12:21 |
| seb128 | 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 | 12:22 |
| === cpg is now known as cpg|away | ||
| ev | right - for some reason I don't have /usr/share/applications/nautilus.desktop | 12:23 |
| seb128 | ev, sudo apt-get install --reinstall nautilus | 12:23 |
| ev | fixed. Very strange. I wouldn't have removed that myself. | 12:25 |
| ev | Thanks seb128, and sorry for the noise. | 12:25 |
| seb128 | ev, yw! | 12:25 |
| pitti | 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:25 |
| pitti | 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 |
| ev | pitti: https://bugs.launchpad.net/daisy/+bug/1085004 - not yet, unfortunately | 12:26 |
| ubottu | Launchpad bug 1085004 in Daisy "We should increment counters for each type of corrupted report received" [High,Triaged] | 12:26 |
| pitti | ev: ack | 12:26 |
| ev | well, we can count them with a script | 12:26 |
| ev | but that will take a while | 12:26 |
| ev | Hadoop will fix that | 12:26 |
| ev | we can write a job in Pig Latin that counts the total number of reports and the number without SAS fields | 12:27 |
| ev | and it will be much quicker than what we have today | 12:27 |
| pitti | 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:27 |
| mdeslaur | 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:28 |
| ev | okay | 12:29 |
| ev | 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 |
| mdeslaur | OdyX: we should probably change it to "\$$Id[:\$$]" | 12:29 |
| OdyX | mdeslaur: aww shit | 12:30 |
| OdyX | mdeslaur: I'm working on the 1.5.3 and un-dpkgconffile'ing currently. | 12:30 |
| OdyX | mdeslaur: /etc/cups/cupsd.conf shouldn't be a conffile. | 12:31 |
| infinity | mdeslaur: You missed a lively discussion in #debian-devel about cups's conffile abuses. | 12:31 |
| OdyX | oh you here too :) | 12:31 |
| mdeslaur | hrm? how is it not a conf file...now I regret missing that discussion :) | 12:31 |
| infinity | mdeslaur: It *is* a dpkg conffile, but it really shouldn't be, since cupsd modifies it during runtime, apparently. | 12:33 |
| infinity | mdeslaur: Which is just so many kinds of ewwww. | 12:34 |
| mdeslaur | during runtime? | 12:34 |
| infinity | So I'm told. | 12:34 |
| jdstrand | @pilot in | 12:35 |
| === 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 | ||
| infinity | It creates new ones based on cupsd.conf.default | 12:35 |
| === Tonio_aw is now known as Tonio__ | ||
| infinity | So, THAT can be (and is) a conffile, but cupsd.conf shouldn't be,. | 12:35 |
| jdstrand | infinity: do you ever sleep? :P | 12:35 |
| xnox | pitti: PyGIDeprecationWarning: Calling io_add_watch with a file object is deprecated; call it with a GLib.IOChannel object | 12:35 |
| infinity | jdstrand: No. | 12:35 |
| mdeslaur | wait a sec, no it doesn't | 12:35 |
| xnox | pitti: where file, is a socket. Any porting samples? | 12:35 |
| jdstrand | 'nuff said | 12:35 |
| infinity | 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 |
| mdeslaur | yes, the admin can use the web interface to change settings in cupsd.conf | 12:36 |
| bdrung | can the vlc-nox bug (no 81) on https://errors.ubuntu.com/ reassigned against libproxy? | 12:37 |
| OdyX | infinity, mdeslaur : http://paste.debian.net/213533/ <- that would be the un-conffile'ification. Comments ? | 12:37 |
| infinity | mdeslaur: If they change a value and change it back, will the file end up identical to the original? | 12:37 |
| OdyX | infinity: just tested, no. | 12:38 |
| infinity | Then yeah, that's not a conffile, it's a config setting cache, at best. :P | 12:39 |
| infinity | OdyX: Hrm, the compare-versions upgrade magic might be problematic if you're doing this to multiple releases. | 12:39 |
| infinity | OdyX: Though, I guess accidentally triggering the move around thing on more than one upgrade doesn't actually hurt anything either. | 12:41 |
| OdyX | infinity: why ? in that case it would be moved back and forth without problems, no ? | 12:41 |
| infinity | Jinx. :) | 12:41 |
| mdeslaur | infinity: oh, right...I see what you mean | 12:43 |
| mdeslaur | infinity: although, it doesn't read the cupsd.conf.default file either | 12:43 |
| infinity | OdyX: It also needs an abort-upgrade case in postrm, if I'm nitpicking. | 12:43 |
| === tkamppeter_ is now known as tkamppeter | ||
| infinity | mdeslaur: No? Curious. Then what's it for? :P | 12:44 |
| === doko_ is now known as doko | ||
| OdyX | mdeslaur: I think it does, but I might be wrong. | 12:44 |
| xnox | pitti: anyway pushed bzr-dbus branch for review. | 12:44 |
| xnox | =) | 12:44 |
| mdeslaur | OdyX: in what circumstance? | 12:44 |
| infinity | - The web interface now pulls the default cupsd.conf file | 12:46 |
| infinity | from cupsd.conf.default in the CUPS config directory. | 12:46 |
| infinity | ^-- From the changelog. | 12:46 |
| infinity | But not sure where that happens in the code. | 12:46 |
| infinity | cgi-bin/admin.c:2077 | 12:47 |
| infinity | (In the raring version, anyway) | 12:47 |
| doko | xnox, ? | 12:48 |
| xnox | doko: do you "maintain" binutils in raring? | 12:48 |
| infinity | He does, even without quotes. | 12:48 |
| xnox | 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 |
| OdyX | mdeslaur: pushed some reverts and the cvs thing to master / git. | 12:49 |
| mdeslaur | yeah, I'm just looking at that | 12:49 |
| infinity | xnox: Pretty sure Colin already poked him about it. | 12:49 |
| xnox | doko: dpkg-checkbuilddeps: Unmet build dependencies: gettext:any | 12:49 |
| xnox | doko: if you upload that soonish, QA will be happy to see a bulb go green on binutils. | 12:49 |
| xnox | infinity: doko: ack =) | 12:50 |
| infinity | It's not world-ending to wait for his next real upload. | 12:50 |
| infinity | The thing didn't even have an autopkgtest until 4 days ago, after all. :P | 12:50 |
| mdeslaur | OdyX, infinity: it seems to load it, and not do anything with it...how odd... | 12:51 |
| infinity | mdeslaur: Yeah, cause that's the ONLY odd behaviour cups has. | 12:51 |
| mdeslaur | hehe | 12:51 |
| OdyX | :) | 12:51 |
| infinity | I keep waiting for "printing on Linux" to become a self-solving problem when people just stop buying printers. | 12:52 |
| mdeslaur | infinity: hehe, good luck with that :) | 12:53 |
| infinity | I think my parents' generation needs to be collectively hit by a rather large number of busses to make that happen. | 12:53 |
| OdyX | infinity: http://paste.debian.net/213538/ <- that way then ? | 12:55 |
| mdeslaur | OdyX: I'm still waiting for upstream to decide what to do with DefaultAuthType | 12:56 |
| === amitk is now known as amitk-afk | ||
| OdyX | mdeslaur: I'm kinda disappointed by apple's reactiveness in this all affair. | 12:57 |
| mdeslaur | yeah, well, they do only have a single developer working on it :P | 12:58 |
| mdeslaur | isn't everyone root on OS X anyway? :)_ | 12:58 |
| infinity | OdyX: That looks better. | 12:59 |
| Sweetshark | .oO(I should have stopped coding/debugging yesterday night earlier. when you start calling classes CopKiller its a bad sign ... | 13:00 |
| infinity | Sweetshark: I assume this relates to DCOP more than, say, police officers? | 13:01 |
| pitti | xnox: ah, I'm actually considering to revert the deprecation for python file-like arguments; it's just easier that way | 13:01 |
| xnox | 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 |
| xnox | pitti: sounds like a good idea. | 13:02 |
| pitti | xnox: as for the porting, if you have an fd, the canonical syntax is GLib.IOChannel.unix_new(fd) | 13:03 |
| pitti | or GLib.IOChannel.unix_new(f.fileno()) for a python-y file | 13:03 |
| xnox | pitti: hmm... I did GLib.IOChannel(mysocket.fileno()) | 13:04 |
| xnox | pitti: where mysocket is socket.socket() | 13:04 |
| Sweetshark | 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:04 |
| doko | xnox, infinity: does the world survive when I do this next week with another upload? if not, please go ahead and upload | 13:06 |
| pitti | xnox: right, that works too; I added overrides for the IOChannel ctor to accept an fd or a file object | 13:06 |
| xnox | pitti: ack. | 13:06 |
| Sweetshark | 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:06 |
| xnox | 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 |
| infinity | 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:07 |
| pitti | xnox: fine to keep the red bulb for a week or so | 13:11 |
| pitti | xnox: it will become a blocker for upload once we build autopkgtest results into britney, but we haven't yet | 13:11 |
| pitti | xnox, doko: so don't worry about uploading this now; we have more red dots which require real fixes | 13:12 |
| israeldahl | 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:18 |
| pitti | xnox: responded to https://code.launchpad.net/~xnox/bzr-dbus/pygi/+merge/137173, thanks! | 13:19 |
| henrix | infinity: still around? | 13:19 |
| xnox | pitti: thank you for review ;-) | 13:20 |
| infinity | henrix: Maybe. | 13:20 |
| henrix | infinity: :) | 13:20 |
| henrix | infinity: i'm seeing something odd: | 13:20 |
| infinity | henrix: 'sup? | 13:20 |
| henrix | $ rmadison --architecture=source linux-meta | grep precise | 13:20 |
| henrix | linux-meta | 3.2.0.23.25 | precise | source | 13:20 |
| henrix | linux-meta | 3.2.0.33.36 | precise-security | source | 13:20 |
| henrix | linux-meta | 3.2.0.34.37 | precise-updates | source | 13:20 |
| henrix | -security has a different -meta version | 13:21 |
| infinity | Huh. Weird. I didn't get a reject on that. | 13:21 |
| infinity | henrix: Launchpad claims it's right. rmadison could be lying. | 13:21 |
| henrix | and there was another pkg with similar prob (/me checks) | 13:21 |
| henrix | linux-meta-lts-quantal has the same prob | 13:22 |
| henrix | infinity: ok, so you believe this is something transitory? | 13:22 |
| infinity | henrix: I'm checking the archive itself. | 13:22 |
| henrix | infinity: cool, thanks | 13:23 |
| pitti | tjaalton: seems you were right, I updated bug 1081009 | 13:23 |
| ubottu | Launchpad bug 1081009 in linux (Ubuntu) "[arrandale] GPU lockup IPEHR: 0x02000022" [High,Triaged] https://launchpad.net/bugs/1081009 | 13:23 |
| pitti | tjaalton: thanks for the hint! | 13:23 |
| infinity | Version: 3.2.0.34.37 | 13:23 |
| infinity | henrix: ftpmaster is right. Let me check security.u.c | 13:24 |
| infinity | henrix: security.u.c is also right, so rmadison's just lost the plot. | 13:24 |
| === dholbach_ is now known as dholbach | ||
| henrix | infinity: ok | 13:25 |
| henrix | infinity: i found this issue because the bot was complaining about these 2 packages | 13:25 |
| israeldahl | Anyone know how software-center categorizes apps? What file does it read to categorize them? | 13:25 |
| tjaalton | pitti: nice :) | 13:26 |
| infinity | Hrm. madison-list on lillypilly gets it right. Perhaps the new caching for rmadison is a bit too agressive. :P | 13:27 |
| infinity | s/list/light/ | 13:27 |
| henrix | infinity: ok, so this is something that will eventually get fixed, right? | 13:27 |
| henrix | infinity: you checked both packages? | 13:28 |
| infinity | henrix: Both are fine, yeah. | 13:29 |
| henrix | infinity: cool, thanks! | 13:29 |
| infinity | Oh, bah, I'd clear rmadison's cache, but I can't write to it. Brilliant. | 13:32 |
| OdyX | 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:34 |
| pitti | ev: wow, you're on a bug triaging spree :) | 13:35 |
| infinity | OdyX: A NEWS.Debian might be in order. | 13:36 |
| === popey_ is now known as popey | ||
| mvo | israeldahl: yeah, please check /usr/share/app-install/desktop/software-center.menu | 13:38 |
| israeldahl | mvo: thank you! If a program doesn't display in the correct category in software-center what file is it missing? | 13:40 |
| infinity | henrix: rmadison should be sane again. | 13:42 |
| mvo | 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 |
| henrix | infinity: it is! cool! thanks | 13:42 |
| israeldahl | 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 |
| israeldahl | mvo:not sure how to even fix it | 13:44 |
| mvo | 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:47 |
| OdyX | infinity: actually, migrating automatically might actually be harmful if one migrates an attack to the new file. | 13:48 |
| israeldahl | 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? | 13:48 |
| === attente_zzz is now known as attente | ||
| israeldahl | 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:50 |
| mvo | 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 |
| ev | pitti: :) | 13:52 |
| mvo | israeldahl: so idally a update for the archive packages should fix it | 13:53 |
| israeldahl | 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:54 |
| mvo | 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:55 |
| israeldahl | 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 | 13:57 |
| mvo | israeldahl: except for important fixes precise is frozen, its best if you prepare it for the current development version (raring) | 14:05 |
| israeldahl | mvo: Ok! Can I at least patch it somehow? | 14:06 |
| mvo | israeldahl: for precise you mean? or for raring? | 14:06 |
| israeldahl | mvo: for precise and quantal | 14:06 |
| mvo | 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:07 |
| israeldahl | mvo: I have a raring iso raring to go, I will try to merge through that (can I just do that in precise?) | 14:09 |
| === scott-wokr is now known as scott-work | ||
| israeldahl | mvo: thanks so much you have definetly helped me!! | 14:17 |
| seb128 | 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? ;-) | 14:29 |
| === slank_away is now known as slank | ||
| mpt | ev, bug 1084979 | 14:36 |
| ubottu | Launchpad bug 1084979 in Apport "Submitting error report asks confounding questions" [Medium,Confirmed] https://launchpad.net/bugs/1084979 | 14:36 |
| stokachu | xnox: orly? | 14:40 |
| xnox | stokachu: ha. got carried away. Yeah, I think I did help somebody to get it working a few months ago. | 14:43 |
| xnox | stokachu: should look it up again. | 14:43 |
| stokachu | xnox: that would be sweet if there was a way to get it working | 14:44 |
| xnox | stokachu: so there is no "partman-method/auto cryptoraid" | 14:48 |
| xnox | stokachu: so one must use expert recipe with stacking. | 14:48 |
| jdstrand | Riddell: hey, could yes give owncloud in https://launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages a quick spin? | 14:49 |
| stokachu | i was reading up on expert recipe but wasn't able to figure out how to do the crypto portion | 14:49 |
| jdstrand | Riddell: then comment in bug #1084109 if it works for you. If it does, I'll push it today | 14:50 |
| ubottu | Launchpad bug 1084109 in owncloud (Ubuntu Quantal) "quantal security update" [Undecided,Fix committed] https://launchpad.net/bugs/1084109 | 14:50 |
| Riddell | jdstrand: oh interesting, one of those got rejected I think | 14:50 |
| Riddell | mm, oneiric got rejected, I'll upload that with fixed changelog | 14:51 |
| jdstrand | 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:51 |
| jdstrand | Riddell: are you planning updates for precise and oneiric to 4.0.8 too? | 14:52 |
| === mcclurmc_away is now known as mcclurmc | ||
| jdstrand | 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:54 |
| Riddell | jdstrand: actually those are SRUs and they just empty the package, so different team | 14:55 |
| jdstrand | ah, ok | 14:55 |
| xnox | 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 |
| Riddell | they can't be backported alas | 14:55 |
| jdstrand | works for me :) | 14:55 |
| jdstrand | Riddell: icky | 14:55 |
| xnox | stokachu: I will push a few branches and then work on implementing this. | 14:55 |
| xnox | stokachu: might take a little bit of time. Anything else I can do for you? | 14:55 |
| jdstrand | 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:55 |
| Riddell | jdstrand: bug 1079150 | 14:56 |
| ubottu | Launchpad bug 1079150 in owncloud (Ubuntu) "Remove obsolete versions of owncloud " [Undecided,Confirmed] https://launchpad.net/bugs/1079150 | 14:56 |
| jdstrand | Riddell: thanks | 14:56 |
| jdstrand | that's really a shame | 14:57 |
| micahg | Riddell: how does owncloud provide packages if it can't be backported? | 15:03 |
| Riddell | 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:05 |
| Riddell | jdstrand: yep works with the new package ( http://ec2-54-234-63-47.compute-1.amazonaws.com/owncloud/ foo/bar ) | 15:16 |
| jdstrand | \o/ | 15:20 |
| jdstrand | Riddell: thanks! | 15:20 |
| jdstrand | Riddell: pushed to quantal-security | 15:23 |
| seb128 | pitti, can you put https://code.launchpad.net/~stijnbrouwers/ubuntu/quantal/kamoso/fix-missing-icons/+merge/134772 "Work In progress"? | 15:24 |
| Riddell | thnaks jdstrand | 15:24 |
| pitti | seb128: oui, je peux :) | 15:24 |
| seb128 | pitti, merci ;-) | 15:25 |
| seb128 | 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:27 |
| ScottK | seb128: kamoso's currently unbuildable due to KDE graphics library API changes they haven't ported to yet. | 15:28 |
| ScottK | It should go upstream as we'll need an update from them before we can get a new kamoso in raring. | 15:28 |
| seb128 | ScottK, ok, there are 2 sponsoring requests for it in the queue, I asked details/upstreaming on both | 15:28 |
| ScottK | seb128: You can point them at afiestas on #kubuntu-devel if you want. He's upstream. | 15:29 |
| seb128 | 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:29 |
| Riddell | seb128: http://userbase.kde.org/Asking_Questions#Reporting_KDE_Bugs | 15:30 |
| seb128 | 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 |
| seb128 | Riddell, thanks | 15:30 |
| seb128 | ogra-cb_, https://bugs.launchpad.net/ubuntu/+source/gmp/+bug/1079831 ... do you know if "arm64" support patches are useful for Ubuntu? | 15:33 |
| ubottu | Launchpad bug 1079831 in gmp (Ubuntu) "arm64 support for gmp" [Undecided,New] | 15:33 |
| seb128 | or somebody who has a clue about arm flavors ;-) | 15:34 |
| ScottK | infinity: ^^^ | 15:35 |
| infinity | seb128: Yes. | 15:36 |
| seb128 | infinity, can you have a quick look if the fix for that bug seems fine to you? | 15:37 |
| seb128 | infinity, did you see my eglibc misc:Depends comment earlier btw? ;-) | 15:37 |
| infinity | seb128: I think Colin already sponsored that, unless it's an updated patch. I'll look. | 15:37 |
| infinity | seb128: And no, I missed the eglibc mention. | 15:38 |
| seb128 | infinity, oh, yeah, Colin did, thanks | 15:38 |
| seb128 | 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:38 |
| seb128 | 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 |
| infinity | seb128: Yeah, not because of the patch, though. | 15:39 |
| infinity | seb128: I'll look at the misc:Depends thing and merge it in Debian, if sane. | 15:39 |
| seb128 | infinity, thanks! | 15:39 |
| infinity | The complete lack of explanation on the MP isn't promising... | 15:39 |
| infinity | misc:Depends usually ends up being shorthand for "debconf", doesn't it? | 15:41 |
| seb128 | infinity, the guy has been filling a stack of "add ${misc:Depends}" to Depends | 15:41 |
| infinity | That would make debconf Essential. Pretty sure we don't want that. | 15:41 |
| infinity | Well, transitively Essential. | 15:41 |
| seb128 | infinity, not only, dh_gconf adds gconf to ${misc:Depends} for packages that ship a schemas for example | 15:41 |
| infinity | seb128: Sure, but for libc6, I don't think I'd get gconf. :) | 15:42 |
| seb128 | 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:42 |
| Laney | Well, you'd get debconf if you use debconf. | 15:43 |
| Laney | But I get being wary about automagic depends on a package like eglibc. :P | 15:43 |
| infinity | Laney: I do, but it's also guarded specifically so libc doesn't NEED it. | 15:43 |
| infinity | Methinks I'll just reject this. | 15:43 |
| seb128 | works for me ;-) | 15:44 |
| Laney | It's a 'new contributor' initiative | 15:44 |
| Laney | Here's a list of packages with this lintian tag. Go fix them. | 15:44 |
| seb128 | Laney, not sure those initiatives are useful... | 15:44 |
| seb128 | Laney, that typically create work more than it's useful | 15:44 |
| ScottK | dholbach: ^^^ | 15:45 |
| Laney | It'd be better if the list was curated to packages that it might benefit | 15:45 |
| dholbach | ScottK, well I asked for help with filling in the right lintian tags | 15:45 |
| ScottK | dholbach: Just making sure you're aware of the discussion. | 15:46 |
| Laney | 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 | 15:46 |
| === yofel_ is now known as yofel | ||
| infinity | Hrm. Do I need to delete the MP to get it off the sponsors radar, or is a "disapprove" review enough? | 15:46 |
| dholbach | infinity, it needs to be rejected | 15:46 |
| micahg | Work In Progress... | 15:46 |
| infinity | dholbach: I don't see a reject option. | 15:46 |
| dholbach | (MP status, not MP comment status) | 15:46 |
| Laney | I think WIP works | 15:46 |
| dholbach | at the top | 15:46 |
| dholbach | or WIP, yes | 15:47 |
| infinity | Yeah, I have WIP, Needs Review, or Merged. | 15:47 |
| infinity | But none of those is true. | 15:47 |
| infinity | Weird that I can't reject... | 15:47 |
| seb128 | yeah, dunno what's up with that, it's annoying | 15:47 |
| Laney | Just one weird thing about UDD | 15:47 |
| dholbach | infinity, only TB people can | 15:47 |
| infinity | stgraber: Want to reject https://code.launchpad.net/~bkerensa/ubuntu/raring/eglibc/depends-fix1/+merge/135995 for me? :P | 15:47 |
| dholbach | so I'm happy to disable the lintian tag bits in Harvest | 15:48 |
| Laney | Perhaps restrict it to universe packages or something | 15:48 |
| dholbach | but it'd be shame if I did and then nobody replied in the ubuntu-devel@ discussion with some feedback | 15:48 |
| stgraber | infinity: there you go | 15:48 |
| infinity | To be fair, if lintian is bitching about that for eglibc, I should add an override. | 15:48 |
| * infinity runs lintian on his source... | 15:49 | |
| xnox | 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 |
| infinity | I don't see a lintian warning for that. | 15:49 |
| micahg | right, lintian warnings don't always mean add this here | 15:49 |
| xnox | infinity: and if your package breaks with knew dh, it would be maintainers fault for not having misc. | 15:49 |
| infinity | (base)adconrad@cthulhu:~/build/eglibc/ubuntu$ lintian eglibc_2.16-0ubuntu8.dsc | 15:49 |
| infinity | W: eglibc source: unknown-field-in-dsc testsuite | 15:50 |
| infinity | ^-- My only warning. | 15:50 |
| xnox | infinity: lintian -i -I -E --pedantic -v *.dsc | 15:50 |
| ScottK | xnox: You know you can do -iIEv, right? | 15:50 |
| infinity | Oh, debhelper-but-no-misc-depends is only an I? | 15:51 |
| xnox | ScottK: no short option for pedantic & I have bundling flags like that. | 15:51 |
| infinity | I so don't care about that. | 15:51 |
| ScottK | Yes, that's why I didn't include pedantic | 15:51 |
| infinity | pitti: lintian doesn't love your testsuite header in .dsc, BTW. | 15:53 |
| * infinity waits for the contributors sending patches to remove autopkgtest headers. | 15:53 | |
| pitti | hah | 15:53 |
| pitti | yeah, I noticed :( | 15:54 |
| pitti | well, rm -r debian/ will remove all lintian warnings :) | 15:54 |
| infinity | Tempting. | 15:54 |
| xnox | pitti: so bzr-dbus passes in release, but fails in proposed. | 15:55 |
| xnox | pitti: GLib.io_add_watch(self.sock, GLib.PRIORITY_HIGH, GLib.IO_IN, self.handle_network_packet) | 15:55 |
| xnox | TypeError: third argument not callable | 15:55 |
| xnox | while it's fine in raring-release. | 15:55 |
| xnox | is my code wrong? | 15:56 |
| pitti | urgh; the -proposed pygobject only fixes two things in the test suite | 15:56 |
| xnox | pitti: hmm... | 15:56 |
| pitti | well, is it callable? | 15:56 |
| xnox | pitti: let me doublecheck my chroot first. | 15:56 |
| pitti | oh, _third_ | 15:56 |
| pitti | that's GLib.IO_IN | 15:56 |
| pitti | I really have no idea how it could pass in -release | 15:57 |
| xnox | pitti: well -release is actually my machine which can be out-of-date. | 15:57 |
| pitti | so, I guess there's some bug in the io_add_watch override | 15:58 |
| pitti | this has to jump through some incredibly hackish hacks to support the old API | 15:58 |
| pitti | (which is why it's throwing so many deprecation errors, so that we can eventually get rid of it) | 15:58 |
| xnox | pitti: yeap, my local machine is out-of-date. | 16:01 |
| xnox | pitti: red herring with -proposed, test suite passes locally but not inside sbuild. | 16:13 |
| xnox | I will check what's going on in bzr-dbus. | 16:13 |
| === Quintasan_ is now known as Quintasan | ||
| seb128 | xnox, are you maintaining lvm2 in ubuntu? ;-) | 16:24 |
| xnox | seb128: sponsorship items, eh? | 16:25 |
| seb128 | xnox, yeah... there are some which are the > 3 weeks waiting part of the queue | 16:25 |
| xnox | seb128: I will review & test them, I'm booking some time for that next week. | 16:25 |
| xnox | =/ it's non-trivial to test. | 16:26 |
| seb128 | xnox, thanks | 16:26 |
| Laney | Any chance of a cheeky little rescore of https://launchpad.net/ubuntu/+source/gst-plugins-bad1.0/1.0.3-1ubuntu1/+build/4022148 ? | 16:26 |
| seb128 | xnox, well, https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1076304 is "should use the upstream manpage rather than the debian dir one" | 16:26 |
| ubottu | Launchpad bug 1076304 in lvm2 (Ubuntu) "dmeventd should use upstream manpage" [Undecided,In progress] | 16:26 |
| Laney | I think the lack of this build is keeping -good from migrating | 16:26 |
| seb128 | xnox, that's likely not that hard to test ;-) | 16:27 |
| xnox | ack | 16:27 |
| seb128 | xnox, I just don't know if have a specific manpage because we tweak over upstream and we need tweaked documentation... | 16:27 |
| seb128 | xnox, thanks | 16:27 |
| doko | infinity, arm odyssee continues ... llvm-3.2 | 16:27 |
| doko | In file included from /build/buildd/llvm-3.2-3.2~rc1/lib/CodeGen/RegAllocPBQP.cpp:48:0: | 16:27 |
| doko | /build/buildd/llvm-3.2-3.2~rc1/include/llvm/CodeGen/PBQP/HeuristicSolver.h:61:5: error: stray '\37' in program | 16:27 |
| doko | giving back | 16:27 |
| infinity | I put that \37 there on purpose. | 16:27 |
| infinity | LLVM just doesn't know how to say "thank you". | 16:28 |
| doko | will give it back until it finds \42 and then declare the issue solved | 16:32 |
| pitti | xnox: ah, thanks (was in meeting, sorry) | 16:32 |
| infinity | doko: *grin* | 16:33 |
| infinity | Laney: Done. | 16:34 |
| Laney | merci | 16:34 |
| pitti | je veux que Laney sait la language officielle d'équipe de bureau :) | 16:35 |
| pitti | err, "je vois" | 16:35 |
| infinity | Laney: update_output.txt implies there may also be an issue with "lives". | 16:35 |
| tjaalton | is there some recent change to build tools that can cause ftbfs? | 16:35 |
| infinity | pitti: "langue". | 16:35 |
| infinity | tjaalton: That's wildly vague. | 16:36 |
| infinity | tjaalton: So, I'll respond with "maybe". | 16:36 |
| pitti | infinity: oh, merci; mon français est encore très mal.. | 16:36 |
| tjaalton | infinity: ok let me be less vague, a sec | 16:36 |
| Laney | infinity: I see that with some 0.10 stuff (this is 1.0). Will see what it looks like after we get that build. | 16:36 |
| seb128 | pitti, tu peux mettre https://code.launchpad.net/~hloeung/ubuntu/precise/rsyslog/fix-ownership-workdir/+merge/133385 en "merged" stp? merci! | 16:36 |
| === henrix is now known as henrix_ | ||
| pitti | seb128: oui, fini | 16:37 |
| seb128 | pitti, merci | 16:37 |
| infinity | Laney: Oh, 1.0 looks much worse. | 16:38 |
| Laney | :-) | 16:38 |
| tjaalton | infinity: sssd built fine on 15th, fails today, same upstream version. but now I wonder if the bump to compat level (8->9) could've caused it | 16:38 |
| tjaalton | I'll check the build log once more | 16:39 |
| doko | pitti: is this bavarais, or saxonglais? ;p | 16:39 |
| pitti | doko: c'est franglemand! | 16:40 |
| infinity | tjaalton: I'm not sure how a debhelper compat level would change the fact that it appears to need -pthread in CFLAGS. | 16:40 |
| pitti | doko: I use an English web site to learn French, and make German errors | 16:41 |
| tjaalton | infinity: right, wonder why it didn't before | 16:42 |
| === jbicha is now known as Guest25887 | ||
| infinity | tjaalton: It also seems to have misplaced --libdir in the merge, no idea if that's a bad thing. | 16:43 |
| tjaalton | ah, crap | 16:43 |
| tjaalton | maybe I need a raring chroot now :P | 16:43 |
| seb128 | pitti, https://code.launchpad.net/~charno/ubuntu/quantal/kdepim/fix-for-1075130/+merge/132930 -> work in progress please | 16:44 |
| infinity | tjaalton: Let me test here quick-like. | 16:44 |
| pitti | seb128: techboard-privileges-bot at your service, sir | 16:45 |
| seb128 | pitti, danke | 16:45 |
| tjaalton | infinity: actually I thought compat 9 should set that automatically? | 16:45 |
| tjaalton | the old entry had old cdbs cruft on it | 16:45 |
| infinity | tjaalton: Oh, so it claims. | 16:47 |
| seb128 | pitti, you should ask for a fee for those requests :p | 16:47 |
| * seb128 would be in trouble | 16:47 | |
| tjaalton | mk-sbuilding raring chroot.. | 16:47 |
| pitti | seb128: nah, cleaning up the sponsoring queue is great | 16:48 |
| pitti | seb128: mais, tu peux me offrir une bière si tu veux :) | 16:48 |
| seb128 | pitti, la prochaine fois qu'on se voit, avec plaisir ! | 16:49 |
| seb128 | ScottK, do you have a VCS for kdevelop-custom-buildsystem ? can you get https://code.launchpad.net/~dholbach/ubuntu/raring/kdevelop-custom-buildsystem/description-typo-fixes/+merge/132382 merged ? | 16:49 |
| seb128 | Riddell, ^ | 16:49 |
| seb128 | not sure if it can be uploaded or if https://bugs.launchpad.net/ubuntu/+source/kdevelop-custom-buildsystem/+bug/1051234 is still valid | 16:49 |
| ubottu | Launchpad bug 1051234 in kdevelop-custom-buildsystem (Ubuntu) "kdevelop-custom-buildsystem: FTBFS and not installable" [Undecided,New] | 16:49 |
| dholbach | ^ Quintasan wanted to do it | 16:50 |
| dholbach | it was a UDS demo | 16:50 |
| Quintasan | Wasn't it like, merged? | 16:50 |
| * Quintasan merges | 16:50 | |
| dholbach | fantastico | 16:50 |
| seb128 | dholbach, get your UDS demos out of my queue :p | 16:52 |
| dholbach | oh it's your queue now | 16:52 |
| seb128 | dholbach, I'm in the seat | 16:53 |
| seb128 | dholbach, but I'm handing it back soon don't worry ;-) | 16:53 |
| tjaalton | infinity: fails the same even with --libdir set | 16:54 |
| infinity | tjaalton: Yeah, and also with compat level reduced. | 16:55 |
| infinity | tjaalton: I'd have to look at old build logs, but I suspect -lpthread was being pulled in as a transative linkage before. | 16:56 |
| tjaalton | I'll try building the old one | 16:57 |
| infinity | tjaalton: Yeah, in the old log, there's an extra -lpthread -ldl on the tail end. | 16:59 |
| tjaalton | ok, well that version failed to build now too | 17:00 |
| infinity | I'd blame a build-dep. Like maybe nspr or something. | 17:01 |
| infinity | But either way, if sssd is directly referencing pthreads (and it is), it should link it, not count on a transitive dep. | 17:01 |
| tjaalton | ok thanks | 17:01 |
| tjaalton | I'll dig deeper.. libnspr & libnss did get updated in the meantime, by me :) | 17:02 |
| === Guest25887 is now known as jbicha_ | ||
| infinity | (The only reason I'm guessing nspr is because, in the old build log, "-lpthread -ldl" were immediately after "-lnspr4", so they may have been a package deal from a pkg-config --libs call or something) | 17:03 |
| infinity | So, you may well have two bugs on your hands here. It's possible one of the rdeps doesn't properly advertise all the things it needs to link but, on the other hand, src/sss_client/common.c is directly calling into pthreads, so it should link it regardless. | 17:04 |
| infinity | tjaalton: And it could also be that an rdep was *incorrectly* advertising -lpthread as being needed, and sssd just happened to get lucky and not have to link it itself, when it really should have. :P | 17:06 |
| tjaalton | infinity: heh, right. maybe I'll just be lazy and bug upstream. friday evening and all | 17:08 |
| tjaalton | seems to build on sid though.. | 17:08 |
| infinity | tjaalton: Should be easy to sort out where the -lpthread is coming from on sid, then. | 17:10 |
| seb128 | Quintasan, did you merge https://code.launchpad.net/~dholbach/ubuntu/raring/kdevelop-custom-buildsystem/description-typo-fixes/+merge/132382 ? where did you merge it ? (the request didn't change status) | 17:10 |
| tjaalton | infinity: yeah | 17:10 |
| Quintasan | seb128: not yet, is it urgent? | 17:10 |
| infinity | tjaalton: Assuming it uses pkg-config for its dirty work, rgrep is your friend. | 17:10 |
| infinity | tjaalton: Also comparing the configure output with a fine-toothed diff. | 17:10 |
| seb128 | Quintasan, not at all, I misread your comment before, I though you merged it already ... that happens often that the target branch info is wrong which leads to stuff not keeping marked merged when they should | 17:11 |
| seb128 | Quintasan, so I was checking if that was the case there | 17:11 |
| infinity | tjaalton: (Either way, I'm still not convinced it's a "bug" in an rdep, but rather a bug in sssd that may have been tickled by an rdep no longer being buggy) | 17:11 |
| Quintasan | seb128: oh you don't want me to merge that into lp:ubuntu/kdevelop-custom-buildsystem? | 17:11 |
| infinity | tjaalton: If an rdep was previously over-linked, that would lead to this. | 17:12 |
| * Quintasan looks if we have a packaging branch for that or it needs a new upload | 17:12 | |
| Quintasan | ah, I see | 17:12 |
| Quintasan | no point in merging that there | 17:12 |
| seb128 | Quintasan, I've no opinion on where it should be maintained or no clue where is your packaging vcs ;-) | 17:12 |
| tjaalton | infinity: yup | 17:13 |
| stokachu | stgraber: ping | 17:15 |
| stgraber | stokachu: pong | 17:21 |
| stokachu | stgraber: there is a patch in sudo 1.8.6 in raring that addressing buildign with sssd | 17:22 |
| stokachu | stgraber: im attempting to backport sudo into precise and sudo is failing because its looking for libsss_sudo.so.1 and only libsss_sudo.so.0 exists | 17:23 |
| stokachu | will sssd need to be backported as well? | 17:23 |
| stokachu | sudo's support for sssd didnt land until 1.8.6 unfortunately | 17:24 |
| Quintasan | seb128: no packaging branch at all for this, is it okay if I just apply the diff and upload to raring? | 17:25 |
| seb128 | Quintasan, yes ;-) | 17:25 |
| Quintasan | dholbach: Thanks for the fix | 17:26 |
| stokachu | stgraber: looks like sssd in raring defines libsss_sudo.so.1 so im thinking we'd need to backport sssd into precise as well | 17:27 |
| stokachu | though im not particularly sure what type of effect it would have in the grand scheme of things | 17:29 |
| infinity | stokachu: It's hardcoded to the .1 SOVER in debian/patches/fix_sssd_build.patch | 17:30 |
| infinity | stokachu: You might try twiddling that. | 17:30 |
| dholbach | Quintasan, dobrze | 17:30 |
| stgraber | stokachu: if you need sssd support in sudo, then you'll likely need to backport sssd too yes | 17:31 |
| stgraber | stokachu: if you just need the new sudo but not the sssd support, just drop the --with-sssd from debian/rules | 17:31 |
| stokachu | i need sudo/sssd because of the ldap caching capabilities | 17:31 |
| stokachu | and sssd 1.9 this is not labeled as experimental anymore | 17:31 |
| stokachu | infinity: i thought about that until i saw the experimental text in the manpage :X | 17:32 |
| stgraber | ok, then yes, you'll need to backport sssd... | 17:32 |
| infinity | stgraber: See above. Could it just be that the hardcoded SONAME (why is that hardcoded?) is causing him issues? | 17:32 |
| stokachu | yea it is the hardcoded portion of that patch that causes issues | 17:33 |
| stokachu | but i think the bigger problem would be its experimental support in sssd 1.8 | 17:33 |
| stokachu | as far as making backport requests go is it the same process when you need backport a in order for backport b to work as intended? | 17:34 |
| micahg | stokachu: there's a bug ATM where we can't build-depend on other backports due to the old sbui | 17:34 |
| micahg | *sbuild | 17:34 |
| stokachu | micahg: ah ok, so in this particular case would I just make a note of the build-depends in the case? | 17:35 |
| micahg | stokachu: this is in archive only BTW | 17:35 |
| stgraber | stokachu: IIRC sudo doesn't actually build-depend on sssd, it's only a run time optional dependency (as in, if the library is there, it'll use it) | 17:35 |
| infinity | It's not actually *linking* to sssd anyway, is it? Just dlopen()ing? (at least, that's my assumption from the hardcoded path) | 17:35 |
| stgraber | infinity: right, it's just a dlopen | 17:36 |
| stokachu | ah yea | 17:36 |
| infinity | Yeah, so not a build-dep issue. | 17:36 |
| micahg | ah, ok, so, yeah, we can backport both then | 17:36 |
| stokachu | cool so i can file them separately | 17:36 |
| stokachu | awesome! thanks guys ill get started on that | 17:36 |
| stgraber | we were supposed to get a proper .so in the non-dev package in raring, but that didn't happen yet, that was probably done in 1.9 though | 17:36 |
| * micahg just realized he can work around the sbuild backport issues with a native PPA...needs further thought | 17:36 | |
| infinity | micahg: Or someone needs to bug me when I'm not heading to bed, and I can just fix it the way we discussed. | 17:37 |
| infinity | (turn off NotAutomatic in the chroots) | 17:37 |
| infinity | Which isn't perfect, but it's better than now. | 17:37 |
| micahg | infinity: oh, that's what we discussed? I don't think that's the right thing to do... | 17:37 |
| infinity | Yes, the "right" thing to do is the crazy "only pull in new build-deps when necessary" thing that the aptitude resolver does, but that's a lot more work for very little gain. | 17:38 |
| stgraber | turning off NotAutomatic in the chroots but only when building in the backports pocket right? | 17:38 |
| stgraber | we surely don't want to end up building using backports for the proposed pocket :) | 17:38 |
| infinity | stgraber: Eh? | 17:38 |
| infinity | stgraber: backports isn't in sources.list when building for proposed. | 17:39 |
| micahg | right, that would be very wronf | 17:39 |
| micahg | *wrong | 17:39 |
| stgraber | infinity: ok, all good then :) I sometimes forget how different sbuild chroots are from a standard system ;) | 17:39 |
| micahg | infinity: I'm thinking the PPA solution might be better for the few times that we need this rather than hacking notautomatic... | 17:40 |
| ScottK | It's fixing a missing bit of the not-automatic implementation | 17:41 |
| micahg | infinity: but I'd say it's ScottK's call on which solution he'd prefer | 17:41 |
| * ScottK wants it fixed and leaves the details to the person doing the work. | 17:41 | |
| infinity | micahg: I'm not sure how a PPA solves it. Unless you mean because you can backport in sets, and then copy them all at once. | 17:45 |
| infinity | micahg: But that doesn't help you if you have a new upload that depends on something previously-backported. | 17:45 |
| infinity | micahg: Unless you do something icky like copy it from backports to the PPA, just to use it as a build-dep, I guess. | 17:46 |
| micahg | infinity: sure it does, it's called copy-package :) | 17:46 |
| infinity | *shrug* | 17:46 |
| infinity | That would work. | 17:46 |
| infinity | Feels a bit messy, but if you really want the isolation, that solves it. | 17:46 |
| micahg | too bad I didn't think of it until now... | 17:46 |
| micahg | but that leaves me as the only person that can do it since I'm the only backporter that can get a native PPA ATM AIUI | 17:47 |
| stokachu | ugh.. build score 2505... start in 7 hours... | 17:47 |
| micahg | infinity: I guess I'll start a thread on the backporters list and see if anyone else cares one way or the other | 17:48 |
| micahg | wait, I'm not the only one, Laney can also :) | 17:48 |
| seb128 | stgraber, hey, could you set https://code.launchpad.net/~darkxst/ubuntu/quantal/gui-ufw/lp1071915/+merge/131696 to work in progress? | 17:52 |
| ScottK | micahg: I think it's fundamentally wrong to have stuff in backports that can't be built in backports. | 17:52 |
| micahg | ScottK: it can be built with the backports pocket, just not in LP | 17:53 |
| ScottK | That's what I meant | 17:53 |
| micahg | it's a broken sbuild that's the problem, not the sources available | 17:53 |
| ScottK | I get that. | 17:53 |
| seb128 | stgraber, sorry, rather merged ... it seems it got uploaded | 17:53 |
| infinity | micahg: Well, but it means someone can't rev the source and reupload it without going through a copy-package/PPA dance. | 17:53 |
| micahg | infinity: truee | 17:54 |
| micahg | infinity: you can say the same for uploads to -security though... | 17:54 |
| infinity | micahg: Also, "broken sbuild" is stating things wrong, IMO. NotAutomatic is broken by design. :P | 17:54 |
| micahg | infinity: no, with a new sbuild, you get the versioned dependencies | 17:54 |
| * ScottK prefers "incomplete implementation of NotAutomatic" | 17:54 | |
| stgraber | seb128: done | 17:55 |
| infinity | micahg: Not true, -security uploads can build against the release pocket + security just fine. | 17:55 |
| ScottK | micahg: Failure to have a new feature isn't really 'broken'. | 17:55 |
| micahg | infinity: yes, but you have to do a PPA dance | 17:55 |
| infinity | micahg: POtentially, in theory. I've never seen a security upload that won't build in proposed. Have you? | 17:55 |
| infinity | (We frequently rev security uploads for SRUs...) | 17:56 |
| micahg | infinity: that's fine, but you can't just rev and upload to security which is a parallel to the backports case | 17:56 |
| seb128 | stgraber, thanks | 17:56 |
| ScottK | Building powerpc build of libunity-webapps 2.4.3daily12.11.30.1-0ubuntu1 in ubuntu raring RELEASE [ubuntu-unity/daily-build] | 17:56 |
| ScottK | I thought those were all supposed to go away? | 17:56 |
| ScottK | infinity: ^^^? | 17:56 |
| infinity | ScottK: No, welcome to the new world order. They replaced commit-level autobuilds with daily autobuilds. I've nearly worn my fingers off arguing about it this week, so I'll refrain from reiterating. | 17:57 |
| micahg | ScottK: AIUI, it's staged there and then auto-copied once it passes the tests | 17:57 |
| ScottK | Sigh. | 17:57 |
| ScottK | Sure, because there are tons of buildd's lying around. | 17:58 |
| ScottK | BTW, KDE upstream people want us to do KDE daily updates after upstream feature freeze. | 17:58 |
| infinity | Even if there were, my arguments are mostly technical, not resource usage, but I've given up for now. | 17:58 |
| micahg | ScottK: as I said, it's your call about the backports solution, but I don't see it being any different than security uploads (working around an LP limitation, which by security was self imposed...) | 17:58 |
| infinity | micahg: The only LP limitation for security was needing an embargo path. | 17:59 |
| infinity | micahg: LP totally knows how to build for security just fine. | 17:59 |
| ScottK | micahg: If you want to do that as a work-around until it's fixed, I won't object, but then you, personally, are on the hook for fixing whatever happens after. | 17:59 |
| * ScottK liked turn of NotAutomatic for backports builds. | 18:00 | |
| infinity | micahg: In fact, an upload to -security directly (or a stale build in security that's retried) works just right. | 18:00 |
| ScottK | It seems like a simple enough solution, at least conceptually. | 18:00 |
| micahg | infinity: no, not unless the blocker that auto-failed security pocket builds was removed | 18:00 |
| infinity | Auto-failed? Or auto-rejected? | 18:00 |
| micahg | auto failed IIRC | 18:01 |
| infinity | The *builds* should work perfectly fine. | 18:01 |
| infinity | They have since day 1. | 18:01 |
| micahg | yes, it was hard coded | 18:01 |
| Laney | I have no native PPA | 18:01 |
| Laney | one which builds arm, sure, but no nonvirt one | 18:01 |
| micahg | Laney: I'm saying you and I could get one if we wanted to... | 18:01 |
| infinity | Laney: It would have to be a new PPA, ~canonical-backporters/ppa or some such. | 18:01 |
| mlankhorst | how can you tell the difference? :P | 18:01 |
| Laney | yeah we could | 18:02 |
| micahg | Laney: which solution do you prefer? | 18:02 |
| Laney | Is the lp-buildd fix not likely to happen any time soon? | 18:02 |
| infinity | Laney: The fix I'd proposed is distasteful to micahg. | 18:02 |
| Laney | ignoring NotAutomatic? | 18:02 |
| Laney | you know what, let me read the scrollback. | 18:03 |
| infinity | Laney: And the supposedly "correct" fix isn't a fix, it's an overhaul. | 18:03 |
| infinity | Laney: Yeah, ignoring NotAutomatic was my proposal, it makes micahg break out in hives. :P | 18:03 |
| micahg | not quite that opposed... | 18:03 |
| infinity | I'm actually not convinced that trying to keep them all compartmentalized is the right answer either. | 18:04 |
| micahg | it just forces people to get more of backports... | 18:04 |
| micahg | well, possibly | 18:04 |
| Laney | I think it's preferable to having to do any weird hacks or not having this work at all | 18:04 |
| infinity | Occasionally, sure, it might pull in some extra backported libraries. | 18:05 |
| ScottK | If people are installing stuff from backports, I think pulling in a few extra libs is fine. | 18:05 |
| ScottK | We test rdepends anyway, so it should be ~OK. | 18:05 |
| Laney | I'm somewhat philosophically opposed to introducing C-only solutions where possible | 18:05 |
| Laney | the non-ideal-but-quite-simple fix is better than that IMHO | 18:06 |
| infinity | Laney: Would C++ be acceptable? | 18:06 |
| micahg | GHC must be better | 18:06 |
| ScottK | Only if built in the right order. | 18:06 |
| Laney | Now that's another problem that Soyuz could solve ;-) | 18:07 |
| infinity | Right, I'm going to bed. | 18:07 |
| Laney | (by getting an analog of BD-uninstallable) | 18:07 |
| infinity | Argue amongst yourselves. | 18:07 |
| Laney | ScottK and I have outvoted micahg :P | 18:07 |
| infinity | And designate someone as the dude who tells me if I'm fixing the chroots or not, and for which releases. | 18:07 |
| infinity | And don't tell me now, even if you've decided. | 18:07 |
| infinity | See above, re: bed. | 18:07 |
| Laney | I know how you are about going to bed. | 18:07 |
| Laney | (just keep him talking) | 18:08 |
| infinity | *glare* | 18:08 |
| ScottK | infinity: You're always 'about to go to bed', but then you don't. | 18:08 |
| infinity | I hate you both so much right now. | 18:08 |
| infinity | SO MUCH. | 18:08 |
| ScottK | See my last remarks. | 18:08 |
| infinity | Also, good "night". See you guys later. :) | 18:08 |
| micahg | infinity: pleasant dreams | 18:09 |
| * micahg is used to being outvoted... | 18:09 | |
| * Laney chuckles | 18:10 | |
| Laney | glad that -bad build made the plugins migrate | 18:17 |
| === henrix is now known as henrix_ | ||
| SpamapS | slangasek: hey, I'm thinking of fixing the smbd/nmbd/winbind upstart jobs to start on runlevel 2 instead of local-filesystems + net-device-up | 18:27 |
| SpamapS | slangasek: thoughts? | 18:27 |
| === deryck is now known as deryck[lunch] | ||
| === mcclurmc is now known as mcclurmc_away | ||
| slangasek | SpamapS: they're that way deliberately because they're a filesystem server and some crazy person might have their /home loop-mounted over smb | 18:59 |
| === glebihan_ is now known as glebihan | ||
| slangasek | bryce, mlankhorst: llvm-3.1 accepted | 19:08 |
| slangasek | Quix0te: please quit tilting at ircmills | 19:11 |
| sarnold | slangasek: hahaha | 19:11 |
| highvoltage | what the heck is he doing? | 19:14 |
| highvoltage | thanks :) | 19:14 |
| kees | aaah | 19:14 |
| * Laney feels sad that he had whatever was going on /ignored | 19:14 | |
| kees | how is the ban not working? | 19:15 |
| highvoltage | I usually do a /kickban and then the right expression is usually taken care of | 19:16 |
| kees | I wonder if the host vs mask was a problem | 19:17 |
| kees | let's see if that works | 19:17 |
| kees | yeah, that seemed to do it. | 19:19 |
| sarnold | thanks kees | 19:20 |
| kees | sure, np | 19:20 |
| ScottK | Laney: One of the nice things about quassel is I can filter out stuff, but it's still in the database, so if I want to turn the filter off, I can can the history is still there (so I could see what was up in this case - I had it filtered as well). | 19:22 |
| Laney | ah, that would be nice in some limited situations | 19:23 |
| ScottK | yes. It's definitely rare it comes up. | 19:24 |
| === deryck[lunch] is now known as deryck | ||
| mlankhorst | slangasek: x11proto-* accepted? | 19:45 |
| slangasek | mlankhorst: not yet; do you want llvm-3.1 built/accepted first? | 19:45 |
| slangasek | (binaries) | 19:45 |
| mlankhorst | x11proto and llvm can be in any order you want | 19:46 |
| mlankhorst | ppa10 seemed to have built succesfully, so I'll need a precise1 sponsored :) | 19:46 |
| mlankhorst | let me upload the entire crap somewhere for sponsoring.. sec | 19:48 |
| slangasek | mlankhorst: best to have bryceh sponsor so that I can do the subsequent SRU review. Though, you should be able to upload these too provided they're in the X package set? | 19:53 |
| mlankhorst | let me check.. | 19:54 |
| bryceh | what are the packages? | 19:55 |
| mlankhorst | bryceh: .*-lts-quantal | 19:55 |
| mlankhorst | I'll try uploading myself | 19:55 |
| bryceh | mlankhorst, right. I'm happy to package them. IIRC you put in a request to add them to the X package list? know if that's been done? | 19:56 |
| bryceh | er, s/package/upload/ | 19:56 |
| mlankhorst | I think it's done, but those packages don't exist in precise so no idea if it will work or not.. | 19:56 |
| bryceh | mlankhorst, one way to find out ;-) | 19:56 |
| bryceh | mlankhorst, give it a shot; if you get a reject back lemme know | 19:57 |
| mlankhorst | yeah I'm just finishing up now | 19:57 |
| mlankhorst | woops needs precise-proposed | 19:58 |
| bryceh | mlankhorst, if it doesn't work, we'll need to get that fixed. | 19:58 |
| mlankhorst | all of it should have been added at least.. | 19:59 |
| mlankhorst | ok xorg worked, rest.. not sure yet | 20:01 |
| mlankhorst | uploaded libxrandr, wayland and libdrm renamed, those are for the first round | 20:01 |
| mlankhorst | suppose xorg could be done too | 20:02 |
| mlankhorst | bryceh: ok no idea if it worked, didn't seemed to be rejected during the upload itself, but have no confirmation yet | 20:04 |
| mlankhorst | Rejected: | 20:05 |
| mlankhorst | The signer of this package is lacking the upload rights for the source package, component or package set in question. | 20:05 |
| mlankhorst | hm seems libxrandr-lts-quantal didn't work.. | 20:05 |
| mlankhorst | other ones got accepted though | 20:05 |
| bryceh | I do see xorg-lts-quantal at https://launchpad.net/ubuntu/precise/+queue | 20:06 |
| bryceh | wayland and libdrm got in too. What did you get rejection on? | 20:06 |
| mlankhorst | libxrandr-lts-quantal | 20:06 |
| bryceh | ok cool, so sounds like the X package list got updated but some packages were missed? | 20:07 |
| mlankhorst | yeah | 20:07 |
| mlankhorst | I'll try the rest in build order | 20:07 |
| mlankhorst | mesa, xorg-server, then all ddx's | 20:08 |
| bryceh | mlankhorst, ok, send an email to get that added to the list. If you don't hear back soonish I can take care of uploading that one if you want. | 20:08 |
| mlankhorst | bryceh: I'll let you sponsor all the rejects | 20:08 |
| bryceh | wee | 20:09 |
| mlankhorst | now all the ddx's.. | 20:10 |
| mlankhorst | bryceh: http://people.canonical.com/~mlankhorst/ libxrandr-lts-quantal stuff | 20:13 |
| slangasek | mlankhorst, bryceh: x11proto-gl changes existing struct definitions; convince me that this is safe and won't cause regressions elsewhere in the stack if, say, we need to do a security release of another package that build-deps on it in precise? | 20:15 |
| mlankhorst | slangasek: I did in fact test it, and it worked fine with old libxrandr, xserver, mesa.. | 20:17 |
| mlankhorst | but hold on let me check what exactly you mean.. | 20:17 |
| mlankhorst | bryceh: x11-xserver-utils-lts-quantal seemed to have been rejected too, can you sponsor that too? | 20:18 |
| bryceh | yep | 20:18 |
| bryceh | mlankhorst, ok both uploaded | 20:23 |
| mlankhorst | thanks | 20:23 |
| bryceh | mlankhorst, any other rejects so far? | 20:23 |
| mlankhorst | nah rest got in | 20:23 |
| bryceh | awesome | 20:23 |
| mlankhorst | slangasek: enjoy :P | 20:24 |
| bryceh | mlankhorst, wonder if we could omit the ~precise1 on this stuff, since this is regular archive not ppa. | 20:24 |
| mlankhorst | slangasek: I would accept the xorg-lts-quantal package last | 20:24 |
| mlankhorst | bryceh: I thought about that, but I'm not sure it's perfect yet.. | 20:24 |
| bryceh | mlankhorst, yep, easy enough to fix later | 20:25 |
| mlankhorst | mostly in case I mess up the renaming or something | 20:25 |
| ScottK | bryceh: For SRU, there's no required naming convention. A lot of people use the security naming convention. | 20:25 |
| bryceh | ScottK, yeah just thinking the shorter the version number the less scary these already longly named packages will be for folks. but no biggie. | 20:26 |
| ScottK | So you use a 0.1 instead of a ~precise1. | 20:26 |
| mlankhorst | ScottK: maybe, but I need to append the same version to 43 packages on each rebuild, so I added this instead.. | 20:27 |
| ScottK | Right. Either is fine. | 20:27 |
| mlankhorst | plus the quantal versions could use those in their version numbers on fixes too.. | 20:27 |
| bryceh | lunchtime. bbiab | 20:27 |
| ScottK | mlankhorst: That's why you use 0.1 instead of 1 to make sure you don't collide. | 20:28 |
| ScottK | If you're two releases down you go 0.0.1. | 20:28 |
| mlankhorst | I painted this bikeshed, back off ;) | 20:28 |
| ScottK | I could go on about backports revisions, but I won't ... | 20:29 |
| mlankhorst | ty! | 20:29 |
| highvoltage | mlankhorst: hey ScottK knows what he's talking about when it comes to version numbers! | 20:31 |
| mlankhorst | but but, my bikeshed :-( | 20:31 |
| * mlankhor1t slaps mlankhorst around a bit with a large trout | 20:34 | |
| cyphermox | stokachu: sorry it took so long; but I'm testing the package for SRU locally now, then I'll be ready to upload it the the precise queue | 20:36 |
| psusi | in bug #1079791 Ted Ts'o mentions that e2fsprogs 1.42.x is a stable series with only critical bugfixes backported and recommends that precise track it. Should e2fsprogs maybe get a SRU exception and what would the proceedure be for that? | 20:55 |
| ubottu | Launchpad bug 1079791 in e2fsprogs (Ubuntu) "chattr does not understand nodatacow / COW_No option "+C"" [Undecided,New] https://launchpad.net/bugs/1079791 | 20:55 |
| stokachu | cyphermox: cool man thanks for all your work | 20:59 |
| stokachu | infinity: ive got test results back for the eglibc bug and it is verified the issue is resolved | 21:00 |
| stokachu | infinity: this was in reference to bug 1068199 | 21:07 |
| ubottu | Launchpad bug 1068199 in eglibc (Ubuntu Lucid) "please add support for MAP_HUGETLB in eglibc for Lucid" [High,In progress] https://launchpad.net/bugs/1068199 | 21:07 |
| arosen | I was wondering if anyone know off hand if ubuntu opensources the spec files that they use to create packages? And if so where I could find them? | 21:39 |
| ScottK | arosen: Are you one an Ubuntu system? | 21:40 |
| ScottK | If so, apt-get source ${PACKAGENAME} and look in the debian directory in the retrieved source package. | 21:41 |
| === cpg|away is now known as cpg | ||
| Chipzz | arosen: ubuntu doesn't use spec files; spec files are for RPM based systems | 21:59 |
| Chipzz | arosen: ubuntu uses a debian dir inside the source package, with debian/rules and debian/control as primary files | 22:00 |
| === cpg is now known as cpg|away | ||
| === Ursinha is now known as Ursinha-afk | ||
| === cpg|away is now known as cpg | ||
| === Ursinha-afk is now known as Ursinha | ||
| cjwatson | infinity: I tried removing the archiveuploader restriction that prevents direct uploads to -security, and wgrant pointed out that it wouldn't work because of restrictions elsewhere (in LP, not on the buildd side). Bug 1026665. | 23:02 |
| ubottu | Launchpad bug 1026665 in Launchpad itself "Not possible to upload directly to -security" [Low,Triaged] https://launchpad.net/bugs/1026665 | 23:02 |
| === cpg is now known as cpg|away | ||
| wgrant | cjwatson, infinity: It's quite easy to remove those restirctions, we just need to track down and kill all of them | 23:18 |
| wgrant | I know of two, maybe three | 23:18 |
| === cpg|away is now known as cpg | ||
| === seb128 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 | @pilot in | 23:46 |
| === 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 | ||
| seb128 | @pilot out | 23:46 |
| === 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 | bye | 23:46 |
| === cpg is now known as cpg|away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!