tsimonq2where could I find all of the UDS sessions after this upcoming one? YouTube?00:24
hallynok, if i switch vmbuilder from Architecture:all to :any, that should be ok?  (it builds fine on power8)01:30
hallynhm, no01:33
hallynmaybe i shouldn't have to,01:33
tsimonq2and why do some package updates go to wily first instead of xenial?01:40
cyphermoxtsimonq2: 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
tsimonq2well obviously not02:02
tsimonq2-16 is in xenial-proposed02:03
tsimonq2-17 is in wily-proposed02:03
tsimonq2cyphermox: or is that irregular?02:06
cyphermoxtsimonq2: I suppose they're fixing bugs in wily and there's a good reason why it didn't land in xenial first02:08
tsimonq2cyphermox: 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
cyphermoxno, 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
tsimonq2cyphermox: do you know if upstream packages(Debian) go to xenial, and if so, what repo? main? universe?02:09
tsimonq2cyphermox: or is that conditional02:10
tsimonq2cyphermox: and if so how is that controlled02:10
infinitytsimonq2: 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
tsimonq2infinity: got it :)02:11
tsimonq2infinity: can YOU answer that question that I just asked him?02:11
infinityYou could probably answer it yourself with some Googling.02:12
infinityBut we autosync from Debian until Debian Import Freeze (in a few months).02:12
tsimonq2infinity: but you would give me the answer I want, as I want it02:12
tsimonq2infinity: but would it go to main?02:12
infinityNot if it's not already in main.02:12
tsimonq2infinity: 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
infinityYou'd file a Main Inclusion Request and make a case for why you think we should support it.02:13
tsimonq2and where's that>02:14
tsimonq2and what are the requirements for packages in main?02:14
infinitySeriously, Google a bit dude.  Just a little.02:14
* infinity goes back to his vacation.02:14
* ScottK read that as vaccination for a moment.02:15
=== nudtrobert1 is now known as nudtrobert
tjaaltoninfinity: 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
pittiGood morning06:46
=== nudtrobert1 is now known as nudtrobert
=== cpaelzer_ is now known as cpaelzer
dholbachgood morning07:53
seb128hey dholbach07:54
dholbachhey seb12807:54
seb128wgrant, hey, did you have any chance to debug the evolution/e-d-s translation issue on launchpad?07:54
LocutusOfBorg1hi folks, does freenode have an ubuntu channel for xserver folks?08:17
LocutusOfBorg1wrt #151164908:17
seb128LocutusOfBorg1, there was #ubuntu-x, unsure if it's still active, but you can also try to grab tjaalton or robert_ancell08:23
tjaalton#ubuntu-x is still there08:25
tjaaltonLocutusOfBorg1: merge is pending08:25
tjaaltonI've done it locally already08:26
tjaaltonjust have five critical bugs to sort out before end of next week, so had to postpone testing this08:26
LocutusOfBorg1tjaalton, WOW thanks!08:31
LocutusOfBorg1well, in my ppa is already built08:32
LocutusOfBorg1please be aware of the new wrapper08:32
tjaaltonI know08:32
LocutusOfBorg1I did add xserver-xorg-legacy to virtualbox-x11 package, because it still need a root x mode (upstream is working on this)08:32
LocutusOfBorg1and on ubuntu xenial it is currently failing to migrate in -release because of the installation test failure08:33
tjaaltonknow that too :)08:33
LocutusOfBorg1wonderful, so I'm happy to see you taking care of it08:33
tjaaltonyes, maybe next week08:33
tjaaltonmaybe the week after08:33
* LocutusOfBorg1 is wondering if we can have something like "make the package mandatory if exists, don't install otherwise", without playing with rules file08:34
LocutusOfBorg1tjaalton, not a problem, actually my wonder was an answer like "ubuntu don't want to have this wrapper"08:34
LocutusOfBorg1but if you plan to merge it, it is fine then, and I hope to remove the legacy dependency before xenial release anyway08:35
=== hikiko-lpt is now known as hikiko
=== davidcalle_ is now known as davidcalle
pitticjwatson: looking at bug 1511376 to do the equivalent finish-install fix in ubiquity10:27
ubottubug 1511376 in ubiquity (Ubuntu Xenial) "install writes /etc/mtab as file, not symlink" [High,In progress] https://launchpad.net/bugs/151137610:27
pitticjwatson: as ubiquity doesn't actually (seem to) use the finish-install udeb10:27
pitticjwatson: I wondered, woudl ubiquity/install_misc.py chroot_cleanup() be an appropriate place for that, or is there a better one?10:28
pitticjwatson: i. e. to set /target/etc/mtab -> /proc/self/mounts10:28
=== _salem is now known as salem_
cjwatsonpitti: That doesn't feel like the right place, no.  I'd suggest somewhere in scripts/plugininstall.py:Install11:22
cjwatsonThere's a bunch of fairly ad-hoc finalisation tasks in there11:22
pitticjwatson: ah, thank you11:23
=== rickspencer3_ is now known as rickspencer3
cyphermoxgood morning12:28
mdeslaurgood morning cyphermox12:37
=== zyga is now known as zyga-afk
dupingpingHi, everybody.14:44
dupingpingWho made the page? http://www.ubuntu.com/certification/desktop/models/?release=12.04+LTS&category=Desktop&category=Laptop14:44
dupingpingHow about modify it as follow?14:44
dupingpingI just designed this page.14:45
seb128bdmurray, hey, could you explain those15: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
seb128but the table has reports for the 7 previous versions15:09
seb128could you let that nautilus update in? the regressions mentioned are false ones15:10
bdmurrayseb128: 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
seb128which ones?15:11
seb128bdmurray, that has reports on 1:3.10.1-0ubuntu9.315:13
seb128it's just not common15:13
bdmurraybut not on ubuntu8 which was the one in the release pocket15:13
seb128right, but it's also a false regression15:13
dupingpingI just designed this page.15:14
seb128dupingping, hey, you already wrote that15:14
bdmurrayhttps://errors.ubuntu.com/problem/7b4d30774cd6698d6ac8a5718610a01b33b5e427 ?15:14
dupingpingseb128, the page is useful?15:14
seb128dupingping, no idea, it looks like "old" compared to the ubuntu one to me15:15
seb128the styling15:15
seb128but I don't work on that website15:15
seb128dupingping, you can open a bug with your suggestion on https://bugs.launchpad.net/ubuntu-website-content/+filebug15:15
dupingpingseb128, yes, i see.15:16
seb128bdmurray, 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 relevant15:18
seb128bdmurray, 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 reports15:18
bdmurrayseb128: 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
seb128bdmurray, 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 though15:22
bdmurrayseb128: the review might be helpful for the phased updater too, so thanks15:24
Odd_Blokepitti: 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
pittiOdd_Bloke: sure!15:36
pittiOdd_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 to15:36
Odd_Blokepitti: Great; I have a build from a couple of days ago, so I'll push that up somewhere.15:39
pittiOdd_Bloke: no hurry, though; I probably won't get to testing it today any more, need to leave in about an hour15:40
Odd_Blokepitti: 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
pittiOdd_Bloke: either works for me15:41
pittiOdd_Bloke: then I'll see how well I can download it through airport or hotel wifi :)15:42
Odd_Blokepitti: :D15:42
Odd_Blokepitti: I am producing QCOW2 images, so it's only ~320MB.15:42
pitti"only" :)15:42
pittiit 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
tsimonq2could I use the devel alias in my sources.list?15:44
pittitsimonq2: yes, works in principle15:45
pittiI just found it to interact in funny ways with apt-cacher-ng, otherwise it's fine15:45
tsimonq2pitti: could I do replace all from xenial to devel?15:45
tsimonq2pitti: so how do I fix the apt-cacher-ng issues?15:46
pittiI don't know15:46
pittiI gave up using "devel"15:46
tsimonq2anybody else know?15:46
pittitsimonq2: it might even work for you15:47
pittibut I have tons of schroots, containers, QEMUs of different relelases etc. which all share one acng, and occasionally it caused hash sum mismatches15:47
pittibut just try it15:48
tsimonq2pitti: but how would I fix the hash sum mismatches then?15:48
pittipitti | I don't know15:48
tsimonq2hmm.would +1 know about this better?15:49
Saviqpitti, 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
slangasekpitti: 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
pittiSaviq: sorry, I don't understand the question16:08
pittislangasek: yes, britney has used explicit triggers for maybe one or two months now, which makes the whole thing much more robust16:08
pittislangasek: it's also a prerequisite for minimizing deps from proposed16:09
pittislangasek: yes, there are two places: in result.tar there's a testinfo.json which contains it in machine parseable form16:09
pittislangasek: and if you look at the top of a log it says e. g. ADT_TEST_TRIGGERS=linux-meta/
slangasekpitti: 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
slangasekpitti: could we have the triggers exposed on the index somehow?16:09
pittislangasek: yeah, I guess that would be usefull16:10
pittiuseful too16:10
slangasekpitti: for that matter I don't see a link to result.tar16:10
slangasekartifacts.tar.gz doesn't include this16:11
pittislangasek: no, it needs to be in result.tar, as proposed-migration, kernel-matrix, etc. need the testinfo.json16:11
pittiright, there's no link to it; the general idea is to present results.tar in the debci log in a more human friendly  manner16:11
pittiso that log should get it at lesat16:12
pittibut showing it on the index page also sounds useful16:12
slangasekpitti: ok, that's all the more reason to have the trigger info on the index page16:12
* pitti files bug 151178016:13
ubottubug 1511780 in Auto Package Testing "debci: show test triggers" [Undecided,New] https://launchpad.net/bugs/151178016:13
slangasekta :)16:13
slangasekmeanwhile I've confirmed that devscripts was the trigger for the regression, how disappointing :)16:13
pittislangasek: if I ever get out of "OMGfixthisnow" mode, there's tons of improvements like this to be made16:13
* slangasek nods16:13
Saviqpitti, 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 dependencies16:14
Saviqpitti, building a unity8 source package takes a long time in the train today because of all the packages its Build-Depends pulls in16:14
pittislangasek: confirming which package broke what should get a lot easier and more predictable with the -proposed minimalization too16:14
pittislangasek: 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 -proposed16:15
pittislangasek: I was going to look at that during the flight; no distractions :16:15
pittiSaviq: oh, I see; well, you never need any of the B-D to build a source16:15
Saviqpitti, but some packages need some specific dh_ bits, and there's no way to declare those, either16:15
pittiSaviq: "debuild -S -nc" should do fine and avoids any black magic that debian/rules might do to your package, or fail on16:16
pittiSaviq: dh_* are not called for -S16:16
pittijust debian/rules clean, which you can eliminate with -nc16:16
pitti(of course you must then ensure to not have any build cruft there -- but we all build in sbuild, right?)16:16
pittiSaviq: I assume this is in the context of the train/automatic merges and stuff?16:17
Saviqpitti, yes16:17
pitti-nc should be fine there16:17
Saviqpitti, yeah, that helps16:17
Saviqrobru, ↑↑16:17
pittiSaviq: I'm surprised that you survived for so long without that16:17
pittia lot of packages need all kind of stuff which you really don't want to all install on these production boxes? :-)16:17
slangasekSaviq, robru, pitti: I thought we had to use the clean target because it might do things like e.g. generation of debian/control16:18
slangasekin the context of the train16:18
Saviqslangasek, I also thought there's things like autoconf that you need to call before you can get a tarball out of a branch16:21
Saviqor *re*conf16:21
slangasekthough in that case these are not properly constructed UDD-style source-package branches, which I thought was a prerequisite for the train16:22
didrocksSaviq: slangasek: yeah, a word of warning, but some cmake/autotools project expect the clean target to be run to build the source package16:24
didrocksfamous example being projects only having autogen.sh16:24
* slangasek nods16:24
didrocksalso, same issue with python projects, you need to resolve the imports for setup.py16:24
didrockshence 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
Saviqdidrocks, yeah, thanks, helps a lot16:25
Saviqdidrocks, I was just asking whether it's a topic in the dpkg community to potentially introduce something like Source-Depends16:26
Saviqwould save hours in the train...16:27
pittiSaviq: no, it's not a topic AFAIK16:27
didrocksSaviq: 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
Saviqdidrocks, yeah, that's what I was thinking16:27
Saviqrobru, ↑16:27
pittierr, autogen.sh in "clean"? that's evil16:27
pittithat belongs into build16:27
didrockspitti: you will never know what I've seen, my eyes are bleeding ;)16:28
didrockssee, that's why I've glasses now!16:28
pittiperhaps a good chance to actaully fix these packages :)16:28
Saviqpitti, I think the problem is that the result of autogen.sh is expected to be part of the tarball...16:28
Saviqor at least that's the history16:28
Saviqdidrocks, robru, bug #151178516:33
ubottubug 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/151178516:33
pittiSaviq: hm, that is really old school16:35
pittiSaviq: normally you just build-dep on dh-autoreconf, have dh --with=autoreconf (or call dh_autoreconf for non-dh packages), and it'll DTRT16:35
pittiavoids lots of noise between package builds, as they are really hard to review and utterly uninteresting16:36
Saviqsure, agreed, wonder if there's a solution for setup.py16:36
Saviqmaybe we can drop b-d in the train and fix packaging instead16:36
pittiSaviq: 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
Saviqpitti, nope, +1 from me16:37
didrockspitti: how would you do it for python project?16:37
pittididrocks, Saviq: OOI, why does building a .dsc need to call setup.py?16:37
didrocksbumping version for release16:37
didrocks(and so creating version.py)16:37
pittisorry guys, I need to leave, and then long travel to Austin16:38
didrocks(I guess some of our packages have the same mechanism in CMakeLists.txt)16:38
didrockspitti: have a safe travel!16:38
pittisee you next week in an odd time zone :)16:38
didrocksenjoy jetlag! ;-)16:38
happyaronpitti: safe trip, :)16:42
sil2100slangasek, 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 testable16:42
slangaseksil2100: porter-ppc64el.canonical.com?16:42
sil2100slangasek: how do you use that? ;)16:43
sil2100First time I see this address16:43
slangaseksil2100: https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes16:43
sil2100Is it VPN only?16:43
sil2100slangasek: thanks16:43
sil2100slangasek: 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 exist16:53
sil2100slangasek: and I don't want to meddle too much on a machine that's used by others16:55
slangaseksil2100: 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 term17:25
slangaseksil2100: we're working on getting this fixed but it's going to take a bit of hardware shuffling17:25
sil2100Ok... any other possibility of getting some ppc64el chroot to test that issue?17:26
slangaseksil2100: probably easier to let me remote debug it for you.  What's the root of the issue you're trying to solve?17:27
sil2100slangasek: it seems that the new ocaml is uninstallable on ppc64el, at least that's what the transition page says - not much more info sadly17:29
sil2100It built fine and works good on all other archs17:30
sil2100Want to make sure it's not a red herring17:30
cjwatsonsil2100: for installability issues, all you need is chdist(1) from ubuntu-dev-tools17:46
* slangasek nods17:47
cjwatsonsil2100: sorry, devscripts, not ubuntu-dev-tools17:48
cjwatsonno need at all to be on the same architecture, since it's purely configuring apt differently and then letting it do the graph analysis17:48
cjwatson(and you can't actually install packages, obviously, but just say no to that prompt)17:49
slangasekI 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
cjwatsonI think that is unlikely.  it's been around for ages and has always worked well for me17:50
cjwatsondose-debcheck does the analysis17:50
cjwatsonor dose-distcheck or whatever it's called these days17:51
cjwatsonThe following packages have unmet dependencies.17:53
cjwatson camlp4 : Depends: ocaml-nox-4.01.017:53
cjwatson camlp4-extra : Depends: ocaml-nox-4.01.017:53
cjwatsonsays chdist17:53
cjwatsonI bet this is NBS17:54
cjwatsonyeah, camlp4 is now distributed separately, and probably hasn't been auto-synced due to it being in an ubuntu-versioned source17:55
cjwatsonbeing called away, will come back and sort this out soon17:56
tumbleweedautopkgtest.ubuntu.com seems MIA18:08
sarnoldtumbleweed: there's some issues in the datacenter, it's possible that's one of the affected services18:09
sil2100cjwatson: camlp4 is something different18:09
sil2100cjwatson: anyway, thanks!18:09
robruslangasek: 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
robruslangasek: pitti I'm open to trying 'debuild -S -nc' after a maual './debian/rules clean', I'm not sure what implications that would have though18:14
cjwatsonsil2100: camlp4 is the cause of your problem :P18:38
cjwatsonsil2100: 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 transition18:39
cjwatsonsil2100: I've synced camlp4 now, that should make this glitch go away18:40
sil2100cjwatson: strange that it didn't cause any problems on other archs18:45
sil2100I actually thought that camlp4 was already synced because of that18:45
sil2100cjwatson: anyway, thanks! :)18:47
hallynarges: hey are you around?19:11
hallyncould 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
hallyni 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-1ubuntu119:13
hallynor 1:0.2.6-1ubuntu0.15.04.119:14
hallynok yup, auto-rejected19:16
slangaseksil2100, cjwatson: either of you know why camlp4 has added a 'camlp4-dbgsym' binary package? (currently in binary NEW)19:30
slangasekthat seems like a horribly wrong thing for the Debian ftpmasters to have let into the archive19:31
ScottKslangasek: I don't think it generates that binary in Debian.19:47
cjwatsonslangasek: our NEW shows *-dbgsym19:48
cjwatsonsil2100: yeah, I didn't look at other arches19:48
cjwatsonslangasek: (this is arguably a bug, but not a very important one)19:48
argeshallyn: ok back i see netcf in vivid queue.... is that the right one?19:52
slangasekcjwatson: oh; so the dbgsym being listed as 'NEW' doesn't mean it's in Debian as a .deb, ok19:58
slangasekdoko: I'm assuming that your syncing of swig 3.0.7-1 means that we want to trade swig2 for swig3 in main now20:04
hallynarges: yup, it's the right one now :)  thx20:05
cjwatsonsil2100,slangasek: there is in fact a subtle bug in the transition tracker which you can ignore for your purposes20:31
cjwatsonit'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 -proposed20:32
cjwatsonthe 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
cjwatsonso 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 -proposed20:33
=== salem_ is now known as _salem
cjwatsonbut 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
cjwatsonso the top-level tracker "go" script fails to filter out camlp4-extra, but just on ppc64el20:34
cjwatsonyou owe me half an hour of my life scratching my head trying to figure that one out :P20:34
* cjwatson attempts a quick fix20:34
hjdCould 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
cjwatsonhjd: done20:48
hjdcjwatson: Thank you.20:48
cjwatsondamnit, 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 it20:50
cjwatsonI'll come back to it in a bit and figure it out if nobody beats me to it20:50
cjwatsonI guess I could just have hit a locking failure, since update-transitions doesn't have locking of its own20:53
cjwatsonah yes, just locking silliness21:00
cjwatsonsil2100: should sort itself out in a bit but I have to wait for cron to do its thing21:04
hjdAnother 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
hjdThough 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
sil2100cjwatson: 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!