| === 5EXABD84D is now known as infinity | ||
| === davmor2_hols is now known as davmor2 | ||
| sidi | I've just built an architecture-indepedent package on my PPA using Architecture: all, and LP only shows an amd64 build (https://code.launchpad.net/~ucl-cs-study-devs/+archive/ubuntu/multitasking-study/+packages, zeitgeist-chrome-datasource), does that mean that the i386 architecture will use the amd64 package or does that mean I did something wrong? | 13:21 |
|---|---|---|
| dobey | sidi: it only builds on a single architecture | 13:23 |
| dobey | sidi: the binary package will be installable on all | 13:23 |
| dobey | there's no need to build it on all architectures since it is arch-indep | 13:24 |
| sidi | dobey, ah I see! So the amd64 indicates the arch of the build bot and not the target arch | 13:33 |
| cjwatson | Correct | 13:34 |
| sidi | Thanks! | 13:37 |
| dobey | yep | 13:38 |
| sidi | Ok now I have a much weirder problem. I'm building my own glib2 package, directly forked from the vivid release one. My own code is mostly contained into gio and builds well. I get failures to build the package during dh_test. I get an error ("missing test plan") right after the test PASS: gdatetime 37 /GDateTime/to_utc in the build log (https://launchpadlibrarian.net/201883914/buildlog_ubuntu-vivid-amd64.glib2.0_2.44.0-1ppa1_BUILDING.txt.gz), except I d | 14:57 |
| sidi | id not touch gdatetime.c at all, or gdatetime's test case (bzr diff agrees with me on this one). So I'm running the exact same code and test as the Ubuntu glib package which builds without an error. I'm not sure if the question is for here or #glib, but what could be the cause of this? The error reliably occurs at that point on the PPA and my local build bot. | 14:57 |
| sidi | (I believe it's a GLib error, though) | 14:59 |
| cjwatson | sidi: This isn't Launchpad-specific at all. I expect you'd have a better change of getting a good answer somewhere that knows about the package you're building. | 15:03 |
| cjwatson | I think the original error message is a little higher up: | 15:04 |
| cjwatson | GLib:ERROR:/build/buildd/glib2.0-2.44.0/./glib/tests/gdatetime.c:674:test_GDateTime_now_utc: assertion failed (tm.tm_sec == g_date_time_get_second (dt)): (1 == 2) | 15:04 |
| cjwatson | But I'm not a GLib expert. | 15:04 |
| sidi | cjwatson, I'm talking with them right now. I'm just curious why the Ubuntu package built because I get the error both on the PPA buildbot and locally, but I reckon that's most likely a glib issue | 15:05 |
| cjwatson | Perhaps different version of a build-dependency, or perhaps some other skew you didn't notice in your source packages. Run debdiff on both source packages, and diff the build logs. | 15:05 |
| sidi | Are all the build bots running the exact same configuration? | 15:06 |
| cjwatson | All the PPA builders are, but the Ubuntu builders are on an older kernel. | 15:06 |
| cjwatson | (for the moment) | 15:06 |
| cjwatson | It's possible that that's the cause, though you should first try building the actual Ubuntu source package locally to confirm. | 15:07 |
| sidi | cjwatson, when I use the exact same package as the Ubuntu one I still get the error | 15:07 |
| sidi | I'm double checking by redownloading the source package from apt (though I was using the same on the same rev number as Ubuntu's source pkg in the test I just did) | 15:07 |
| cjwatson | Right, so it could conceivably be to do with running on trusty's kernel, although in that case you'd normally expect it to fail on ppc64el even in Ubuntu. | 15:07 |
| cjwatson | You could try 2.45.1-2 from wily and see if it exhibits the same effect. | 15:08 |
| sidi | will do that one next | 15:09 |
| sidi | it takes about 20-30 mins per build so I'll be back later and let you know! | 15:09 |
| sidi | Do you know the exact kernel versions of both Ubuntu and PPA bots? | 15:10 |
| sidi | Might help to debug with upstream | 15:10 |
| cjwatson | sidi: They're right there at the top of every build log. | 15:11 |
| sidi | oh! Thanks | 15:11 |
| cjwatson | Do check for other differences though. | 15:15 |
| dobey | sidi: generally, if the package builds fine without your patch, and fails with your patch, then your patch broke something. this is exactly what unit tests are for and why it's failing :) | 15:15 |
| cjwatson | dobey: Read harder | 15:16 |
| cjwatson | dobey: 16:07 <sidi> cjwatson, when I use the exact same package as the Ubuntu one I still get the error | 15:16 |
| dobey | oh | 15:16 |
| cjwatson | sidi: Kernel differences do occasionally account for bugs, but the facts that they didn't occur on the ppc64el build (also 3.13) and that gdatetime shouldn't be all that desperately kernel-sensitive both make me a bit sceptical | 15:17 |
| cjwatson | But diffing build logs is often a useful tool. | 15:17 |
| cjwatson | Or it could be a racy test and you got unlucky in multiple configurations ... | 15:18 |
| dobey | and glib is pretty well portable and generally robust at building, too. | 15:18 |
| dobey | sidi: btw, your versioning choice is not very friendly either. you'd want to use 2.44.0-1ubuntu3~ppa1 i think, otherwise the ubuntu version will be seen as newer than your ppa version | 15:22 |
| cjwatson | Still will be unless you make that +ppa1 not ~ppa1 | 15:24 |
| dobey | oh, right, should be 3.1~ppa1 | 15:24 |
| cjwatson | 3+ppa1 is fine too | 15:24 |
| cjwatson | And I would not use 3.1~ppa1 unless I were backporting something from 2.44.0-1ubuntu3.1 | 15:25 |
| cjwatson | Not that it will normally matter but it's better to be in good habits IMO | 15:25 |
| dobey | yeah, i guess. i'm just recommending what the launchpad ppa help page recommends, which is "next version with ~foo appended" | 15:25 |
| dobey | anyway, time for me to get lunch. bbiab :) | 15:29 |
| cjwatson | https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#Versioning does not say that. | 15:35 |
| cjwatson | There is a bit later about snapshots which says something along those lines, although with a rather dubious over-elaborate example. | 15:36 |
| sidi | dobey, cjwatson i wasn't aware of the need for +, thanks for the tip | 16:21 |
| sidi | Though I do intend to update the packages if there's a SRU for as long as I need the PPA | 16:21 |
| cjwatson | well, + isn't required as such, just a suggestion | 16:21 |
| sidi | (by the way, is there any service/method to receive emails when specific Ubuntu packages get updated?) | 16:21 |
| cjwatson | anyway, whatever, could go round all day on versions | 16:22 |
| cjwatson | sidi: we don't have per-package feeds, sorry - you could subscribe to wily-changes@lists.ubuntu.com etc. and filter the resulting mail firehose | 16:23 |
| sidi | hm.. :D | 16:25 |
| sidi | cjwatson, actually I'll maintain the PPA only for vivid. I'm doing a field study and the participants will be vivid users. I'm aiming to finish before October | 16:26 |
| sidi | is there a ML for SRUs per distro? | 16:26 |
| sidi | vivid-changes@.. I premuse? | 16:26 |
| sidi | yup | 16:27 |
| cjwatson | Indeed. | 16:40 |
| cjwatson | wily was just an example. | 16:41 |
| dobey | sidi: fwiw, i built the stock glib2.0 source from vivid on a vivid pbuilder here just now, and it built fine. | 17:47 |
| sidi | dobey, I managed to get a local build of 2.0_2.44.0-1ubuntu3 from apt-source (the one that failed for me before was 2.44.0-1). I'm waiting for the PPA to build mine, got sidetracked by some grading... Will let you know, but thanks for checking too | 17:59 |
| dobey | if you just built 2.44.0-1 before, that's the debian source, not the ubuntu one. glib2.0 has almost always had a patch or two carried on it in ubuntu | 18:04 |
| sidi | dobey, i think at that time you had the exact same source | 18:09 |
| sidi | this was a tiny bit before vivid's release, on the 30th of march. Looking at the current Ubuntu package's changelog, there was no ubuntu patch applied for 17 days after this package | 18:10 |
| sidi | and I seem to recall I had it in my updates before that date | 18:10 |
| sidi | I'd need to check with the maintainers to be 100% sure though | 18:10 |
| dobey | well, i'm sure you can't have installed an update prior to the update existing | 18:13 |
| dobey | :) | 18:13 |
| sidi | dobey, what I mean was that I seem to recall my vivid (unstable) update manager proposed 2.44.0-1 | 18:14 |
| sidi | dobey, https://launchpad.net/ubuntu/+source/glib2.0/2.44.0-1/+build/7123078 i think it was built | 18:15 |
| sidi | 2015-03-31 | 18:15 |
| sidi | Well if the problem's fixed with more recent glibs it's probably not worth investigating | 18:16 |
| dobey | oh, there's a newer version in vivid-proposed currently too | 18:20 |
| sidi | I saw that. I don't remember Ubuntu inner workings very well though, the proposed ones are only for users who enable proposed packages, aren't they? | 18:20 |
| sidi | or will they be pushed to all users eventually? | 18:21 |
| dobey | it's the staging ground before being pushed out to the updates pocket | 18:21 |
| dobey | so once whatever testing necessary is done, and the wait period has passed, it will be an update | 18:21 |
| sidi | Ok, so I should build that one too | 18:22 |
| dobey | i'm surprised it hasn't been pushed out already though, since it looks like it was uploaded a few weeks ago | 18:22 |
| dobey | oh well | 18:22 |
| sidi | actually, dobey can I use apt-get source to get packages from other distros? | 18:24 |
| sidi | e.g. the proposed for vivid or the WW package? | 18:24 |
| dobey | apt-get source will only pull from whatever deb-src lines you have in your sources.list files | 18:25 |
| sidi | right | 18:25 |
| dobey | bzr branch lp:ubuntu/vivid-proposed/glib2.0 should pull the vivid-proposed source (but you'll need to build the deb source package yourself) | 18:25 |
| sidi | so I should download the {orig,debian}.tar.xz and unpack them in a folder and I get the same thing, right? | 18:25 |
| dobey | or you can use the pull-lp-source command as well | 18:25 |
| dobey | yeah, you can download the source files directly off lp too | 18:26 |
| sidi | (i've actually had very weird interactions with bzr branch in the past, getting versions of some packages from ~2012, so I stopped using that) | 18:26 |
| sidi | (it seems not all maintainers keep their bzr branches up to date) | 18:26 |
| sidi | will pull-lp-source use packages or bzr brancheS? | 18:26 |
| cjwatson | The former | 18:28 |
| cjwatson | The bzr branches are generally supposed to be auto-imported, but the importer is often broken | 18:28 |
| cjwatson | It's not the maintainers' fault in the general case | 18:28 |
| sidi | Ah I see | 18:28 |
| cjwatson | It's going to be replaced by something git-based in the coming months, hopefully | 18:29 |
| dobey | yeah, glib2.0 seems to be up to date, but sometimes the importer will fail to do an import for whatever reason | 18:29 |
| cjwatson | Basically, don't bother with the auto-imported bzr branches, regardless of what some misguided documentation currently says | 18:29 |
| sidi | wow pull-lp-source is much more enjoyable :-) | 18:30 |
| cjwatson | Don't get me wrong, revision control is good, just not good enough to overcome the huge roadblock of being broken a significant percentage of the time ... | 18:31 |
| sidi | cjwatson, that's the thing I hate about doing ubuntu packaging. Debian packaging in itself is hard, and there are so many docs that it's hard to find one authoritative source of information that lists *all* the errors and mistakes I can make. Add in Launchpad/bzr and PPA specifics and it's just hard. If I also had to package for Fedora/CentOS/Mint I would just go insane | 18:32 |
| dobey | cjwatson: will importing to git actually fix the problems that plague the importer? | 18:32 |
| sidi | I really wish there were git/bzr trees of the original branches, with an added debian folder, and I could navigate through the branch's tags to get the exact package I want | 18:32 |
| sidi | then I need to learn fewer tools | 18:32 |
| cjwatson | dobey: Yes | 18:33 |
| cjwatson | dobey: It's inherently much more reliable, basically due to not having file-ids | 18:33 |
| cjwatson | (And misc other things, but that accounts for a lot of it) | 18:33 |
| cjwatson | Being able to do reliable parallel imports makes so many things so much easier | 18:35 |
| === hggdh_ is now known as hggdh | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!