| === attente is now known as attente_zzz | ||
| skunk | im working on a c program for the Software centre... why is it good practice to put 'f' after a float value? | 00:54 |
|---|---|---|
| === cpg|away is now known as cpg | ||
| === plant is now known as Aaron | ||
| === spm` is now known as spm | ||
| pitti | Good morning | 06:55 |
| pitti | stokachu: I am fine with a precise SRU and did upload your fix, but the SRU team rejected it (followed up in the bug); infinity, do you know why gdb was rejected for precise? | 06:57 |
| === yofel_ is now known as yofel | ||
| === philballew_ is now known as philballew | ||
| dholbach | good morning | 07:42 |
| mitya57 | guten morgen dholbach | 07:50 |
| dholbach | mitya57, доброе утро | 07:53 |
| pitti | doko_, ScottK: hm, no /usr/bin/python2 in Debian? that's a bit of a bummer | 07:53 |
| pitti | as /usr/bin/python has been ruined by PEP-394, we need that to reliably get python 2 | 07:53 |
| mitya57 | I remember jcristau said he won't allow addition of that symlink for wheezy | 07:54 |
| mitya57 | so we'll probably get that later | 07:54 |
| pitti | hm, that requires hacks like http://bugzilla-attachments.gnome.org/attachment.cgi?id=228194 | 07:56 |
| pitti | and PEP-394 mandates its existence | 07:56 |
| mitya57 | dh_python2 (in Debian) automatically converts python2 shebangs to python, doesn't it? | 07:58 |
| pitti | that only works for packages, though | 07:58 |
| pitti | not for custom scripts, jhbuild, or upstream configure/make/make install | 07:58 |
| mitya57 | that's sad, yeah | 08:00 |
| cjwatson | pitti: write polyglot 2/3 code and then you can pretend that you are in a sensible universe where that PEP doesn't exist | 08:08 |
| pitti | haha | 08:08 |
| cjwatson | pitti: also, any distribution that *actually* points python to python3 has doomed itself to lots of python code failing anyway; who'll notice another one | 08:09 |
| pitti | yes, that's pretty much what I said in https://bugzilla.gnome.org/show_bug.cgi?id=658237 | 08:09 |
| ubottu | Gnome bug 658237 in general "Fix Python shebang lines" [Normal,Unconfirmed] | 08:09 |
| pitti | that seems to be a really bad move from Arch | 08:09 |
| pitti | but formally it's covered by this silly PEP, unfortunately | 08:10 |
| pitti | (not that this helps in any way to fix the actual breakage of pretty much all programs and custom scripts) | 08:10 |
| === tkamppeter__ is now known as tkamppeter | ||
| === Tonio__ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio__ | ||
| === mcclurmc_away is now known as mcclurmc | ||
| === doko_ is now known as doko | ||
| batee | Hello, does anyone know about applying seccomp filter rules to a newly spawning process through exec(). Further application of filter should be only for newly spawned process. | 09:45 |
| menace | Hi, is there a tool for comparing repositories according to package-differences? | 10:42 |
| darkxst | is anyone around that can sponsor an xorg-server fix? https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1073724. it fixes an incredibly annoying bug with broken pointer barriers in gnome-shell and I believe has no ill effects for unity | 10:51 |
| ubottu | Launchpad bug 1073724 in xorg-server (Ubuntu) "Pointer barriers have gaps along the edge of the screen" [Undecided,Confirmed] | 10:51 |
| cjwatson | menace: https://code.launchpad.net/~cjwatson/+junk/suite-diff might help | 10:51 |
| cjwatson | not especially polished :-) | 10:52 |
| menace | oh nice | 10:53 |
| === Tonio_ is now known as Tonio_aw | ||
| menace | perhaps i have some time for polishing ^^ | 10:55 |
| === Tonio_aw is now known as Tonio_ | ||
| seb128 | dholbach, hey, I've a libxml2 question for you | 11:12 |
| dholbach | sure | 11:12 |
| seb128 | dholbach, http://launchpadlibrarian.net/119213170/libxml2_2.8.0%2Bdfsg1-5_2.8.0%2Bdfsg1-5ubuntu1.diff.gz | 11:12 |
| seb128 | dholbach, you added a libxml2-udeb binary in that upload but it's not documented in the changelog | 11:12 |
| seb128 | dholbach, what's the deal with that? | 11:13 |
| dholbach | seb128, no, it was automatically added | 11:13 |
| dholbach | it's always added upon ubuntu builds | 11:13 |
| seb128 | hum, "automatically"? by what? | 11:13 |
| dholbach | WITH_UDEB := $(shell dpkg-vendor --derives-from Ubuntu && echo yes) | 11:14 |
| dholbach | debian/rules | 11:14 |
| seb128 | dholbach, ok, I see the rules is doing weird stuff ... it's just weird that it ends up in the diff this way | 11:14 |
| seb128 | dholbach, danke | 11:14 |
| dholbach | seb128, so yes, we can sync from experimental - the problem is https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1075146 | 11:14 |
| ubottu | Launchpad bug 1075146 in libxml2 (Ubuntu) "libxml2 2.9.0+dfsg1-3 FTBFS in raring" [High,New] | 11:14 |
| === _salem is now known as salem_ | ||
| dholbach | I asked for help to decide where to file a bug about the problem (upstream?) or if we need to patch this locally, but so far nobody could figure out where the problem came from | 11:15 |
| seb128 | dholbach, yeah, I ran into that as well, I figured out it's a doko issue ... I'm just merging the current unstable version for now instead | 11:15 |
| dholbach | might be better to just figure out the build problem - AFAIR the unstable diff was not too important | 11:16 |
| seb128 | dholbach, ok | 11:16 |
| seb128 | dholbach, I will look at another package, I don't feel like debugging toolchain issues before lunch ;-) | 11:17 |
| dholbach | seb128, it's just interesting that it's just the new version which FTBFS in raring | 11:19 |
| === kengyu is now known as kengyu_afk | ||
| dholbach | seb128, libxml2_2.9.0+dfsg1-3.dsc fails in quantal too - it's just weird that it does not occur in sid | 11:31 |
| pitti | dholbach: do you want to earn extra karma and forward bug 1073323 to debian? | 11:32 |
| ubottu | Launchpad bug 1073323 in gzip (Ubuntu) "Add simple test cases" [Undecided,Fix committed] https://launchpad.net/bugs/1073323 | 11:32 |
| pitti | dholbach: or are you working on making the upstream tests work in adt? | 11:33 |
| dholbach | pitti, ah yes, I can forward it - I'll add it to my TODO list | 11:33 |
| Laney | does anyone have a handy script to deduplicate Packages/Sources files, keeping only the newest version? | 11:33 |
| pitti | bdrung: do you want to upload/forward to Debian bug 1073390, or want me to sponsor/help out? | 11:34 |
| ubottu | Error: Debian bug 1073390 could not be found | 11:34 |
| pitti | bdrung: I mean bug 1073390 | 11:34 |
| ubottu | Launchpad bug 1073390 in libarchive (Ubuntu) "libarchive-dev needs a compile/link/run test" [Undecided,In progress] https://launchpad.net/bugs/1073390 | 11:34 |
| pitti | In file included from argmatch.c:28:0: | 11:41 |
| pitti | ./stdio.h:1012:20: error: 'gets' undeclared here (not in a function) | 11:41 |
| pitti | err, what? | 11:41 |
| pitti | that line merely does #include <stdio.h> | 11:41 |
| pitti | (that's a new FTBFS of coreutils in raring) | 11:41 |
| pitti | seems gets() is only exported if __USE_ISOC11 is not set, which might be a new default in raring | 11:42 |
| pitti | doko: ^ did you happen to see this already? | 11:43 |
| doko | pitti, yes, I think cjwatson did fix something similar in bison | 11:44 |
| pitti | doko: ooh, thanks for the pointer! | 11:44 |
| pitti | that's useful indeed | 11:44 |
| * pitti tries to remember how dpatch works | 11:46 | |
| mitya57 | does anybody know why python-markdown is in main (no binaries are)? | 11:47 |
| mitya57 | (it is in main according to LP) | 11:48 |
| pitti | python-markdown | 2.2.1-1 | raring/universe | source, all | 11:48 |
| pitti | it's not | 11:48 |
| mitya57 | so Launchpad lies? https://launchpad.net/ubuntu/+source/python-markdown | 11:48 |
| pitti | yeah, apparently | 11:48 |
| mitya57 | ah, ok | 11:48 |
| StevenK | release (universe) ? | 11:49 |
| geser | mitya57: don't get fooled by the "Component: main" field, simply ignore it and look at the table instead | 11:54 |
| Laney | that's main in debian I believe | 11:55 |
| StevenK | There's even small text saying it comes from the package and may be wrong | 11:56 |
| StevenK | Maybe it needs a <blink> tag | 11:56 |
| mitya57 | geser, StevenK: Laney is right, it's main in debian, question solved | 11:58 |
| cjwatson | pitti: there are various different approaches depending on the exact version of gnulib files involved - you might also look at m4 and diffutils if that helps | 11:59 |
| xnox | pitti: i was that happen with parted and one more package. | 12:04 |
| xnox | I've tried to "update" / "bootstrap" gnulib in those packages but failed to do so in a correct manner. | 12:05 |
| * xnox likes the patch in bison. | 12:06 | |
| seb128 | slangasek, RAOF, SpamapS, other SRU team members: what's the official line from the SRU team on copying updates to the new serie as well as copying them from -proposed to -updates? seems to be done inconsistently at the moment | 12:11 |
| cjwatson | xnox: I wouldn't recommend doing a full update | 12:11 |
| cjwatson | not unless you're upstream | 12:11 |
| cjwatson | xnox: I'm happy to sort out parted if you could push the merge work you've done so far | 12:11 |
| bdrung | pitti: i'll take care of that patch | 12:12 |
| cjwatson | I've done it half a dozen times or so now so I can do it pretty much by rote :) | 12:12 |
| === MacSlow is now known as MacSlow|lunch | ||
| cjwatson | xnox: or come to think of it I could just fix it in Debian ... | 12:15 |
| xnox | cjwatson: ack. | 12:17 |
| xnox | cjwatson: I think I can just adapt your patch in the ubuntu merge. As it doesn't affect debian yet. | 12:17 |
| xnox | do we have a bts tag for eglibc2.16 ftbfs? | 12:18 |
| xnox | (e.g. the gets issue) | 12:18 |
| cjwatson | no idea | 12:18 |
| cjwatson | I'll do it in Debian anyway, at least in our git repository, as otherwise it'll inconvenience the glibc maintainers | 12:19 |
| pitti | bdrung: thanks | 12:22 |
| pitti | cjwatson: I shamelessly stole your reduced backport for bison; that only needed minor unfuzzing and works fine | 12:22 |
| siretart | cjwatson: hi. sorry to bother you, but did you see my inquiry regarding libav for raring on the mailing list? i have no problem with waiting a few more days, but i just wanted to know if you intend to answer that mail or not. | 12:25 |
| cjwatson | siretart: I didn't see it | 12:27 |
| siretart | cjwatson: Good that I ping you on irc then ;-) -- https://lists.ubuntu.com/archives/ubuntu-devel/2012-November/036083.html | 12:29 |
| siretart | hm. did I scare him that much? | 12:31 |
| Peace- | hi i would like know if someone can help me to create a new package for bashrc | 12:33 |
| cjwatson | siretart: replied now, anyway | 12:33 |
| Peace- | basically i would like add some stuff to default .bashrc for each user | 12:33 |
| siretart | cjwatson: thanks! | 12:33 |
| Peace- | the only way is skel? | 12:34 |
| robru | Peace-, yeah, when a new user is created, the files are copied from /etc/skel, so if you modify the files there then it is copied to each user. is that a problem? | 12:39 |
| Peace- | robru: i have read that put too much stuff on skel is not reccomended | 12:39 |
| Peace- | just that | 12:39 |
| robru | Peace-, well I'm not an expert on that. I don't really see why it would be a problem. what are you wanted to add? a ton of stuff? | 12:40 |
| Peace- | robru: :D | 12:40 |
| Peace- | i was asking anyway cuz it works i did already my own package | 12:40 |
| Peace- | so i was just curiorus | 12:41 |
| robru | Peace-, it's probably fine. I mean unless you are putting hundreds of GB's in there. it just copies the files, so it's not like the system is bothered by copying some files that are slightly larger than before. | 12:41 |
| Peace- | robru: well i have made this http://code.google.com/p/kde-peace-settings/source/browse/#git%2Fkde-myown-settings%2Fetc%2Fskel | 12:43 |
| Peace- | robru: so i have vlc bashrc and some other little things | 12:43 |
| === Tonio_ is now known as Tonio_aw | ||
| robru | Peace-, yeah those are really tiny, I don't see any problem there | 12:47 |
| Peace- | ok | 12:47 |
| ev | pitti: do you have the power to unbreak ddebs.u.c? https://bugs.launchpad.net/daisy/+bug/1075056/comments/1 | 12:48 |
| ubottu | Launchpad bug 1075056 in Daisy "Retracers hung on "ERROR: Package download error, try again later: Failed to fetch..."" [Critical,Confirmed] | 12:48 |
| === cpg is now known as cpg|away | ||
| cjwatson | Peace-: it's not recommended for the *distribution* to put too much stuff there - that policy directive doesn't apply to local packages though | 12:49 |
| pitti | ev: hm, let me try to regenerate those; which release is that for? | 12:50 |
| * pitti sighs at the ddebs.u.c. hack | 12:50 | |
| cjwatson | for the distribution, there's not only a concern of size, but also what you do about upgrades - usually when you think about this hard the resolution ends up being to put things somewhere else instead, so the advice in policy is there to try to stop people wasting time | 12:50 |
| ev | huh, quantal | 12:51 |
| ev | I was looking at precise | 12:52 |
| ev | but libicc2-dbgsym doesn't exist in quantal as far as I can see | 12:52 |
| Peace- | cjwatson: well i am going to create a package that contains what i want to each user and i should upload it on ppa | 12:53 |
| === Tonio_aw is now known as Tonio_ | ||
| Peace- | i have already did but i was not sure if this could be a problem for users expecially for skel folder i mean | 12:53 |
| Peace- | anyway as robru said it's very tiny folder so it should not be a problem if some users would install my package | 12:53 |
| === Ursinha_ is now known as Ursinha | ||
| === attente_zzz is now known as attente | ||
| pitti | ev: hm, in quantal libicc2-dbgsym doesn't exist at all in ddebs' indexes.. | 13:00 |
| pitti | ah, the version in the bug report is for precise | 13:00 |
| ev | ah I must've misread the pastebin | 13:03 |
| pitti | ev: running | 13:05 |
| pitti | (sorry, doing three things at once) | 13:05 |
| cjwatson | Laney: ok, never mind - while I worked out a reasonably uncomplicated set of build-deps to allow both, I think it's probably safer to just bump them to the new version, i.e. prepend "1.0.1.3+really" to both << and >> versions | 13:34 |
| ev | pitti: no worries | 13:35 |
| cjwatson | anyway. not actually meant to be working today :-) | 13:36 |
| seb128 | cjwatson, "the new -proposed migration system will enforce that this work is done before" ... what "work" for you refer too? is the system checking for nbs status (e.g enforcing that all rdepends are ported to the soname version of a lib when there is an soname update)? | 13:39 |
| cjwatson | Yes | 13:39 |
| cjwatson | At least if you make those libraries go away in the new source package | 13:39 |
| seb128 | urg | 13:39 |
| === MacSlow|lunch is now known as MacSlow | ||
| seb128 | I didn't think about that, seems to be problematic | 13:40 |
| cjwatson | I don't think it will be | 13:40 |
| cjwatson | I view it as an actively good thing | 13:40 |
| seb128 | or we will need start to press the delete source button a lot | 13:40 |
| cjwatson | Or people could actually do the damn work to port NBS | 13:40 |
| cjwatson | We do it anyway - it's not like this is work we avoid | 13:40 |
| seb128 | well, we also end up dropping stuff, usually at the end of the cycle | 13:41 |
| seb128 | like for e-d-s in quantal | 13:41 |
| cjwatson | And it is troublesome when people are lazy and don't do it, because then we discover build failures when we're trying to do urgent updates | 13:41 |
| cjwatson | It hurts velocity | 13:41 |
| seb128 | I guess we should drop early and let people add stuff back if they are interested in ported | 13:41 |
| cjwatson | We need to stop doing things in a giant rush at the end of the cycle, and do things incrementally through the cycle instead | 13:41 |
| cjwatson | That's one of the things I'm trying to move toward | 13:42 |
| cjwatson | s | 13:42 |
| seb128 | right | 13:42 |
| seb128 | well I'm all for agressive universe cleaning | 13:42 |
| cjwatson | I'm not | 13:42 |
| cjwatson | I'm all for *fixing* it | 13:42 |
| pitti | if there are universe packages which are hard to port and are "for later", a workaround/compromise could be to remove their binaries, but keep the source? | 13:42 |
| seb128 | I've neither the time nor the motivation to port all universe's rdepends to be able to update libs | 13:42 |
| cjwatson | Removing the binaries is certainly a possibility | 13:42 |
| cjwatson | seb128: That's not my problem, sorry! | 13:42 |
| pitti | there will always be some universe packages which need lots of upstream work for porting | 13:42 |
| cjwatson | And that's one of the things the +1 maint team is explicitly supposed to be helping with | 13:43 |
| pitti | but for those where we can, we should certainly do it right away rather than having them linger for month | 13:43 |
| pitti | s | 13:43 |
| seb128 | cjwatson, yeah, and I know different people have different opinions on what to do with universe outdated packages | 13:43 |
| cjwatson | I've lost patience with the "universe doesn't matter" thing I'm afraid | 13:43 |
| cjwatson | Turns out that to many of our users it does | 13:43 |
| stokachu | cjwatson, infinity: is it possible to have bug https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1036834 re-evaluated for inclusion into precise? | 13:43 |
| ubottu | Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress] | 13:43 |
| cjwatson | stokachu: I'm not familiar with why it was rejected in the first place ... | 13:44 |
| xnox | seb128: upload new library soname bump as a new source package & transition main to it, then the old one drops out to universe and you can hand over to motu/+1 | 13:44 |
| stokachu | yea there wasn't any information in teh bug as to why | 13:44 |
| seb128 | cjwatson, it's not that it doesn't matter, is that we have limited resources and we can either spend those improving what 90% of your users run or spend the same time porting universe stuff used in aa magnitude less | 13:44 |
| cjwatson | xnox: I don't recommend that except in extreme cases | 13:44 |
| cjwatson | seb128: We are doing lots of this work anyway. You're just making the +1 maint team do it instead | 13:45 |
| ogra_ | yeah, the libs would pile up over time | 13:45 |
| cjwatson | This isn't actually a net saving, it just annoys everyone | 13:45 |
| stokachu | is there a way to see who actually rejected it? | 13:45 |
| seb128 | cjwatson, well, as said I would recommend agressive dropping instead | 13:45 |
| cjwatson | stokachu: No | 13:45 |
| xnox | cjwatson: I understand and agree that fixing stuff is the best way. | 13:45 |
| seb128 | which we sort of did for e-d-s rdepends in quantal | 13:45 |
| cjwatson | seb128: Which is no help to people who have it installed, so I do not recommend that unless there is no realistic alternative | 13:45 |
| seb128 | we even dropped evolution-indicator which was canonical's code | 13:45 |
| pitti | yeah, under the new regime that seems to be the best thing for stuff that's effectively unportable by us | 13:45 |
| cjwatson | It is an option, but it is not and should not be the first resort! | 13:45 |
| pitti | the nice thing is, it forces us to keep the universe in an installable shape all the time! | 13:46 |
| stokachu | who would I talk to in order to get this overruled? | 13:46 |
| stokachu | possibly overruled* | 13:46 |
| seb128 | cjwatson, the alternative is to spend a month of my time porting universe stuff and tell my manager I couldn't deliver thing we should have delivered | 13:46 |
| cjwatson | stokachu: None of us can overrule anything until we figure out who did it and why | 13:46 |
| cjwatson | seb128: oh nonsense | 13:46 |
| cjwatson | It's not a month of your time, stop exaggerating | 13:46 |
| pitti | cjwatson: I think you might be seeing this under a too absolute perspective | 13:46 |
| cjwatson | And I'm not saying it has to be *you* | 13:46 |
| pitti | cjwatson: for a lot of cases it is actually a month | 13:46 |
| stokachu | should i just post a question in the bug and hopefully someone will say why? | 13:46 |
| xnox | seb128: 3 people did python3.3 transition of main & universe in less than a week. | 13:46 |
| seb128 | cjwatson, well, we estimated evolution-indicator to be a week worth of time to port to the new e-d-s last cycle and same for pidgin-libnotify | 13:47 |
| pitti | cjwatson: and we just can't/don't do it and drop instead if upstream abandoned the project; I think that's only fair | 13:47 |
| cjwatson | pitti: On the contrary I think seb128 is being way too absolutist. I've done lots of this porting and hey, look, it turns out I delivered plenty of other stuff too | 13:47 |
| cjwatson | pitti: where did I say we should *always* port everything? | 13:47 |
| cjwatson | (hint: I didn't, and I'm annoyed at being characterised that way) | 13:47 |
| seb128 | cjwatson, well, you are saying that not porting block the migration of the new libs | 13:47 |
| seb128 | we we need to port or drop | 13:47 |
| === dendrobates is now known as dendro-afk | ||
| cjwatson | I said repeatedly that removal is an option, just not the first resort | 13:48 |
| cjwatson | seb128: Yes | 13:48 |
| stokachu | cjwatson: i<3u | 13:48 |
| seb128 | cjwatson, so I think we agree, I'm just saying that in practice time constrain mean we will see drops increase (maybe to add things back a bit later when time allows) | 13:48 |
| cjwatson | stokachu: might be worth grepping IRC logs and the like | 13:48 |
| pitti | right, that falls under the "no realistic alternative" exception | 13:48 |
| seb128 | cjwatson, like in practice time for porting comes rather after ff than before | 13:48 |
| cjwatson | seb128: we shipped precise and quantal with zero out-of-date binary packages and zero NBS, so I don't see why things would need to change | 13:49 |
| cjwatson | we're doing all this work over the course of a cycle anyway | 13:49 |
| seb128 | cjwatson, well, I do consider that we have been agressive in dropping for quantal... | 13:49 |
| pitti | seb128: well, we did survive it with dropping packages; that seemed to have worked fine? | 13:49 |
| cjwatson | and what you're saying is basically that Adam and I get to pick up all your trash at the end | 13:49 |
| seb128 | pitti, we dropped stuff used in quantal, e.g evolution-indicator (indicator-messages' integration for evolution) | 13:49 |
| pitti | it now just means that we need to do it right away | 13:50 |
| seb128 | or pidgin's indicator-messages integration | 13:50 |
| seb128 | or a bunch of universe rdepends from eds: dates, contacts, ... | 13:50 |
| seb128 | pitti, right, that's what I was saying | 13:50 |
| pitti | well, we have to pick either: velocity or having a giant universe with a lot of upstream-unmaintained bits | 13:51 |
| seb128 | cjwatson, "<cjwatson> and what you're saying is basically that Adam and I get to pick up all your trash at the end" ... sorry I didn't say that, I say we should be more agressive in dropping unmaintained stuff from the archive | 13:51 |
| xnox | seb128: I think I clearly remember you saying that all indicators will be ported to the new api. If pidgin's indicator-messages integration is dropped.... how are xubuntu & lubuntu getting ther notifications currently? | 13:51 |
| pitti | and personally I'm favoring the former, even if some of those universe packages might have users | 13:51 |
| seb128 | pitti, that conversation started with me saying that I'm "all for agressive dropping" | 13:51 |
| pitti | we can't have our cake and eat it too | 13:51 |
| xnox | they are using the older api, is it still in the archive? | 13:51 |
| cjwatson | pitti: cleaning things up as we go should ultimately improve velocity; I don't at all agree that this is a binary thing | 13:51 |
| cjwatson | we lose velocity by having to stop and fix the archive all the time in order to land changes | 13:51 |
| pitti | no, it's not a binary thing; I didn't say that we'd immediatley drop all NBS rdeps | 13:51 |
| seb128 | xnox, they don't I guess | 13:51 |
| cjwatson | pitti: I mean it's not a choice between velocity and fixing things | 13:52 |
| xnox | seb128: 8-? | 13:52 |
| cjwatson | (changes> which BTW are often actually in universe - things that customers want but that we haven't yet qualified for main are in universe, for instance) | 13:52 |
| pitti | cjwatson: well, it is; we need to find a good balance | 13:52 |
| cjwatson | pitti: it should not be a choice. one of the things that has absolutely killed our velocity in the past is a constantly broken archive | 13:52 |
| cjwatson | and I believe I have pretty clear management backing for fixing that, so if you feel that you have a problem with delivering things as a result then I think you should talk to your manager | 13:53 |
| pitti | right; but if you have to port 50 rdepends of e-d-s it kills velocity too, as you effectively can't land it for weeks | 13:53 |
| seb128 | or poppler | 13:53 |
| pitti | so, certainly we have to do that | 13:53 |
| cjwatson | poppler is a great example because the desktop team didn't bother to do that at all and it fell to apw | 13:54 |
| cjwatson | last time I remember | 13:54 |
| Daviey | dropping 50 rdepends would be crazy talk, just because someone wants a slightly newer library. | 13:54 |
| seb128 | we do bother doing the main desktop part, we are just so overworked that we can't possibly porting universe as well | 13:54 |
| pitti | Daviey: nobody is proposing that | 13:54 |
| cjwatson | like I say, I don't mind some removals, but you need to take a sensible position rather than just "I can't be bothered porting any of this, remove" | 13:54 |
| seb128 | or we need to stop what we are doing to port universe | 13:54 |
| xnox | Somehow i am failing to see how a newer poppler or e-d-s is a hard-dependency for any feature work. | 13:54 |
| Daviey | Anyone that claims it's not their job to keep the archive good, should renounce their ubuntu-dev membership. | 13:54 |
| cjwatson | where "port" is often "reupload" | 13:54 |
| pitti | I'm just saying that claiming that "porting all rdepends right away is increasing velocity" is not quite right | 13:55 |
| pitti | I'm not saying that we shouldn't port things right away; I think we should, and I'm quite happy that it's now being enforced | 13:55 |
| pitti | (with my former archive admin / stable+1 maintainer hat on) | 13:55 |
| cjwatson | I mean, lots of the porting people say they don't have time to do I've done in the past, and a pretty sizeable proportion has been a matter of no-change uploads | 13:56 |
| cjwatson | so, I'm sorry but I don't see that as a major imposition on anyone | 13:56 |
| seb128 | Daviey, there is a different between "keep the archive good" and "care for everything in universe, including old stuff that you think are unmaintained and have no users" | 13:56 |
| seb128 | cjwatson, well, it's not a "major imposition", I just fear that still like libav stay in proposed for a month and block other things | 13:57 |
| cjwatson | and I'm not saying you need to do the latter, only that you actually need to analyse the trade-offs before removing, and if it's just a matter of no-change uploads then why on earth not | 13:57 |
| seb128 | that I agree with | 13:57 |
| cjwatson | seb128: many of the unported libav rdeps were on images and really used | 13:57 |
| mvo | slangasek: hi, do you mind if I do a raring apt upload? | 13:57 |
| seb128 | usually those non ported at those which are non trivial though | 13:57 |
| seb128 | at->are | 13:58 |
| cjwatson | seb128: they wouldn't have been that hard for the person who changed libav to do; they were not too bad for me once I figured out the patterns | 13:58 |
| pitti | e-d-s is certainly a rather extreme case; most libraries are quite a bit easier | 13:58 |
| cjwatson | it's not like I'm not speaking from experience here, since I did a lot of the libav porting personally last time round | 13:58 |
| seb128 | pitti, extreme but real | 13:58 |
| pitti | yeah, but not the common case | 13:58 |
| seb128 | e-d-s was simply not doable without somebody full time for a month | 13:59 |
| seb128 | we did end up dropping tons of stuff | 13:59 |
| seb128 | but at least we didn't block the main image on having all those resolved/dropped | 13:59 |
| seb128 | well, let's see how it goes in practice | 13:59 |
| seb128 | I guess we will need to get down to the "I've looked at it, will take a week of work to port, nobody has time atm, let's drop and add it back later" | 14:00 |
| cjwatson | BTW the more stuff we move out to universe (e.g. Kubuntu last cycle) the less I agree with the "universe -> nobody cares" built-in assumption | 14:00 |
| seb128 | on the case by case basis | 14:00 |
| pitti | the nice thing is that it puts responsibility at the right place for Ubuntu uploads; for Debian syncs, it'll still fall under stable+1, but it's been like that before anyway | 14:00 |
| cjwatson | I think we've been way too far on the side of "the uploader can just forget about it" until now | 14:00 |
| seb128 | pitti, I'm not sure I agree with that, because I've to update e-d-s to update GNOME doesn't mean I want to be responsable for the e-d-s rdepends in the archive | 14:01 |
| cjwatson | This way, the uploader actually has to think - not necessarily do all the work personally, but do some of it, find people to help, remove stuff if it's too painful | 14:01 |
| pitti | it'll decrease the speed of landing things (i. e. velocity) a bit, but the net result is much nicer IMHO | 14:01 |
| pitti | especialy if we want to go to the rolling release thing | 14:01 |
| Daviey | Maybe the real issue here is the ease that a lib transition can be done? I wonder if more scrutiny is the correct answer here? It seems that this is pain we endure when we jump ahead of Debian... no? | 14:01 |
| cjwatson | Before, they could make it somebody else's problem all the time, and I honestly think that in the majority of cases - not necessarily all - that was just plain irresponsible | 14:01 |
| seb128 | cjwatson, there is probably a bit of that as well yes... | 14:02 |
| pitti | Daviey: that'd be velocity again -- Debian's freeze takes very long, we can't afford to wait until they release | 14:02 |
| seb128 | well, let's see how that plays out | 14:02 |
| Daviey | pitti: And you can outline specific reasons for needing a transition ? | 14:02 |
| cjwatson | so, I'm probably way too knee-jerk on this, sorry, it's one of my hot buttons | 14:02 |
| pitti | Daviey: in some cases we do Debian experimental uploads, but that of course doesn't really address the "port all Debian main" issue | 14:02 |
| Daviey | that outweigh the cost? | 14:02 |
| pitti | I'm not sure that I understand the question; we could also stop updating package versions entirely surely | 14:03 |
| cjwatson | I do think that when we drop binaries that amounts to making it the user's problem, which is sometimes even worse, so I don't see that as an automatic solution | 14:03 |
| cjwatson | It can be a solution if things are really unused; but I'm just aware that for a developer who might otherwise have to do porting work, the incentive is definitely to say "oh, whatever, nobody cares about this surely" | 14:04 |
| cjwatson | (I've done that myself and been occasionally wrong) | 14:04 |
| seb128 | cjwatson, well, as said it's not used or not, it's "what will benefit more user, time spend on the default desktop or time spent on universe packages that we doubt are used"... there is a balance to find for sure, but porting 50 rdepends is taking time even if the fixes are trivial and can easily can put you some days off | 14:06 |
| seb128 | cjwatson, where the said soname update is needed to land some chunck of work you need to land it can be problematic to find those "some days" in between | 14:06 |
| pitti | seb128: I think that's a price we just have to pay | 14:06 |
| cjwatson | Mm, I wonder which of those users actually thank us more for :-) | 14:07 |
| pitti | (but as cjwatson says, more people than just you can be involved in that) | 14:07 |
| seb128 | pitti, in an ideal work sure I would like to have time to land my features and fix everything in universe, in practice... | 14:07 |
| cjwatson | Sometimes the problem is that if you happen to be in the 1% of people who use something, well, that's 100% of you | 14:07 |
| cjwatson | And there's only so many times that we get to annoy 1% of users | 14:07 |
| pitti | seb128: but to be honest, so do the people who need to clean up NBS :) | 14:08 |
| Daviey | pitti: What i am saying is, this specific example.. all i can find as rational is "gstreamer (via gst-libav) requires this version"... That isn't IMO, enough justification. Has anybody looked at if it is a hard requirement? Is it less work to resolve that? | 14:08 |
| cjwatson | Anyway, I agree that there is a balance and I guess we'll find some kind of medium between our positions | 14:08 |
| Daviey | (it probably turns out that all that is required is no-change-rebuilds :) | 14:09 |
| cjwatson | stokachu: I've followed up to the gdb bug with what I think happened | 14:13 |
| === Tonio_ is now known as Tonio_aw | ||
| cjwatson | stokachu: (erm, really this time - LP timed out on my first attempt) | 14:15 |
| === lynxman_ is now known as lynxman | ||
| === JamesJRH_ is now known as JamesJRH | ||
| siretart | how to add a transition to http://people.canonical.com/~ubuntu-archive/transitions/? file bug or is there a bzr branch that I can could touch? | 14:24 |
| pitti | hah, gvfs' autopkgtests discovered a Python 3.2 → 3.3 behaviour change in Popen | 14:24 |
| * pitti fixes | 14:24 | |
| siretart | ah, seems to be https://code.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker - nvm | 14:25 |
| pitti | ev: ... still waiting on apt-ftparchive to finish... | 14:26 |
| ev | :) | 14:27 |
| zyga | hey, I'm running some tests and I'd like to build a chroot for raring | 14:30 |
| zyga | I'm using debootstrap but it has no script for raring yet | 14:31 |
| zyga | are we going to update debootstrap in quantal to make that possible? | 14:31 |
| cjwatson | Upgrade to raring or use the debootstrap from quantal-proposed | 14:31 |
| zyga | or should I use some other means of doing that | 14:31 |
| zyga | oh, cool | 14:31 |
| cjwatson | Or 'sudo ln -s gutsy /usr/share/debootstrap/scripts/raring' | 14:31 |
| zyga | thanks, let me try those | 14:31 |
| cjwatson | It'd have been in quantal as released but we found out about the name too late | 14:32 |
| zyga | hmm, I'm already using proposed | 14:32 |
| cjwatson | siretart: Laney should be able to help (he says, carefully washing his hands) | 14:32 |
| zyga | with debootstrap 1.0.42 | 14:32 |
| cjwatson | zyga: Oh, sorry, it's still in the queue. Just set the symlink manually for now | 14:33 |
| zyga | thanks | 14:33 |
| mr_pouit | pitti: hey, any thought on https://bugzilla.gnome.org/show_bug.cgi?id=687525 ? I've SRUs for xfdesktop and thunar waiting for approval to quantal-proposed, but if this gvfs patch is fine for a SRU, I guess it's better than my workarounds. | 14:33 |
| ubottu | Gnome bug 687525 in general "gvfs causes filemanagers to show partitions twice" [Normal,New] | 14:33 |
| xnox | siretart: yeah, just make a merge proposal for that branch and it will all just magically happen. | 14:33 |
| Laney | you can't do MPs for junk branches | 14:34 |
| Laney | but give xnox the address and he'll review it for you :-) | 14:34 |
| xnox | siretart: there is a README for "how to get started" | 14:34 |
| xnox | siretart: yeah I used to target the "lp:ubuntu-transition-target and that means merge notification is sent to all people who can merge" | 14:34 |
| xnox | siretart: but yeah, I'll be happy to merge trackers =)))) | 14:35 |
| siretart | xnox: https://code.launchpad.net/~siretart/+junk/transition-tracker.libav | 14:35 |
| pitti | mr_pouit: this looks SRUable to me indeed | 14:35 |
| siretart | I don't see the button 'merge proposal' | 14:35 |
| pitti | mr_pouit: just don't take my word as the final one, as I'm neither in -desktop or SRU teams any more | 14:35 |
| pitti | siretart: right, +junk don't have MPs | 14:36 |
| siretart | i see | 14:36 |
| siretart | thanks for the clarification, pitti | 14:36 |
| mr_pouit | pitti: yeah, but you're a lot in the gvfs git commit log :P. Thanks, I'll look into preparing the sru. | 14:36 |
| === Tonio_aw is now known as Tonio_ | ||
| cjwatson | zyga: accepted the {precise,quantal}-proposed debootstrap uploads now | 14:37 |
| xnox | siretart: merged. now after some time it will be available on the website. | 14:37 |
| siretart | xnox: thanks. that'll help me to get started with what to test and upload. | 14:37 |
| xnox | siretart: ;-) | 14:40 |
| pitti | cjwatson: ^ which reminds me, do we need an NBS report for -proposed? | 14:43 |
| seb128 | pitti, <cjwatson> making a -proposed version of NBS is on the to-do | 14:44 |
| pitti | ah, thanks | 14:45 |
| seb128 | pitti, just seen on #ubuntu+1-maint ;-) | 14:45 |
| seb128 | <cjwatson> but you can use http://people.canonical.com/~ubuntu-archive/proposed-migration/ | 14:45 |
| seb128 | (will take some practice to learn the format) | 14:45 |
| pitti | because that should provide most of what we need for transition tracking? | 14:45 |
| seb128 | pitti, for completeness ;-) | 14:45 |
| cjwatson | Yeah, in practice everything from NBS should show up on update_output | 14:46 |
| cjwatson | (or update_excuses if not fully built) | 14:46 |
| Daviey | cjwatson: I need to start creating an NBS report for another (non-primary) archive. I'd greatly like to re-use something you create. | 14:46 |
| cjwatson | Which I expect the +1 team to be keeping as low as possible | 14:46 |
| cjwatson | Daviey: it's all in ubuntu-archive-tools ... | 14:46 |
| Daviey | cjwatson: Oh, i thought you were going to create something refreshed. Last time i looked at the tool in u-a-t, it had an issue.. Maube i am talking crap | 14:48 |
| cjwatson | Well, that's what outputs the reports we use | 14:48 |
| cjwatson | I certainly had no intention of rewriting it from scratch | 14:48 |
| cjwatson | update_output> For instance the haskell-unordered-containers transition shows up as the first "Trying easy from autohinter" section there and you can see the uninstallables left after the attempt to shove in that plus all its rdeps | 14:49 |
| cjwatson | Which mostly corresponds to the yesod* stuff on http://people.canonical.com/~laney/www-test/ghc.html | 14:49 |
| * Laney just deleted that | 14:50 | |
| cjwatson | poo :) | 14:50 |
| cjwatson | but anyway, you can imagine :) | 14:50 |
| Laney | use the normal URL now | 14:50 |
| cjwatson | So http://people.canonical.com/~ubuntu-archive/transitions/ghc.html | 14:51 |
| cjwatson | Or for the ptlib stuff it's clearer - you can see that just t38modem is left untransitioned | 14:51 |
| cjwatson | What the transition tracker does is give you the build-dep/dep hierarchy which in some cases approximates a sensible order to approach the uploads | 14:52 |
| cjwatson | The red lines should wind up basically the same as what update_output says | 14:52 |
| cjwatson | (There are some confusing haskell autohinter entries further down which are essentially random "what if we try some of these packages but not all of them" heuristics - in this case, ignore them) | 14:53 |
| cjwatson | I look forward to running the next perl transition through this - that'll be a laugh) | 14:54 |
| cjwatson | apw: the entries in the "main run" section of update_output correspond to attempting to promote single packages rather than groups; so for instance it tries to promote uim, discovers that that makes uim-mozc uninstallable, and backs out | 14:56 |
| cjwatson | (I already corresponded with the uploader about that since it needs a mozc merge; it's just an example) | 14:56 |
| cjwatson | mjpegtools is a more interesting example that IIRC corresponds to actual NBS | 14:56 |
| pitti | ScottK, Riddell: hm, apport-kde fails on this: http://paste.ubuntu.com/1337463/ -> known bug? | 14:58 |
| cjwatson | And some of the packages are just uninstallable on their own account, for example python-augeas which depends on libpython2.6 | 14:58 |
| cjwatson | apw: that roughly help? | 14:58 |
| apw | cjwatson, yeah thanks, will poke at it and come back at you | 14:58 |
| pitti | ScottK, Riddell: i. e. pykde4 incompatibility with py3.3? | 15:02 |
| stokachu | cjwatson: you got it figured out? | 15:06 |
| cjwatson | stokachu: I updated the bug | 15:10 |
| stokachu | cjwatson: ok cool, so i just need a sponsor again then i believe? | 15:10 |
| cjwatson | wait, gdb is already in precise-proposed ... | 15:10 |
| cjwatson | I mean in the queue | 15:10 |
| * cjwatson reviews | 15:11 | |
| cjwatson | stokachu: why expand the @gnu@ et al items in debian/control.in ? | 15:11 |
| pitti | stokachu: no need to reupload BTW; one can fish it out of rejected | 15:12 |
| cjwatson | http://paste.ubuntu.com/1337490/ | 15:12 |
| cjwatson | pitti: it's in unapproved | 15:12 |
| pitti | stokachu: (if you did already, no harm, though) | 15:12 |
| pitti | cjwatson: ah, ok | 15:12 |
| cjwatson | stokachu: the Build-Depends changes there look spurious, as if somebody had copied debian/control over the top of debian/control.in or something | 15:12 |
| stokachu | its the way previous people have been building i believe | 15:13 |
| cjwatson | Well, no, it isn't or it wouldn't be in the diff to this version | 15:13 |
| stokachu | previously they were just modifying debian/control i believe | 15:14 |
| xnox | pitti: ev: the crash handler (apport) fails with "__init__() takes from 1 to 6 positional arguments but 7 were given" in raring, so I can't submit much.... | 15:14 |
| cjwatson | stokachu: You should indeed modify both debian/control.in and debian/control for the Multi-Arch change, but there should have been no need to modify the Build-Depends line at all | 15:15 |
| cjwatson | That looks accidental | 15:15 |
| stokachu | ill go back and look its beena while | 15:15 |
| pitti | xnox: right, I just fixed that in trunk | 15:16 |
| cjwatson | stokachu: If you agree that only the Multi-Arch line needs to be changed, I can just reupload without the spurious B-D change | 15:16 |
| xnox | pitti: ack. | 15:16 |
| pitti | xnox: half of my packages have some problem with py 3.3 .. | 15:16 |
| stokachu | cjwatson: yea only the multi-arch needs changing | 15:16 |
| pitti | xnox: new upstream release is out, currently test-building ubuntu upload | 15:17 |
| pitti | xnox: I'm walking through all adt-raring-* failures | 15:17 |
| stokachu | cjwatson: im still pretty sure i did the build-depends change intentionally | 15:17 |
| cjwatson | stokachu: I can't understand why | 15:17 |
| stokachu | cjwatson: during my builds control.in was overwriting control | 15:17 |
| stokachu | missing all the build-depends | 15:17 |
| cjwatson | Those @...@ symbols are meant to be automatically expanded | 15:18 |
| cjwatson | In the process of generating control from control.in | 15:18 |
| stokachu | right.. but control.in was missing build-depends | 15:18 |
| cjwatson | That's not what the diff says | 15:18 |
| stokachu | thats why i added the additional build depends to control.in | 15:18 |
| cjwatson | I reversed the @gnu@ and @kfreebsd@ expansions and there was no other change | 15:18 |
| cjwatson | You didn't add any build-depends | 15:19 |
| cjwatson | You expanded @gnu@ and @kfreebsd@ symbols - that's all | 15:19 |
| stokachu | hmm ok im not sure then | 15:20 |
| cjwatson | Which should be unnecessary and I'd like to avoid unnecessary changes in an SRU | 15:20 |
| cjwatson | If you like, I'll revert that part and try test-building without | 15:20 |
| stokachu | sure, thanks | 15:20 |
| cjwatson | (But I should go, meant to be on holiday today) | 15:20 |
| stokachu | ok no worries | 15:21 |
| stokachu | i can do it and see if i can reproduce why i thought modifying control.in was necessary | 15:21 |
| stokachu | like i said its been awhile since i messed with it | 15:22 |
| stokachu | cjwatson: it looks like control isn't build populated with @gnu@ or @kfreebsd@ during my builds | 15:39 |
| stokachu | s/build/being/ | 15:39 |
| apw | stokachu, are you saying there that they remain as @gnu@ etc in debian/control ? | 15:39 |
| stokachu | http://paste.ubuntu.com/1337554/ | 15:40 |
| stokachu | they are empty | 15:40 |
| apw | stokachu, and that prevents it building ? | 15:41 |
| stokachu | apw: yea its complaining about missing build depends | 15:41 |
| stokachu | i did a fresh source tree and only added Multi-Arch: allowed in control.in | 15:42 |
| apw | stokachu, version you are working against is ? | 15:44 |
| stokachu | 7.4-2012.04-0ubuntu2 in precise | 15:45 |
| didrocks | xnox: do you mind pushing the unity-lens-radios changes to lp:ubuntu/unity-lens-radios please? | 15:46 |
| === mcclurmc is now known as mcclurmc_away | ||
| apw | stokachu, where are you cleaning this, ie. what release are you building your source package ? | 15:51 |
| apw | stokachu, as when i clean that combination i get something in the []'s there | 15:51 |
| apw | stokachu, http://paste.ubuntu.com/1337577/ | 15:52 |
| stokachu | apw: im building within sbuild targetted for precise-amd64 | 15:52 |
| apw | stokachu, right but the source package where are you making that | 15:52 |
| stokachu | apw: im just using the existing one from the archive | 15:53 |
| apw | stokachu, i thought you said you had added a line to debian/control.in | 15:53 |
| xnox | didrocks: ack. | 15:54 |
| didrocks | xnox: thanks :) | 15:54 |
| stokachu | apw: sorry not sure i follow, i get a clean source with either pget (from pbuilder-scripts) or apt-get source then I just modify the file within the tree and re-run pbuild | 15:55 |
| stokachu | last month i attempted with sbuild but got similar results | 15:55 |
| * apw regets the source to confirm | 15:56 | |
| stokachu | ive also attempted to pull straight from bzr and run a bzr bd -- -S -us -uc | 15:56 |
| stokachu | each one hating me more and more | 15:56 |
| apw | stokachu, ok so the source before any mods has stuff in my brackets ... | 15:57 |
| stokachu | and when you attemp to build it what happens? | 15:57 |
| apw | stokachu, where are you adding m-a: allow ? | 15:58 |
| apw | for which package, so i can make sure my build matches yours | 15:58 |
| stokachu | the gdb stanza | 15:58 |
| stokachu | second one from the top | 15:58 |
| apw | ok to build mine i am then going to build a new source package and build that with sbuild | 16:00 |
| stokachu | ok | 16:00 |
| xnox | didrocks: hopefully the importer will not have a fizzy fit about it =) | 16:02 |
| didrocks | xnox: it doesn't really like for the kind of merge-upstream branch | 16:02 |
| didrocks | xnox: that's why I specify the branch in Bzr-Vcs | 16:03 |
| xnox | didrocks: ok. I did push to lp:ubuntu/unity-lens-radios as you requested. Do you want stuff in lp:unity-lens-radios as well? | 16:03 |
| didrocks | xnox: for upstream changes, sure :) | 16:04 |
| === Sweetsha1k is now known as Sweetshark | ||
| apw | stokachu, ok i think i see what is going wrong. wherever you are building this does not have the build-depends installed, soooo you lose some of your dependancies on clean | 16:06 |
| stokachu | apw: i thought sbuild/pbuild would handle that portion cleanly? | 16:06 |
| apw | stokachu, basically when i made my source pacakge it has the same issue, because i was lazy and didn't install the build-deps before making the source package | 16:06 |
| stokachu | ah | 16:06 |
| apw | stokachu, so it depends, if you make the source package right and submit that it has the right things in it | 16:07 |
| apw | stokachu, so i think looking at it in this case installing type-handling may help | 16:07 |
| apw | as it is that that errors here and leaves those []'s empty for me | 16:07 |
| apw | but to be 'right' you should have the build-deps installed | 16:07 |
| stokachu | ah ok | 16:07 |
| apw | i use mk-build-deps --install <package> to make a fake package to pull them all in, so i can remove it later | 16:08 |
| stokachu | apw: ok ill do that on the host machine and re-try | 16:08 |
| stokachu | apw: this is the first time this has happened, should i add this into my workflow for all packages? | 16:09 |
| apw | stokachu, i have to concur it is the first time i have been bitten by it also, i believe that is the right thing to do | 16:10 |
| stokachu | ok ill make a note of that | 16:10 |
| apw | stokachu, myself i tend to build the package and debdiff against the previous one, and confirm its only different the way i expect; if not like here then i worry about the builddeps | 16:11 |
| apw | stokachu, to spot the issue here i did debian/rules clean and looked at that output, the error was plane there | 16:11 |
| stokachu | ok that makes sense | 16:12 |
| xnox | doko: libguestfs fails to build from source because it misses a presence of an optional symbol in libpython. The way it checks for correct library is via: http://paste.ubuntu.com/1337639/ | 16:15 |
| xnox | which is different between python3.2 & 3.3. | 16:15 |
| xnox | is that intentional or libguestfs is silly? | 16:15 |
| === sem_ is now known as Peace- | ||
| === dendro-afk is now known as dendrobates | ||
| batee | Hi, Could you please suggest me a place to download the source code of the "Seccomp Filter"? | 16:19 |
| * didrocks wonders why ubuntu.getSeries(name_or_version="quantal") doesn't work with the launchpad api | 16:21 | |
| Adri2000 | EmilienM: hi :)[A[A[A[A[Asn: Vuillemot | 16:22 |
| Adri2000 | paste fail. sorry about that :) | 16:22 |
| apw | batee, you'd have to be more specific as to what you are using that you want the source for, but there is a package called libseccomp0 which claims to be the high level interface for that; otherwise it is likely kernel side code | 16:23 |
| === mcclurmc_away is now known as mcclurmc | ||
| batee | apw, I need to look at the source code for the function SCMP_SYS(). I am currently using libseccomp library. In the library when we define new filtering rules seccomp_rule_add() function is used. One argument for that function is the return value of SCMP_SYS() function. it is an integer id relevent to each system call. | 16:26 |
| Laney | didrocks: WFM - what do you get? | 16:27 |
| Laney | >>> lp.distributions['ubuntu'].getSeries(name_or_version='quantal').displayname | 16:27 |
| Laney | u'Quantal' | 16:27 |
| doko | xnox, this seems to be an error. The Makefile has a correct value. so something seems to be wrong when generating the _sysconfigdata.py at build time | 16:27 |
| apw | batee, so i would start with the source for that library then, apt-get source libseccomp0 should get that | 16:28 |
| didrocks | Laney: '', hum, I'm using lp.distributions['Ubuntu'] though, which returns me a valid ubuntu distro containing all series when calling .series collection | 16:28 |
| didrocks | Laney: let me try 'ubuntu' | 16:28 |
| xnox | doko: do you want a bug about this? | 16:28 |
| didrocks | Laney: indeed, that works :) funny that those double objects exists, both valid, but different behaviors :) | 16:28 |
| doko | xnox, I'd prefer a patch ;-P | 16:28 |
| didrocks | Laney: thanks! | 16:28 |
| Laney | weird | 16:28 |
| Laney | np! | 16:28 |
| xnox | doko: well, I have a patch against a single package that fails to build because of this misgenerated file. | 16:29 |
| xnox | :P | 16:29 |
| batee | apw, Libseccomp simply use the SCMP_SYS(). library dose not define the SCMP_SYS() function. It is from the seccomp kernel code itself. | 16:31 |
| apw | batee, then that is in the package 'linux' | 16:31 |
| batee | apw, ok thanks | 16:32 |
| === Tonio_ is now known as Tonio_aw | ||
| === Tonio_aw is now known as Tonio_ | ||
| apw | batee, that said i cannot see SCMP_SYS in it anywhere | 16:38 |
| apw | batee, and it is actually in libseccomp: | 16:39 |
| apw | ./include/seccomp.h:#define SCMP_SYS(x)__NR_##x | 16:40 |
| apw | batee, which is basically converting the string 'read' to __NR_read, which is a define in unistd.h | 16:41 |
| batee | apw, Thank you very much for the information. | 17:01 |
| batee | apw, Is there a simple way to get the integer value corresponding to each system call. | 17:01 |
| apw | batee, they are in unistd.h; so grep -r __NR_read /usr/include will tell you or you could just include those files | 17:05 |
| batee | apw, Thank you. | 17:07 |
| === deryck is now known as deryck[lunch] | ||
| slangasek | mvo: no objections | 18:07 |
| stokachu | could i get a sponsor for bug 1036834 with the latest debdiff for precise | 18:08 |
| ubottu | Launchpad bug 1036834 in gdb (Ubuntu Precise) "[FFe] gdb should be marked "Multi-arch: allowed"" [High,In progress] https://launchpad.net/bugs/1036834 | 18:08 |
| stokachu | it has all the necessary corrections made | 18:08 |
| slangasek | seb128: the official line is that you're supposed to be uploading to raring at the same time as you SRU for all SRUs uploaded after raring opening, and for those uploaded before raring opened the SRU team is supposed to copy them forward... but this is an error-prone process currently | 18:09 |
| seb128 | slangasek, do you recommend we get manual uploads for those which didn't get copied then? | 18:09 |
| slangasek | seb128: generally that's going to be better, yeah, because then the package is built against the new toolchain | 18:12 |
| seb128 | slangasek, well, it's not like we didn't copy the whole archive without rebuilding it on serie open ;-) | 18:12 |
| seb128 | slangasek, but fair enough, it's a bit extra work but not the end of the world, thanks | 18:13 |
| slangasek | seb128: true, but now we are open so those copies are meant to stop. If you have a list of packages that were missed and you'd like copied, I can do that now | 18:14 |
| slangasek | seb128: certainly for any SRUs uploaded today though, the usual rules apply and the package should be uploaded to raring first (and not doing so is a blocker for the SRU) | 18:15 |
| seb128 | slangasek, bamf file-roller libunity unity-lens-applications unity-lens-photos unity-lens-video | 18:15 |
| === attente is now known as attente_zzz | ||
| seb128 | slangasek, thanks ;-) | 18:15 |
| seb128 | slangasek, btw if you have any SRU review time I would appreciate http://launchpadlibrarian.net/121655774/gnome-settings-daemon_3.4.2-0ubuntu0.5_source.changes to get it (it's a bug leading to have user configs overwriten on "dconf update" runs) | 18:17 |
| slangasek | well, I can certainly squeeze in some time for that one | 18:18 |
| didrocks | thanks slangasek, seb128, will upload directly from now on | 18:19 |
| seb128 | slangasek, thanks | 18:20 |
| seb128 | didrocks, 'ci | 18:20 |
| === schmidtm_ is now known as schmidtm | ||
| stgraber | slangasek: is there a tool giving the list of source packages in the stable release updates and proposed pockets that aren't in the dev release? | 18:53 |
| slangasek | stgraber: not afaik, which is what makes this whole thing error-prone; it should really be part of http://people.canonical.com/~ubuntu-archive/pending-sru.html, probably as a flag or highlight or something so we know to run sru-release with -d | 18:54 |
| stgraber | slangasek: ok, I wrote a script for that yesterday so I can send a MP for it and then someone (or me) can extend the sru report for it | 18:54 |
| stgraber | slangasek: btw, according to my script, we're good now. The only missing SRU was bamf which was accepted in the release pocket a few minutes ago: http://paste.ubuntu.com/1338017/ | 18:55 |
| stgraber | slangasek: the script itself is: http://paste.ubuntu.com/1338023/ | 18:55 |
| infinity | stgraber: suite-diff can do it. | 18:56 |
| infinity | Which may or may not exist in a useful place... | 18:56 |
| stgraber | infinity: can't find any script by that name in ubuntu-dev-tools or ubuntu-archive-tools :) | 18:56 |
| infinity | Yeah, I realised after I said it that it may be a cjwatson special that only exists on ftpmaster. | 18:57 |
| slangasek | stgraber: really? I was still in the process of copying the packages seb128 pointed out above (copy-packages didn't want to copy them for me all at once); did you double-copy here? | 18:58 |
| stgraber | slangasek: the first run of my script spotted bamf as missing, a second run didn't. According to LP, it's been published to the dev release so will be actually published at the end of the publisher run. | 18:59 |
| slangasek | stgraber: right, but seb128 listed a bunch of other packages | 18:59 |
| slangasek | and those are still in progress | 18:59 |
| stgraber | slangasek: pocket = release, "Published 7 minutes ago" "Copied from ubuntu quantal in Primary Archive for Ubuntu by Steve Langasek" | 18:59 |
| infinity | stgraber: Your script is almost certainly wrong, given that I also know that linux is out-of-date (intentionally) in raring. | 18:59 |
| stgraber | infinity: hmm, that's true, wondering what happened there... /me digs | 19:00 |
| infinity | stgraber: Here's what I get from quantal-updates to raring: | 19:03 |
| infinity | http://paste.ubuntu.com/1338048/ | 19:03 |
| infinity | stgraber: If you want to compare and debug your script. | 19:04 |
| infinity | (though vorlon's about to fix half of those) | 19:04 |
| stgraber | infinity: thanks | 19:04 |
| === attente_zzz is now known as attente | ||
| infinity | stgraber: And since your script was also doing proposed: http://paste.ubuntu.com/1338054/ | 19:06 |
| stgraber | infinity: alright, found a few things that were wrong (including apt_pkg's help that was lying to me...), fixing those now | 19:10 |
| infinity | (We could probably jam suite-diff into ubuntu-archive-tools too, but since it's used against Sources/Packages files, it's slightly less useful to people who don't keep a dists/ mirror around) | 19:11 |
| infinity | Though, it's likely way faster than an API implementation. | 19:12 |
| slangasek | infinity: do we care about the standalone tool if we get the info integrated into pending-sru? | 19:13 |
| infinity | slangasek: The standalone tool has a lot of cool uses, but for this use-case, a single report of "these packages are older in raring than in quantal-updates" is probably enough, yes. | 19:14 |
| infinity | Or, rather, raring+raring-proposed. | 19:15 |
| === mcclurmc is now known as mcclurmc_away | ||
| stgraber | infinity: hmm, my script is saying that yours is lying :) | 19:23 |
| stgraber | infinity: you're missing: gnome-shell, linux-lowlatency, linux-meta-lowlatency and ubiquity | 19:23 |
| infinity | stgraber: Oh, I only did main. (And I'm not missing ubiquity, read harder) | 19:24 |
| infinity | stgraber: But my only doing main explains the other three. | 19:25 |
| infinity | slangasek: Any plans on a new udev that links with kmod (which will keep libkmod-udeb in main), or should I just drop it to universe for now? | 19:28 |
| slangasek | infinity: plans yes, but not immediate ones | 19:28 |
| stgraber | infinity: oh right, I'm actually the one missing ubiquity, misread the diff. | 19:28 |
| infinity | slangasek: Alright. I'll just drop it for now, and let magic sort it out when libudev-udeb starts depending on libkmod-udeb. | 19:28 |
| infinity | (Or however that dep will work) | 19:28 |
| * infinity tries to remember what evil is afoot when various d-i components decide to try to drag every universe kernel into main... | 19:29 | |
| infinity | I know we've seen this in previous cycles, I don't recall the cause. | 19:30 |
| stgraber | infinity, slangasek: ok, I think I fixed all the bugs (was mostly down to apt_pkg.version_compare being weird): http://paste.ubuntu.com/1338119/ | 19:35 |
| stgraber | oh, I probably should have it show the version numbers | 19:36 |
| stgraber | output with version numbers: http://paste.ubuntu.com/1338154/ | 19:44 |
| infinity | stgraber: That looks somewhat saner. | 19:46 |
| smoser | so with -proposed being where we upload.. | 19:46 |
| smoser | if we're doing udd should i commit things to lp:ubuntu/raring-proposed/cloud-init ? | 19:46 |
| infinity | smoser: You upload to "raring", we force it into proposed. ;) | 19:46 |
| smoser | good answer | 19:47 |
| smoser | thanks | 19:47 |
| infinity | smoser: UDD's understanding of this is, perhaps, a bit flawed right now. | 19:47 |
| smoser | good enough for me. | 19:47 |
| smoser | wonder if someone can tell me why bug 1070345 does not show up on https://bugs.launchpad.net/ubuntu/precise/+source/cloud-init | 19:54 |
| ubottu | Launchpad bug 1070345 in Ubuntu Raring "need to restart landscape after updating config" [Medium,Triaged] https://launchpad.net/bugs/1070345 | 19:54 |
| achiang | are people with @ubuntu.com email addresses allowed to post unmoderated to -devel? or is that completely unrelated, and you actually need to have launchpad team membership? | 19:54 |
| infinity | smoser: Because you're looking at ubuntu/precise/+source, instead of ubuntu/+source | 19:55 |
| smoser | but i *want* precise/+source | 19:55 |
| smoser | i was hoping to see a list of bugs that were nominated for precise | 19:55 |
| infinity | smoser: Oh, I see, it has a precise task. | 19:55 |
| smoser | maybe because its not fix-released in ubuntu ? | 19:56 |
| infinity | Err, oh. | 19:56 |
| infinity | No. | 19:56 |
| infinity | It has no precise task. :P | 19:56 |
| stgraber | infinity: hmm, looks like quantal released with a few packages missing from precise-updates. Cleaning up the list now. | 19:56 |
| infinity | smoser: Those shouldn't be Ubuntu tasks, they should be cloud-init in Ubuntu tasks. | 19:57 |
| infinity | smoser: Preeeeetty sure that bug does affect the entire Ubuntu project. | 19:57 |
| smoser | yeah. your'e right. thats it. | 19:57 |
| jbicha | achiang: unrelated, I believe you have to be in ~ubuntu-dev or on the whitelist | 19:57 |
| achiang | jbicha: ok, thanks | 19:58 |
| smoser | hm.. now how do i do that. | 19:58 |
| smoser | "This bug is already open on Ubuntu with no package specified. You should fill in a package name for the existing bug." | 19:59 |
| smoser | i think i'm just going to delete the ubuntu task and re-add it. | 19:59 |
| infinity | smoser: Nah. | 19:59 |
| infinity | smoser: I'll fix. | 19:59 |
| infinity | smoser: Or, you can get there first. :P | 19:59 |
| smoser | infinity, well, it seems ew crossed paths. | 20:00 |
| slangasek | smoser: hey, any chance you could smoke test mountall 2.43 from raring for me? | 20:05 |
| slangasek | smoser: this fixes the last regression I know of from the asynchronous events change; if it checks out for you I'll SRU that back to quantal and then SRU the whole thing back to precise | 20:06 |
| smoser | slangasek, i'll give it a quick sniff on an instance. | 20:06 |
| smoser | what is the bug thtat you've addressed? | 20:07 |
| infinity | Changelog claims https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/1059471 | 20:07 |
| ubottu | Launchpad bug 1059471 in mountall (Ubuntu Quantal) "2.41 fails to mount root partition" [High,Triaged] | 20:07 |
| * infinity reads the bug. | 20:08 | |
| slangasek | yeah, not one you're likely to hit in your setup | 20:08 |
| slangasek | but I'm looking for a regression-regression test | 20:08 |
| infinity | slangasek: Hrm, will that fix the bug I've been seeing very recently where my machine claims /tmp isn't ready and then boots anyway? | 20:08 |
| slangasek | infinity: I don't know, try it and tell me :) | 20:08 |
| infinity | slangasek: I shall, once my laptop's idle. | 20:08 |
| infinity | The best bugs are the ones I don't have to file. | 20:09 |
| stgraber | slangasek, infinity: result for precise => quantal: http://paste.ubuntu.com/1338218/ | 20:09 |
| slangasek | infinity: is /tmp a real mount point for you? | 20:09 |
| slangasek | stgraber: oh srsly? | 20:09 |
| infinity | slangasek: Nope. I have no /tmp in my fstab, I haven't hunted down yet WHY I'm getting that bizarre message on boot. | 20:09 |
| slangasek | stgraber: ugh, what's with that boinc version number? | 20:10 |
| slangasek | infinity: mmk | 20:10 |
| stgraber | nvidia-* is a false positive, I need to fix the script, but the rest should probably be fixed | 20:10 |
| infinity | alias fancontrol='killall plugin-container' | 20:14 |
| slangasek | that mythtv mismatch looks nasty | 20:15 |
| slangasek | someone uploaded the same upstream version twice, but managed to use the wrong datestamp and uploaded them the wrong way around? :P | 20:15 |
| infinity | Something like that... | 20:15 |
| infinity | Given that I assume the last part of that version is a commit ID, I'm guessing they're both identical save the version in the changelog. | 20:16 |
| arges | did the ddebs move? looking for 3.5.0-13-generic don't see it on ddebs.ubuntu.com | 20:17 |
| infinity | arges: No, you're just living in the past. | 20:18 |
| infinity | arges: We don't keep old ddebs on ddebs.ubuntu.com forever, and 3.5.0 is -17- in the release pocket, -18- in updates... | 20:18 |
| doko | xnox, done | 20:18 |
| infinity | arges: (Both of which are on ddebs) | 20:19 |
| arges | infinity, but the past is so much fun | 20:19 |
| infinity | arges: Until you get eaten by a dinosaur, sure. | 20:20 |
| infinity | arges: (In other words, if lamont's hungry, run) | 20:20 |
| arges | so I take it, there were a few more ddeb sacrifices? | 20:20 |
| infinity | arges: Erm, no sacrifice here. We just don't keep ddebs for every version ever published, only the ones currently published (ish). | 20:21 |
| infinity | arges: That will change (sort of) when we push them to the librarian instead, though ddebs.u.c will still only host ddebs that match published versions. | 20:21 |
| arges | infinity, ok. yup that makes sense. When will we push to librarian | 20:22 |
| infinity | arges: This isn't some culling, though, this is how it's always worked. | 20:22 |
| arges | and anything I can do to help with that? | 20:22 |
| infinity | arges: The librarian bit, I'm looking into this week. Need to do some testing to make sure the world won't asplode, then I can flip the switch. | 20:22 |
| arges | infinity, sweet | 20:22 |
| lamont | infinity: my hunger doesn't enter into it. :-p | 20:26 |
| infinity | lamont: Om nom. | 20:27 |
| === cpg|away is now known as cpg | ||
| lamont | that which eats only yummy stuff: omnomnivore | 20:30 |
| === carif1 is now known as carif-1-1 | ||
| doko | infinity, do you work on the debhelper merge? | 20:34 |
| infinity | doko: I was going to. It's actually a clean merge, but I'm suspicious there may be logical conflicts between the two patchsets, so wanted to have a quick poke, | 20:39 |
| doko | thanks | 20:39 |
| GunnarHj | charles: ping? | 20:41 |
| charles | GunnarHj: pong | 20:41 |
| GunnarHj | charles: Hi! Saw you decision. I'd hoped for something else... ;-) | 20:42 |
| GunnarHj | charles: "an RFE against GDateTime" What's an RFE? | 20:42 |
| slangasek | infinity: really? the remaining delta should be quite self-contained... I wouldn't expect conflicts | 20:44 |
| charles | GunnarHj: I was conflicted, too. I hate turning down good code | 20:46 |
| charles | GunnarHj: what I meant was you should file a feature request in glib for a GDateTime function that does what that indicator-datetime bug describes | 20:47 |
| infinity | slangasek: Hrm, now I feel like I may be misremembering. Or I was sleepy. :P | 20:47 |
| charles | GunnarHj: so that J Random App doesn't have to reinvent the wheel by doing the code itself | 20:47 |
| slangasek | infinity: there was a one-time fix-up already to merge the upstart handling, but that should all be in the past now | 20:47 |
| infinity | slangasek: I thought the Debian delta had some init-related something in it that I was concerned might logically conflict with our own init-mangling, but now that I look, it looks entirely unrelated. | 20:47 |
| slangasek | infinity: (and was due to me pushing patches to do things differently in Debian than we have in Ubuntu up to now) | 20:48 |
| GunnarHj | charles: Ok, thanks for explaining. Think I'll do that. | 20:48 |
| infinity | slangasek: I must have been somewhere else when I last looked at this. :P | 20:48 |
| GunnarHj | charles: Would you oppose to an Ubuntu specific patch in the meantime? | 20:48 |
| === Tonio_ is now known as Tonio_aw | ||
| charles | GunnarHj: an Ubuntu-specific patch to GDateTime? | 20:49 |
| === Tonio_aw is now known as Tonio_ | ||
| GunnarHj | charles: No, I meant to indicator-datetime. | 20:50 |
| charles | GunnarHj: hrrm, that puts us right back where we were :) | 20:50 |
| infinity | slangasek: Maybe I was looking at our delta and assuming it was Debian's, or something equally sleep-deprived and silly. | 20:50 |
| charles | GunnarHj: I'd like to see what upstream thinks first, and treat indicator-datetime changes as a last resort | 20:50 |
| GunnarHj | charles: Ok, that makes sense. I'll approach them soon with the idea. | 20:51 |
| slangasek | infinity: we should be able to further reduce the debhelper delta in the future I think, but that first requires unhobbling insserv in Ubuntu | 20:53 |
| charles | GunnarHj: sounds good. Could add a comment in the indicator-datetime bug that links up to the upstream bug? | 20:53 |
| charles | s/Could add/Could you add/ | 20:53 |
| slangasek | (and that's lower priority than getting upstart itself in working order in Debian) | 20:53 |
| GunnarHj | charles: Will do that too. Thanks for your advice! | 20:54 |
| === popey_ is now known as popey | ||
| === cpg is now known as cpg|away | ||
| === cpg|away is now known as cpg | ||
| maxiaojun | hi | 21:17 |
| === mcclurmc_away is now known as mcclurmc | ||
| === Tonio_ is now known as Tonio_aw | ||
| === salem_ is now known as _salem | ||
| === Tonio_aw is now known as Tonio_ | ||
| infinity | slangasek: So, that new mountall fixed my bug. Yay. | 21:42 |
| slangasek | infinity: damn | 21:42 |
| slangasek | infinity: that means I don't understand the change I made :P | 21:42 |
| infinity | slangasek: Your apt kernel autoremoval stuff is curious, though. Does it actually work? | 21:42 |
| slangasek | infinity: works in my tests | 21:42 |
| infinity | slangasek: I would have assumed that NeverAutoRemove influences how it writes the DB, not how it interprets it. | 21:43 |
| infinity | slangasek: (Which is why none of my kernels are currently marked auto...) | 21:43 |
| slangasek | evidently not | 21:43 |
| infinity | slangasek: Hrm. Your computer and mine disagree, then. :P | 21:43 |
| slangasek | however, the Never-MarkAuto-Sections *does* influence how it writes the db | 21:43 |
| slangasek | which is why I filed bug #1074787 | 21:44 |
| ubottu | Launchpad bug 1074787 in linux-meta (Ubuntu Raring) "linux-meta metapackages should not be in section 'metapackages'" [High,Triaged] https://launchpad.net/bugs/1074787 | 21:44 |
| slangasek | (and overrode everything in the archive) | 21:44 |
| infinity | slangasek: Ahh. And THAT's why none of my kernels are auto? Check. | 21:44 |
| slangasek | so once that fix gets committed to the kernel team's repo, and things have had a chance to settle out, I'm thinking to do an upgrade quirk in update-manager | 21:45 |
| slangasek | ... or whatever that other thing is called that used to be part of u-m but isn't anymore... ubuntu-release-upgrader? | 21:45 |
| infinity | That thing. | 21:45 |
| infinity | Which reminds me, I should fix live-build to have the same hack for linux-image that it does for linux-headers... | 21:45 |
| infinity | Or we'll have the install kernel installed forever. | 21:46 |
| * slangasek nods | 21:46 | |
| infinity | slangasek: So, the theory here is that if I apt-mark auto all of my current linux-image* packages, your bits should magically DTRT? | 21:46 |
| * infinity wonders if there's any sane way for us to SRU that... | 21:47 | |
| slangasek | that's the idea, yes; and yes I'm planning to SRU | 21:47 |
| infinity | I mean to SRU "mark all kernels auto", not the other bits. | 21:47 |
| slangasek | right, that's the part I was going to put in the u-r-u quirk | 21:47 |
| slangasek | for precise and later | 21:48 |
| infinity | Sure, that doesn't help people who've been running precise for 6 months. | 21:48 |
| infinity | They'll get new kernels autoremoved, and the last 6 months of SRUs installed forever. | 21:48 |
| slangasek | the archive override helps them immediately to prevent the problem from getting worse | 21:48 |
| slangasek | and the last 6 months of SRUs will stay only until their next upgrade | 21:48 |
| infinity | Which could be in 4.5 years. ;) | 21:48 |
| infinity | But yeah, that may be the best we can safely do. | 21:48 |
| slangasek | AFAICS we can *only* effectively apply this fix from something *not* running from a maintainer script | 21:49 |
| slangasek | so u-r-u is the only option that comes to mind | 21:49 |
| infinity | I assume you fixed the overrides in updates/proposed for both precise and quantal? | 21:49 |
| infinity | Oh, but they'll need to be re-fixed every time until all the SRU kernels are DTRT. | 21:49 |
| slangasek | just reviewing now to make sure I've gotten them all (inc. security) | 21:49 |
| slangasek | do they? this is an override on the metapackages | 21:50 |
| infinity | Oh. | 21:50 |
| slangasek | so that should be sticky | 21:50 |
| infinity | Right. | 21:50 |
| infinity | Neverming. Sticky indeed. | 21:50 |
| maxiaojun | Anyone interested in or involved in Jockey here? | 21:50 |
| slangasek | so I'd gotten precise-{updates,proposed} and quantal-proposed; no kernel in quantal-updates yet | 21:50 |
| infinity | slangasek: So, apt writes out the auto DB as the very last thing, I geuss? A Dpkg::Post-Invoke hook would still be too early? | 21:50 |
| slangasek | taking care of precise-security now | 21:50 |
| slangasek | infinity: yeah, it writes it out from what it has in memory, so no dice | 21:51 |
| infinity | slangasek: There's a kernel in quantal-updates. I released it yesterday. | 21:51 |
| slangasek | maxiaojun: jockey has been renamed to / replaced by 'ubuntu-drivers'; I don't know if anyone who's involved with it is currently around | 21:51 |
| infinity | (That said, there are more on the way, for other flavours) | 21:51 |
| infinity | Assuming all the -meta packages have this bug. | 21:51 |
| slangasek | infinity: in that case, the override I did to quantal-proposed pre-yesterday should have already taken, I think? | 21:51 |
| infinity | slangasek: Seems like a reasonable guess. | 21:52 |
| slangasek | (apt-cache says yes) | 21:52 |
| infinity | slangasek: I wasn't sure of the timing there. ;) | 21:52 |
| * infinity marks all his kernels auto to see what happens. | 21:52 | |
| maxiaojun | Is ubuntu-driver shipped in 12.10? Any code to see in LP? | 21:52 |
| maxiaojun | ubuntu-drivers I'm sorry | 21:53 |
| slangasek | maxiaojun: according to the source package, the code lives at git://github.com/tseliot/ubuntu-drivers-common.git | 21:53 |
| slangasek | maxiaojun: (shown by 'apt-cache showsrc ubuntu-drivers-common | grep Vcs') | 21:54 |
| infinity | slangasek: You also missed linux-backports-modules in your no-auto-removiness. | 21:55 |
| maxiaojun | slangasek: Thank you for your help. I generally use packages.ubtuntu.com since I run 12.04 | 21:56 |
| maxiaojun | packages.ubuntu.com | 21:57 |
| infinity | slangasek: And while I'm looking, why do you use "^linux-image-$kernel.*"? Wouldn't an exact match be saner? | 21:57 |
| slangasek | infinity: rmadison claims linux-backports-modules doesn't exist? | 21:57 |
| infinity | slangasek: (That means that, for instance, linux-image-1.2.3-12-generic would also match linux-image-1.2.3-12-generic-pae, for instance) | 21:57 |
| slangasek | infinity: exact match> you're probably right, I was perhaps adhering too closely to existing convention | 21:58 |
| infinity | slangasek: linux-backports-modules-3.2.0 would be the precise source package. The regex would be something like ^linux-backports-modules-.*-$kernel | 21:58 |
| slangasek | (and nevermind the fact that .* on the end is redundant in a regexp) | 21:58 |
| maxiaojun | My issue with Jockey or ubuntu-drivers is that they don't try to pull b43 firmware at all. | 21:59 |
| slangasek | infinity: so if that didn't already get fixed, it's presumably not in 'metapackages'? | 21:59 |
| infinity | slangasek: And, I suppose $-terminated in all cases, if it's matching those as partial strings. | 21:59 |
| jayco | Hello all, im new to this. I am a third year software engineering student and I would like to know how i can get involved in ubuntu development. | 22:01 |
| maxiaojun | Another issue is that some hardware now support VAAPI (Video Acceleration API), but enable such features requires manual package installation now. | 22:01 |
| slangasek | maxiaojun: I'm surprised to hear that, b43 is a long-known use case. but beyond filing a bug report or reviewing the branch history, I have no specific advice I can offer | 22:01 |
| maxiaojun | jayco: No offence, do you run Ubuntu natively on at least one of your computers? | 22:02 |
| infinity | slangasek: The lbm meta bits don't seem to be in the wrong section, no. I was referring to the apt snippet not trying to keep lbm around to match the installed kernels. | 22:03 |
| jayco | maxiaojun: yes that is the only operating system i run at home. | 22:03 |
| slangasek | jayco: http://www.ubuntu.com/community/get-involved | 22:04 |
| slangasek | infinity: oh, ok | 22:05 |
| maxiaojun | slangasek: I think there are (many) bug reports for Jockey already. Not sure the state of ubuntu-drivers. | 22:05 |
| maxiaojun | jayco: You should notice some bugs of Ubuntu already? | 22:06 |
| slangasek | infinity: fwiw this is not a regression, linux-backport-modules was never marked before. do you want to file a new bug report for this etc etc? | 22:08 |
| infinity | slangasek: Sure. I was figure you'd JFDI while fixing the other regexes to be exact matches. ;) | 22:08 |
| infinity | (Or I can do both right now) | 22:08 |
| scientes | is there a amd64 kernel in i686 for 11.10? | 22:08 |
| infinity | dpkg -l linux\*image\*[0-9]\* | awk '/^i/ {print $2}' | xargs sudo apt-mark auto && sudo apt-get --purge autoremove | 22:09 |
| infinity | ^-- Actually DTRT. Yay. | 22:09 |
| maxiaojun | jayco: Do you have an LP account? | 22:11 |
| slangasek | infinity: be my guest :) | 22:11 |
| infinity | scientes: There aren't amd64 kernels in i386 in any release, but from (at least) precise on, you can add amd64 as a foreign-arch and install the amd64 kernel through the magic of multi-arch. | 22:12 |
| infinity | scientes: That may or may not work on oneiric, I don't recall if all the kernel's rdeps were multi-arch friendly in oneiric. | 22:12 |
| slangasek | which is hands-down the best ride at Disneyland, fwiw | 22:12 |
| slangasek | (The Magic of Multi-Arch) | 22:12 |
| scientes | i just want to be able to chroot into amd64 installs | 22:13 |
| jayco | maxiaojun: sorry for the deleyed response, kids running around and screaming in the background. Yes I have a LP account and have just installed the tools. | 22:13 |
| scientes | without the bad-binary party fail | 22:13 |
| infinity | scientes: Right, this is the sane way to do it, s'all I'm saying. | 22:13 |
| infinity | (Many of us run i386 userspace and amd64 kernels this very way) | 22:13 |
| * infinity grumbles about dkms poop in his /lib/modules preventing clean purging. | 22:14 | |
| scientes | i'll just try --force-architecture | 22:15 |
| slangasek | why would you do that instead of enabling multiarch? | 22:15 |
| slangasek | given that you frequent #multiarch, I wonder if I'm being trolled: ) | 22:16 |
| scientes | lololol | 22:16 |
| scientes | b/c its just one package... | 22:16 |
| infinity | One package that you might want to get upgrades for automatically... | 22:16 |
| scientes | aha, good point | 22:16 |
| maxiaojun | jayco: https://bugs.launchpad.net/ubuntu/+bugs?field.searchtext=&search=Search%20Bug%20Reports&field.scope=project&field.scope.target=ubuntu&orderby=-heat&start=0 | 22:17 |
| xnox | is it just me or svn 1.7 is fast and no longer has nested .svn directories everywhere? | 22:17 |
| infinity | xnox: Both those things are true, yes. | 22:17 |
| infinity | xnox: And if both these things had happened five years ago, people might care. | 22:17 |
| jayco | maxiaojun: thanks for your patience. I will start at the link you have given me. Cheers. | 22:20 |
| infinity | Damnit, I shouldn't have removed all my kernels before testing this change. :P | 22:21 |
| slangasek | heh | 22:21 |
| infinity | slangasek: Oh, the other thing Andy and I discussed was keeping headers in lockstep with the current kernels too (so, you'd potentially have 2 or 3 headers packages installed), so dkms can actually act on all installed kernels. | 22:22 |
| xnox | infinity: just install a few from kernel ppa. | 22:22 |
| scientes | depends linux-firmware:amd64 but it is not installable | 22:22 |
| xnox | cause those should be cleaned up as well =) | 22:22 |
| infinity | scientes: yeah, that may have been one of the deps Colin had to mangle. If you just grab linux-firmware:amd64 from precise, it should work. | 22:22 |
| infinity | scientes: (Cause it'll have the right M-A bits) | 22:23 |
| slangasek | infinity: I'm less convinced headers handling warrants a backport since we've never done that part before | 22:23 |
| === Tonio_ is now known as Tonio_aw | ||
| infinity | slangasek: No, true. Oh, actually, it can also be done outside of apt. I think we once discussed having linux-image-$abi suggest linux-headers-$abi, which would be enough to keep it from being autoremoved, wouldn't it? It's been a while since I tested the headers theories. | 22:24 |
| slangasek | dunno | 22:24 |
| infinity | Anyhow. Can be looked at later. | 22:24 |
| scientes | yeah i've filed many m-a bugs....i guess i'm just impatient when it comes to problems with legacy systems | 22:24 |
| slangasek | I wouldn't expect Suggests to have that effect | 22:24 |
| slangasek | scientes: then upgrade from the legacy system to 12.04 :) | 22:25 |
| infinity | scientes: Well, the right answer is probably "don't run oneiric". ;) | 22:25 |
| maxiaojun | scientes: I guess support period mostly means security fixes. | 22:26 |
| scientes | maxiaojun, that is what it has always meant | 22:28 |
| yofel | cjwatson: would you be so kind to refresh the kubuntu packageset please? I added ffmpegthumbs, kfloppy, kiten and pairs to supported as they're part of the KDE SC | 22:28 |
| scientes | except for firefox, e.g. | 22:28 |
| maxiaojun | scientes: exactly | 22:29 |
| === Tonio_aw is now known as Tonio_ | ||
| scientes | what is "gdb-multiarch"? | 22:43 |
| infinity | scientes: The package description seems to shed some light... | 22:44 |
| scientes | you mean like debug arm over ssh with gdbserver? | 22:45 |
| scientes | from x86? | 22:45 |
| infinity | Dunno. I know about as much as the description tells me. :P | 22:46 |
| scientes | (i did read the description) | 22:46 |
| scientes | aka includes all the disassemblers | 22:46 |
| === mhall119_ is now known as mhall119 | ||
| slangasek | ooh, I wonder if it's time to drop the ia32-libs package | 22:52 |
| === attente is now known as attente_zzz | ||
| xnox | slangasek: ev: or cjwatson: please make "raring" the series goal of https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-wubi-publishing | 23:04 |
| xnox | carry over from quantal. | 23:05 |
| slangasek | xnox: done.. how's that recipe coming? :) | 23:06 |
| slangasek | xnox: btw, somewhere along the line I thought I heard ScottK say "patches welcome" wrt the python-qt4 split? | 23:10 |
| xnox | slangasek: there are a few things to be done (given the last analysis between me and ev) it might be half built & half pre-compiled binaries =) | 23:10 |
| slangasek | tasty | 23:10 |
| xnox | slangasek: after ScottK saw doko's patch to "fix" pykde4 against python3.3 (it was the last package) ScottK may now have reservations about _any_ patches. | 23:11 |
| xnox | https://launchpadlibrarian.net/121171442/pykde4_4%3A4.9.2-0ubuntu2_4%3A4.9.2-0ubuntu3.diff.gz | 23:11 |
| xnox | + ${PYTHON_INCLUDE_DIR2} | 23:12 |
| xnox | is an excellent variable name =) | 23:12 |
| doko | f*ck cmake ... | 23:12 |
| slangasek | doko: what about putting all the headers under the multiarch include path... so we don't have to fight with cmake anymore? | 23:13 |
| xnox | my CMake patches were sensible as it has depricated the _DIR and _PATH variables and the PYTHON_INCLUDE_PATHS is actually a correct solution. | 23:13 |
| doko | slangasek, thought about it, will break other configuration stuff, which checks for Python.h in /usr/include/pythonX.Y | 23:13 |
| slangasek | cute | 23:14 |
| slangasek | ok | 23:14 |
| xnox | CMake implemented this after the first round of fighting with regular multiarch. | 23:14 |
| cjwatson | yofel: I've refreshed it up to whatever the current data said, but I suspect that's only updated daily, so remind me tomorrow | 23:14 |
| yofel | ok, thanks | 23:14 |
| === Ursinha is now known as Ursinha-afk | ||
| infinity | Gee, I really wish apt was one of those packages that ran configure on clean, that's so very convenient. | 23:33 |
| * doko curses debhelper about LP: #1075146 | 23:34 | |
| ubottu | Launchpad bug 1075146 in libxml2 (Ubuntu) "libxml2 2.9.0+dfsg1-3 FTBFS in raring" [High,New] https://launchpad.net/bugs/1075146 | 23:34 |
| xnox | infinity: jam and one other buildsystem does it as well. | 23:36 |
| xnox | agree waste of time & will fail with flames at cross-arch build probably =) | 23:36 |
| infinity | slangasek: New apt uploaded with discussed changes. I'll take up the headers issue separately. | 23:41 |
| === Ursinha-afk is now known as Ursinha | ||
| stgraber | slangasek: so apparently merging my code into sru-report would make the report 15m slower to generate ;) | 23:56 |
| slangasek | yeah let's not do that then | 23:56 |
| slangasek | the report already knows about what versions are where | 23:57 |
| slangasek | we really just need it to additionally check raring, and copy packages over as needed | 23:57 |
| slangasek | er, tell us to copy packages that is | 23:58 |
| slangasek | I'm not looking for this to report on all archive inconsistencies, I just want it to tell us when we should be using -d | 23:58 |
| cjwatson | I think sru-release should work that out for itself | 23:59 |
| stgraber | right, checking just raring should be fine, that's just an extra version check so doesn't take really long. What's really slow is when checking for older releases (oneiric and precise mostly) where we have hundreds of packages in -updates (langpacks mostly) | 23:59 |
| slangasek | cjwatson: that works too | 23:59 |
| cjwatson | it could easily say "quantal-updates == raring, obviously this should just be copied up" - or prompt about it if that makes people nervous | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!