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