| micahg | Please reject my first hplip upload to trusty, wasn't cleaned | 02:16 |
|---|---|---|
| slangasek | has anyone started rebuilds for boost? I notice uhd needs rebuilt for new boost, because gnuradio FTBFS for log4cpp rebuild | 03:26 |
| === ara is now known as Guest14068 | ||
| slangasek | oh, right. hey, new binaries for review | 07:59 |
| slangasek | :P | 07:59 |
| slangasek | xnox: does this look like a boost bug to you? https://launchpad.net/ubuntu/+source/fatrat/1.2.0~beta2-0ubuntu11/+build/7750690 | 08:00 |
| slangasek | doko: ok, I've started batch uploading libraries; many of the packages will Just Work, but those with symbols files are bound to fail. I'll revise my script to hold back packages that include symbols files; do you have any suggestions for batch-fixing of these? (https://launchpadlibrarian.net/213449479/buildlog_ubuntu-wily-amd64.atlas-cpp_0.6.2-4.1ubuntu1_BUILDING.txt.gz) | 08:10 |
| doko | slangasek, s/std::basic_string/std::__cxx11::basic_string/ will get you some updates. but not the ones where the return type for the string type is enocded ([abi:cxx11]) | 08:11 |
| slangasek | doko: ok. btw, since we now have per-library transition trackers for the library renames, should we maybe drop the libstdc++6 one? since that's not a transition that will ever "complete" anyway, given the inexact matches | 08:15 |
| doko | sure | 08:15 |
| slangasek | ok, pushed (but the tracker currently takes quite a while to process all the transitions, so web won't be updated for a few hours) | 08:16 |
| xnox | slangasek: it's a Qt4 moc's bug that it fails to parse BOOST_JOIN, because moc is not a good enough cpp, this is fixed in QT5... | 08:35 |
| xnox | slangasek: one should use, e.g. #ifndef Q_MOC_RUN ... #endif to "fix" it. | 08:36 |
| slangasek | xnox: ok; for now I'll just drop the package from wily | 08:38 |
| xnox | slangasek: Divide and conquer | 08:38 |
| xnox | slangasek: we could fix them all by recompiling qt4 with this: | 08:41 |
| xnox | http://pkgs.fedoraproject.org/cgit/qt.git/tree/qt-everywhere-opensource-src-4.8.0-rc1-moc-boost148.patch?id=f0ce6564e29e22eac504c538698517bdcef80061;id2=060db3c767b670dc1e168252644c937abc9fe607 | 08:41 |
| slangasek | xnox: right; the fact that it's qt4 tells me approximately how well-maintained and relevant it is however, so that puts it in the set of things I'm not going to let be in the critical path of the transition. it's now a wily-proposed-only FTBFS That someone can fix | 08:42 |
| xnox | slangasek: ok. | 08:43 |
| xnox | slangasek: this is not the only package where i have seen this happening at though. And fixing it at moc level overall will be best, than patching these falling leaf things. | 08:43 |
| xnox | i'll do that, and trigger the rebuild of things that failed with that. | 08:44 |
| * xnox goes to find coffee | 08:44 | |
| xnox | hm, we have those qt4 patches in place already. | 08:51 |
| === henrix_ is now known as henrix | ||
| doko | slangasek, go to bed and tell Laney and me where to continue | 12:01 |
| === utlemming is now known as utlemming_away | ||
| === utlemming_away is now known as utlemming | ||
| === utlemming is now known as utlemming_away | ||
| === psivaa is now known as psivaa-lunch | ||
| === utlemming_away is now known as utlemming | ||
| === psivaa-lunch is now known as psivaa | ||
| andol | Any chance that anyone in here cares about the http://releases.ubuntu.com/vivid/ FOOSUMS don't appear to match up with their corresponding FOOSUMS.gpg? http://paste.ubuntu.com/11994117/. In addition to the BAD signature reported by gpg there is also the oddness of the FOOSUMS file appearning newer than their correspdoning signatures files. | 16:38 |
| infinity | andol: Grr. Will fix. I blame whoever is mucking in my trees to drop new snappy releases in. | 16:49 |
| infinity | rsalveti: ^-- Who did that? | 16:49 |
| andol | infinity: Thanks. | 16:51 |
| infinity | andol: Thanks for catching it. | 16:52 |
| infinity | andol: Should be happier now. | 16:52 |
| andol | Yepp, yepp | 16:53 |
| rsalveti | infinity: I believe I did that, but looking at my logs I did call sign-cdimage, not sure what happened, sorry | 16:54 |
| rsalveti | will make sure this doesn't happen again | 16:55 |
| infinity | rsalveti: The simpler thing is just to drop your files in and call "checksum-directory ." | 16:57 |
| infinity | rsalveti: And double-check against the published version to make sure nothing broke before you sync-mirrors. | 16:57 |
| rsalveti | infinity: cool, thanks | 16:58 |
| infinity | rsalveti: Also, can we ever drop the compat symlinks I had to add for that blog post that pointed at the wrong path? I guess we can for wily, but never for vivid? | 16:59 |
| infinity | rsalveti: I was going to write proper snappy support into cdimage at some point so this all made sense, but yay time. | 16:59 |
| rsalveti | slangasek: can we drop the compat symlinks? | 16:59 |
| rsalveti | don't remember what caused it | 17:00 |
| rsalveti | but if it's just because of a blog post, sure, unless it's a post from mark :-) | 17:00 |
| infinity | rsalveti: I don't remember who the blog post was from, but it was vaguely "official", hence the symlinks. :P | 17:00 |
| infinity | rsalveti: It doesn't bug me if they stay there forever for vivid, just want to make sure no docs will reference them (other than the offending blog post) going forward, so we don't have to perpetuate the hack. | 17:01 |
| rsalveti | yeah, for wily we can for sure remove it | 17:01 |
| slangasek | doko_: I already did go to bed, and handed you the script on #distro for you to continue with... :) doesn't look like there've been any new libraries uploaded since this morning, however. that's fine, I can pick these up again, it's mostly scriptable by now | 19:57 |
| slangasek | rsalveti: yes, no objection from me to removal of the symlinks | 19:58 |
| slangasek | who maintains ben? Laney? | 20:37 |
| Laney | slangasek: fs(mall)vo | 20:49 |
| slangasek | Laney: ok, so... if I'm noticing it not scaling so well in the face of all the C++ ABI transitions... is that you? :) | 20:50 |
| Laney | slangasek: I can't be blamed for the upstream code | 20:52 |
| Laney | slangasek: You can run it with sh -x or something to see if it's a problem with the way we are invoking it | 20:52 |
| slangasek | ben appears to be a binary executable | 20:52 |
| Laney | there's a runner | 20:53 |
| slangasek | the runner isn't what's taking 99% CPU and 70% memory for 3 hours | 20:53 |
| Laney | schroot -c trusty-transitions; /srv/transitions/<mumble>/go | 20:53 |
| Laney | if it's the one instance of 'ben tracker' then fair enough | 20:54 |
| Laney | but we also loop over 'ben monitor' to generate the .txt output | 20:54 |
| Laney | and that could probably go if this part doesn't scale well | 20:54 |
| slangasek | it's the ben tracker that's the hit | 20:54 |
| Laney | We might try the latest upstream code (probably easiest a wily environment) to see if it's improved | 20:55 |
| Laney | and if not then mehdi is who you want | 20:55 |
| Laney | if so then we need to upgrade | 20:55 |
| slangasek | ok, well I'm not shaving that yak right now; still working on getting the libraries themselves uploaded | 20:56 |
| slangasek | (which I'm sure will only make ben's performance worse) | 20:56 |
| Laney | yeah... that would be a backport to trusty which I'm not sure would be very fun | 20:57 |
| Laney | oh also, there's a package so the initial yak might not have to be so hairy | 21:02 |
| slangasek | replicating the transitions environment as a wily test env is enough of a yak already | 21:03 |
| slangasek | Laney: maybe an easier question: why is pion still showing up on http://people.canonical.com/~ubuntu-archive/transitions/html/log4cpp-g++5.html ? | 21:08 |
| slangasek | and fixed my batch script to do something sensible now with -dbg packages | 21:09 |
| slangasek | so another batch of uploads coming | 21:10 |
| Laney | slangasek: At a guess: the -dev package matches your -bad | 21:16 |
| slangasek | Laney: libpion-dev Depends: liblog4cpp5-dev, liblog4cpp5v5. Ben doesn't have any smarts to match on package name boundaries? | 21:18 |
| doko_ | crap, | 21:19 |
| doko_ | rejecting | 21:19 |
| slangasek | um? | 21:19 |
| slangasek | 'dch -r -D wily' :) | 21:19 |
| doko_ | too late here again ... | 21:20 |
| slangasek | Laney: so if ben doesn't have any smarts for making depends fields match on package name boundaries, but /you/ do, I'd be happy to take a tried-and-true regexp and use it in my script for autogenerating these transitions files... instead of having them all be subtly wrong | 21:21 |
| slangasek | monitor/ongoing/dh-python2.ben has a promising candidate: (^| )(pkg1|pkg2)\s*([,(]|$) | 21:23 |
| slangasek | that misses ':arch', but that's easily added | 21:23 |
| Laney | slangasek: I don't mean that - I mean that your regexp is a match for the string "liblog4cpp5-dev" which is in Depends of libpion-dev | 21:25 |
| Laney | I thought that ben already split at package boundaries for these queries but if people have been hacking around it then maybe not? | 21:26 |
| slangasek | Laney: ok, so my 'bad' is .depends ~ /liblog4cpp5\b/ | 21:26 |
| slangasek | which obviously matches liblog4cpp5-dev, but | 21:27 |
| slangasek | anyway I'll try the dh-python2 approach | 21:27 |
| slangasek | (blind, since it'll take forever to regen) | 21:27 |
| slangasek | oh, I guess the horribly broken dbus-c++ one probably doesn't help performance | 21:34 |
| slangasek | Laney: ok, I think - and this is just a guess here - that ben's performance may improve now that the config no longer includes two broken trackers with a null regexp matching every package in the archive | 21:40 |
| slangasek | sorry, looks like an earlier iteration of the code I was using to autogenerate them choked badly on packages with '+' in the name :P | 21:42 |
| === doko_ is now known as doko | ||
| slangasek | oh hey look, ben finished in < 20m instead of > 3h | 21:57 |
| slangasek | Laney, doko: here's the current state of the art of my auto-library-mangling script; at this point it works pretty reliably for everything but symbols files - and for packages with symbols files, it aborts and leaves you with a working directory you can use to fix those up: http://paste.ubuntu.com/11996364/ | 22:29 |
| doko | slangasek, would you mind sending this to debian-devel too? | 22:29 |
| slangasek | doko: when I get a chance; I'm currently still trying to get us to the point that we can unblock gcc-5 in Ubuntu | 22:30 |
| slangasek | anyway, if anyone wants to help with this transition, they could hack that script to run it for some of the packages needing symbols file updates | 22:31 |
| slangasek | so far I have csound and ctpp2 | 22:31 |
| slangasek | (that need attention, I mean) | 22:31 |
| doko | slangasek, how do you want to handle the auto removals which were done in debian testing? I assume we should do something similar, but I don't know how | 22:31 |
| slangasek | doko: we have an autoremoval job for archive admins, but it looks like it hasn't been run in at least 15 days | 22:32 |
| slangasek | doko: for now, I have a blacklist that I'm using: http://paste.ubuntu.com/11996394/ | 22:33 |
| doko | slangasek, can I see the issues with csound and ctpp2? or should I build these myself? | 22:34 |
| slangasek | this script has Ubuntuisms in it btw, won't quite work for Debian | 22:34 |
| slangasek | doko: it's symbols files changes, I've only added them to the blacklist so I can skip over them and churn through the others | 22:35 |
| doko | ok | 22:35 |
| slangasek | so feel free to claim one for looking | 22:35 |
| doko | both | 22:35 |
| slangasek | ok | 22:35 |
| doko | slangasek, could you check getfem++? needed by csound | 22:38 |
| slangasek | doko: I'm up to 'f' now, you should have it soon | 22:40 |
| doko | ta | 22:40 |
| ari-tczew | can someone accept source package "jersey1" @wily-proposed? missing B-D is already in archive | 22:44 |
| infinity | ari-tczew: The dep-wait would have cleared on its own if you waited a bit. | 22:49 |
| ari-tczew | infinity: also automatically, ok | 22:50 |
| slangasek | C++ libraries that are currently FTBFS and need investigation: clanlib libcrypto++ fbreader dcmtk | 23:04 |
| slangasek | (I haven't looked at these at all beyond seeing that there are build failure emails; they could all be simple things) | 23:04 |
| doko | I would love to nuke cdbs | 23:10 |
| * slangasek sources some plutonium | 23:10 | |
| slangasek | clanlib reuploaded | 23:26 |
| doko | wtf is d-shlibmove? | 23:29 |
| slangasek | heh | 23:31 |
| slangasek | flac, geographiclib also have symbols files | 23:32 |
| doko | afk now, ctpp2 in the works, but I hate cdbs | 23:35 |
| slangasek | just noticed the script needs to be smartened for binary packages with 'c2a' in the name | 23:38 |
| slangasek | (yes, we still have a bunch of those around) | 23:38 |
| infinity | slangasek: Hey, why not? We still have binaries with '1g' in the name. | 23:43 |
| infinity | Or, rather, just 'g'. | 23:43 |
| slangasek | doko: getfem++ uploaded now | 23:45 |
| slangasek | infinity: yeah, but those are libraries written in C, where stable ABIs exist :) | 23:45 |
| slangasek | infinity: I'm pretty sure most of the c2a libs are old GNOME abandonware | 23:45 |
| infinity | Very stable, in the case of libz1. | 23:45 |
| infinity | Which could drop the 'g' if someone actually renamed the library package to be policy-compliant. | 23:46 |
| infinity | I wonder why no one's ever bothered. | 23:46 |
| infinity | Oh, probably because of thousands of versioned deps. | 23:47 |
| slangasek | yep | 23:47 |
| infinity | But now that we have versioned Provides, that could be sorted. | 23:47 |
| slangasek | do we? | 23:47 |
| infinity | Yup. | 23:47 |
| slangasek | in stable apt + dpkg? | 23:47 |
| infinity | Provides: zlib1g (= 1.2.3) does what you'd expect. | 23:47 |
| infinity | Not sure which versions of packaging tools are needed to make it happy. Would have to check. | 23:48 |
| infinity | slangasek: Bah. Only in utopic's apt. jessie is good, trusty is not. | 23:51 |
| infinity | slangasek: But post-16.04, renaming zlib1g could totally be a thing. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!