| === zukeprime is now known as rayq | ||
| smoser | ugh. | 02:25 |
|---|---|---|
| smoser | hey, my core dev mempership expired today | 02:25 |
| smoser | can i get it fixed ? | 02:25 |
| pitti | doko: kde4pimlibs 5 h? it ran for 2:30 h, which is fairly normal | 04:52 |
| pitti | oh, you mean it was waiting for 5 h? | 04:53 |
| pitti | doko: wrt. your question of "someone else"> the cloud stuff can be handled by infinity, slangasek, stgraber, and Laney (I gave training to Laney); the most common admin tasks are documented on prod-ues-proposed-migration | 05:09 |
| pitti | doko: err, documented on https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration | 05:10 |
| pitti | doko: armhf and ppc64 are still kind of "step kinds" from the old infra, waiting to move to scaling stack; happy to show you (or some one else) about admin | 05:10 |
| pitti | dpm: hey David! Can we please have http://people.canonical.com/~dpm/data/ubuntu-l10n/ for RTM 15.04? | 05:27 |
| dpm | morning pitti | 05:27 |
| * dpm files RT | 05:27 | |
| pitti | dpm: ah, that's something for IS? thanks | 05:28 |
| dpm | yeah | 05:28 |
| pitti | dpm: you can drop rtm 14.09 btw, it's obsolete | 05:28 |
| pitti | dpm: (and utopic too) | 05:29 |
| dpm | ack | 05:29 |
| === didrocks1 is now known as didrocks | ||
| dholbach | good morning | 06:44 |
| didrocks | @pilot in | 07:31 |
| === udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks | ||
| * dholbach hugs didrocks | 07:58 | |
| * didrocks hugs dholbach back | 07:58 | |
| Laney | pitti: I don't think I would have known how to debug a stuck "in progress", if that's what it was | 08:06 |
| pitti | Laney: you could have looked at the queue length | 08:07 |
| Laney | yeah | 08:07 |
| pitti | Laney: we have 8 armhf runners, any number of requests that's larger than that will have to wait | 08:07 |
| Laney | so I could have said that it looks like it might be waiting | 08:07 |
| pitti | Laney: http://autopkgtest.ubuntu.com/packages/k/kde4pimlibs/wily/armhf/ looks like it took its usual time (2:30) | 08:07 |
| Laney | would it be hard to have a separate queued state? | 08:08 |
| pitti | it started at 20:56:30 UTC, not sure when britney requested it (could dig out of the logs) | 08:08 |
| pitti | Laney: not easy right now; we'd need a way to export what's currently running from all the workers | 08:09 |
| pitti | Laney: rabbitmq should know this (i. e. which are being processed and which are waiting), but we don't export the queue status right now | 08:10 |
| pitti | the rabbit management plugin has quite some nice stuff, this sounds like a good place to start | 08:10 |
| pitti | Laney: or the other way round, you can get access to the armhf runners, and then just check what's currently running; want to? | 08:11 |
| pitti | infinity: FYI, I gave you access to the cyclops and wolfe boxes, in case you want to peek at them (or reboot, restart worker, or what not); I added some documentation to https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Administration | 08:28 |
| infinity | pitti: Mmkay. That's temporarily helpful, but I'm hoping we can get more to a self-service model, like lp-buildd. | 08:32 |
| pitti | infinity: yes, absolutely; this is for administration, not for developers | 08:32 |
| infinity | (Which, granted, it took us 8 years to build a user-accessible "cancel" function but...) | 08:32 |
| pitti | (i. e. when the boxes lock up or what not) | 08:32 |
| infinity | pitti: Sure, point being that once this is all in scalingstack, an "admin" and a "user" should look almost identical, minus a tiny bit of glue. | 08:32 |
| pitti | infinity: it's still the plan to export the queues and show them in debci | 08:32 |
| pitti | infinity: yes, once armhf/ppc64el work in scalingstack all these external workers will just disappear | 08:33 |
| pitti | until then, we have to make-do | 08:33 |
| * infinity nods. | 08:33 | |
| infinity | pitti: So, for the scalingstack arches, do we have a clean way to cancel a job? | 08:33 |
| infinity | pitti: May as well work on the utopia on x86, and be happy we get it all for free when the other arches catch up. | 08:34 |
| pitti | infinity: clean, yes (kill the adt-run process); "easily accessible", no; and I'm not even sure we should make this | 08:34 |
| infinity | pitti: Why not? | 08:34 |
| pitti | I mean, if you kill adt-run, it'll just be re-run immediately | 08:35 |
| infinity | pitti: It's just a build job like any other. | 08:35 |
| infinity | pitti: Killing should be from the master/queue, not the slave. ;) | 08:35 |
| pitti | infinity: what's your use case? i. e. who would want to do this and when? | 08:35 |
| infinity | pitti: ie: master is told "make it die", it tries to fetch current logs, if succeed, kill remote VM, if timeout, kill remote VM, either way, log job as cancelled. | 08:36 |
| pitti | infinity: master is britney? | 08:36 |
| infinity | pitti: The same use-case as killing a package build. Sometimes you don't want it to run. Sometimes it's hung. Sometimes you're freeing up resources. Sometimes you know it's going to fail and why waste 8h, etc, etc. | 08:36 |
| pitti | infinity: if it's hung, the kill will work right now (but it'll be immediately re-picked up by some worker, and re-run) | 08:37 |
| infinity | pitti: master is your queue. britney is just a fire-and-forget job creation client. | 08:37 |
| pitti | ah | 08:37 |
| pitti | right, removing it from the queue and killing the running job would work | 08:37 |
| infinity | pitti: In the LP sense, britney would be like creating package build records on upload. Your queue is buildd-manager (and its SQL tables), which is where state lives. | 08:37 |
| infinity | And slaves should be completely stupid. Easily murdered at will. Not with killing a process, probably, but just by hard resetting VMs. | 08:38 |
| infinity | (Though having the kill fallback is nice for non-VM runners, as we also do in lp-buildd) | 08:38 |
| infinity | Or, rather, lp-buildd tries a "clean" kill, and if that times out *and* the builder is a VM, buildd-manager says "ah, screw it", and resets hard. | 08:39 |
| infinity | But we also reset VMs between all builds for security/sanity reasons too. Not sure if you're doing that yet in scalingstack autopackagtest, but you probably should be. | 08:40 |
| infinity | Once you're always resetting VMs anyway, it starts looking like the hammer for every nail, cause it's simple. :P | 08:40 |
| infinity | pitti: Anyhow, all of this also needs a sane view of the queue in general, before queue manipulation is a thing. | 08:40 |
| infinity | pitti: So, a, then b. | 08:41 |
| infinity | Oh, and A, section 2, which is that we need a view into in-progress jobs, or "is it hung?" is a question no one can answer without a shell. | 08:41 |
| pitti | infinity: every test always gets a brand new VM | 08:41 |
| pitti | infinity: i. e. with nova boot, and nova delete at the end | 08:41 |
| infinity | pitti: Excellent, good. I expected that, but wasn't sure. | 08:42 |
| pitti | tests have full root, and can break the testbed in unknown and interesting ways; there's nothign to salvage | 08:42 |
| pitti | infinity: right, that's part of the "show queue in debci" thingy | 08:42 |
| pitti | to see which are running, and which are queued | 08:42 |
| infinity | pitti: Kay, so queue+logtail, ideally. | 08:42 |
| infinity | pitti: queue is interesting info, but without a logtail, it's still a guessing game. | 08:43 |
| infinity | "Job was started 3h ago, and...?" | 08:43 |
| infinity | (FWIW, this is the thing I hate the absolute most about buildd.debian.org after the last decade of Soyuz usage, that tail is way more useful than we thought it was when implementing it as a silly, shiny feature) | 08:44 |
| pitti | undoubtedly :) (unfortunately also rather involved to implement) | 08:44 |
| infinity | pitti: Do the slaves have a listener of any sort, or do you do all your state polling via ssh/scp? | 08:52 |
| pitti | infinity: no ssh involved, it's just AMQP for the requests, and the slaves put the results directly into swift | 08:53 |
| pitti | loose coupling | 08:53 |
| pitti | infinity: i. e. they listen to AMQP queues | 08:54 |
| infinity | pitti: Ahh, kay, so the slave is returning bits to swift? | 08:54 |
| pitti | infinity: we can implement tailing via AMQP (just send out the log tail every 30 s to a broadcast queue or so) | 08:54 |
| infinity | pitti: So, one could just jam a logtail into swift as well. | 08:54 |
| pitti | nah, not into swift | 08:54 |
| pitti | seems easiest to use a broadcasting AMQP queue for that | 08:55 |
| pitti | then we don't need any new auth/firewall holes/host name hardcoding anywhere | 08:55 |
| infinity | Fair enough, I don't speak AMQP. | 08:55 |
| pitti | infinity: it's more or less just a queue which you can feed requests into, and someone else picks out a request (with lots of routing options, but an unbreakable FIFO is the simplest use case) | 08:56 |
| pitti | i. e. what we don't want is britney to do "ssh armhfworker1.canonical.com", as that is brittle and not scalable in so many ways | 08:57 |
| infinity | pitti: Right. But it handles large messages fine, then? | 08:57 |
| pitti | so britney puts a test request for "linux" into some "wily-amd64" queue, and whichever worker listens to that queue can process it | 08:57 |
| pitti | infinity: FSVO large -- the messages are mostly bound by memory; so they shouldn't exceed 50 MB or so | 08:58 |
| pitti | but we are speaking about a log tail of maybe 1 kB or so | 08:58 |
| infinity | pitti: Oh, sure, a logtail should never be more than a few dozen kB, or you're doing it wrong. | 08:58 |
| infinity | (or less, indeed) | 08:58 |
| pitti | infinity: so an idea is that every release-arch queue could have an accompanying release-arch-logtail queue which works in teh other direction; i. e. the workers put the log tail into these every n seconds | 08:59 |
| pitti | and whoever bothers to listen can show them | 08:59 |
| pitti | this queue would be configured to be in this kind of "lossy" mode, as opposed to the request queues which never lose anything | 09:00 |
| pitti | infinity: heh, seems http://notes.variogr.am/post/143623387/broadcasting-your-logs-with-rabbitmq-and-python does pretty much that | 09:05 |
| pitti | infinity: so maybe implementing this should even be A1 -- once we have a page with all logtails of all currently running tests, then this implies knowing which tests are running; and everything on excuses.html which is "in progress" but not running is then queued | 09:08 |
| Riddell | pitti: KDE mostly cleared from excuses, rocs is failing on ppc64el with an unknown error, worth trying again? http://autopkgtest.ubuntu.com/packages/r/rocs/wily/ppc64el/ | 09:19 |
| pitti | error writing to /tmp/ccPiwlDE.s: Cannot allocate memory | 09:20 |
| pitti | Riddell: yes, worth retrying; done | 09:20 |
| * pitti looks at bluez-qt | 09:20 | |
| pitti | Temporary failure resolving 'ports.ubuntu.com' - sigh, retrying | 09:20 |
| cjwatson | smoser: ~developer-membership-board should be able to fix that up quickly. did you miss the expiration warning mails? | 09:34 |
| infinity | cjwatson: It got sorted. And yes, he missed all the emails. | 09:38 |
| sitter | pitti: can we somehow dump arbitrary files into the artifacts tarball? namely upon ACC failure it would be handy to have the ACC headers and so forth artifacted | 09:39 |
| cjwatson | smoser: Would it have helped if those mails were more filterable? Since I have a branch in progress for that ... | 09:39 |
| pitti | sitter: yes, absolutely; see https://people.debian.org/~mpitt/autopkgtest/README.package-tests.html , your test can put anything into the $ADT_ARTIFACTS dir, and it'll appear in the "artifacts.tar.gz" from autopkgtest.u.c. | 09:40 |
| sitter | groovy thanks | 09:40 |
| pitti | Riddell: ack, rocs happy again | 09:45 |
| Riddell | awooga | 09:46 |
| === kickinz1 is now known as kickinz1|lunch | ||
| mapreri | dholbach: thanks :) | 11:29 |
| === MacSlow is now known as MacSlow|lunch | ||
| didrocks | @pilot out | 11:38 |
| === udevbot_ changed the topic of #ubuntu-devel to: Archive: feature freeze | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| diwic | doko, so, I *think* trust-store should be in main now, because it says so in launchpad, so I retried the pulseaudio build, but it didn't seem to help | 11:56 |
| cjwatson | You're reading the wrong bit of the LP UI. | 11:56 |
| cjwatson | "Component:" on https://launchpad.net/ubuntu/+source/trust-store just means the package defaults, as indicated by the small print there (sorry ...). The actual published location is per-series below. | 11:57 |
| doko | didrocks, what cjwatson said, still in universe | 11:57 |
| cjwatson | Also pulseaudio will retry automatically once trust-store is actually in main. | 11:57 |
| diwic | doko, cjwatson, ok, thanks | 11:57 |
| doko | but I find this ui confusing too | 11:58 |
| didrocks | phew, for a sec, I didn't get the context ;) | 11:59 |
| cjwatson | It's tempting to just delete the Component field there. | 11:59 |
| cjwatson | https://bugs.launchpad.net/launchpad/+bug/521722 ends up suggesting that too | 11:59 |
| ubottu | Launchpad bug 521722 in Launchpad itself "Display of Component on distro source summary page may be wrong (but we know the right value)" [Low,Triaged] | 11:59 |
| cjwatson | diwic: would it have been less confusing if the Component:* field there were simply absent? there's then the per-series bit below that says "release (universe)" etc. | 12:04 |
| infinity | cjwatson: I'm inclined to agree that the .dsc component is completely useless and should just not be shown. | 12:04 |
| infinity | cjwatson: The other option is "show component of the proposed>updates>security>release pocket in the devel series", but that's really not useful. About as not useful as the package list from the current stable. ;) | 12:05 |
| cjwatson | Also misleading in a different way, because we don't know what you care about (latest, or LTS, or ...) | 12:06 |
| infinity | Basically, the whole top half of that page is useless. | 12:07 |
| cjwatson | It makes a slight difference whether it's contrib or non-free for Debian stuff imported into multiverse, but really not a lot and not +index-worthy. | 12:07 |
| infinity | cjwatson: I'd argue that what most people looking at that page care about is the package list from the devel series, but I'd be just as happy with not showing it there at all, since it's not clear which series it's from. | 12:07 |
| cjwatson | Yeah, it needs a total rework, but it seems worth dealing with the bits that are actually bleeding (.dsc component). | 12:07 |
| cjwatson | Since that's a five-line change. | 12:08 |
| infinity | cjwatson: anyhow, yes, agreed. Package list is a bigger debate (perhaps), I think consensus that .dsc component is useless and confusing is pretty much unanimous. | 12:08 |
| cjwatson | OK, I'll nuke it | 12:08 |
| cjwatson | But first, shopping | 12:08 |
| diwic | cjwatson, thanks for asking. I'm not familiar with the internals of main vs universe and how things are promoted/demoted, but I suppose if not all the binary packages are in the same as the source package, then yes, it's a bit confusing | 12:09 |
| infinity | cjwatson: Curiously, somtimes it's correct... | 12:09 |
| infinity | cjwatson: I wonder if that's just historical data versus new. | 12:09 |
| cjwatson | diwic: Well, that and the fact that the source isn't in main either; the "Component:" at the top is extracted from the source package and has nothing to do with actual publication other than setting defaults | 12:10 |
| cjwatson | Which is utterly mysterious to most people | 12:11 |
| infinity | cjwatson: Could it be that historical data was ginaed from Ubuntu and older packages get it "right" by accident or something? | 12:11 |
| cjwatson | infinity: The package list? | 12:11 |
| infinity | cjwatson: (see, eg: poppassd, which is 'main' per .dsc, but 'universe' on the offending page) | 12:11 |
| infinity | cjwatson: No, the component. | 12:11 |
| infinity | cjwatson: So, it's not even consistently wrong. :P | 12:11 |
| smoser | cjwatson, i wish i had a good excuse. but only excuse is "so much mail stuff gets lost". maybe it could have pinged me on irc. | 12:16 |
| infinity | smoser: I'd say rejecting your uploads is a fair last resort to the mail going missing. | 12:17 |
| cjwatson | infinity: Probably something to do with one being a direct upload and the other being copied from SPRs created by gina, indeed, but meh, too twisty for me to really want to totally track down. | 12:17 |
| cjwatson | infinity: Oh, in fact, I expect it's because trust-store's initial upload was to a PPA. | 12:18 |
| cjwatson | infinity: Which only has main. | 12:18 |
| infinity | cjwatson: Ahh, could be. | 12:19 |
| smoser | infinity, it definitely got my attention :) | 12:19 |
| infinity | cjwatson: All very confusing anyway. Purge with fire. | 12:19 |
| cjwatson | Yeah. | 12:19 |
| cjwatson | infinity: Though you're right that it's weirdly inconsistent - compare poppassd and makepasswd | 12:21 |
| infinity | cjwatson: But makepasswd has been synced recently, the last poppassd was lucid, the consistency is probably a historical thing. | 12:22 |
| cjwatson | I guess that could just be because something in gina has changed since 2010. | 12:22 |
| cjwatson | Right. | 12:22 |
| infinity | cjwatson: Also, kinda not caring anymore. | 12:22 |
| cjwatson | :-) | 12:22 |
| infinity | cjwatson: Anything that deletes some code and cleans up a bad UI can't possibly be wrong. | 12:23 |
| === MacSlow|lunch is now known as MacSlow | ||
| rbasak | Hash Sum Aaargh! | 13:41 |
| * pitti tosses an apt 1.1 to rbasak and pats him | 13:43 | |
| barry | pitti: ubuntu-drivers-common \o/ - thanks :) | 13:49 |
| pitti | barry: yw :) | 13:49 |
| === Luke_ is now known as Luke | ||
| smoser | anyone generally oauth knowledgable that could help me ... | 15:04 |
| smoser | currently i have some code that is logging a oauth request and its headers. | 15:04 |
| smoser | like : http://paste.ubuntu.com/12263581/ | 15:06 |
| smoser | i'm wondering is there anything there that i shoudl redact from the log ? is is token or consumer key needed to be masked out. Its easy enough to do it, but if they're not sensitive (note, there is no token_key or token_secret) then they're quite likely useful for debugging | 15:06 |
| ricotz | stgraber, hi, pastebinit could you use a little tweak to deal with paste.debian.net forcing https | 15:29 |
| octoquad | didrocks & Laney thanks for merging my MP for USC :) | 15:31 |
| didrocks | thanks you octoquad for your MP! :) | 15:32 |
| octoquad | I'm curious, what's the plan for USC and Snappy? | 15:35 |
| didrocks | ogra_: ^ | 15:36 |
| stgraber | ricotz: patches are welcome :) not that I've touched pastebinit in over a year, I should probably do another release soon-ish :) | 15:36 |
| doko | mitya57, will you still merge python-sphinx? | 15:41 |
| ogra_ | didrocks, no idea, i'm not a software center person :) | 15:44 |
| didrocks | ogra_: you are the snappy one though :p | 15:44 |
| ogra_ | i would guwss the snappy store will replace it at some point | 15:44 |
| ogra_ | well, the "snappy scope" actually | 15:45 |
| ogra_ | which isnt much different from the click scope on the phone afaik | 15:45 |
| ogra_ | didrocks, i think kyrofa works on that iirc | 15:48 |
| didrocks | nice :) | 15:49 |
| octoquad | cool, thanks ogra_ | 15:49 |
| ricotz | stgraber, https://paste.debian.net/plain/310262 ;) | 15:50 |
| infinity | in 103 | 15:51 |
| kyrofa | didrocks, ogra_ is right. Demo is here: https://www.youtube.com/watch?v=17nVOHrCh7Y&feature=youtu.be | 15:51 |
| didrocks | I guess that's for octoquad ^ | 15:52 |
| octoquad | watching already :P | 15:52 |
| Laney | kyrofa: you have a good narrating voice | 15:53 |
| octoquad | nice, remember to add dark theme support hey :P | 15:53 |
| * Laney wants to buy whatever it is you are selling | 15:53 | |
| kyrofa | Laney, haha, thanks! | 15:53 |
| Laney | a box of air? i'll have ten! | 15:53 |
| ogra_ | Laney, and if you take them all at once you get a discount !! | 15:57 |
| Laney | $100 each, 10 for the low low price of $1050 | 15:58 |
| ogra_ | $1049 with friendship bonus, others pay more ! | 15:59 |
| didrocks | (without shipping) | 15:59 |
| stgraber | ricotz: pushed to trunk | 15:59 |
| dobey | hmm | 16:28 |
| dobey | noooooo | 16:28 |
| dobey | sigh | 16:28 |
| doko | barry, did you file bug reports for the python3.5 ftbfs? | 16:32 |
| dobey | didrocks: well that was rude :( | 16:43 |
| didrocks | dobey: hum? what about? | 16:43 |
| dobey | didrocks: pushing stuff directly to lp:software-center like that | 16:44 |
| didrocks | dobey: seems Tarmac was down for 8 hours, nobody is reviewing USC merge for ages, Laney told we were ok to push directly after build | 16:44 |
| dobey | there is no tarmac for software-center | 16:44 |
| dobey | it is not ok to push directly to trunk | 16:44 |
| didrocks | is the procedure for it documented? | 16:44 |
| didrocks | I may have missed it, but tried to look | 16:44 |
| dobey | i have been meaning to switch it over to the CI train, yes; but i haven't gotten around to it yet | 16:45 |
| dobey | but anyway, those two branches shouldn't have been merged anyway, since they don't meet the requirement of contributor agreement | 16:45 |
| didrocks | so, you are maintaining USC? We keep get us (desktop team) pinged about it because nobody is taking care of MP | 16:45 |
| dobey | well, you can ship distro patches until they get merged if you want | 16:46 |
| didrocks | dobey: so if you are taking again some time for looking at this project, please unmerge them (also, I saw that most of people just distro-patch it and it hadn't a release for almost 2 years) and get it in line | 16:46 |
| dobey | as i've told to do in the past | 16:46 |
| didrocks | dobey: yeah, let's do that | 16:46 |
| didrocks | octoquad: reopening MP ^ | 16:47 |
| octoquad | didrocks, np | 16:47 |
| didrocks | dobey: let me rewind trunk | 16:47 |
| dobey | if desktop team wants to take over ownership of it, i'm fine with that too. i really don't want to deal with it. but patience is appreciated | 16:47 |
| didrocks | dobey: no, it's just that it's been weeks/months that we are pinged about USC issues | 16:47 |
| didrocks | but we do prefer you, as you have more expertise on it looking at things if possible :) | 16:48 |
| dobey | well we don't ship it on the phone, snappy, or server | 16:48 |
| didrocks | we do have a desktop product we ship every 6 months though | 16:48 |
| dobey | i wouldn't say i have more expertise about it. | 16:48 |
| dobey | it got dumped in my lap a few years ago | 16:49 |
| didrocks | you were not agile enough to avoid it it seems :p | 16:49 |
| dobey | yes, and unfortunately the ubuntu.iso includes software-center | 16:49 |
| dobey | well it made sense at the time | 16:49 |
| didrocks | dobey: trunk rewinded, reopening MP in a sec | 16:49 |
| dobey | since we were the "ubuntu one" team at the time, and software-center fit fairly well under that | 16:50 |
| dobey | software-center doesn't really fit well under the scope of "unity api" though | 16:50 |
| dobey | anyway | 16:51 |
| didrocks | dobey: indeed, so all done now, if you have some time to give a look, that would be great! | 16:51 |
| didrocks | dobey: let's keep the distro patches for now | 16:51 |
| octoquad | doby didrocks what will happen to the mp now? will it still make it for ui freeze? | 16:51 |
| didrocks | octoquad: it's still in wily | 16:51 |
| didrocks | octoquad: just not in software-center trunk | 16:51 |
| didrocks | (in distro as distro-patches) | 16:52 |
| octoquad | I see. Thanks for clearing that up. | 16:52 |
| didrocks | yw! | 16:52 |
| dobey | octoquad: you need to sign the contributor agreement, before your changes can land | 16:52 |
| octoquad | where do I find that dobey? | 16:52 |
| dobey | octoquad: http://www.ubuntu.com/legal/contributors | 16:53 |
| octoquad | but, does it really matter? The future of USC might come to an end soon right? | 16:53 |
| octoquad | ta dobey | 16:53 |
| dobey | it's been coming to an end soon for three years, so i wouldn't put too much stock in "soon" right now :) | 16:54 |
| octoquad | dobey, hehe | 16:54 |
| dobey | the sooner it goes away, the happier i'll be though (as will anyone who wants to get rid of python2 from the ISO) | 16:55 |
| jcastro | dobey: if no one is maintaining that stuff then your team could at least let people know | 16:55 |
| jcastro | this whole black-hole business won't help anyone | 16:55 |
| octoquad | didrocks, will that fix also be available in xx? | 16:55 |
| dobey | jcastro: it's in "maintenance" mode | 16:55 |
| jcastro | it's like you guys keep dropping projects but not telling anyone, how are people supposed to contribute? | 16:56 |
| dobey | we aren't dropping projects | 16:56 |
| didrocks | octoquad: the fix will stay until someone remove the distro-patch | 16:56 |
| didrocks | octoquad: so the default is "yes" :) | 16:56 |
| octoquad | didrocks, ok. What's a distro-patch, I'm relatively new to contributing | 16:56 |
| jcastro | is there a different definition for not responding to pings or MPs from people other than dropping? | 16:56 |
| dobey | we should just call 16.04 "dos equis" | 16:57 |
| jcastro | "maintenance" isn't the word most people would use | 16:57 |
| didrocks | octoquad: a patch applied to the package in a distro that isn't in upstream trunk | 16:57 |
| didrocks | octoquad: so basically "only on ubuntu" in this case | 16:57 |
| dobey | jcastro: don't add more confusion to the issue, please. i have responded to pings | 16:57 |
| octoquad | didrocks, aaah, thanks :) | 16:57 |
| didrocks | octoquad: yw ;) | 16:57 |
| octoquad | bbl | 16:58 |
| dobey | didrocks: anyway, if your team is getting too many pings about software-center, and think it needs more attention/priority for a bit, then get your PM to bring it up in the unity api stakeholders meeting | 17:00 |
| didrocks | dobey: or get your team doing their patch pilot shift for people with upload rights and they will see them? | 17:00 |
| dobey | didrocks: our team doesn't have a patch pilot shift | 17:01 |
| mitya57 | doko, not in this cycle | 17:01 |
| didrocks | I thought everyone with upload rights had some | 17:01 |
| doko | mitya57, just because we have some dep-waits | 17:01 |
| dobey | and i'm the only one with any upload rights, and it's only like 2 or 3 packages i have upload rights for :-/ | 17:02 |
| mitya57 | doko, I will merge it in the beginning of wily+1, but I can look at the dep-waits now | 17:02 |
| didrocks | dobey: so maybe look at the shifts on the list for those 2-3 packages? That would make dholbach even happier :p | 17:02 |
| didrocks | and will fix that issue | 17:02 |
| doko | mitya57, ta | 17:02 |
| dobey | didrocks: CI train has basically eliminated any need for people to get upload rights too | 17:03 |
| didrocks | yeah | 17:03 |
| mitya57 | doko, though this is strange as sphinx 1.3 arrived in main just a couple of days before the import freeze | 17:03 |
| mitya57 | You probably need to blame those who synced those packages | 17:03 |
| hallyn | pitti: stgraber: want to get http://paste.ubuntu.com/12264542/ into systemd in the archive. i could just push, but i assume pitti is in the middle of some changes so don't want to cause a mess :) | 17:07 |
| doko | mitya57, can't see who synced it: https://launchpad.net/ubuntu/+source/routes and no email to changes email. https://launchpad.net/ubuntu/+source/routes/+publishinghistory | 17:10 |
| doko | probably I should just remove it, unstable already has a newer version | 17:11 |
| mitya57 | oh yes, routes was uploaded by p1otr on the same day I uploaded 1.3 to unstable | 17:11 |
| mitya57 | Can we just remove 2.2-1 from -proposed and let it be autosynced again when wily+1 opens? | 17:12 |
| doko | I'll do it | 17:12 |
| mitya57 | Thx | 17:13 |
| tdaitx | tjaalton, hi! I have been taking a look at a few FTBFS for armhf... a few of those are caused by GLsizeiptr type being khronos_ssize_t on GLES* and a ptrdiff_t in glext (and GLEW), on armhf ptrdiff_t is a signed int while khronos_ssize_t is a signed long int - a similar problem happens to GLintptr, do you know of any reason for that mismatch? I was wondering if there anything preventing khronos_ssize_t to be set to ptrdiff_t | 17:16 |
| tdaitx | (I build mesa fine that way, have yet to build reverse deps) | 17:16 |
| tdaitx | tjaalton, since you are a mesa maintainer, you might have come across a discussion on this (I haven't been able to find anything so far) | 17:18 |
| === greyback_ is now known as greyback|eod | ||
| tjaalton | tdaitx: huh, no idea.. first time i hear about it | 17:57 |
| tdaitx | heh, ok, then it might be fixable =) | 17:58 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| to10fcm | hey guys, i am getting this error running different binaries on my system: "relocation error: /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference" | 19:28 |
| to10fcm | any ideas on how to fix? i saw a reference to it and GCC5 in a log for this chan (http://irclogs.ubuntu.com/2015/07/17/%23ubuntu-devel.txt) so I thought I'd come here to ask first | 19:28 |
| to10fcm | brb restating | 19:40 |
| smoser | infinity, could you look at https://bugs.launchpad.net/ubuntu/+source/bcache-tools/+bug/1491111 | 19:43 |
| ubottu | Launchpad bug 1491111 in bcache-tools (Ubuntu Trusty) "add bcache-tools to trusty archive" [High,Confirmed] | 19:43 |
| smoser | it seems like something you've helped me with before. and seems to fit in with pitti's SRU stuff https://lists.ubuntu.com/archives/technical-board/2015-September/002154.html | 19:44 |
| === JanC_ is now known as JanC | ||
| doko | infinity, could you provide a glibc 2.22 test build in a ppa? then I could include it in the test rebuild | 20:00 |
| sarnold | to10fcm: what are you trying to do? I think you'd want either all the libraries and executable to be compiled with gcc <5 or gcc >5, but mixing the two would lead to problems, probably of the sort you tripped on | 20:01 |
| doko | barry, fyi, http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-ppc64el-20150902-wily.html was built with 3.5 as the default | 20:02 |
| barry | doko: cool, thanks | 20:03 |
| to10fcm | sarnold, I just want to run dolphin. I have kubuntu installed and I did apt-get update && apt-get upgrade and I'm on 15.10 dev preview and dolphin errors out with this error: | 20:45 |
| to10fcm | dolphin: relocation error: /usr/lib/x86_64-linux-gnu/libQtWebKit.so.4: symbol _ZTVNSt7__cxx1115basic_stringbufIcSt11char_traitsIcESaIcEEE, version GLIBCXX_3.4.21 not defined in file libstdc++.so.6 with link time reference | 20:45 |
| doko | to10fcm, dpkg -l dolphin ? | 20:56 |
| to10fcm | ii dolphin 4:15.04.2-0ubuntu1 amd64 file manager | 20:57 |
| doko | to10fcm, should be 4:15.08.0-0ubuntu1 | 20:57 |
| doko | is your mirror up to date? | 20:57 |
| doko | did you run apt-get dist-upgrade? | 20:57 |
| to10fcm | a while back when i upgraded to 15.10 dev preview. i guess i can do it again and see if i get upgraded to some newer version | 21:00 |
| TJ- | Anyone got 2 bluetooth adapters working? I'm finding that bluetoothd/bluetoothctl only see hci0 whereas 'hcitool dev' sees all adapters. I'd like to get confirmation that others get the same result | 21:09 |
| doko | to10fcm, you have to run the complete apt-get update && apt-get dist-upgrade | 21:10 |
| doko | TJ-, any news about your openjdk-8 backport? | 21:11 |
| TJ- | doko: I've not had chance to look at it recently. I didn't find any problems with the limited testing I could do, but I didn't have time to do testing against tomcat/jboss etc. | 21:13 |
| doko | ta | 21:13 |
| to10fcm | doko, will do. brb after restart to tell u how it went lol | 21:14 |
| TJ- | I've not had a stable working environment for a while now either. Hit so may bugs on 15.10 I'm about 5 years behind | 21:14 |
| doko | TJ-, anything compiler specific? | 21:19 |
| TJ- | doko: No ... almost exclusively upstream's tearing out existing functionality in 'new' releases and breaking existing functionality | 21:21 |
| TJ- | e.g. systemd-cryptsetup *won't* support keyscripts; bluez not providing a simple agent nor PinCode Pairing, A2DP (punted to gstreamer/pulseaudio), headset profiles HCF/HSP (punted to ofono), LMV pvs not recognising metadata ... the list goes on! | 21:24 |
| doko | TJ-, bug reports, or pester pitti about systemd, and seb128 about bluez | 21:27 |
| lamont | wily dist-upgrade, now I have nopanel/launcher/etc... hints on what more I need to have installed? | 21:27 |
| TJ- | Yeah, reports are in. I've been attempting to figure out fixes or workarounds but some of them are far too big for simple patches. | 21:28 |
| TJ- | pitti: is aware of, and just as frustrated, about the systemd-cryptsetup issue. Nothing we can do to fix it though. Upstream want a major new generic API implementing. I've suggested we disable systemd-cryptsetup and use the 'legacy' cryptsetup init scripts which do the job perfectly (and are still used in the initrd) | 21:29 |
| doko | lamont, working here ... | 21:34 |
| lamont | it helps when ubuntu-desktop hasn't been removed (apt-get install -f) | 21:35 |
| lamont | testing now | 21:36 |
| lamont | much happier | 21:37 |
| lamont | (u-d brogut back in unity, compiz, compiz-gnome, et. al. | 21:38 |
| lamont | :( | 21:38 |
| * lamont goes back to selep | 21:38 | |
| to10fcm | whoever was helpiing me, thank you! | 21:38 |
| sarnold | to10fcm: excellent :) | 22:06 |
| doko | infinity, https://launchpad.net/ubuntu/+source/pytango/8.1.5-1build3 | 22:13 |
| doko | could you have a look at the image, where the c++ alternative points to? looks very much this is still pointing to g++-4.9 | 22:13 |
| Unit193 | sarnold: Hiya, know much about openssl's interaction as a library with other applications? | 22:16 |
| sarnold | Unit193: hey :) I'm going to guess "no", but keep going.. I might get lucky :) | 22:17 |
| Unit193 | Maybe I should take this to #ubuntu-server. | 22:17 |
| tdaitx | doko, gcc 4.7 FTBFS on ppc64el due to the gcc-as-needed.patch trying to apply to a non existing aarch64-linux.h, for the aarch64 to exist I would need to enable with_linaro_branch, is that ok? | 22:18 |
| tdaitx | doko, or should I separate the aarch64-linux.h part from gcc-as-needed.diff and apply it only when with_linaro_branch is valid? | 22:19 |
| doko | tdaitx, ignore it. 4.8 is the first version to build there | 22:19 |
| tdaitx | oh, ok | 22:20 |
| * tdaitx moving to the next FTBFS package... | 22:20 | |
| slangasek | mdeslaur: edk2 updated in Debian unstable; will sync it to wily when I think of it again | 22:22 |
| slangasek | mdeslaur: which I guess actually requires a round-trip through binary new hmm | 22:22 |
| tdaitx | slangasek, seems like someone else unblocked sssd for the build, the dependencies it was waiting for are done and it builds fine locally | 22:46 |
| tdaitx | slangasek, same for pulseaudio, libtrust-store-dev is available as well, so a rebuild should go fine | 22:49 |
| slangasek | tdaitx: the build-dependencies of sssd exist but are not in main | 22:51 |
| slangasek | tdaitx: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed | 22:51 |
| tdaitx | slangasek, in this case, how exactly can I help? | 22:53 |
| slangasek | tdaitx: you can follow https://wiki.ubuntu.com/MainInclusionProcess | 23:01 |
| slangasek | tdaitx: be sure to check for existing bugs for the dependencies in question, to avoid duplication | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!