| tsimonq2 | where could I find all of the UDS sessions after this upcoming one? YouTube? | 00:24 |
|---|---|---|
| hallyn | ok, if i switch vmbuilder from Architecture:all to :any, that should be ok? (it builds fine on power8) | 01:30 |
| hallyn | hm, no | 01:33 |
| hallyn | maybe i shouldn't have to, | 01:33 |
| tsimonq2 | and why do some package updates go to wily first instead of xenial? | 01:40 |
| cyphermox | tsimonq2: that doesn't sound right, packages would go to xenial now, wily is released. the usual process is that stable updates should land in the development release before they are uploaded to wily. | 01:57 |
| tsimonq2 | well obviously not | 02:02 |
| tsimonq2 | -16 is in xenial-proposed | 02:03 |
| tsimonq2 | -17 is in wily-proposed | 02:03 |
| tsimonq2 | (kernel) | 02:03 |
| tsimonq2 | Why? | 02:03 |
| tsimonq2 | cyphermox: or is that irregular? | 02:06 |
| cyphermox | tsimonq2: I suppose they're fixing bugs in wily and there's a good reason why it didn't land in xenial first | 02:08 |
| tsimonq2 | cyphermox: but usually that doesn't happen? | 02:08 |
| cyphermox | (possibly because they're in the process of preparing a new shiny other kernel for xenial) | 02:08 |
| cyphermox | no, usually stuff lands in xenial first, on the premise that stuff should be tested in the devel release before the fix is send to wily-proposed. | 02:09 |
| tsimonq2 | cyphermox: do you know if upstream packages(Debian) go to xenial, and if so, what repo? main? universe? | 02:09 |
| tsimonq2 | cyphermox: or is that conditional | 02:10 |
| tsimonq2 | cyphermox: and if so how is that controlled | 02:10 |
| infinity | tsimonq2: The kernel is a unique snowflake. Once it's ready to move from wily-proposed to wily-updates, I'll copy it to xenial as well. | 02:11 |
| infinity | (Until 4.3.0 lands in xenial) | 02:11 |
| tsimonq2 | infinity: got it :) | 02:11 |
| tsimonq2 | infinity: can YOU answer that question that I just asked him? | 02:11 |
| infinity | You could probably answer it yourself with some Googling. | 02:12 |
| infinity | But we autosync from Debian until Debian Import Freeze (in a few months). | 02:12 |
| tsimonq2 | infinity: but you would give me the answer I want, as I want it | 02:12 |
| tsimonq2 | infinity: but would it go to main? | 02:12 |
| infinity | Not if it's not already in main. | 02:12 |
| tsimonq2 | infinity: but how would I get it from Debian into main instead of universe? | 02:13 |
| tsimonq2 | (would do it in the future, just curious) | 02:13 |
| infinity | You'd file a Main Inclusion Request and make a case for why you think we should support it. | 02:13 |
| tsimonq2 | and where's that> | 02:14 |
| tsimonq2 | and what are the requirements for packages in main? | 02:14 |
| infinity | Seriously, Google a bit dude. Just a little. | 02:14 |
| * infinity goes back to his vacation. | 02:14 | |
| tsimonq2 | sorry | 02:14 |
| * ScottK read that as vaccination for a moment. | 02:15 | |
| tsimonq2 | XD | 02:15 |
| === nudtrobert1 is now known as nudtrobert | ||
| tjaalton | infinity: btw, added a debdiff for vivid on the initramfs-tools bug which adds kernel/ubuntu/i915 modules to copy, but wonder if I should just upload? | 05:58 |
| pitti | Good morning | 06:46 |
| === nudtrobert1 is now known as nudtrobert | ||
| === cpaelzer_ is now known as cpaelzer | ||
| dholbach | good morning | 07:53 |
| seb128 | hey dholbach | 07:54 |
| dholbach | hey seb128 | 07:54 |
| seb128 | wgrant, hey, did you have any chance to debug the evolution/e-d-s translation issue on launchpad? | 07:54 |
| LocutusOfBorg1 | hi folks, does freenode have an ubuntu channel for xserver folks? | 08:17 |
| LocutusOfBorg1 | wrt #1511649 | 08:17 |
| seb128 | LocutusOfBorg1, there was #ubuntu-x, unsure if it's still active, but you can also try to grab tjaalton or robert_ancell | 08:23 |
| tjaalton | #ubuntu-x is still there | 08:25 |
| tjaalton | LocutusOfBorg1: merge is pending | 08:25 |
| tjaalton | I've done it locally already | 08:26 |
| tjaalton | just have five critical bugs to sort out before end of next week, so had to postpone testing this | 08:26 |
| LocutusOfBorg1 | tjaalton, WOW thanks! | 08:31 |
| LocutusOfBorg1 | well, in my ppa is already built | 08:32 |
| LocutusOfBorg1 | please be aware of the new wrapper | 08:32 |
| LocutusOfBorg1 | https://packages.qa.debian.org/x/xorg-server/news/20150821T010032Z.html | 08:32 |
| tjaalton | I know | 08:32 |
| LocutusOfBorg1 | I did add xserver-xorg-legacy to virtualbox-x11 package, because it still need a root x mode (upstream is working on this) | 08:32 |
| LocutusOfBorg1 | and on ubuntu xenial it is currently failing to migrate in -release because of the installation test failure | 08:33 |
| tjaalton | know that too :) | 08:33 |
| LocutusOfBorg1 | wonderful, so I'm happy to see you taking care of it | 08:33 |
| LocutusOfBorg1 | :D | 08:33 |
| tjaalton | yes, maybe next week | 08:33 |
| tjaalton | maybe the week after | 08:33 |
| * LocutusOfBorg1 is wondering if we can have something like "make the package mandatory if exists, don't install otherwise", without playing with rules file | 08:34 | |
| LocutusOfBorg1 | tjaalton, not a problem, actually my wonder was an answer like "ubuntu don't want to have this wrapper" | 08:34 |
| LocutusOfBorg1 | but if you plan to merge it, it is fine then, and I hope to remove the legacy dependency before xenial release anyway | 08:35 |
| tjaalton | yep | 08:41 |
| === hikiko-lpt is now known as hikiko | ||
| === davidcalle_ is now known as davidcalle | ||
| pitti | cjwatson: looking at bug 1511376 to do the equivalent finish-install fix in ubiquity | 10:27 |
| ubottu | bug 1511376 in ubiquity (Ubuntu Xenial) "install writes /etc/mtab as file, not symlink" [High,In progress] https://launchpad.net/bugs/1511376 | 10:27 |
| pitti | cjwatson: as ubiquity doesn't actually (seem to) use the finish-install udeb | 10:27 |
| pitti | cjwatson: I wondered, woudl ubiquity/install_misc.py chroot_cleanup() be an appropriate place for that, or is there a better one? | 10:28 |
| pitti | cjwatson: i. e. to set /target/etc/mtab -> /proc/self/mounts | 10:28 |
| === _salem is now known as salem_ | ||
| cjwatson | pitti: That doesn't feel like the right place, no. I'd suggest somewhere in scripts/plugininstall.py:Install | 11:22 |
| cjwatson | There's a bunch of fairly ad-hoc finalisation tasks in there | 11:22 |
| pitti | cjwatson: ah, thank you | 11:23 |
| === rickspencer3_ is now known as rickspencer3 | ||
| cyphermox | good morning | 12:28 |
| mdeslaur | good morning cyphermox | 12:37 |
| === zyga is now known as zyga-afk | ||
| dupingping | Hi, everybody. | 14:44 |
| dupingping | Who made the page? http://www.ubuntu.com/certification/desktop/models/?release=12.04+LTS&category=Desktop&category=Laptop | 14:44 |
| dupingping | How about modify it as follow? | 14:44 |
| dupingping | http://people.ubuntu.com/~dupingping86/ | 14:44 |
| dupingping | I just designed this page. | 14:45 |
| seb128 | bdmurray, hey, could you explain those | 15:09 |
| seb128 | "Your upload of nautilus version 1:3.10.1-0ubuntu9.9 to trusty has resulted in an error that was first reported about this version of the package. The error follows: | 15:09 |
| seb128 | https://errors.ubuntu.com/problem/c96cb327d13f20d2ae77c13634dd34454a57e6cf" | 15:09 |
| seb128 | but the table has reports for the 7 previous versions | 15:09 |
| seb128 | could you let that nautilus update in? the regressions mentioned are false ones | 15:10 |
| bdmurray | seb128: in that case the problem didn't exist in or wasn't reported about 9.8 and that particular issue should be ignored, however I think there are some legitimate ones. | 15:11 |
| seb128 | which ones? | 15:11 |
| bdmurray | https://errors.ubuntu.com/problem/ddc9b270a643149cf4e73a57de6c326d8a468fb0 | 15:12 |
| seb128 | bdmurray, that has reports on 1:3.10.1-0ubuntu9.3 | 15:13 |
| seb128 | it's just not common | 15:13 |
| bdmurray | but not on ubuntu8 which was the one in the release pocket | 15:13 |
| dupingping | http://people.ubuntu.com/~dupingping86/ | 15:13 |
| seb128 | right, but it's also a false regression | 15:13 |
| dupingping | I just designed this page. | 15:14 |
| seb128 | dupingping, hey, you already wrote that | 15:14 |
| bdmurray | https://errors.ubuntu.com/problem/7b4d30774cd6698d6ac8a5718610a01b33b5e427 ? | 15:14 |
| dupingping | seb128, the page is useful? | 15:14 |
| seb128 | dupingping, no idea, it looks like "old" compared to the ubuntu one to me | 15:15 |
| seb128 | the styling | 15:15 |
| seb128 | but I don't work on that website | 15:15 |
| seb128 | dupingping, you can open a bug with your suggestion on https://bugs.launchpad.net/ubuntu-website-content/+filebug | 15:15 |
| bdmurray | https://errors.ubuntu.com/problem/148216bb1232ca884058218ca27b169db04d02e0 | 15:15 |
| dupingping | seb128, yes, i see. | 15:16 |
| seb128 | bdmurray, again, that new one skept the previous version for some reason, but it as a couple of report for each precedent ones, it's not relevant | 15:18 |
| seb128 | bdmurray, unsure about the one before, it doesn't make sense for that to be a new issue due to the change and has only 3 reports | 15:18 |
| bdmurray | seb128: 148216 only has package versions from -updates in 14.04 which seems suspicious. How about I review all the Trusty ones and email you with the ones that aren't obviously not regressions. | 15:20 |
| seb128 | bdmurray, ok, that works for me. The change in that SRU is a 1 liner basically undoing a change that was done in recent versions so going back to old code, it shouldn't create a regression ... I'm happy to review the list just to make sure though | 15:22 |
| bdmurray | seb128: the review might be helpful for the phased updater too, so thanks | 15:24 |
| Odd_Bloke | pitti: So as I mentioned earlier this week, we are substantially changing how we build images for xenial; if I point you at an image file (let me know the image format you consume), would you be able to test that out and check it works for you? | 15:34 |
| pitti | Odd_Bloke: sure! | 15:36 |
| pitti | Odd_Bloke: qcow2 for local qemu is most appreciated, and that works for glance import too; otherwise, qemu-img can convert between stuff, but woudl be easier not to | 15:36 |
| Odd_Bloke | pitti: Great; I have a build from a couple of days ago, so I'll push that up somewhere. | 15:39 |
| pitti | Odd_Bloke: no hurry, though; I probably won't get to testing it today any more, need to leave in about an hour | 15:40 |
| Odd_Bloke | pitti: Don't worry, my Internet connection is in no hurry. ;) Is a message in here enough, or shall I drop you an email with the URL? | 15:41 |
| pitti | Odd_Bloke: either works for me | 15:41 |
| pitti | Odd_Bloke: then I'll see how well I can download it through airport or hotel wifi :) | 15:42 |
| Odd_Bloke | pitti: :D | 15:42 |
| Odd_Bloke | pitti: I am producing QCOW2 images, so it's only ~320MB. | 15:42 |
| pitti | "only" :) | 15:42 |
| pitti | it was 150 or so in raring when we started with those, but they accumulated a lot of stuff (my package purge list has become rather long :) ) | 15:43 |
| tsimonq2 | could I use the devel alias in my sources.list? | 15:44 |
| pitti | tsimonq2: yes, works in principle | 15:45 |
| pitti | I just found it to interact in funny ways with apt-cacher-ng, otherwise it's fine | 15:45 |
| tsimonq2 | pitti: could I do replace all from xenial to devel? | 15:45 |
| pitti | yes | 15:45 |
| tsimonq2 | pitti: so how do I fix the apt-cacher-ng issues? | 15:46 |
| pitti | I don't know | 15:46 |
| pitti | I gave up using "devel" | 15:46 |
| tsimonq2 | anybody else know? | 15:46 |
| pitti | tsimonq2: it might even work for you | 15:47 |
| pitti | but I have tons of schroots, containers, QEMUs of different relelases etc. which all share one acng, and occasionally it caused hash sum mismatches | 15:47 |
| pitti | but just try it | 15:48 |
| tsimonq2 | pitti: but how would I fix the hash sum mismatches then? | 15:48 |
| pitti | pitti | I don't know | 15:48 |
| tsimonq2 | hmm.would +1 know about this better? | 15:49 |
| Saviq | pitti, hey, question about packaging, from time to time we hit the proverbial wall of Build-Depends being too broad, has there been talk, or maybe there's a solution, to declare what's needed to build just the source package? maybe also test dependencies (autopkgtest helps here, but nocheck could skip those top-level deps)? | 16:02 |
| slangasek | pitti: is p-m now using the trigger syntax for autopkgtests, and is there a way to see the value of triggers on autopkgtest.u.c? | 16:04 |
| pitti | Saviq: sorry, I don't understand the question | 16:08 |
| pitti | slangasek: yes, britney has used explicit triggers for maybe one or two months now, which makes the whole thing much more robust | 16:08 |
| pitti | slangasek: it's also a prerequisite for minimizing deps from proposed | 16:09 |
| pitti | slangasek: yes, there are two places: in result.tar there's a testinfo.json which contains it in machine parseable form | 16:09 |
| pitti | slangasek: and if you look at the top of a log it says e. g. ADT_TEST_TRIGGERS=linux-meta/4.2.0.16.19 | 16:09 |
| slangasek | pitti: right. so fwiw I'm currently trying to figure out of devscripts in xenial-proposed is what caused the regression (on 2 of 3 architectures) in license-reconcile: http://autopkgtest.ubuntu.com/packages/l/license-reconcile/xenial/amd64/ http://autopkgtest.ubuntu.com/packages/l/license-reconcile/xenial/armhf/ | 16:09 |
| slangasek | pitti: could we have the triggers exposed on the index somehow? | 16:09 |
| pitti | slangasek: yeah, I guess that would be usefull | 16:10 |
| pitti | useful too | 16:10 |
| slangasek | pitti: for that matter I don't see a link to result.tar | 16:10 |
| slangasek | artifacts.tar.gz doesn't include this | 16:11 |
| pitti | slangasek: no, it needs to be in result.tar, as proposed-migration, kernel-matrix, etc. need the testinfo.json | 16:11 |
| pitti | right, there's no link to it; the general idea is to present results.tar in the debci log in a more human friendly manner | 16:11 |
| pitti | so that log should get it at lesat | 16:12 |
| pitti | but showing it on the index page also sounds useful | 16:12 |
| slangasek | pitti: ok, that's all the more reason to have the trigger info on the index page | 16:12 |
| * pitti files bug 1511780 | 16:13 | |
| ubottu | bug 1511780 in Auto Package Testing "debci: show test triggers" [Undecided,New] https://launchpad.net/bugs/1511780 | 16:13 |
| slangasek | ta :) | 16:13 |
| slangasek | meanwhile I've confirmed that devscripts was the trigger for the regression, how disappointing :) | 16:13 |
| pitti | slangasek: if I ever get out of "OMGfixthisnow" mode, there's tons of improvements like this to be made | 16:13 |
| * slangasek nods | 16:13 | |
| Saviq | pitti, if you only want to build a source package, you rarely need all of Build-Depends, same if you don't run the tests, some dependencies in Build-Depends are really runtime test dependencies | 16:14 |
| Saviq | pitti, building a unity8 source package takes a long time in the train today because of all the packages its Build-Depends pulls in | 16:14 |
| pitti | slangasek: confirming which package broke what should get a lot easier and more predictable with the -proposed minimalization too | 16:14 |
| pitti | slangasek: I have 3/4 of the autopkgtest support written, but still fighting with what to do in the case when that apt pinning fails and we need to use full -proposed | 16:15 |
| pitti | slangasek: I was going to look at that during the flight; no distractions : | 16:15 |
| pitti | ) | 16:15 |
| pitti | Saviq: oh, I see; well, you never need any of the B-D to build a source | 16:15 |
| Saviq | pitti, but some packages need some specific dh_ bits, and there's no way to declare those, either | 16:15 |
| pitti | Saviq: "debuild -S -nc" should do fine and avoids any black magic that debian/rules might do to your package, or fail on | 16:16 |
| pitti | Saviq: dh_* are not called for -S | 16:16 |
| pitti | just debian/rules clean, which you can eliminate with -nc | 16:16 |
| pitti | (of course you must then ensure to not have any build cruft there -- but we all build in sbuild, right?) | 16:16 |
| Saviq | yup | 16:16 |
| pitti | Saviq: I assume this is in the context of the train/automatic merges and stuff? | 16:17 |
| Saviq | pitti, yes | 16:17 |
| pitti | -nc should be fine there | 16:17 |
| Saviq | pitti, yeah, that helps | 16:17 |
| Saviq | robru, ↑↑ | 16:17 |
| pitti | Saviq: I'm surprised that you survived for so long without that | 16:17 |
| pitti | a lot of packages need all kind of stuff which you really don't want to all install on these production boxes? :-) | 16:17 |
| slangasek | Saviq, robru, pitti: I thought we had to use the clean target because it might do things like e.g. generation of debian/control | 16:18 |
| slangasek | in the context of the train | 16:18 |
| Saviq | slangasek, I also thought there's things like autoconf that you need to call before you can get a tarball out of a branch | 16:21 |
| Saviq | or *re*conf | 16:21 |
| slangasek | well | 16:21 |
| slangasek | perhaps | 16:21 |
| slangasek | though in that case these are not properly constructed UDD-style source-package branches, which I thought was a prerequisite for the train | 16:22 |
| didrocks | Saviq: slangasek: yeah, a word of warning, but some cmake/autotools project expect the clean target to be run to build the source package | 16:24 |
| didrocks | famous example being projects only having autogen.sh | 16:24 |
| * slangasek nods | 16:24 | |
| didrocks | also, same issue with python projects, you need to resolve the imports for setup.py | 16:24 |
| didrocks | hence the only rule that worked was "let's get b-d" | 16:24 |
| didrocks | (not saying it's the right thing, just giving context) | 16:25 |
| Saviq | didrocks, yeah, thanks, helps a lot | 16:25 |
| Saviq | didrocks, I was just asking whether it's a topic in the dpkg community to potentially introduce something like Source-Depends | 16:26 |
| Saviq | would save hours in the train... | 16:27 |
| pitti | Saviq: no, it's not a topic AFAIK | 16:27 |
| didrocks | Saviq: maybe we can start with a X-Source-Depends and brought the issue upstream? (and if not present, the train fallback to Build-Depends) | 16:27 |
| Saviq | didrocks, yeah, that's what I was thinking | 16:27 |
| Saviq | robru, ↑ | 16:27 |
| pitti | err, autogen.sh in "clean"? that's evil | 16:27 |
| pitti | that belongs into build | 16:27 |
| didrocks | pitti: you will never know what I've seen, my eyes are bleeding ;) | 16:28 |
| didrocks | see, that's why I've glasses now! | 16:28 |
| pitti | perhaps a good chance to actaully fix these packages :) | 16:28 |
| Saviq | pitti, I think the problem is that the result of autogen.sh is expected to be part of the tarball... | 16:28 |
| Saviq | or at least that's the history | 16:28 |
| Saviq | didrocks, robru, bug #1511785 | 16:33 |
| ubottu | bug 1511785 in CI Train [cu2d] "Could save a lot of time in package preparation if we skipped build-depends" [Undecided,New] https://launchpad.net/bugs/1511785 | 16:33 |
| pitti | Saviq: hm, that is really old school | 16:35 |
| pitti | Saviq: normally you just build-dep on dh-autoreconf, have dh --with=autoreconf (or call dh_autoreconf for non-dh packages), and it'll DTRT | 16:35 |
| pitti | avoids lots of noise between package builds, as they are really hard to review and utterly uninteresting | 16:36 |
| Saviq | sure, agreed, wonder if there's a solution for setup.py | 16:36 |
| Saviq | maybe we can drop b-d in the train and fix packaging instead | 16:36 |
| pitti | Saviq: would it be totally unreasonable for train packages to require that they get updated to packaging standards which are only 3 years old, not 10? :-) | 16:36 |
| Saviq | pitti, nope, +1 from me | 16:37 |
| didrocks | pitti: how would you do it for python project? | 16:37 |
| pitti | didrocks, Saviq: OOI, why does building a .dsc need to call setup.py? | 16:37 |
| didrocks | bumping version for release | 16:37 |
| didrocks | (and so creating version.py) | 16:37 |
| pitti | sorry guys, I need to leave, and then long travel to Austin | 16:38 |
| didrocks | (I guess some of our packages have the same mechanism in CMakeLists.txt) | 16:38 |
| didrocks | pitti: have a safe travel! | 16:38 |
| pitti | see you next week in an odd time zone :) | 16:38 |
| Saviq | o/ | 16:38 |
| didrocks | enjoy jetlag! ;-) | 16:38 |
| happyaron | pitti: safe trip, :) | 16:42 |
| sil2100 | slangasek, cjwatson: could anyone of you guys help me check the installability problem of ocaml on ppc64el? I don't have any way of getting this arch testable | 16:42 |
| slangasek | sil2100: porter-ppc64el.canonical.com? | 16:42 |
| sil2100 | slangasek: how do you use that? ;) | 16:43 |
| sil2100 | First time I see this address | 16:43 |
| slangasek | sil2100: https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes | 16:43 |
| sil2100 | Is it VPN only? | 16:43 |
| sil2100 | slangasek: thanks | 16:43 |
| sil2100 | slangasek: so, on the ppc64el porterbox it seems that the xenial chroot doesn't exist - it appears in the schroot -l but can't switch to it as /srv/chroots/xenial-ppc64el does not exist | 16:53 |
| sil2100 | slangasek: and I don't want to meddle too much on a machine that's used by others | 16:55 |
| slangasek | sil2100: oh, sorry, of course this is xenial - and the current porter box is a P7, whereas xenial is built targetting P8 hardware, so we're without a working porter environment for xenial for the near term | 17:25 |
| slangasek | sil2100: we're working on getting this fixed but it's going to take a bit of hardware shuffling | 17:25 |
| sil2100 | Ok... any other possibility of getting some ppc64el chroot to test that issue? | 17:26 |
| slangasek | sil2100: probably easier to let me remote debug it for you. What's the root of the issue you're trying to solve? | 17:27 |
| sil2100 | slangasek: it seems that the new ocaml is uninstallable on ppc64el, at least that's what the transition page says - not much more info sadly | 17:29 |
| sil2100 | It built fine and works good on all other archs | 17:30 |
| sil2100 | Want to make sure it's not a red herring | 17:30 |
| cjwatson | sil2100: for installability issues, all you need is chdist(1) from ubuntu-dev-tools | 17:46 |
| * slangasek nods | 17:47 | |
| cjwatson | sil2100: sorry, devscripts, not ubuntu-dev-tools | 17:48 |
| cjwatson | no need at all to be on the same architecture, since it's purely configuring apt differently and then letting it do the graph analysis | 17:48 |
| cjwatson | (and you can't actually install packages, obviously, but just say no to that prompt) | 17:49 |
| slangasek | I don't remember seeing '.uninstallable' as a transition tag before; how does that work, anyway? is it possible the tag itself is broken for ppc64el? | 17:49 |
| cjwatson | I think that is unlikely. it's been around for ages and has always worked well for me | 17:50 |
| cjwatson | dose-debcheck does the analysis | 17:50 |
| cjwatson | or dose-distcheck or whatever it's called these days | 17:51 |
| cjwatson | The following packages have unmet dependencies. | 17:53 |
| cjwatson | camlp4 : Depends: ocaml-nox-4.01.0 | 17:53 |
| cjwatson | camlp4-extra : Depends: ocaml-nox-4.01.0 | 17:53 |
| cjwatson | says chdist | 17:53 |
| cjwatson | ah | 17:53 |
| cjwatson | I bet this is NBS | 17:54 |
| cjwatson | yeah, camlp4 is now distributed separately, and probably hasn't been auto-synced due to it being in an ubuntu-versioned source | 17:55 |
| cjwatson | being called away, will come back and sort this out soon | 17:56 |
| tumbleweed | autopkgtest.ubuntu.com seems MIA | 18:08 |
| sarnold | tumbleweed: there's some issues in the datacenter, it's possible that's one of the affected services | 18:09 |
| sil2100 | cjwatson: camlp4 is something different | 18:09 |
| sil2100 | cjwatson: anyway, thanks! | 18:09 |
| robru | slangasek: yes we have a couple packages now that are generating debian/control by './debian/rules clean' but we invoke that manually, eg, no deps are present during cleaning. deps get installed by 'bzr bd' afterwards. | 18:14 |
| robru | slangasek: pitti I'm open to trying 'debuild -S -nc' after a maual './debian/rules clean', I'm not sure what implications that would have though | 18:14 |
| cjwatson | sil2100: camlp4 is the cause of your problem :P | 18:38 |
| cjwatson | sil2100: it's still present in xenial and lists ocaml as its source package there, and therefore gets counted as uninstallable by the tracker even though that isn't really true for the purposes of the transition | 18:39 |
| cjwatson | sil2100: I've synced camlp4 now, that should make this glitch go away | 18:40 |
| sil2100 | cjwatson: strange that it didn't cause any problems on other archs | 18:45 |
| sil2100 | I actually thought that camlp4 was already synced because of that | 18:45 |
| sil2100 | cjwatson: anyway, thanks! :) | 18:47 |
| hallyn | urg | 19:10 |
| hallyn | arges: hey are you around? | 19:11 |
| hallyn | could you remove the netcf vivid package i just pushed to vivid-proposed? (it may just get auto-refused - i used same version # currently in use in wily) | 19:11 |
| hallyn | i guess i'll use 1:0.2.6-1ubuntu1~15.04.1 ? vivid currently has 1:0.2.6-1, wily has 1:0.2.6-1ubuntu1 | 19:13 |
| hallyn | or 1:0.2.6-1ubuntu0.15.04.1 | 19:14 |
| hallyn | ok yup, auto-rejected | 19:16 |
| slangasek | sil2100, cjwatson: either of you know why camlp4 has added a 'camlp4-dbgsym' binary package? (currently in binary NEW) | 19:30 |
| slangasek | that seems like a horribly wrong thing for the Debian ftpmasters to have let into the archive | 19:31 |
| ScottK | slangasek: I don't think it generates that binary in Debian. | 19:47 |
| cjwatson | slangasek: our NEW shows *-dbgsym | 19:48 |
| cjwatson | sil2100: yeah, I didn't look at other arches | 19:48 |
| cjwatson | slangasek: (this is arguably a bug, but not a very important one) | 19:48 |
| arges | hallyn: ok back i see netcf in vivid queue.... is that the right one? | 19:52 |
| slangasek | cjwatson: oh; so the dbgsym being listed as 'NEW' doesn't mean it's in Debian as a .deb, ok | 19:58 |
| slangasek | doko: I'm assuming that your syncing of swig 3.0.7-1 means that we want to trade swig2 for swig3 in main now | 20:04 |
| hallyn | arges: yup, it's the right one now :) thx | 20:05 |
| cjwatson | sil2100,slangasek: there is in fact a subtle bug in the transition tracker which you can ignore for your purposes | 20:31 |
| cjwatson | it's to do with the stuff that tries to filter out packages from the release pocket that've been superseded en bloc by source packages in -proposed | 20:32 |
| cjwatson | the problem is that that only filters out binaries from a given component if it finds binaries from that component in -proposed *in the same component* | 20:32 |
| cjwatson | so camlp4-extra is in universe, and should be disregarded since it's only in the release pocket and there's a newer version of the ocaml source in -proposed | 20:33 |
| === salem_ is now known as _salem | ||
| cjwatson | but as it happens, the only non-arch-all binary built by the ocaml source that remains in universe is ocaml-native-compilers, and that happens to be built on all architectures except for ppc64el (presumably it requires porting) | 20:33 |
| cjwatson | so the top-level tracker "go" script fails to filter out camlp4-extra, but just on ppc64el | 20:34 |
| cjwatson | you owe me half an hour of my life scratching my head trying to figure that one out :P | 20:34 |
| * cjwatson attempts a quick fix | 20:34 | |
| hjd | Could someone please retry libio-compress-lzma-perl in Xenial? :) Looks like it failed to build initially because it was synced/attempted built before one of its dependencies (libio-compress-perl) which is now available. | 20:45 |
| cjwatson | hjd: done | 20:48 |
| hjd | cjwatson: Thank you. | 20:48 |
| cjwatson | damnit, I shouldn't edit transition tracker code at 9pm on Friday, I fear I may have broken it and don't immediately have time to fix it | 20:50 |
| cjwatson | I'll come back to it in a bit and figure it out if nobody beats me to it | 20:50 |
| cjwatson | I guess I could just have hit a locking failure, since update-transitions doesn't have locking of its own | 20:53 |
| cjwatson | ah yes, just locking silliness | 21:00 |
| cjwatson | sil2100: should sort itself out in a bit but I have to wait for cron to do its thing | 21:04 |
| hjd | Another thing I stumbled across; django-celery depends on python3-django-nose which in turn depends on python3-nose. However, this was broken for a short while in python3-django-nose so it didn't pull in python3-nose which caused django-celery to ftbfs in Xenial. This should be fixed again now, and I suspect the package would build successfully on a rebuild. | 21:10 |
| hjd | Though I wonder whether there's any guidelines regarding transitive dependencies or if packages should ideally list all necessary dependencies even if they happen to also be installed by other dependencies? | 21:10 |
| sil2100 | cjwatson: thanks! | 21:13 |
| === benonsoftware is now known as MisterHiyas | ||
| === Unit193 is now known as HeadlessHorseman | ||
| === nhandler is now known as evilnhandler | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!