| rbasak | roaksoax: do you want to upload that? | 00:00 |
|---|---|---|
| rbasak | roaksoax: I was about to go to bed. | 00:00 |
| slangasek | nacc_: and the php7.0-cli dependency on libqdbm14 (universe) needs to be resolved before pkg-php-tools is buildable | 00:13 |
| nacc_ | slangasek: ok, the build of php7.0 takes a while, so i'm waiting for it to finish before submitting the debdiff | 00:17 |
| nacc_ | slangasek: i'm fairly confident it is right now that it's going properly (they changed the way extenions were compiled in, so had to adjust the php5 delta) | 00:18 |
| slangasek | nacc_: ok. please do point me at the debdiff once you've uploaded it | 00:48 |
| nacc_ | slangasek: will do -- also, i'm finally looking at LP: #cobbler 1543820 | 00:52 |
| nacc_ | gah | 00:52 |
| nacc_ | LP: #1543820 | 00:52 |
| ubottu | Launchpad bug 1543820 in jmespath.php (Ubuntu) "jmespath.php: add nocheck and stage1 build profiles" [Wishlist,New] https://launchpad.net/bugs/1543820 | 00:52 |
| slangasek | excellent | 00:52 |
| nacc_ | i understand the test: target issue | 00:52 |
| nacc_ | but i don't know how to fixup the coverage: one? | 00:52 |
| nacc_ | and test: is a dependency for all: | 00:53 |
| nacc_ | actually | 00:53 |
| nacc_ | so would i remove that dependency in the makefile and then just add a dh_override_auto_test? coverage i think won't get invoked during the build | 00:54 |
| nacc_ | slangasek: urgh, sorry, was confusing that and LP #1543817 | 01:01 |
| ubottu | Launchpad bug 1543817 in php-guzzlehttp-psr7 (Ubuntu) "php-guzzlehttp-psr7: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/1543817 | 01:01 |
| nacc_ | it feels like they will have the same answer, though | 01:01 |
| nacc_ | is it ok for me to change the all: target to not run tests by default? so i can override it in debian/rules? or should that work? | 01:01 |
| nacc_ | slangasek: fyi, build just finished, works w/ debdiff from LP: #1547245 | 01:11 |
| ubottu | Launchpad bug 1547245 in php7.0 (Ubuntu) "php7.0: remove dependencies that come from universe" [Undecided,New] https://launchpad.net/bugs/1547245 | 01:11 |
| slangasek | nacc_: php5-xmlrpc is in main and doesn't depend on xmlrpc-epi; is this maybe an optional dependency? | 01:17 |
| slangasek | nacc_: interbase and imap packages were built for php5, but came from separate source packages in that version. So this is probably ok for here and now (until we finish the main build-depends discussion) | 01:19 |
| nacc_ | slangasek: i think the xmlrpc-epi dependency is altogether new in 7.0 and the xmlrpc module (it's makefile) uses xmlrpc-epi explicitly (http://anonscm.debian.org/cgit/pkg-php/php.git/commit/?h=master-7.0&id=1ae43adc9057c3911d1ada8e3a1231d456f6f20f) | 01:19 |
| slangasek | ok | 01:19 |
| slangasek | nacc_: so, that's probably something that should get an MIR rather than just being dropped; but I'm ok with applying this patch now and uploading, to unblock us | 01:20 |
| nacc_ | slangasek: well, here's the really confusing part with php5 | 01:20 |
| nacc_ | well, maybe a side discussion | 01:22 |
| nacc_ | php5 and php5.6 are different src pckages | 01:23 |
| nacc_ | :) | 01:23 |
| nacc_ | it leads to some weirdness and i don't know why it's that way, tbh | 01:23 |
| nacc_ | but i can do the MIR for packages that now won't exist | 01:23 |
| nacc_ | slangasek: so far that's php-xmlrpc, php-interbase and php-imap (with their corresponding 7.0 names) | 01:24 |
| slangasek | hmm yes | 01:25 |
| slangasek | I don't know why that is | 01:25 |
| sarnold | which of those packages will exist when xenial is released? php5? php5.6? php7? | 01:26 |
| nacc_ | only php7 | 01:27 |
| nacc_ | is the plan | 01:27 |
| nacc_ | sarnold: --^ | 01:27 |
| sarnold | nacc_: no php 5.x in xenial, even in universe? | 01:28 |
| nacc_ | sarnold: correct | 01:28 |
| nacc_ | sarnold: if you want php5 stay on 14.04 LTS | 01:28 |
| sarnold | wow, feels ambitious :) woo. thanks. | 01:28 |
| Pharaoh_Atem | nacc_: so we're doing the php7 move? | 01:33 |
| Pharaoh_Atem | awesome | 01:33 |
| Pharaoh_Atem | meanwhile, I'm about to break down and cry in the amount of effort I've expended to try to build this package in a sane fashion | 01:34 |
| robert_ancell | jsalisbury, that dir you sent me for the kernel to test is empty | 01:34 |
| slangasek | nacc_: btw do you know anything about the autopkgtest failures on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#php7.0 ? it doesn't look like a false positive to me | 01:36 |
| Pharaoh_Atem | slangasek: I'm actually trying to fix them | 01:48 |
| Pharaoh_Atem | the weird thing is, I can run them manually (i.e., run the commands in the scripts in order) and everything is fine in my Xenial VM | 01:48 |
| Pharaoh_Atem | however, autopkgtest is failing for whatever reason | 01:48 |
| nacc_ | slangasek: Pharaoh_Atem: i'll try and take a look | 01:49 |
| Pharaoh_Atem | nacc_: my theory is that all the a2* commands need to be guarded to redirect their output to /dev/null and set to OR with true | 01:49 |
| Pharaoh_Atem | but I've been having a hell of a time trying to prove that | 01:49 |
| nacc_ | Pharaoh_Atem: hrm | 01:50 |
| Pharaoh_Atem | pbuilder and sbuild make me want to hurt people | 01:50 |
| Pharaoh_Atem | I've never encountered a more obnoxious chroot builder tool | 01:50 |
| Pharaoh_Atem | err, package builder tool using chroots | 01:51 |
| sarnold | i'm suriously surprised no one's replaced them with lbuild for lxc or kbuild for kvm.. | 01:51 |
| nacc_ | Pharaoh_Atem: trying it locally, will let you know | 01:52 |
| Pharaoh_Atem | nacc_: awesome | 01:52 |
| Pharaoh_Atem | thanks | 01:52 |
| Pharaoh_Atem | sarnold: this is the first time I've attempted to build debian packages using pbuilder and the like in quite a while | 01:52 |
| Pharaoh_Atem | most of the time, I just use open build service | 01:53 |
| nacc_ | slangasek: for those packages that need MIR, is the general strategy to start with basically php7.0 as the source and just strip them down to the point where they just have the bits needed for say php7.0-xmlrpc? and then that source and binary would be in universe? | 01:53 |
| Pharaoh_Atem | nacc_: if you need my patch diff, I can send it to you | 01:53 |
| nacc_ | slangasek: do we, to enforce the break from php5 to php7 have the php7 packages break their php5 counterparts? i'm noticing that the bootstrap may not be necessary anymore (!) because the deps are versioned, e.g. php7.0-cli php7.0_7.0.3-5ubuntu1.dsc | 01:55 |
| nacc_ | err | 01:55 |
| nacc_ | php7.0-cli Breaks: php5-cli (<< 5.6.16+dfsg-4~) | 01:56 |
| nacc_ | slangasek: i *think* those exist because in debian they are coinstallable | 01:58 |
| Pharaoh_Atem | nacc_: I'm also going through and ensuring that every test turns off stuff that could potentially conflict that was turned on by other tests | 01:58 |
| slangasek | nacc_: MIR> the process is, you identify the build-dependency that's needed for php7.0-xmlrpc (xmlrpc-epi), you go through the checklist for that package to see what it needs in order to be in main; then you look at any dependencies /that/ package has which aren't in main and do the same | 02:00 |
| nacc_ | slangasek: ah ok, so sort of the same process, but for each of these | 02:01 |
| nacc_ | got it | 02:01 |
| Pharaoh_Atem | sarnold: is there anything that's as simple as RH/Fedora's mock for Debian packages? | 02:01 |
| slangasek | nacc_: regarding the breaks, if the package is policy-compliant then that's because php7.0-cli took over some file previously provided by php5-cli | 02:02 |
| slangasek | if they're coinstallable and no bootstrap is needed, then that's peachy :) | 02:02 |
| nacc_ | slangasek: well, they are possibly now :/ frustrating given how much time i spent on it, but yeah, much easier | 02:02 |
| nacc_ | i think that means we can just start building stuff once we have the updated pkg-php-tools and php-pear | 02:03 |
| Pharaoh_Atem | neat | 02:03 |
| slangasek | very possible | 02:03 |
| nacc_ | although i'm not sure if they'll automatically pull in the php7 deps | 02:03 |
| sarnold | Pharaoh_Atem: sorry, I've never heard of mock; what does it do? | 02:03 |
| nacc_ | i'll need to test that with the current archive | 02:03 |
| slangasek | that depends how their build-depends are listed | 02:03 |
| slangasek | anything that was on your list for "rebuild only" should pull in the php7 versions of packages, yes | 02:03 |
| Pharaoh_Atem | sarnold: http://linuxmanpages.net/manpages/fedora21/man1/mock.1.html | 02:04 |
| Pharaoh_Atem | it takes Source RPMs and can rebuild them for any arbitrary target | 02:04 |
| Pharaoh_Atem | into binary packages | 02:04 |
| Pharaoh_Atem | it can also create generic chroots that you can use for arbitrary purposes | 02:04 |
| nacc_ | slangasek: right, but i'm worried that with the coinstallable version, what's happening is that sbuild right now is installing php5-cli for phpunit and php7.0-cli for the package and possibly running under php5 ... i'm not sure | 02:04 |
| slangasek | ah | 02:05 |
| Pharaoh_Atem | sarnold: it's actually available in Ubuntu, too :P ( http://manpages.ubuntu.com/manpages/wily/en/man1/mock.1.html ) | 02:05 |
| sarnold | hah | 02:05 |
| Pharaoh_Atem | the version in Ubuntu is a tad bit old, but it works | 02:05 |
| nacc_ | slangasek: does that make sense? i'm just worried that the world we're building in now is different than the one i did the builds with (and i know produced the right result) | 02:05 |
| sarnold | Pharaoh_Atem: schroot manges the chroot bits.. sbuild uses them to build packages.. | 02:06 |
| sarnold | Pharaoh_Atem: debootstrap can populate a directory with a debian / ubuntu install | 02:06 |
| slangasek | nacc_: well, to date the only things we're building are php-pear (done) and pkg-php-tools (dep-wait) which were the bits at the bottom of your tree. I don't have to upload no-change rebuilds for the other stuff until you confirm that's appropriate | 02:07 |
| nacc_ | slangasek: that is, i'm noticing if i tell sbuild that there is a build conflict with php5-cli, e.g., the build fails unless i'm in a staged build (which is roughly the result we want with updated php-pear and pkg-php-tools) | 02:07 |
| nacc_ | ok, i'll spend some time tmrw morning, if that's ok with you, thinking about that | 02:07 |
| Pharaoh_Atem | sarnold: yeah, the functionality of debootstrap is sorta not necessary in RH/Fedora because it's built into Yum (RHEL; Fedora <22) and DNF (Fedora >=22) | 02:07 |
| slangasek | nacc_: but also, if the builds *are* doing the right thing, we can do the whole bootstrap in the main archive by just double-uploading no-change rebuilds | 02:07 |
| slangasek | sorry, I mean if they aren't doing the right thing | 02:07 |
| nacc_ | slangasek: right | 02:07 |
| sarnold | Pharaoh_Atem: have you seen this yet? https://wiki.ubuntu.com/SimpleSbuild | 02:08 |
| Pharaoh_Atem | yeah | 02:08 |
| nacc_ | slangasek: i'm starting to think that possibly we'll be able to just build straight through in the right order | 02:08 |
| Pharaoh_Atem | I've been trying to set that up | 02:08 |
| nacc_ | slangasek: but that's what i'd like to confirm tmrw before we kick it off | 02:08 |
| slangasek | nacc_: ok | 02:08 |
| Pharaoh_Atem | sarnold: it just finished building the chroot tarball, so I think it might actually work, just maybe possibly... | 02:09 |
| nacc_ | slangasek: and pkg-php-tools should be able to go once php7.0 is updated? | 02:09 |
| slangasek | nacc_: yes | 02:09 |
| slangasek | nacc_: so I'll retry that build as soon as php7.0 is done, which I'm expecting to be in less than a half hour | 02:10 |
| nacc_ | slangasek: yeah it takes a while, i noticed, but that was on my laptop :) | 02:10 |
| === beisner- is now known as beisner | ||
| nacc_ | slangasek: thanks for all your help! | 02:10 |
| nacc_ | i really appreiate it | 02:11 |
| slangasek | no prob | 02:11 |
| nacc_ | slangasek: sigh, just confirmed, e.g., that php-guzzlehttp-psr7 can just be rebuilt against xenial w/o bootstrap/modification | 02:15 |
| nacc_ | slangasek: there's two weeks+ of work that can be tossed :) | 02:15 |
| nacc_ | oh well, learned a lot | 02:15 |
| Pharaoh_Atem | nacc_: at least you enjoyed it, right? | 02:16 |
| Pharaoh_Atem | or did you hate everything :P | 02:16 |
| nacc_ | Pharaoh_Atem: no it was good, just stressful :) | 02:16 |
| slangasek | nacc_: interesting, is this because something changed out from underneath you with php5-cli? | 02:16 |
| nacc_ | slangasek: yeah, debian has updated both php5 and php7 past the point where there was a conflict in the build-deps | 02:17 |
| nacc_ | err, in the binary packages | 02:17 |
| * slangasek nods | 02:17 | |
| slangasek | so, a race condition | 02:17 |
| nacc_ | e.g., when i started, php7.0-cli and php5-cli conflicted | 02:17 |
| nacc_ | now they don't :) | 02:17 |
| nacc_ | yeh | 02:17 |
| Pharaoh_Atem | so that means a mass import for the php stack will fix everything? | 02:17 |
| nacc_ | Pharaoh_Atem: that's what i need to check | 02:17 |
| nacc_ | Pharaoh_Atem: I *think* the debian packages right now still refer to php5 in their deps | 02:18 |
| Pharaoh_Atem | guh | 02:18 |
| nacc_ | Pharaoh_Atem: because debian hasn't uploaded the new php-pear and pkg-php-tools | 02:18 |
| nacc_ | that's the step that will diverge for now in ubuntu | 02:18 |
| Pharaoh_Atem | that won't be for very long, practically speaking | 02:18 |
| nacc_ | with the understanding that what we have is what debian has in their git tree(s) | 02:18 |
| nacc_ | yeah | 02:18 |
| nacc_ | so it's a very known delta to carry for hopefully a short amount of time | 02:18 |
| Pharaoh_Atem | that's why I've been submitting fixes to php7.0 to their git tree | 02:19 |
| nacc_ | yep and those have all been sync'd to ubuntu already, afaict | 02:19 |
| Pharaoh_Atem | I've had some testing of it done against our applications | 02:19 |
| Pharaoh_Atem | the fpm stuff has not | 02:19 |
| nacc_ | Pharaoh_Atem: ok | 02:19 |
| Pharaoh_Atem | ondrej didn't see my patches and only applied the newest set from last week yesterday | 02:19 |
| nacc_ | Pharaoh_Atem: you saw this, right? | 02:20 |
| nacc_ | /tmp/adt-run.qW8OfQ/build.vJ1/php7.0-7.0.3/debian/tests/mod-php: 6: /tmp/adt-run.qW8OfQ/build.vJ1/php7.0-7.0.3/debian/tests/mod-php: cannot create /var/www/html/hello.php: Directory nonexistent | 02:20 |
| Pharaoh_Atem | no, I didn't | 02:20 |
| Pharaoh_Atem | that's weird | 02:20 |
| nacc_ | it's in the middle of the bulid log | 02:20 |
| nacc_ | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/php7.0/20160217_205539@/log.gz | 02:20 |
| nacc_ | i'm not sure why fpm is exiting yet, but when you've been running the tests, were you testing the archive version of php-fpm or your pathed version? | 02:21 |
| Pharaoh_Atem | is /var/www/html not your default path? | 02:21 |
| Pharaoh_Atem | nacc_: archive version | 02:21 |
| nacc_ | Pharaoh_Atem: that's the archive's build | 02:21 |
| Pharaoh_Atem | I'm extremely confused now | 02:21 |
| nacc_ | http://autopkgtest.ubuntu.com/packages/p/php7.0/xenial/amd64/ | 02:22 |
| nacc_ | start there | 02:22 |
| nacc_ | then test log | 02:22 |
| Pharaoh_Atem | ah | 02:22 |
| Pharaoh_Atem | now I get it | 02:22 |
| nacc_ | that's what i assume you were trying to resolve (as those tests need to pass) | 02:22 |
| Pharaoh_Atem | yes | 02:23 |
| Pharaoh_Atem | weirdly enough | 02:23 |
| Pharaoh_Atem | that's not a test I modified | 02:23 |
| Pharaoh_Atem | hold on | 02:26 |
| Pharaoh_Atem | hold the phone | 02:26 |
| Pharaoh_Atem | I think I *might* know why | 02:26 |
| Pharaoh_Atem | I hope I'm wrong | 02:26 |
| Pharaoh_Atem | because otherwise this will be really dumb | 02:26 |
| Pharaoh_Atem | nope, libapache2-mod-php7.0 depends on apache2 | 02:27 |
| Pharaoh_Atem | oh, wait | 02:28 |
| Pharaoh_Atem | nacc_: I know what happened | 02:28 |
| Pharaoh_Atem | libapache2-mod-php7.0 doesn't depend on apache2, only apache2-bin | 02:28 |
| Pharaoh_Atem | the directory is created when apache2 is installed | 02:28 |
| Pharaoh_Atem | NOT when apache2-bin is installed | 02:28 |
| * Pharaoh_Atem groans | 02:28 | |
| Pharaoh_Atem | nacc_: so basically, I need to add apache2 as a dep to the mod-php test | 02:30 |
| Pharaoh_Atem | nacc_: it worked for me before because apache2 was installed | 02:31 |
| Pharaoh_Atem | but this builder environment didn't have it | 02:31 |
| === juliank is now known as Guest490 | ||
| === juliank_ is now known as juliank | ||
| nacc_ | Pharaoh_Atem: glad to help :) | 02:36 |
| nacc_ | Pharaoh_Atem: will that fix fpm too? | 02:36 |
| Pharaoh_Atem | fpm already had apache2 as a dep, but I think the other fix I made should make things better | 02:36 |
| Pharaoh_Atem | if you'd be so kind to test a pair of patches I'll send your way? | 02:36 |
| nacc_ | Pharaoh_Atem: sure just e-mail them to me | 02:37 |
| Pharaoh_Atem | nacc_: they should be in your canonical inbox | 02:39 |
| nacc_ | Pharaoh_Atem: ok ,might not get to it til the am, fyi | 02:41 |
| nacc_ | Pharaoh_Atem: working on dinner at the moment :) | 02:41 |
| Pharaoh_Atem | that's okay | 02:43 |
| Pharaoh_Atem | hopefully it fixes those tests | 02:44 |
| Pharaoh_Atem | if these are good, I'll send them up to Ondrej for inclusion in the master-7.0 dgit | 02:46 |
| cpaelzer | good morning | 05:48 |
| pitti | Good morning | 06:35 |
| pitti | stgraber: yes, it was broken due to a proxy issue, I fixed it last night | 06:35 |
| highvoltage | 5 | 06:39 |
| cpaelzer | we have a test failing in dep8/autopkg runs due to sse3 not being available | 07:08 |
| cpaelzer | which makes sense as the default vm has only up to sse2 | 07:08 |
| cpaelzer | I wonder if there is a way to define a d/t/control in a way so that tests would have sse3 available or something similar | 07:09 |
| pitti | cpaelzer: your test could detect that and just skip itself (i. e. early exit 0) | 07:09 |
| cpaelzer | locally I confirmed that providing adt-run with "--qemu-options='-cpu qemu64,+ssse3' " it works | 07:09 |
| pitti | but this bears the question, how is that going to work on an real system? | 07:09 |
| cpaelzer | it is supposed to only work on real systems with >=sse3 | 07:10 |
| cpaelzer | disabling that would mean disabling all tests, so I wondered if there would be any way | 07:10 |
| cpaelzer | of corse in the worst case one might detect and early exit, but keep the tests for those who run it local with the qemu options | 07:11 |
| pitti | cpaelzer: if only some of the tests need ss3, then only check it there? | 07:11 |
| cpaelzer | pitti: all of them need it | 07:11 |
| cpaelzer | but I'd really like to check if there is really no way to get such options passed properly before disabling it | 07:12 |
| pitti | cpaelzer: so where is "disabling that would mean disabling all tests" a problem then? | 07:12 |
| pitti | if your debian/tests/whatever just checks /proc/cpuinfo and prints a sensible message and exits 0? | 07:12 |
| cpaelzer | pitti: the problem would be no dep8 tests in normal CI on package upload | 07:12 |
| pitti | if none of the tests below can run, then you aren't losing anything | 07:12 |
| pitti | right, but that's nothing the test itself can influence | 07:13 |
| pitti | a test doesn't have magic powers over the testbed you are running it on | 07:13 |
| cpaelzer | pitti: ok, I'd hoped there would be a way to force the test env to have such properties - like the isolation or class flags | 07:14 |
| cpaelzer | pitti: but thanks I really just wanted to make sure there is no easy way to get sse3 in the test env overlooked | 07:14 |
| jamespage | cpaelzer, ok - lets just put a check in the test to skip the tests if sse if not found then | 07:14 |
| cpaelzer | jamespage: ok | 07:14 |
| jamespage | I'm not really around this morning - if you can't find a sponsor, I'll pickup pm today | 07:15 |
| pitti | cpaelzer: no, this kind of feature test is way too specific | 07:15 |
| pitti | cpaelzer: I don't have control over the -cpu flags in production, we are using scalingstack instances, not direct QEMU invocations | 07:15 |
| cpaelzer | jamespage: ok, I'll pull the current package make the check happen test it and look around - if no one is here I'll mail you | 07:15 |
| cpaelzer | pitti: the only thing we could control there could be via a flavor maybe | 07:16 |
| cpaelzer | ah I see autopkgtest is a flavour already | 07:17 |
| cpaelzer | it is probably too much, for just this test to put extra effort there | 07:17 |
| cpaelzer | on-site aptop repair incoming - til later | 07:21 |
| pitti | @pilot in | 07:35 |
| === udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti | ||
| dholbach | good morning | 07:49 |
| mgedmin | did anything change on archive.ubuntu.com recently? | 08:10 |
| mgedmin | my squid-deb-proxy is reporting 503 errors for URLs like http://security.ubuntu.com/ubuntu/dists/precise-security/main/binary-amd64/Packages | 08:11 |
| mgedmin | (and also archive.ubuntu.com) | 08:11 |
| mgedmin | and then actual security updates fail with apt hash mismatch errors | 08:11 |
| mgedmin | ("WARNING: The following packages cannot be authenticated") | 08:12 |
| doko | cjwatson, could you have a look, if ghc can be built with llvm-3.8 (or -3.6) instead of 3.5? | 08:19 |
| hallyn | doko: should pkcon be willing to install a file called com.ubuntu.terminal_0.7.170_multi.click on amd64? | 08:48 |
| hallyn | (it says "Fatal error: Wrong architecture 'multi'") | 08:48 |
| hallyn | I'm jus asking you since yourname is in the changelog, | 08:48 |
| hallyn | though it looks like you just fixed the bulid, nm | 08:49 |
| doko | hallyn, I have no idea about click ... | 08:49 |
| hallyn | doko: yeah, sorry to bother you | 08:49 |
| hallyn | the whole chnagelog is a lot of "rebuild" :) | 08:49 |
| doko | pitti, nacc_: how many packages depend on swig's php support? | 08:53 |
| flexiondotorg_ | dholbach, Morning | 09:04 |
| dholbach | hi flexiondotorg_ | 09:04 |
| doko | seb128, Laney, willcooke: fyi, https://bugs.launchpad.net/ubuntu/+source/lua-bitop/+bug/1547395 | 09:09 |
| ubottu | Launchpad bug 1547395 in luasocket (Ubuntu) "MIR: new dependencies for libquvi-scripts / libquvi" [Undecided,New] | 09:09 |
| pitti | doko: was about 7, and none of the removed binaries had rdepends | 09:22 |
| doko | nacc_, jamespage: fop needs a xmlgraphics-commons merge | 09:41 |
| pitti | nacc_: can you please look at https://launchpad.net/ubuntu/+source/phpunit/5.1.3-1+ubuntu1/+build/9036792 ? segfault in dh_phpcomposer | 09:42 |
| pitti | doko: x-c merge is already in -proposed | 09:42 |
| pitti | l | 09:42 |
| doko | ta | 09:46 |
| pitti | nacc_: you have an irritating habit to add trailing space to your debian/changelog entries :) | 09:46 |
| doko | did somebody give back pcl on amd64? | 09:47 |
| pitti | ^ not me | 09:47 |
| xnox | kees, depends. I have seen obscure events resulting in reversal of "boot" direction. E.g. restart or stop dbus. Whilst doesn't quite means shutdown, the only practical way to recover is reboot. dm-0... depends what's on it, what upstart-udev events are emitted, and what other things trigger on that. On Ubuntu it shouldn't cause too much havoc by default.... | 09:56 |
| pitti | xnox: not sure about the context, but "systemctl stop dbus" is a no-op under Ubuntu FYI (and thus restart doesn't work either -- I recently made that a bit more robust) | 09:57 |
| xnox | pitti, the context was from "kees" saying many hours back -> "<kees> xnox: got a weird question for you -- why would the surprise appearance of dm-0 during upstart boot cause upstart to shut down they system?" | 10:01 |
| Saviq | pitti, morning, do you know anything about why apport-retrace would fail with "ERROR: E:Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -e /usr/bin/appstreamcli; then appstreamcli refresh > /dev/null; fi', E:Sub-process returned an error code"" since ~yesterday? | 10:03 |
| pitti | nacc_: please also look at bug 1543850, you attached the wrong debdiff | 10:05 |
| ubottu | bug 1543850 in phpunit-global-state (Ubuntu) "phpunit-global-state: add nocheck and stage1 build profiles" [Wishlist,Incomplete] https://launchpad.net/bugs/1543850 | 10:05 |
| pitti | Saviq: no; apparently appstream landed on the images/in ubuntu-desktop and now has a broken hook? | 10:05 |
| pitti | Saviq: it probably needs another test for "am I root" | 10:05 |
| Saviq | pitti, yeah, my apt-cacher-ng broke, too, need to allow the new file types | 10:06 |
| pitti | Saviq: oh, I'm using acng too, I didn't yet see that | 10:06 |
| Saviq | pitti, 403 on the .yml files | 10:06 |
| pitti | ah, I don't have /usr/bin/appstreamcli | 10:06 |
| Saviq | oh well, that's *a* solution | 10:07 |
| * Saviq files bug with apport and acng | 10:08 | |
| Saviq | although, wonder, should the first one be with appstream instead | 10:09 |
| pitti | Saviq: it's only a bug in appstream | 10:11 |
| pitti | Saviq: it apparently installs that apt hook, and that needs fixing | 10:11 |
| pitti | [ `id -u` = 0 ] or something | 10:12 |
| Saviq | pitti, bug #1547428 | 10:12 |
| ubottu | bug 1547428 in appstream (Ubuntu) "Fails to update packages in apport-retrace" [Undecided,New] https://launchpad.net/bugs/1547428 | 10:12 |
| Laney | https://github.com/ximion/appstream/pull/28 | 10:12 |
| * pitti hugs Laney, thanks! | 10:14 | |
| Saviq | pitti, bug #1547431 for acng | 10:16 |
| ubottu | bug 1547431 in apt-cacher-ng (Ubuntu) "Does not allow appstream files" [Undecided,New] https://launchpad.net/bugs/1547431 | 10:16 |
| pitti | nacc_: btw, for next time: simpler to just add multiple tasks to one bug about the same issue ("add stage1 blabla") | 10:22 |
| * pitti declares victory in today's sponsoring battle against nacc :) | 10:26 | |
| pitti | l | 10:27 |
| ogra_ | m | 10:31 |
| xnox | pitti, we have lxd for s390x. | 10:32 |
| xnox | pitti, is that because nacc fell asleep or some such?! =) | 10:32 |
| pitti | nacc_: segfault in https://launchpad.net/ubuntu/+source/twig/1.23.1-1ubuntu2/+build/9036982 too | 10:40 |
| cjwatson | doko: My general sense from debian-haskell@ is "haha no", and I'm certainly not going to go down a rabbit-hole on it when the experts think it's implausible to touch that. My understanding is that GHC is going to end up vendoring LLVM. :-/ | 10:49 |
| doko | ok, at least it's now demoted | 10:52 |
| cpaelzer | this morning we discussed here about skipping tests in openvswitch-dpdk if the environment can't provide sse3 | 11:01 |
| cpaelzer | since fixing this autppkgtest blocks another packets migration through proposed I wanted to ask if somebody would have a minute to sponsor bug #1547460 | 11:02 |
| ubottu | bug 1547460 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk failing in autopkgtests" [High,Triaged] https://launchpad.net/bugs/1547460 | 11:02 |
| cpaelzer | jamespage: you are not back already are you ? ^^ | 11:02 |
| infinity | cpaelzer: So, while skipping tests when they literally can't run is reasonable, we also shouldn't find ourselves in a situation where we can't test at all in our production builds. Have you talked to people about perhaps bumping the baseline scalingstack machine configs? I don't think any of the underlying hardware lacks sse3, we're probably just running in -cpu=core2duo or something and masking it out. | 11:04 |
| doko | rbasak, jamespage: now Debian is depending a lot on tomcat8 (libservlet3.1-java) instead of tomcat7 (libservlet3.0-java). I saw that seb128 changed libhsqldb1.8.0-java to libservlet3.0-java. time to move to tomcat8? | 11:04 |
| xnox | apw, Setting up linux-image-4.4.0-6-generic (4.4.0-6.21) ... | 11:04 |
| xnox | Running depmod. | 11:04 |
| xnox | update-initramfs: deferring update (hook will be called later) | 11:04 |
| xnox | cp: cannot stat ‘/boot/initrd.img-4.4.0-6-generic’: No such file or directory | 11:04 |
| xnox | Failed to copy /boot/initrd.img-4.4.0-6-generic to /initrd.img at /var/lib/dpkg/info/linux-image-4.4.0-6-generic.postinst line 745. | 11:04 |
| xnox | dpkg: error processing package linux-image-4.4.0-6-generic (--configure): | 11:04 |
| xnox | apw, on amd64.... | 11:04 |
| cpaelzer | infinity: yeah talked this morning with piiti and jamespage and skipping them was what was decided | 11:04 |
| cpaelzer | infinity: we talked about the flavour used for autopackagetest very briefly, and as soon as that might be changed the test would run as-is again without further upload needed | 11:05 |
| cpaelzer | infinity: but we didn't consider changing the flavour an immediate task like "for today" | 11:05 |
| xnox | $ ls -latr /initrd.img | 11:05 |
| xnox | -rw-r--r-- 1 root root 0 Jan 31 13:21 /initrd.img | 11:05 |
| infinity | cpaelzer: *nod* | 11:05 |
| xnox | which is well aweful. | 11:06 |
| xnox | apw, ^ | 11:06 |
| cpaelzer | infinity: but you are right, I guess no one would have driven that - I'll write down a note to send a mail to the mailing list about it | 11:06 |
| infinity | xnox: Where did that root filesystem come from? | 11:06 |
| doko | ahh, that's LP: #1539903 | 11:06 |
| ubottu | Launchpad bug 1539903 in tomcat8 (Ubuntu) "tomcat-8 in main for upcoming 16.04 LTS" [Low,Fix committed] https://launchpad.net/bugs/1539903 | 11:06 |
| xnox | infinity, that's just my xenial laptop.... fairely normal install with full disk encryption. but otherwise mostly harmless. | 11:07 |
| apw | xnox, what sort of image is that | 11:07 |
| infinity | xnox: We've seen this on curtin installs, IIRC, where initrd is a file instead of a symlink. | 11:07 |
| infinity | xnox: Oh, that was just installed with ubiquity or d-i, then? | 11:07 |
| apw | and when installed | 11:07 |
| xnox | infinity, i did d-i, cause wanted to keep my windows 10. | 11:07 |
| * xnox checks | 11:08 | |
| infinity | xnox: link_in_boot = yes? | 11:08 |
| apw | infinity, i am starting to think i have to just remove these if they are the wrong type, there are just too many of them | 11:08 |
| xnox | infinity, link_in_boot = no | 11:08 |
| infinity | Oh, that's not link_in_boot, you said / | 11:08 |
| xnox | $ cat media-info | 11:08 |
| xnox | Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160125) | 11:08 |
| * infinity wonders why he's not actually seen this failure mode yet. | 11:08 | |
| apw | infinity, i don't see how link_in_boot matters, i htink we only notice that there because curtain is making a mess in /boot and you don't notice it if you arn't link_in_boot because there is no name clash | 11:08 |
| apw | infinity, me too | 11:09 |
| xnox | well has ubuntu desktop now, also i noticed that it was lacking "quiet splash" -> which i had to fix manually. Do servers not default to quiet & spalsh, btw? | 11:09 |
| infinity | xnox: Servers default to noisy, I believe. | 11:09 |
| xnox | ok. | 11:09 |
| apw | infinity, i assume a d-i install is simply a install linux-generic and let the normal mechanics make a mess | 11:10 |
| infinity | apw: Quite. | 11:10 |
| xnox | apw, i wonder if we should make kernel scripts more resiliant "this is a file, not symlink => purge" before doing anything. | 11:10 |
| infinity | d-i would definitely never be putting a regular file there. | 11:10 |
| apw | infinity, so this has somehow to be either an initramfs-tools or postinst issue | 11:10 |
| xnox | cause this ended up failing to upgrade kernle, and generate apport popup | 11:10 |
| xnox | but that's a bandaid. | 11:10 |
| infinity | apw: Yeahp, it's going to either be initramfs-tools or linux-image.postinst | 11:11 |
| xnox | cause we still don't know who or what is making a mess. | 11:11 |
| apw | xnox, making the postinst resilient would be trivial i am sure, but we have at least two different mess makers out there | 11:11 |
| apw | xnox, and i am loath to let them get away with it | 11:11 |
| apw | xnox, i will finish what i am at, and try and do a server install in a vm and see if it goes wrong too | 11:11 |
| apw | though of course the last milestone should have failed dismally if that was the case | 11:12 |
| xnox | apw, infinity https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547471 | 11:13 |
| ubottu | Launchpad bug 1547471 in linux (Ubuntu) "package linux-image-4.4.0-6-generic 4.4.0-6.21 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] | 11:13 |
| infinity | cpaelzer: Uploaded. | 11:15 |
| cpaelzer | infinity: thanks++, I'll check excuses and such after lunch | 11:16 |
| infinity | tseliot: Can you verify https://bugs.launchpad.net/ubuntu/+source/fglrx-installer/+bug/1518958 so we can push those both to updates? | 11:18 |
| ubottu | Launchpad bug 1518958 in fglrx-installer-updates (Ubuntu Trusty) "SRU Request: fglrx-installer: dkms build failures with linux-lts-wily" [High,Fix committed] | 11:18 |
| tseliot | infinity: sure, can you approve my nvidia-361 (and -updates) in Xenial NEW, please? | 11:19 |
| infinity | tseliot: Not tonight, it's past 3am, but we'll get there soon. | 11:20 |
| tseliot | ok | 11:20 |
| infinity | cpaelzer: Of course, openvswitch-dpdk is now FTBFS: http://paste.ubuntu.com/15130205/ | 11:25 |
| infinity | cpaelzer: Have fun. :P | 11:25 |
| infinity | cpaelzer: Definitely looks like libdpdk.so is underlinkes. | 11:26 |
| infinity | s/underlinkes/underlinked/ | 11:27 |
| infinity | cpaelzer: http://paste.ubuntu.com/15130215/ < -- You should aim to clear all that up. | 11:27 |
| infinity | At least missing -ldl and -lm... And one or two others I can't immediately identify. | 11:28 |
| === _salem is now known as salem_ | ||
| cpaelzer | infinity: it is statically linked atm which is a bug #1546550 on its own | 11:47 |
| ubottu | bug 1546550 in openvswitch-dpdk (Ubuntu) "openvswitch-switch-dpdk links against libdpdk statically" [Medium,Triaged] https://launchpad.net/bugs/1546550 | 11:47 |
| cpaelzer | infinity: there goes my dream that this would have been simple, I'll look into it | 11:47 |
| doko | willcooke, seb128: what's the goal with the libvdpau / libvdpau-va-gl component mismatch? asking because I'm assing to the vdpau-video and intel-vaapi-driver MIRs | 11:48 |
| cpaelzer | infinity: I wonder why that didn't show up in my sbuild | 11:49 |
| infinity | cpaelzer: Which bit? The underlinked stuff? It probably did show up and you didn't notice. It's not fatal. | 11:49 |
| infinity | cpaelzer: Unless you mean a test build of openvswitch-dpdk, which I can only assume you did against the old dpdk by accident. | 11:49 |
| cpaelzer | infinity: I wonder why that didn't show up in my sbuild openvswitch-dpdk, which is why I built against it | 11:50 |
| cpaelzer | infinity: I guess they meet in proposed | 11:50 |
| cpaelzer | infinity: and fail there | 11:51 |
| cpaelzer | infinity: jamespage has already the 2.5 ready (so do I), so I'll patch&test his last 2.5 now | 11:51 |
| infinity | cpaelzer: The bug isn't in openvswitch, though, it's in dpdk. | 11:52 |
| willcooke | tjaalton, any thoughts on doko's query? ^ | 11:52 |
| infinity | cpaelzer: dpdk.so should be linked to all the libs it uses. | 11:52 |
| tjaalton | doko,willcooke: no idea, one got promoted before? | 11:54 |
| doko | tjaalton, what do you mean? | 11:56 |
| tjaalton | doko: willcooke forwarded the question to me.. | 11:57 |
| doko | tjaalton, well libvdpau is in main since 2010 ... https://bugs.launchpad.net/ubuntu/+source/libvdpau/+bug/506788 | 11:58 |
| ubottu | Launchpad bug 506788 in libvdpau (Ubuntu) "[MIR] libvdpau" [High,Fix released] | 11:58 |
| tjaalton | what was the question about? the other one is a separate source | 11:58 |
| doko | tjaalton, component mismatch, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg not sure we want ffmpeg in main | 11:59 |
| tjaalton | hasn't ffmpeg replaced libav on ubuntu too? | 12:00 |
| tjaalton | please be so | 12:00 |
| doko | feel free to file these 30 MIRs for ffmpeg | 12:00 |
| tjaalton | heh | 12:01 |
| tjaalton | i thought it happened in wily | 12:01 |
| tjaalton | guess not | 12:01 |
| tjaalton | seb128: ^ | 12:01 |
| davmor2 | tjaalton: Package: ffmpeg Version: 7:2.8.4-1ubuntu3 Priority: optional Section: universe/video | 12:06 |
| doko | lamont, https://launchpadlibrarian.net/240544779/buildlog_ubuntu-xenial-amd64.isc-dhcp_4.3.3-5ubuntu6_BUILDING.txt.gz | 12:13 |
| doko | wanting to link: LDFLAGS="-lirs-export", was in libbind-export-dev | 12:14 |
| tjaalton | doko: what's the libva MIR? | 12:19 |
| doko | tjaalton, there's none yet (if you click on the svg file, then it wants to open one) | 12:21 |
| tjaalton | doko: ahh, but libvdpau wants to pull in -va-gl? | 12:22 |
| doko | tjaalton, yes | 12:23 |
| tjaalton | ok then | 12:24 |
| doko | lamont, how to proceed? libirs isn't shipped by bind, and isc-dhcp has the bind subdir removed | 12:28 |
| doko | lamont: looks like we need a correspondeing isc-dhcp 4.3.4? to be released on March 29? | 12:32 |
| bluesabre | Laney: can you run the packageset generation script? We have make some changes to shimmer-themes (with Kubuntu's permisssion) and the package should now appear in the xubuntu packageset again | 12:32 |
| Laney | ok | 12:33 |
| tjaalton | doko: that's only because libvdpau-va-gl Provides: vdpau-driver? | 12:35 |
| tjaalton | and should be fixed if libvdpau1 didn't Recommend vdpau-driver | 12:37 |
| doko | tjaalton, but vdpau-driver-all still depends on libvdpau-va-gl1 | 12:39 |
| tjaalton | ah | 12:40 |
| tjaalton | suggests then | 12:40 |
| seb128 | doko, tjaalton, I've no idea about ffmpeg vs libav, we should probably follow debian | 12:40 |
| tjaalton | does that Recommend matter btw? guess not since vdpau-driver is virtual | 12:41 |
| tjaalton | seb128: yeah, probably too late though | 12:41 |
| seb128 | :-/ | 12:41 |
| tjaalton | amazing noone noticed before :) | 12:41 |
| doko | seb128, we don't have libav anymore | 12:41 |
| tjaalton | good | 12:42 |
| tjaalton | I guess we never had libav provided stuff in main, so it's fine | 12:46 |
| seb128 | tjaalton, we had in precise according to https://launchpad.net/distros/ubuntu/+source/libav | 12:47 |
| tjaalton | seb128: ah, so it seems | 12:50 |
| rbasak | nacc_, jamespage: looks like a new tomcat7 microrelease went into Debian yesterday but didn't make our freeze. Worth a manual sync? | 12:54 |
| rbasak | There are new build deps, but given freeze was yesterday the release team may be OK with it. | 12:54 |
| seb128 | lamont, https://errors.ubuntu.com/problem/ff29324d627eef6e11b0e8b37e37b3f645e6ea9c seems a new issue (but lacks symbols/not very useful so) | 12:59 |
| seb128 | bdmurray, ^ do you have any idea why that retracing fails? | 12:59 |
| === lucas_ is now known as lucas | ||
| tseliot | infinity: all tested | 13:07 |
| tjaalton | doko: libvdpau fixed, hopefully | 13:08 |
| slangasek | nacc_: fyi, started looking at <2> on https://launchpadlibrarian.net/238303205/php7-archive-admins.howtov4 ; php-zeta-base is listed as only needing a rebuild, but it fails to build with an error in phpunit, possibly because it gained a phpunit build-dep in the 1.9-2 upload? | 13:13 |
| === ackkk is now known as ackk | ||
| cpaelzer | infinity: FYI I sorted out with jamespage to get the fix to openvswitch-dpdk (that we already had in ppas) combined with my fix | 13:37 |
| cpaelzer | infinity: the issue you pointed out is still an issue on its own and worked on in #1547517 | 13:37 |
| cpaelzer | infinity: thanks | 13:38 |
| cpaelzer | should have written bug #1547517 to get the bot posting the right link | 13:38 |
| ubottu | bug 1547517 in dpdk (Ubuntu) "libdpdk should link against the library it uses" [Low,Triaged] https://launchpad.net/bugs/1547517 | 13:38 |
| jamespage | cpaelzer, just testing both ovs and ovs-dpdk with a snapshot from the 2.5 branch (which is in release stabilization right now) | 13:44 |
| jamespage | and then I'll upload | 13:44 |
| * dholbach hugs pitti | 13:54 | |
| jamespage | cpaelzer, ok - both uploaded - tested fine | 13:55 |
| lamont | seb128: Sorry, you are not a member of a group that is allowed to see the data from error reports. Please fill out this form to request access. | 13:55 |
| lamont | seb128: and I have no idea what I'm requesting access to in order to request it... care to smack things over the head as needed? | 13:58 |
| seb128 | lamont, bdmurray can probably help there | 13:58 |
| seb128 | lamont, it's a segfault which started with the recent xenial update but the retracing fail for some reason so there is no debug symbol so not useful anyway until we get that resolved | 13:59 |
| cpaelzer | jamespage: thanks, I'm happy that both changes go along well | 14:01 |
| * cpaelzer touches all kind of wood to leave update_excuses now | 14:01 | |
| lamont | seb128: segfault in what? | 14:04 |
| lamont | doko: we may just need to deliver libirs? not sure? | 14:05 |
| seb128 | lamont, http://paste.ubuntu.com/15131566/ | 14:05 |
| lamont | but yes, I suspect that we want to at least consider getting 4.3.4 dhcp for xenial | 14:05 |
| lamont | seb128: hrmpf... which version of bind? /me suspects 3ubuntu1 | 14:06 |
| seb128 | lamont, in fact we have a bug with a retracing it seems | 14:06 |
| seb128 | lamont, reports are from 1:9.10.3.dfsg.P2-3~build3 and 1:9.10.3.dfsg.P2-3~ubuntu1 | 14:07 |
| lamont | those are the best, yes? :( | 14:07 |
| seb128 | lamont, | 14:07 |
| seb128 | talloc_abort_unknown_value () at ../talloc.c:417 | 14:07 |
| seb128 | talloc_chunk_from_ptr (ptr=0x7f1504003140) at ../talloc.c:436 | 14:07 |
| seb128 | _talloc_free (ptr=0x7f1504003140, location=0x7f152192e888 "../common/ldb.c:289") at ../talloc.c:1625 | 14:07 |
| seb128 | ldb_asprintf_errstring (ldb=ldb@entry=0x7f151c226010, format=format@entry=0x7f150adfe4b7 "No such Base DN: %s") at ../common/ldb.c:289 | 14:07 |
| lamont | do we hvae the named.conf files from that trace? | 14:07 |
| * lamont needs to step away for a few, but will look when he's back online in 20 or so | 14:08 | |
| seb128 | lamont, I don't think so, apport doesn't seem to have a hook to include that info | 14:08 |
| lamont | seb128: if you can ask the submitter for it, that may help isolate things. | 14:09 |
| lamont | afk | 14:09 |
| seb128 | k | 14:09 |
| doko | lamont, yeah, fixing ... cyphermox told me the same | 14:10 |
| doko | pitti, looks like the gnutls transition is blocked on systemd | 14:11 |
| doko | ginggs, cuda doesn't migrate, missing dependency. see excuses_html | 14:14 |
| ginggs | doko: i saw that, needs nvidia driver for ppc64el, -3 not much different to -2ubuntu1 | 14:16 |
| ginggs | doko: i was talking to tseliot about creating an nvidia-tesla-drivers package for ubuntu - neither of us have ppc64el hardware with a gpu for testing | 14:17 |
| ginggs | doko: and we are working on cuda 7.5 packaging in debian, so hope to have that ready soon | 14:18 |
| === juliank_ is now known as juliank | ||
| dobey | who is our xrandr expert these days? | 14:27 |
| seb128 | I don't think we have one | 14:28 |
| seb128 | you can try tjaalton or robert_ancell | 14:28 |
| seb128 | or maybe the mir team has people knowing about xrandr as well | 14:28 |
| dobey | tjaalton: around? :) | 14:34 |
| tjaalton | dobey: one foot only | 14:35 |
| tjaalton | so be quick :) | 14:35 |
| dobey | tjaalton: oh ok. i don't know if this would be quick. i'm wondering if there's some way to "fake" xinerama-like setup with xrandr on intel, using the VIRTUAL1 output to wrap the actual DP1-X outputs | 14:35 |
| tjaalton | doesn't sound too quick, no :) | 14:37 |
| tjaalton | what are you trying to do? | 14:37 |
| tjaalton | i mean, why fake-xinerama | 14:37 |
| dobey | tjaalton: i have a 4k display, and only way to get 60Hz is MST, and intel treats it as two completely separate monitors :-/ | 14:38 |
| tjaalton | ah | 14:39 |
| tjaalton | yeah no experience with that, but I bet you're not the only one | 14:40 |
| tjaalton | which cpu? | 14:40 |
| dobey | i7 4790S | 14:40 |
| tjaalton | haswell, might work | 14:40 |
| tjaalton | skylake doesn't | 14:40 |
| tjaalton | so if google doesn't help, I can dig something next week | 14:41 |
| dobey | i guess good thing i didn't upgrade yet then | 14:41 |
| tjaalton | same here (to 4k :) | 14:41 |
| dobey | yeah, searching hasn't been productive so far | 14:41 |
| dobey | i've been stuck at 30Hz for far too long | 14:41 |
| tseliot | they implemented RRMonitors exactly for that, IIRC | 14:44 |
| tseliot | the window manager needs to support that though, I think | 14:45 |
| dobey | tseliot: so we need to fix compiz? | 14:47 |
| tseliot | dobey: that, and the new X https://cgit.freedesktop.org/xorg/proto/randrproto/tree/randrproto.txt?id=randrproto-1.5.0 | 14:47 |
| dobey | tseliot: so i can't make this work until 16.04? | 14:48 |
| tseliot | dobey: exactly | 14:48 |
| dobey | tseliot: is compiz fixed in 16.04? | 14:49 |
| tseliot | dobey: not yet | 14:49 |
| dobey | tseliot: will it be? | 14:49 |
| tseliot | dobey: maybe ask the maintainers? | 14:50 |
| tseliot | right now the new X breaks hybrid graphics because of the new RandR, so that should be fixed | 14:51 |
| dobey | tseliot: is there no way to use the VIRTUAL1 output in older xorg to redirect the monitors to a single display? | 14:53 |
| tseliot | dobey: not that I know. You can still ask in #intel-gfx or in #xorg-devel | 14:55 |
| dobey | ok | 14:56 |
| tseliot | dobey: on a second thought, simply rebuilding gtk with RandR 1.5 support might work: https://git.gnome.org/browse/gtk+/commit/?id=e670720d196bac1cef6f88313f6514cdd8c4a0c5 | 15:06 |
| dobey | tseliot: would still need 16.04 for the new X, but hopefully that gtk+ patch will be included. i wonder if anything special will need to be done from chromium/etc though. | 15:08 |
| tseliot | dobey: it turns out the code is already there. Support in X was missing. Maybe you can try the PPA for Xenial? | 15:11 |
| tseliot | but again, that comes with bugs: https://bugs.launchpad.net/gtk/+bug/1547510 | 15:12 |
| ubottu | Launchpad bug 1547510 in GTK+ "display scaling doesn't work with xserver 1.18" [Medium,Confirmed] | 15:12 |
| dobey | tseliot: well, i don't use display scaling, so i guess i'll be fine there :) | 15:15 |
| tseliot | dobey: ok, here's the ppa https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging | 15:16 |
| dobey | tseliot: but i don't think i want to upgrade to xenial yet :) | 15:17 |
| tseliot | fair enough | 15:17 |
| dobey | tseliot: but i'll keep all this in mind when i do. thanks! :) | 15:23 |
| === bladernr_ is now known as bladernr | ||
| nacc | pitti: sigh, so last night we might have realized that bootstrapping is altogether unnecessary | 15:59 |
| nacc | pitti: meaning we can drop all these deltas | 15:59 |
| nacc | pitti: i'll fix up my side to make sure there isn't trailing space, sorry! | 16:01 |
| nacc | pitti: i learned about the lp tasks thing only after starting, now i'm doing that :) | 16:02 |
| Son_Goku | nacc: did my patches help with the tests? | 16:02 |
| nacc | rbasak: jamespage: i'll try and look at tomcat7 | 16:03 |
| nacc | slangasek: will look at php-zeta-base now | 16:03 |
| nacc | Son_Goku: about to kick them off again now | 16:03 |
| Son_Goku | awesome | 16:03 |
| doko | apw, tjaalton: please see https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1075780 is this something which should get promoted? | 16:18 |
| ubottu | Launchpad bug 1075780 in intel-vaapi-driver (Ubuntu) "[MIR] intel-vaapi-driver" [Wishlist,Confirmed] | 16:18 |
| Laney | xnox: could you send a second cfn for the dmb please? | 16:19 |
| nacc | Son_Goku: is it just me or should your patches be numbered 48 and 49? | 16:33 |
| nacc | Son_Goku: that is, the php7.0 src seems to have all the old php5 patches in it still? | 16:33 |
| Son_Goku | nacc: it should cleanly apply on top of php7.0 src on master-7.0 branch | 16:33 |
| Son_Goku | these are patches that apply to the debian git itself | 16:34 |
| Son_Goku | they don’t go into debian/patches | 16:34 |
| Son_Goku | nacc: they apply on top of this: http://anonscm.debian.org/cgit/pkg-php/php.git/log/?h=master-7.0 | 16:35 |
| lamont | ta | 16:36 |
| lamont | bah | 16:36 |
| nacc | Son_Goku: oh ... that's not as helpful for me to test (and is also not what adt is testing); can you spin patches that apply on top of the src package | 16:37 |
| Son_Goku | debian/patches stuff don’t work for fixing tests | 16:38 |
| nacc | Son_Goku: good point | 16:38 |
| Son_Goku | nacc: an easy way to apply them is to expand your source tree, initialize with git, and then do “git am </path/to/patches/in/order.patch>” to apply them | 16:39 |
| Son_Goku | then repack and rebuild | 16:39 |
| Son_Goku | nacc: I could just go ahead and send them to Ondrej anyway | 16:40 |
| nacc | pitti: re: https://launchpad.net/ubuntu/+source/phpunit/5.1.3-1+ubuntu1/+build/9036792 -- i don't see a segfault? | 16:40 |
| nacc | pitti: but the issue is probably the one i mentioned in the xdebug bug | 16:40 |
| === thegodfather is now known as fabbione | ||
| nacc | Son_Goku: ok, got it, rebuilding php7.0 now to test locally | 16:48 |
| Son_Goku | awesome | 16:48 |
| lamont | seb128: happily? that trace is against 9.9.5, so it's not related to my most recent mess^Wupload | 16:58 |
| doko | seb128, Laney: if not seen ... gnome-software doesn't build because of a component mismatch | 16:59 |
| pitti | nacc: oh, seems someone retried the test and it's working now, so apparently it happens only sometimes | 17:02 |
| pitti | nacc: twig still has a segfault; I can retry too if you think that's useful | 17:03 |
| nacc | pitti: testing it now here | 17:04 |
| nacc | pitti: will let you know | 17:04 |
| nacc | pitti: it's possible the new xdebug went in in between? | 17:04 |
| nacc | pitti: hrm, reproduced the twig segfault, debugging it now | 17:04 |
| doko | nacc, remove firebird from b-d's if not yet done | 17:04 |
| pitti | php7.0 lost its firebird dep today | 17:05 |
| nacc | doko: that's done for php7.0 | 17:05 |
| doko | ta | 17:05 |
| Laney | doko: it has an approved MIR and was previously in main | 17:05 |
| seb128 | doko, it built before and control didn't change, appstream needs to be promoted back | 17:05 |
| doko | I didn't demote it ... | 17:05 |
| nacc | pitti: can you tell me why component-mismatches says php7.0 has a dep on xmlrpc-epi? we dropped it via LP #1547245 ? | 17:05 |
| ubottu | Launchpad bug 1547245 in php7.0 (Ubuntu) "php7.0: remove dependencies that come from universe" [Undecided,Fix committed] https://launchpad.net/bugs/1547245 | 17:05 |
| seb128 | doko, I guess it was not promoted, sorry, but it has a MIR approved so it can be | 17:06 |
| Laney | https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1538293/comments/8 | 17:06 |
| ubottu | Launchpad bug 1538293 in appstream (Ubuntu) "[MIR] appstream" [Undecided,Fix released] | 17:06 |
| pitti | nacc: supposedly the new version is still in -proposed, so it sees the one in ubuntu-release? | 17:06 |
| pitti | seb128: an approved MIR isn't sufficient -- you need something in main to depend on it | 17:06 |
| nacc | pitti: ah ha! | 17:06 |
| nacc | pitti: thanks :) sorry, some obvious stuff isn't so obvious to me still :) | 17:06 |
| pitti | seb128: otherwise it's on component-mismatches and archive admins demote it back | 17:06 |
| seb128 | pitti, right, which is what doko is pointing, gnome-software is deptwaiting on it | 17:06 |
| seb128 | but it was probably on component-mismatch for a week or so | 17:07 |
| doko | seb128, well, I even pasted the commit message | 17:07 |
| seb128 | before gnome-software got promoted | 17:07 |
| doko | infinity, did you demote packages this week? | 17:07 |
| seb128 | doko, right, I guess it was demoted in between | 17:07 |
| doko | anyway, promoting | 17:07 |
| infinity | doko: Nope. | 17:07 |
| Laney | I don't see that it got promoted on +publishinghistory | 17:07 |
| Laney | https://launchpad.net/ubuntu/+source/appstream/+publishinghistory | 17:07 |
| Laney | so, not sure what happened before | 17:08 |
| nacc | pitti: also, i *think* the php-defaults -> dh-php5 dep is a false positive. Because php-json used to be its own src package, but now is a binary package produced by php-defaults | 17:08 |
| nacc | and we're going to drop the old src package | 17:08 |
| seb128 | doko, thanks | 17:09 |
| seb128 | doko, could you have a look to bug #1513922? gdb/python is buggy on i386, the attached patch fixes it | 17:09 |
| ubottu | bug 1513922 in gdb (Ubuntu) "[xenial] backtrace gives python error" [High,New] https://launchpad.net/bugs/1513922 | 17:10 |
| doko | I think I should promote tomcat8 now | 17:10 |
| nacc | pitti: finally, thank you for all your help. I really appreciate it! | 17:10 |
| infinity | lamont: Your bind9 udebs are uninstallable (depend on debs, due to new deps that aren't udebby) | 17:10 |
| xnox | pitti, ppc64el are all dead? | 17:11 |
| lamont | infinity: awesome. | 17:11 |
| * lamont adds that to the list for -4 | 17:11 | |
| xnox | pitti, could you hint through juju-core? passed everywhere apart from blocked up ppc64el, and we need it for the demo today... | 17:12 |
| lamont | Depends: ${shlibs:Depends}, ${misc:Depends} | 17:12 |
| lamont | Package-Type: udeb | 17:12 |
| lamont | dammit, I liked using the variables | 17:12 |
| infinity | lamont: Yeah, it's not a bug in your package. | 17:12 |
| infinity | lamont: Except for the part where you're linking libs that aren't udebs. | 17:12 |
| infinity | lamont: It's not debian/control that needs fixing, it's either the other packages that need udebs, or your udeb build of your libs need to have fewer features. | 17:13 |
| infinity | libdns162-udeb : Depends: libgeoip1 but it is not installable | 17:13 |
| infinity | Depends: libgssapi-krb5-2 but it is not installable | 17:13 |
| infinity | Depends: libkrb5-3 but it is not installable | 17:13 |
| lamont | oh | 17:13 |
| doko | pitti, is systemd: autopkgtest for linux 4.4.0-6.21 really a regression? | 17:14 |
| infinity | libxml2-udeb seems broken too, for some reason. Oh, how I love feature freeze. | 17:14 |
| smoser | is anyone else seeing apt 503 from security.ubuntu.com ? | 17:15 |
| seb128 | lamont, unsure, maybe the launchpad report is not the same, the e.u.c are no useful info, I guess we need bdmurray or somebody to tell us why the retracing is not working and get that fixed, then we get more info about the issue | 17:15 |
| lamont | seb128: ack | 17:15 |
| lamont | infinity: looks like I may need to reintroduce the export build/ | 17:15 |
| doko | lamont, ugh, why? how many packages need fixing? | 17:16 |
| doko | seb128, on my list | 17:16 |
| pitti | xnox: they will auto-cleanup/restart in an hour, but I restarted them now | 17:16 |
| lamont | doko: I can't see needing libgeoip in d-i | 17:16 |
| lamont | OTOH, well. | 17:16 |
| bdmurray | seb128: I'm trying to look at it but the Error Tracker is having some issues at the moment | 17:17 |
| nacc | pitti: i think the symfony build goes now (if you add -proposed, where the nwe version of php-proxy-manager is), but that breaks the unit tests ... i'll see if i can fix those up now | 17:17 |
| lamont | the nice part is that libdns is the boottom of the pile, so it's just those 3 | 17:17 |
| seb128 | bdmurray, hey! ok, thanks | 17:17 |
| seb128 | doko, thanks! | 17:17 |
| bdmurray | seb128: what package was the crash about? | 17:17 |
| seb128 | bdmurray, bind9 | 17:18 |
| xnox | pitti, well, something is/was odd with them. As e.g. slowest armhf passed juju-core 4 hours ago, and it was available for testing 5 hours ago. | 17:18 |
| bdmurray | seb128: IIRC that's missing ddebs | 17:18 |
| pitti | xnox: hinted juju | 17:19 |
| seb128 | bdmurray, I though that missing ddebs was deprecated now that those are in launchpad? | 17:19 |
| bdmurray | seb128: but there aren't any in LP either | 17:19 |
| seb128 | https://launchpad.net/ubuntu/+source/bind9/1:9.10.3.dfsg.P2-3~ubuntu1 lists some though | 17:20 |
| xnox | seb128, depends. if things were copied from PPAs with bad config, there might not be any ddebs. | 17:20 |
| pitti | doko: no, systemd for anything else than the systemd update itself is not a regression; we need to land the new systemd to fix the ppc64el test, but that's blocked on gnutls | 17:20 |
| seb128 | https://launchpad.net/ubuntu/xenial/amd64/bind9-host-dbgsym/1:9.10.3.dfsg.P2-3~ubuntu1 | 17:20 |
| pitti | doko: systmed/ppc64el has a hint, though | 17:20 |
| seb128 | xnox, bind9 is an archive upload and the launchpad build record have them | 17:20 |
| xnox | seb128, but that package version is superseeded in -proposed. | 17:20 |
| xnox | .... so garbage collected. | 17:20 |
| doko | pitti, but the linux test in systemd is blocking gnutls28 ... | 17:21 |
| pitti | doko: oh, *this* way around | 17:21 |
| bdmurray | seb128: that's only the -proposed package version | 17:22 |
| seb128 | xnox, right, the retracings are from previous days when that was not the case | 17:22 |
| seb128 | bdmurray, well the issues are only with proposed versions | 17:22 |
| pitti | no, that just looks flaky, it's a failure in apparmor | 17:22 |
| cjwatson | xnox: binary GC is much much less aggressive than that. | 17:23 |
| pitti | doko: hinted | 17:23 |
| pitti | ok, gotta run, cu on Monday | 17:23 |
| bdmurray | seb128: okay, I'll have a look when errors comes back | 17:23 |
| seb128 | bdmurray, thanks | 17:23 |
| seb128 | pitti, have a good w.e! | 17:23 |
| xnox | cjwatson, ok. | 17:28 |
| jtaylor | doko: thanks for the vim-py2 :D | 17:29 |
| doko | jtaylor, otoh this one upstream proposed a py3 compatible package | 17:30 |
| jtaylor | doko: you mean youcompleteme? | 17:31 |
| doko | yes | 17:31 |
| doko | or IcompleteYou | 17:31 |
| jtaylor | doko: thats one of many, also I'm not using the package | 17:31 |
| Pharaoh_Atem | nacc: so how are the tests going? | 17:36 |
| pitti | xnox: FTR, ppc64el machines are getting serial-killed by some test in trusty: | 17:39 |
| pitti | E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/e/eglibc/libc-dev-bin_2.19-0ubuntu6.6_ppc64el.deb 404 Not | 17:39 |
| pitti | +Found | 17:39 |
| pitti | this counts as temporary failure and thus they retry | 17:39 |
| pitti | I didn't look into that yet | 17:39 |
| Laney | Something is going wrong with the apt update | 17:40 |
| cjwatson | Yeah, latest version is 2.19-0ubuntu6.6 | 17:40 |
| cjwatson | Er, 6.7 | 17:40 |
| cjwatson | pitti: Do you have output from the apt update? | 17:40 |
| nacc | Pharaoh_Atem: still building php7.0 :) it's a bit big to get to all the .debs | 17:41 |
| Pharaoh_Atem | yeah, I know :/ | 17:41 |
| nacc | Pharaoh_Atem: will ping you as soon as they are going | 17:41 |
| Pharaoh_Atem | nacc: awesome | 17:45 |
| infinity | lamont: PS: This is blocking d-i, which is blocking the kernel, so ick. | 17:46 |
| nacc | Pharaoh_Atem: kicking off the tests now | 17:46 |
| Pharaoh_Atem | :D | 17:47 |
| lamont | infinity: ack | 17:49 |
| jtaylor | infinity: I hope feature freeze does not mean no glibc update anymore? | 18:07 |
| jtaylor | is there something I can do to help? | 18:09 |
| nacc | Pharaoh_Atem: ok, mod-php tests fixed, but fpm still fails | 18:18 |
| nacc | Pharaoh_Atem: is it possibly due to not restarting apache2? i really don't know much about what's ahppening, but see this line: | 18:19 |
| nacc | "To activate the new configuration, you need to run: service apache2 restart | 18:19 |
| Pharaoh_Atem | hmm | 18:20 |
| Pharaoh_Atem | the fpm test does have an apache2 restart call | 18:21 |
| nacc | Pharaoh_Atem: ok | 18:22 |
| Pharaoh_Atem | nacc: do you have the output from the fpm test? | 18:23 |
| nacc | Pharaoh_Atem: no ... running again to get it | 18:32 |
| === dx- is now known as dx | ||
| Pharaoh_Atem | nacc: thank you | 18:34 |
| infinity | jtaylor: I fully intend to break my own freeze, I got stuck at a sprint this week, so I'm delayed a tad. | 18:38 |
| rbasak | If a conffile is renamed, is the old name supposed to still show as obsolete in "dpkg -s"? If not, then what's the mechanism dpkg uses to make it not appear there? | 18:45 |
| * rbasak goes afk, but will see replies in the next hour or two but will be offline for the weekend after that | 18:52 | |
| teward | who was working on php7 again...? I forget, and I probably should know by now :P | 18:54 |
| sarnold | teward: nacc | 18:55 |
| teward | thank you :) | 18:55 |
| teward | nacc: ping, if you're not busy, regarding php7 and fpm | 19:02 |
| teward | nacc: With regards to php7 and fpm, php5 had the defaults, in Debian, to listen on a UNIX socket by default; has this been evaluated as a comparison to listening on a UNIX socket, and which way is implemented in php7.0-fpm for Xenial? | 19:04 |
| teward | depending on the answer there, I may or may not have to modify the default nginx configuration files to adapt | 19:04 |
| * teward should have checked this before but forgot | 19:04 | |
| Pharaoh_Atem | teward: it's set to use a Unix socket now | 19:05 |
| teward | Pharaoh_Atem: i'm looking at the package in proposed and don't see that, if you can point me at where that change was done? | 19:06 |
| Pharaoh_Atem | with php7.0, it uses a Unix socket by default because httpd 2.4.10 and newer supports using a Unix socket through mod_proxy_fcgi | 19:06 |
| teward | ahhh, okay | 19:06 |
| Pharaoh_Atem | Debian 8 includes httpd 2.4.12, and Ubuntu 16.04 LTS includes a newer version | 19:07 |
| teward | Pharaoh_Atem: do you know what path it's using for the Unix socket? So I can update the nginx default configuration, after I check to make sure it doesn't need an FFe :P | 19:07 |
| Pharaoh_Atem | teward: yes | 19:07 |
| * Pharaoh_Atem wrote the new httpd php-fpm config, so he figured all this out | 19:07 | |
| Pharaoh_Atem | the path is /run/php/php@PHP_VERSION@-fpm.sock | 19:07 |
| Pharaoh_Atem | with @PHP_VERSION@ being replaced dynamically with the correct version number (7.0 in this case) | 19:08 |
| teward | ah, wonderful, now I know what I need to change :) thank you and nacc for your work on it :) | 19:08 |
| Pharaoh_Atem | no problem | 19:08 |
| nacc | Pharaoh_Atem: thanks for helping out | 19:11 |
| Pharaoh_Atem | no problem | 19:11 |
| nacc | Pharaoh_Atem: still trying to figure out why fpm is failing, no logs produces that say exactly why | 19:11 |
| Pharaoh_Atem | that's frustrating | 19:11 |
| nacc | Pharaoh_Atem: just a non-zero exit status | 19:11 |
| Pharaoh_Atem | O.o | 19:12 |
| nacc | I *think* the tests are actually passing | 19:12 |
| Pharaoh_Atem | I think they are too | 19:12 |
| Pharaoh_Atem | because when I manually run them as normal scripts, it works correctly | 19:12 |
| nacc | Pharaoh_Atem: hrm, if the test returns false at the end | 19:14 |
| nacc | wont' it be RC=1? | 19:14 |
| nacc | Pharaoh_Atem: ok, i'm trying to reproduce it manually in a schroot | 19:18 |
| nacc | Pharaoh_Atem: couple of questions | 19:18 |
| nacc | a2enconf php7.0-fpm | 19:18 |
| nacc | ERROR: Conf php7.0-fpm does not exist! | 19:18 |
| nacc | is that expected? | 19:18 |
| nacc | also, dont' you need Depends: wget in the fpm test? (it wasn't installed by default in my schroot for instance) | 19:19 |
| Pharaoh_Atem | hmm | 19:21 |
| Pharaoh_Atem | it doesn't exist? | 19:21 |
| Pharaoh_Atem | that's... weird | 19:21 |
| nacc | hrm, i also get | 19:22 |
| nacc | a2disconf php7.0-cgi | 19:22 |
| nacc | ERROR: Conf php7.0-cgi does not exist! | 19:23 |
| Pharaoh_Atem | if it's not been enabled, it should say that, I think | 19:23 |
| nacc | ok | 19:24 |
| Pharaoh_Atem | so... it looks like my config file is not being installed | 19:24 |
| Pharaoh_Atem | that might be why it's not working | 19:25 |
| nacc | php7.0-fpm: /usr/lib/tmpfiles.d/php7.0-fpm.conf | 19:25 |
| Pharaoh_Atem | that's not the one I care about | 19:25 |
| nacc | there's no other php7.0-fpm.conf in the archive? | 19:26 |
| Pharaoh_Atem | there should be /etc/apache2/conf-available/php7.0-fpm.conf | 19:26 |
| Pharaoh_Atem | the sources have a php-fpm.apache2 file | 19:26 |
| nacc | php7.0-cgi: /etc/apache2/conf-available/php7.0-cgi.conf | 19:26 |
| nacc | php7.0-fpm: /usr/lib/tmpfiles.d/php7.0-fpm.conf | 19:26 |
| nacc | php7.0-fpm is busted? | 19:26 |
| Pharaoh_Atem | I think it's not installing the apache2 conf file | 19:26 |
| nacc | Pharaoh_Atem: it's not in the package | 19:27 |
| Pharaoh_Atem | but it is installing the tmpfiles conf file | 19:27 |
| nacc | Pharaoh_Atem: you should fix the fpm test to do the same checks as cgi | 19:27 |
| nacc | would tell us if that's the case pretty easily | 19:28 |
| Pharaoh_Atem | ah, yes | 19:28 |
| Pharaoh_Atem | ls | 19:28 |
| nacc | Pharaoh_Atem: and probably mod-php should be updated too :) | 19:29 |
| Pharaoh_Atem | hmm, good point | 19:29 |
| nacc | Pharaoh_Atem: ok, so if i manually put the src package's conf file in the right place a2enconf does work | 19:34 |
| Pharaoh_Atem | what am I missing to make it install correctly? | 19:36 |
| nacc | Pharaoh_Atem: not sure, but if i do that and then manually `service start php7.0-fpm`, the test works | 19:36 |
| nacc | Pharaoh_Atem: so those two bits are what is missing right now, afaict | 19:36 |
| Pharaoh_Atem | yeah | 19:37 |
| Pharaoh_Atem | well, I'm also adding the file checks to the tests | 19:37 |
| asper | hey folks. if i install xenial now. will i have to modify my apt-sources to get of the development branch, when it gets released? | 19:37 |
| Pharaoh_Atem | no | 19:37 |
| Pharaoh_Atem | it'll transition to release state automatically | 19:37 |
| Pharaoh_Atem | afaik, there's no actual devel branch maintained publicly? | 19:37 |
| asper | ok thanks. at least one good message today. :) | 19:38 |
| kyrofa | Can anyone explain why sid has sbcl for essentially every arch (https://packages.debian.org/sid/sbcl) and xenial only has it for amd64 and i386 (http://packages.ubuntu.com/xenial/sbcl)? | 19:38 |
| teward | kyrofa: fail to builds, it looks like | 19:39 |
| teward | oh, um, i read the wrong line ;) | 19:40 |
| teward | (disregard me) | 19:40 |
| kyrofa | teward, haha | 19:40 |
| kyrofa | I mean... the autosync should just pull them over, right? | 19:41 |
| teward | kyrofa: i will point out that packages.ubuntu.com is not the best source of information for what is and is not available in the repositories... | 19:41 |
| Pharaoh_Atem | teward: please don't tell me that | 19:41 |
| sarnold | e.g. here's a powerpc package.. https://launchpad.net/ubuntu/+source/sbcl/2:1.3.0-1ubuntu1/+build/8322187 | 19:41 |
| kyrofa | teward, understood, but it reflects what I'm seeing from arm64 at least | 19:41 |
| nacc | kyrofa: https://launchpad.net/ubuntu/+source/sbcl/ | 19:41 |
| teward | kyrofa: well, arm64 is stuck on depwait | 19:42 |
| nacc | kyrofa: you can see underneath the current xenial version | 19:42 |
| teward | on both the current and proposed | 19:42 |
| nacc | the builds and as teward just said | 19:42 |
| teward | https://launchpad.net/ubuntu/+source/sbcl/2:1.3.0-1ubuntu1 | 19:42 |
| teward | ^ that's what's in Xenial now (not proposed, which has FTBFS on all archs and depwait for arm64) | 19:42 |
| nacc | teward: is it just me or is that depwait never going to resolve? given the older versions of sbcl wasn't built for arm64? | 19:43 |
| nacc | Missing build dependencies: sbcl (> 1:0.9.5.50-9) | 19:43 |
| teward | nacc: no clue, sorry, i just happened to be poking launchpad.net looking at other things on my radar, when the question came in and i started poking at that one in LP | 19:44 |
| teward | nacc: probably won't ever resolve, though, no. | 19:44 |
| teward | though, given the thing's in Universe, i'm not 100% concerned | 19:44 |
| nacc | teward: sure, just wondering if that's normal | 19:44 |
| nacc | teward: looks to be a bootstrap-y situtation | 19:44 |
| nacc | *situation | 19:44 |
| teward | nacc: I've never seen it, but what I focus on specifically, myself, is very narrow | 19:44 |
| teward | so, that may be why i've never seen it :) | 19:45 |
| nacc | heh | 19:45 |
| teward | finally the thing accepts the bugfix only upload to fix the nginx default config issues that needed addressed due to php7.0 replacing php5 xD | 19:46 |
| kyrofa | nacc, teward is there a way to fix that? It's blocking me at the moment | 19:46 |
| nacc | kyrofa: is it expected for sbcl to need sbcl to build? is there a restricted build that can be done (staged build or so)? | 19:47 |
| robert_ancell | upload.ubuntu.com down? | 19:47 |
| robert_ancell | back again | 19:48 |
| kyrofa | nacc, heh, I have no clue. All I know is that it's a dependency of the code I'm trying to build | 19:48 |
| teward | robert_ancell: it looks like a delay is all | 19:48 |
| teward | finally came though for my upload heh | 19:48 |
| robert_ancell | teward, I was getting connection refused :( | 19:48 |
| teward | ah | 19:49 |
| teward | then i'm lucky ;) | 19:49 |
| nacc | Pharaoh_Atem: hrm, i noticed this | 19:49 |
| nacc | override_dh_apache2: for sapi in apache2 cgi; do \ | 19:49 |
| nacc | should fpm be there too? | 19:49 |
| nacc | Pharaoh_Atem: in d/rules | 19:49 |
| kyrofa | nacc, but indeed, that dependency seems a bit bogus | 19:50 |
| pepee | for kernel bugs, is it better to report to ubuntu, or upstream? | 19:50 |
| kyrofa | Then again... it's lisp :P | 19:50 |
| sarnold | pepee: ubuntu -- a bot will mmediately mark the bug for expiration and ask you to do some testing with upstream packaged kernels (it'll include links, etc..) | 19:54 |
| nacc | kyrofa: ifeq (,$(BOOTSTRAPLISP)) BOOTSTRAPLISP=/usr/bin/sbcl --disable-debugger --no-sysinit --no-userinit | 19:55 |
| nacc | endif | 19:55 |
| nacc | i think it's a real dep :/ | 19:55 |
| kyrofa | nacc, yikes | 19:55 |
| kyrofa | nacc, I've not seen that before | 19:55 |
| kyrofa | nacc, so it must require some sort of staged build, then | 19:56 |
| nacc | and the later on | 19:56 |
| nacc | ./make.sh --xc-host="$(BOOTSTRAPLISP)" --prefix=$(CURDIR)/stage1 $(FEATURES) | 19:56 |
| nacc | yeah, it basically seems to require a lisp to already be there :) | 19:56 |
| nacc | kyrofa: i know nothing about lisp, but that's just my reading of the package | 19:57 |
| kyrofa | nacc, unfortunately, neither do I. I'll continue to investigate | 19:58 |
| doko | fixed bind9 accepted | 19:58 |
| doko | lamont, infinity: ^^^ | 19:58 |
| pepee | sarnold, what if I submit kernel bugs manually? also, by "better" I mean, which is quicker... | 20:01 |
| pepee | *which one... this is the bug, btw: https://bugs.launchpad.net/ubuntu/+source/linux-lts-wily/+bug/1545401 I also asked in #ubuntu-bugs, no one has replied so far | 20:02 |
| ubottu | Launchpad bug 1545401 in linux-lts-wily (Ubuntu) ""kernel BUG at /build/linux-lts-wily-Vv6Eyd/linux-lts-wily-4.2.0/mm/memory.c:3146!"" [Undecided,New] | 20:02 |
| sarnold | pepee: 'manually'? also, quicker for whom and for what? :) just filing an issue? or getting a fix to a few million people? | 20:02 |
| pepee | quicker as in, the less time from "submitted" to "solved" | 20:03 |
| sarnold | probably submitting to launchpad; it'll still take work on your end but I think it'll get to someone who can fix it faster that way | 20:04 |
| pepee | sarnold, ah, thanks | 20:06 |
| Unit193 | infinity: ...I don't suppose any way to get a package uploaded, jump from 2.2.28 → 2.2.33 (Debian unreleased vcs) without a ffe, even if they are very minor bug fix releases? :3 | 20:10 |
| nacc | Pharaoh_Atem: any experience with phpunit? | 20:12 |
| Pharaoh_Atem | nacc: not much | 20:19 |
| Pharaoh_Atem | I've only really run unit tests | 20:19 |
| Pharaoh_Atem | why? | 20:19 |
| Pharaoh_Atem | nacc: also, in re d/rules, you're right | 20:20 |
| Pharaoh_Atem | it should be there too | 20:20 |
| infinity | Unit193: If it's all bugfixes, the version number is irrelevant. | 20:23 |
| Unit193 | Hoho! I may be in luck. | 20:24 |
| nacc | Pharaoh_Atem: cool, maybe that's the issue? | 20:34 |
| nacc | Pharaoh_Atem: and np on phpunit, i'll learn | 20:34 |
| Unit193 | Men, it's potentially uploadable. :3 | 20:34 |
| Pharaoh_Atem | nacc: sent you new patch series to try | 20:35 |
| Pharaoh_Atem | please try asap | 20:35 |
| gsedej | i have issue with dependency on 16.04 daily, where should I ask (libtinfo5:i386 breaks libtinfo5 on 64b) | 20:40 |
| nacc | Pharaoh_Atem: will do | 20:41 |
| nacc | Pharaoh_Atem: will take time to build, etc | 20:41 |
| nacc | pitti: for now i have had to skip those twig tests | 20:44 |
| nacc | pitti: i've filed upstream issues for each | 20:44 |
| Pharaoh_Atem | nacc: that's fine | 21:06 |
| cjwatson | kyrofa,nacc: language implementations often have self-build-depends. we can certainly bootstrap that on arm64, but it would help if somebody (Logan?) could work out why the current version is failing to build everywhere | 21:34 |
| cjwatson | kyrofa: if you want to help unblock this, that would be a good thing to investigate. https://launchpad.net/ubuntu/+source/sbcl/2:1.3.1-1ubuntu1 | 21:35 |
| Logan | hi | 21:35 |
| nacc | cjwatson: yep, it makes sense | 21:35 |
| Logan | ah yes, I was looking into the sbcl failures | 21:36 |
| nacc | Logan: kyrofa was asking about sbcl earlier -- seems like arm64 is stuck becuase it needs sbcl to already exist? | 21:36 |
| Logan | right, as cjwatson said, we can bootstrap | 21:36 |
| Logan | but we first need to figure out why this minor point release I uploaded yesterday suddenly fails to build on all architectures | 21:37 |
| Logan | well no, it was 1.2.14 to 1.3.0, so I guess that's not a minor point release | 21:37 |
| Logan | no | 21:37 |
| cjwatson | 1.3.0 worked, it was 1.3.1 that failed | 21:37 |
| Logan | it was 1.3.0 to 1.3.1 | 21:37 |
| Logan | yes | 21:37 |
| cjwatson | Logan: let me know when I'm good to run a bootstrap cycle | 21:38 |
| cjwatson | I probably won't remember unprompted | 21:38 |
| Logan | it was some sort of etex failure | 21:38 |
| Logan | urgh | 21:38 |
| Logan | cjwatson: sure thing | 21:38 |
| Logan | I love debugging TeX issues (not) | 21:38 |
| Logan | lemme run a test build in my Debian chroot and see if it's failing there | 21:38 |
| Logan | I can rope in the sbcl maintainer | 21:39 |
| nacc | slangasek: ah! i see php-zeta-base changed versions since i bootstrapped | 21:41 |
| nacc | slangasek: testing now to figure out what's needed | 21:41 |
| === salem_ is now known as _salem | ||
| nacc | Pharaoh_Atem: cp debian/php7.0-fpm.conf debian/php7.0-fpm/etc/apache2/conf-available/ | 21:50 |
| nacc | cp: cannot stat 'debian/php7.0-fpm.conf': No such file or directory | 21:50 |
| Pharaoh_Atem | grr | 21:50 |
| nacc | becuase it's debain/php-fpm.conf ? | 21:52 |
| Pharaoh_Atem | so there's something that's missing to go from debian/php-fpm.conf to debian/php7.0-fpm.conf | 21:52 |
| Pharaoh_Atem | nacc: php-cgi's conf does the correct transformation | 21:52 |
| Pharaoh_Atem | nacc: I think I figured it out! | 21:57 |
| Pharaoh_Atem | nacc: sent you a new patch to add on top of the current series | 21:59 |
| Pharaoh_Atem | please test | 21:59 |
| nacc | Pharaoh_Atem: ok, will do | 22:00 |
| Pharaoh_Atem | my god | 22:01 |
| Pharaoh_Atem | this package is so convoluted | 22:01 |
| Pharaoh_Atem | nacc: I'm hoping that I'll finally have it, and once it works, I can send all of these patches to Ondrej | 22:25 |
| nacc | Pharaoh_Atem: still building, will let you know | 22:26 |
| nacc | Pharaoh_Atem: right, and we'll need to file a bug to update ubuntu, i think, as sync is off now | 22:26 |
| Pharaoh_Atem | right | 22:32 |
| Pharaoh_Atem | but I'll be happy just to get these tests beaten into shape | 22:32 |
| Pharaoh_Atem | then it'll be a matter of taking a look at the php5 bugs filed for fpm and seeing if they even still apply | 22:34 |
| nacc | Pharaoh_Atem: right | 22:35 |
| nacc | slangasek: ha, in between my bootstrap and your update, they added phpunit as a build-dep and run the tests at build tim e:) | 22:35 |
| Pharaoh_Atem | nacc: I'm glad the php-pear circular dependency has been broken | 22:38 |
| Pharaoh_Atem | that was annoying when upgrading php in the past | 22:38 |
| Pharaoh_Atem | but afaik, phpunit is a new circular dependency? | 22:40 |
| nacc | Pharaoh_Atem: well, it's confusing, but i think because php 7 and php5 are coinstallable in debian and we are syncd (as of yesterday), phpunit isn't a problem anymore | 22:41 |
| Pharaoh_Atem | ah | 22:42 |
| nacc | slangasek: file a MIR to promote xmlrpc-epi (and then we can reenable php7.0-xmlrpc) | 22:42 |
| sarnold | wow, xmlrpc-epi's mail list looks a bit idle, https://sourceforge.net/p/xmlrpc-epi/mailman/xmlrpc-epi-devel/ | 22:44 |
| sarnold | one message since 2008-11-05 | 22:45 |
| nacc | sarnold: yeah, not great | 22:45 |
| sarnold | maybe that's because it's perfect | 22:45 |
| sarnold | but it has both 'xml' and 'rpc' in the name so I'm suspicious | 22:46 |
| rharper | lol | 22:46 |
| nacc | sarnold: yep, i realize it's a possible issue | 22:46 |
| nacc | sarnold: i *think* we could also go down the path of having a distinct src package in xenial/universe for just php-xmlrpc, but then we have to keep it in sync (or should try) with php7 (it's actual source) in main | 22:47 |
| nacc | sarnold: but that's just my current opinion | 22:47 |
| sarnold | nacc: not ideal either, heh | 22:47 |
| nacc | Pharaoh_Atem: tests are starting up again now | 23:02 |
| slangasek | nacc: separate source package> or we could focus on getting the build-dep MIR problem solved ;) | 23:32 |
| slangasek | nacc: fwiw I believe all of your bootstrap patches are still appropriate (e.g. for the case of a from-scratch bootstrap), even if not required right now for the transition. I suggest that you forward the remainder up to Debian | 23:32 |
| slangasek | nacc: and yeah, php-zeta-base now uses phpunit, but phpunit has rebuilt for php 7 and php-zeta-base is still failing | 23:33 |
| nacc | slangasek: yeah, it looks to be a real issue with php-zeta-base and php7 | 23:34 |
| slangasek | so, someone needs to make sense of that | 23:34 |
| slangasek | ok | 23:34 |
| nacc | slangasek: i'm working on fixing it | 23:34 |
| slangasek | ok great | 23:35 |
| sarnold | slangasek: probably php7-xmlrpc will runtime-depend upon xmlrpc-epi if it build-depends upon it.. heh | 23:38 |
| slangasek | sarnold: yes, but php7 build-depending on xmlrpc-epi and spitting the php7-xmlrpc binary out to universe would be A-OK | 23:38 |
| sarnold | slangasek: oh! | 23:38 |
| nacc | slangasek: right, that's something i meant to ask about -- i think i've seen src in main producing binaries inmain & universe | 23:39 |
| nacc | but the build-dep would still need to be in main, right? | 23:39 |
| slangasek | nacc: only under the current model, which we are trying to change | 23:39 |
| nacc | slangasek: ah right | 23:40 |
| nacc | sarnold: fyi, you're right, php7.0-xmlrpc depends on libxmlrpc-epi0 | 23:40 |
| nacc | slangasek: would that be an approach we could take for the other bin packages we have removed as well? | 23:41 |
| slangasek | nacc: yes | 23:41 |
| nacc | slangasek: cool! would simplify things greatly for me | 23:41 |
| nacc | slangasek: and would make our delta smaller | 23:41 |
| nacc | slangasek: so ... i *think* 7 of the 10 failures we see in sbuild are because we're root? | 23:45 |
| nacc | slangasek: i'm not sure why debian doesn't see the same problem, though | 23:45 |
| nacc | slangasek: i created a dummy user in an schroot and the tests passed | 23:45 |
| nacc | slangasek: because root doesn't respect file permissions | 23:46 |
| slangasek | nacc: we don't run anything in the build as root | 23:46 |
| nacc | slangasek: ok, that's good -- so probably just my env | 23:47 |
| nacc | slangasek: so i'm back to the original 3 issues :) | 23:47 |
| slangasek | nacc: and I reproduced the problem here (we're talking about php-zeta-base, right?) - you are pulling your build-deps from -proposed, not just from xenial? | 23:47 |
| nacc | slangasek: yeah, i reproduced it here too | 23:48 |
| slangasek | ok | 23:49 |
| nacc | slangasek: not directly related, but similar, for tomcat8 -> main (and tomcat7 in universe), now that the seed change has been merged, I don't need to do a MIR? once tomcat8 is in main, there won't be any comonent-mismatches, afaict | 23:56 |
| slangasek | nacc: should not need to do an MIR, correct. Do similarly need to make sure that we make it a clean swap | 23:57 |
| nacc | slangasek: right | 23:57 |
| nacc | slangasek: at least in that case, since we're keeping tomcat7, it's a little easier | 23:57 |
| slangasek | nacc: and php-guzzlehttp FTBFS | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
