| Logan_ | xnox: I'm getting mediatomb back in sync with Debian. Actually ready to upload. Any objections, as the last uploader? ;) | 04:44 |
|---|---|---|
| Logan_ | (I can't imagine why you'd object to a complex merge that you don't have to do.) | 04:44 |
| slangasek | Logan_: the Debian package doesn't have upstart support. (LP: #212441) How are you getting it in sync without causing regressions in Ubuntu? | 04:57 |
| ubottu | Launchpad bug 212441 in mediatomb (Debian) "Mediatomb Init Script not working : upnp error -117" [Unknown,New] https://launchpad.net/bugs/212441 | 04:57 |
| Logan_ | slangasek: By "in sync," I meant merging. :P | 04:57 |
| slangasek | oh, that's a rather confusing use of the term ;) | 04:57 |
| Logan_ | Well, out of the -0ubuntu black hole, better yet. | 04:58 |
| Logan_ | Well, since xnox didn't really do much in his last upload (just imported a patch from Debian, instead of merging), I'm going to assume that it's okay to merge, I think. | 05:00 |
| Logan_ | Or should I wait? I don't know. I'll give a day for him to respond. :P | 05:01 |
| infinity | Logan_: Given the history, I think you can fairly confidently assume he doesn't care about having TIL on it. | 05:05 |
| Logan_ | Yay. | 05:05 |
| infinity | Logan_: micahg might care (the last person to upload a -ubuntu1) | 05:06 |
| Logan_ | Too late. | 05:06 |
| Logan_ | :P | 05:06 |
| infinity | Logan_: But that was in maverick. :P | 05:06 |
| Logan_ | Is there a record for the oldest built package still in trusty's repositories? | 05:06 |
| Logan_ | I've seen some that were built in edgy. | 05:06 |
| infinity | There may even be one or two from dapper. | 05:07 |
| infinity | Not sure the easiest way to extract that. | 05:07 |
| Logan_ | I feel like I'm destroying history when I fix ppc64el FTBFSes on those packages. | 05:07 |
| * Logan_ sheds a tear. | 05:07 | |
| infinity | You could fudge something together with the LP API. It would be a bit of a lie for anything pre-dapper. | 05:07 |
| infinity | Logan_: Look on the bright side, you're getting things built with a modern toolchain with stack protection and such. | 05:08 |
| Logan_ | Okay, now I feel better. ;P | 05:08 |
| Logan_ | I'm surprised at how receptive Debian maintainers have been to my ppc64el autoreconf patches, since they would gain no benefit except for a longer build time from them. | 05:12 |
| Logan_ | And it doesn't look like Debian will be supporting ppc64el any time soon, given an ML thread I read. | 05:13 |
| Logan_ | Should I be submitting those patches? Because they have been merging them... | 05:14 |
| infinity | Logan_: autoreconf patches should be a no-brainer for future-proofing. The times when one has to hand-patch configure are probably a harder sell (and I've not forwarded many of those yet). | 05:14 |
| Logan_ | Yeah, true. | 05:15 |
| infinity | Logan_: Submit away. Anything merged by Debian is something we don't need to worry about as a downstream, so that's a win. | 05:15 |
| Logan_ | I feel like the myriads of warnings from autoreconf should lead to patches submitted to upstream as well to fix their autotools files. That's going to bite us in the rear end in the future. | 05:16 |
| Logan_ | Because it seems like so much is being deprecated so quickly. | 05:16 |
| infinity | Not that quickly, it's just that a lot of upsteams are stuck in the past. :P | 05:16 |
| Logan_ | Hey, do you think I'd be an alright candidate for core-dev? I feel like I need to package at least one thing from scratch first to show that I can do that. | 05:17 |
| infinity | I think you probably need to learn to be a bit more careful first, and ask (or leave things alone) a bit more often, but you're on the right track. | 05:18 |
| Logan_ | I hear you. I need to be a bit less eager. | 05:18 |
| Logan_ | Working on that. :P | 05:18 |
| Logan_ | I feel safe doing ppc64el FTBFS fixes because I know nobody is going to complain to me about those. :P | 05:19 |
| infinity | Not when they work. :) | 05:19 |
| Logan_ | infinity: Of course I uploaded it with "Merge" as the changelog entry. I forgot to debuild again after writing a proper changelog entry. :P | 06:02 |
| Logan_ | I rectified my mistake by doing a no-change rebuild with a proper retroactive changelog entry. | 06:02 |
| infinity | Logan_: You could have hidden your tracks a bit better by removing the ubuntu1 changelog entry when you did ubuntu2. Too late now, though. ;) | 06:49 |
| Logan_ | infinity: I'm preserving history! Also, I have a quick question. If I touch a file in configure-stamp, do I explicitly have to rm it in clean? | 06:55 |
| Logan_ | Because I need to touch ./AUTHORS for autoreconf to work for a package that is FTBFSing on ppc64el. | 06:55 |
| infinity | Logan_: If you touch a file that some other clean thing (make clean, dh_clean, etc) doesn't clean then, yes, you need to clean it yourself. | 06:55 |
| Logan_ | Okay, thanks. | 06:55 |
| maxiaojun | software center of trusty still shows removed package | 07:33 |
| maxiaojun | anyone to update app-install-data? | 07:33 |
| maxiaojun | examples include pptview and chmsee | 07:34 |
| === maxiaojun_ is now known as maxiaojun | ||
| maxiaojun | https://bugs.launchpad.net/ubuntu/+source/g2ipmsg/+bug/1264801 | 08:18 |
| ubottu | Ubuntu bug 1264801 in g2ipmsg (Ubuntu) "Error on Startup" [Undecided,New] | 08:18 |
| maxiaojun | I guess g2ipmsg should probably be removed or hid from software center. | 08:18 |
| maxiaojun | why there is 6 entries for Marble in USC? | 08:43 |
| maxiaojun | gpixpod seems to be negative value package | 10:08 |
| === sraue_ is now known as sraue | ||
| cjwatson | LoganCloud: AUTOMAKE='automake --foreign' might have done the job rather than touching AUTHORS | 12:04 |
| infinity | (.text+0x194): undefined reference to `ucnv_getMaxCharSize_48' | 12:07 |
| infinity | cjwatson: Ugh. Looks like haskell's gone and made the icu transition more painful. | 12:07 |
| infinity | cjwatson: (Some lower level bits need to be rebuilt again and bubble up sanity, I'm guessing?) | 12:07 |
| xnox | LoganCloud: infinity: instead of touching random empty files to please automake, it's better to add [foreign] to the AM_AUTOMAKE_INIT in the configure.ac/in as that makes automake not care about required files for GNU project. | 12:08 |
| xnox | LoganCloud: infinity: and no, i don't care much about mediatomb =)))) | 12:09 |
| xnox | infinity: i've uploaded haskell-text-icu rebuild, which appears to be the lowest icu based component. and indeed, it changed the magic provides number. So things that rdep from level8 upwords on icu need rebuild =/ | 12:10 |
| xnox | infinity: and for icu to migrate we need haskell stack installable all the way.... | 12:10 |
| infinity | xnox: Well, luckily, some of them are FTBFS, so just need a retry. :P | 12:10 |
| xnox | =)))) | 12:11 |
| xnox | cjwatson: interesting enough: AUTOMAKE='automake -Wno-error' doesn't seem to work if the AM_AUTOMAKE_INIT has [-Werror -Wall] in configure.ac. | 12:13 |
| xnox | but i guess you'd advacate fixing the warnings.... | 12:13 |
| infinity | php5 autopkgtest had some sort of explosion, if someone wants to retry that. | 12:14 |
| infinity | I really should sort out access... | 12:14 |
| === freeflying is now known as freeflying_away | ||
| === freeflying_away is now known as freeflying | ||
| cjwatson | infinity: Random rebuilds aside, http://lists.debian.org/debian-haskell/2013/12/msg00016.html is a recent assessment of the current set of problems with the Haskell stack | 12:42 |
| cjwatson | infinity: I've been going around chasing rebuilds as time permits, but it's not going to get all the way right now | 12:42 |
| cjwatson | Also something odd up with haskell-http-client, which might be Ubuntu-specific, haven't had a chance to chase it yet | 12:44 |
| cjwatson | ... and haskell-http-conduit | 12:45 |
| cjwatson | xnox: yes, I would :) | 12:46 |
| cjwatson | shouldn't be that hard | 12:46 |
| infinity | cjwatson: The thing up with conduit is what I was referring to. | 12:46 |
| infinity | cjwatson: I assume xnox's drilling back down the haskell/icu stack and then back up should fix it. | 12:46 |
| cjwatson | maybe, but I got a very recent failure for that | 12:47 |
| infinity | Yeah, the recent failure was what I was looking at. | 12:47 |
| infinity | But it seems to clearly reference icu48 symbols, which implies something lower down needs to transition first. | 12:47 |
| cjwatson | Anyhow, the whole Haskell stack is going to have to be working at once, probably | 12:47 |
| xnox | cjwatson: re:adjunctions-dev there is a one line patch + version compat bump in the representable-functors github repo. I was thinking to try cherrypicking that into current adjunctions to unblock the stack. | 12:48 |
| cjwatson | xnox: it'll need a bit more than a one-liner, but maybe. link? if it does the job I can push it to Debian | 12:48 |
| xnox | then again i'm haskell clueless. | 12:48 |
| xnox | cjwatson: https://github.com/ekmett/representable-functors/pull/2/files | 12:49 |
| xnox | unless that depends on other changes done in the representable-functors repo...... | 12:49 |
| cjwatson | well, while that might help representable-functors, it won't apply as such to adjunctions | 12:50 |
| cjwatson | and adjunctions needs to be fixed first | 12:50 |
| xnox | *bummer* | 12:50 |
| cjwatson | I already tried just forcing it to build ignoring various version problems | 12:51 |
| cjwatson | src/Data/Functor/Contravariant/Adjunction.hs:10:8: | 12:52 |
| cjwatson | Could not find module `Data.Functor.Corepresentable' | 12:52 |
| cjwatson | Perhaps you meant | 12:52 |
| cjwatson | Data.Functor.Representable (from representable-functors-3.2.0.2) | 12:52 |
| cjwatson | Use -v to see a list of the files searched for. | 12:52 |
| cjwatson | oh, hey, the most current upstream of adjunctions actually works if I cherry-pick the version patches | 12:54 |
| cjwatson | xnox: leave this with me, I *might* be able to get it sorted out today. I'll need to check that representable-tries and algebra still work | 12:55 |
| cjwatson | however, pandoc/gitit is still a problem | 12:56 |
| xnox | cjwatson: i'll be doing icu rebuilds to get the stack as installable as it was before I uploaded icu =/ | 12:56 |
| cjwatson | I already started :) | 12:56 |
| xnox | ok then =) | 12:57 |
| * xnox sacrifices bird seeds to haskell gurus | 12:58 | |
| cjwatson | Grr, I can't upload this to Debian because of uninstallability in unstable | 13:08 |
| === Cimi_ is now known as Cimi | ||
| === mnepton is now known as mneptok | ||
| === LoganCloud_ is now known as LoganCloud | ||
| === LoganCloud is now known as Guest86595 | ||
| === arun is now known as The_dog | ||
| === lan3y is now known as Laney | ||
| === milli` is now known as milli | ||
| === bigon_ is now known as bigon | ||
| Logan_ | cjwatson, xbox: Gotcha, thanks. | 21:35 |
| Logan_ | *xnox, ugh. | 21:36 |
| xnox | Logan_: hm? sup =) | 21:52 |
| Logan_ | <xnox> LoganCloud: infinity: instead of touching random empty files to please automake, it's better to add [foreign] to the AM_AUTOMAKE_INIT in the configure.ac/in as that makes automake not care about required files for GNU project. | 21:53 |
| xnox | ah. k =) | 21:54 |
| xnox | Logan_: yeah, i'm not sure why GNU coding standard is enforced by default by such a general purpose tool =/ | 21:54 |
| Logan_ | It's rather silly. | 21:54 |
| xnox | instead of requiring GNU projects to use "GNU" keyword. | 21:55 |
| === Guest86595 is now known as LoganCloud | ||
| cjwatson | xnox: Fixed haskell-adjunctions in Debian now, so I think it's mostly just pandoc and gitit left now | 23:58 |
| cjwatson | (Which unfortunately are non-trivial) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!