[00:10] <infinity>   %w[8.5 8.4] # At present, Tcl/Tk8.6 is not supported.
[00:10] <infinity> doko: ^-- That's the problem.
=== unhappyaron is now known as happyaron
[01:04] <infinity> doko: Okay, so maybe that's *a* problem, but not *the* problem.
[01:10] <infinity> doko: Though, even ruby trunk claims to not support anything >> 8.5, so I think this is a lost cause, and it should just build-dep on 8.5
[01:10] <infinity> doko: Was there a reason other than "new shiny" to bump the tcltk-defaults ahead of Debian?
[01:17] <doko> infinity, well, I was trying to get the interpreter languages up to date ... things like ocaml did block, didn't expect that many issues with tcl/tk
[01:18] <doko> ruby is the only failing one for now in main
=== jono is now known as Guest94995
=== Logan_ is now known as log
[05:14] <xnox> infinity: doko_ : i distinctly remember multiarched-tktcl patches required to build ruby2.0 against multiarched tcltk... have those been applied? /me looks
[05:14]  * xnox did ask ruby maintainer to do so at debconf....
[05:15] <xnox> right those did get merged.
[05:16] <xnox> horum.
=== Guest95298_ is now known as LoganCloud
[05:23] <xnox> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733372
[05:23] <ubottu> Debian bug 733372 in src:ruby2.0 "ruby2.0: FTBFS: ossl_ssl.c:2179:65: error: 'SSL_OP_MSIE_SSLV2_RSA_PADDING' undeclared (first use in this function)" [Serious,Open]
[05:23] <xnox> upstream does claim 8.6 is not supported... http://bugs.ruby-lang.org/issues/8000
=== log is now known as Logan_
=== lfaraone_ is now known as lfaraone
=== fire is now known as ffio_
=== tkamppeter_ is now known as tkamppeter
[11:35] <xnox> bdmurray: i've uploaded a fix to apport (ubiquity hook) and adt test has failed, with loads of errors of: FileNotFoundError: [Errono 2] No such file or directory: for apport-upack, apport-valgrind, crash-digger. I'm not sure if that's something I have caused, or how to resolve / fix the adt test.
[11:35] <xnox> bdmurray: any ideas?
[11:35] <xnox> pitti is not online.
[11:41] <zyga> any X person here might know why I still need to edit xorg.conf in 2014? Is this something that we can convert to a better (but sensible) default? https://plus.google.com/116315264177593873442/posts/WhF9anC2mow
[11:44] <xnox> zyga: weird, i didn't have to do anything like that with my dual or tripple head setups with all my laptops/desktops. Granted all of them are intel.
[11:44] <xnox> zyga: on the latest laptop I did have to set xorg settings to get the brightness working.
[11:44] <rbasak> zyga: I had to do that for dual-head support on an ancient laptop. How old is your hardware?
[11:44] <xnox> (keys that is)
[11:46] <zyga> xnox: this is A8 apu, current gen, with fglrx as open source drivers resulted in heavy corrpution all the time
[11:46] <zyga> rbasak: brand new
[11:46] <zyga> rbasak: this A8 richland APU
[11:46] <zyga> rbasak: with two screens
[11:47] <zyga> rbasak: one is 2048 another 1024 in width
[11:47] <zyga> rbasak: apparently the default is 2048 max horizontal resolution
[11:47] <zyga> rbasak: I tried with two smaller screens and it worked out of the box
[11:48] <zyga> rbasak: using DVI and VGA outputs, nothing fancy
[11:48] <rbasak> zyga: sounds like a bug to me. Though I'm not familiar with things that happened in X since the days of XFree86 :-/
[11:49] <zyga> (this is a desktop, not a laptop)
[11:50] <zyga> I recall reading that some GPUs have a limit on the max texture size, so large screens would not work with something like unity
[11:51] <zyga> but this was last on i915 or something like that
[11:53] <zyga> asac: hey, any chance for plainbox MIR review? :-)
[12:03] <apw> cjwatson, am i right in thinking that grub2 no longer has 'trigger' support ?
[12:10] <cjwatson> apw: AFAIK it never did
=== _salem is now known as salem_
[12:14] <apw> cjwatson, no longer compared to grub1 ... would it be something we would like if i can be bothered ?
[12:23] <infinity> apw: How would triggers be any better than /etc/kernel/postinst.d/zz-update-grub ?
[12:23] <apw> infinity, when you install or remove 3 kernles at once you would only run it once
[12:24] <infinity> apw: Oh, sure, one could turn zz-update-grub into a trigger wrapper like ldconfig, or do something more clever entirely.
[12:24] <infinity> Not that update-grub takes long to run.
[12:25] <apw> it does take quite a while if you have more than a few kernels installed, and right now twice per kernel
[12:27] <infinity> Is it uncouth to eat a wheel of brie on its own because it's the only food you have?
[12:28] <cjwatson> apw: maybe, yeah
[12:29] <cjwatson> though the postinst is pretty complicated as it is
[12:30] <cjwatson> but it would be nice to speed all that up a bit, I agree
[12:30] <infinity> apw: Anyhow, using something like /sbin/ldconfig as a cheat, you could just add a few guards to zz-update-grub, register the trigger, and call it done.
[12:30] <infinity> Not that I'd recommend that as the best way forward, it was just the easiest way to do ldconfig without forcing all its users to adapt.
[12:30] <cjwatson> The GRUB Legacy trigger work never went into Debian, apparently.  This would need to (I don't want to have an Ubuntu delta for grub2 again).
[12:31] <cjwatson> I don't think it was very complete either - it didn't auto-trigger on things running update-grub, it just supplied an explicit trigger, which isn't as good an approach
[12:32] <cjwatson> infinity: Probably not necessary here.  Adjusting zz-update-grub would do most of the work.
[12:33] <apw> cjwatson, no indeed, they said they wanted the equivalent of our grub1 work in grub2, but ... its not there indeed
[12:33] <cjwatson> It was in the Ubuntu package but was never merged back
[12:33] <infinity> cjwatson: Well, you could guard zz-update-grub or update-grub itself, depending on the desired outcome.
[12:33] <cjwatson> As far as it went, anyway
[12:34] <infinity> Guarding update-grub and registering an update-grub interest would probably do the trick without having to touch any callers.
[12:34] <cjwatson> infinity: Sure, either would work
[12:34] <cjwatson> Indeed, update-grub is already a wrapper script
[12:34] <cjwatson> So it would probably be logical to put it there
[12:34] <apw> yeah
[12:35] <apw> so if i do somethign comprehensive in that manner, it should be mergable back to debian pretty well i assume
[12:36] <infinity> Something like guarding update-grub and an interest trigger would be very mergable back because, like I said, no need to update callers.
[12:36] <infinity> And /sbin/ldconfig /var/lib/dpkg/info/libc-bin.triggers probably have the three lines of hints required to make that work.
[12:37] <apw> infinity, ok cool i'll likely poke at it and get with you on the details
[12:38] <infinity> Probably don't need the NOTRIGGER hack, since grub triggering itself isn't nearly as vile as libc6 triggering ldconfig.
[12:38] <apw> i am mostly interested in fixing the update initramfs mess -extras have made
[12:38] <infinity> update-initramfs is a whole different story...
[12:38] <apw> infinity, but i see ... we still have your 'hacked merge' in here
[12:39] <infinity> Yeah, I'm fixing that this week. :)
[12:39]  * apw will wait till you fix that then
=== Guest90700 is now known as Lutin
=== greyback_ is now known as greyback|lunch
=== greyback|lunch is now known as greyback
=== happyaron is now known as unhappyaron
=== unhappyaron is now known as happyaron
[15:34] <wachin> Good day to all Ubuntu Developers
[15:34] <wachin> On my operating system UbuntuSTudio 13.10 is installed Nautilus 3.8.2 and the search feature is not helping me. I ask you to please leave it as it was before in Nautilus 3.4.
[15:35] <wachin> Consider that only for this reason many people will go to Linux Mint, it is not convenient
[15:35] <rbasak> We're supposed to keep all quilt patches refreshed on an upload right? So if I see offsets in an Ubuntu-delta patch while merging, I should refresh it?
[15:36] <xnox> rbasak: not necessory, the only dpkg requirement is to have no "fuzz", but offsets are ok.
[15:36] <rbasak> xnox: good to know, thanks. What's best practice? Leave it alone?
[15:36] <xnox> rbasak: plus if one uses options different from debian maintainer, one can easily generate very large diff because like timestamps are removed or "a/:b/" are renamed to "foo/:foo.old/" etc....
[15:37] <xnox> rbasak: i tend to go for minimal diff possible, and thus i don't refresh patches unless i have to (e.g. to get rid of fuzz)
[15:37] <wachin> and I read several posts, many people complaining for this reason.
[15:38] <wachin> And I read in a post that is people who complain, developers will do nothing
[15:40] <rbasak> wachin: have you checked to see if these changes are coming from upstream, or from Ubuntu developers?
[15:40] <wachin> I have tried to put myself in your place, to understand why this happened, I understand that you can use it to 3.8 or 3.6 nautilus efficient way for their activities. But for the normal user that is not a help. Nautilus 3.4 are best
[15:41] <wachin> No I'm not know how to that
[15:42] <rbasak> It sounds to me that upstream are making changes that you don't like, and Ubuntu developers are stuck in the middle.
[15:42] <wachin> I am a Spanish parlant. In the #Ubuntu chanel guide to here
[15:43] <xnox> wachin: this is not an appropriate forum to raise those concerns. #ubuntu-devel is for ubuntu core platform development. And e.g. nautilus is a single packaged shared by Ubuntu, Ubuntu Gnome, Ubuntu Studio etc. There are many file managers available, and you are free to install any you like.
[15:43] <xnox> wachin: if you want to change the defaults in any of the distos, please talk to developers/leads of those distros, e.g. ubuntu-studio.
[15:44] <xnox> wachin: or email ubuntu-devel-discuss mailing to reach all interested parties.
[15:44] <wachin> Ok
[15:45] <xnox> wachin: such things are never revert based on "demands" or "cries out" on irc. that is not productive technical discussions.
[15:45] <wachin> Ok xnox, I understand
[15:46] <wachin> Do you know how to I  can write to the team that set nautilus 3.6 -3.8 on Ubuntu
[15:47] <rbasak> wachin: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
[15:48] <xnox> wachin: ubuntu-devel-discuss mailing list.
[15:48] <wachin> Thanks rbasak
[15:51] <zyga> mterry: hey, what did you mean by "Package needs a team bug subscriber", I cannot see any bug controls on the source package page and the upstream project already has a team subscribed
[15:51] <xnox> zyga: which package?
[15:52] <xnox> zyga: typically same team should be subscribed to distro bug mail as well.
[15:52] <zyga> xnox: plainbox MIR request: https://bugs.launchpad.net/ubuntu/+source/plainbox/+bug/1265754
[15:52] <ubottu> Ubuntu bug 1265754 in plainbox (Ubuntu) "[MIR] plainbox" [Undecided,Incomplete]
[15:52] <zyga> xnox: see mterry's comment on that bug
[15:52] <xnox> zyga: on https://launchpad.net/ubuntu/+source/plainbox there should be "+ Sbuscribe to bug mail" on the right.
[15:53] <xnox> zyga: and you should subscribe, e.g. plainbox-team to it.
[15:53] <zyga> ah
[15:53] <zyga> ok, I get it now
[15:53] <zyga> thanks!
[15:56] <mterry> zyga, yup
[15:56] <mterry> xnox, thanks
[15:56] <mterry> zyga, that's just so that when bugs get filed in Ubuntu, they don't go into the void
[15:57] <zyga> mterry: that's a very good point, I just didn't understand how that works
[15:57] <zyga> mterry: I'm filing a bug on the autopkg test issue you found and I'll get it fixed in Debian
[15:58] <zyga> mterry: do you think we should wait for -3 to hit Ubuntu before that MIR can be reconsidered?
[15:58] <mterry> zyga, if you're trying to promote right now, I can approve the MIR as long as the test fix is in the works
[15:59] <zyga> mterry: I'll show you commited -3 in debian SVN and then we can decide, ok?
[16:01] <mitya57> mterry, barry: while we are speaking about the teams: do you think we can subscribe ~ubuntu-pythonistas to jquery* bugs? Or do you know any better team?
[16:02] <mterry> mitya57, is that a real team?
[16:03]  * mitya57 notices that jquery itself has ~ubuntu-foundations-bugs subscribed
[16:05] <mitya57> bdmurray: can we please have ~ubuntu-foundations-bugs subscribed to 4 packages mentioned in bug 1261149?
[16:05] <ubottu> bug 1261149 in libjs-jquery-isonscreen (Ubuntu) "[MIR] jquery-goodies, libjs-jquery-{hotkeys,isonscreen}" [Undecided,Incomplete] https://launchpad.net/bugs/1261149
[16:05] <zyga> mterry: http://anonscm.debian.org/viewvc/python-modules?view=revision&revision=26981
[16:07] <mterry> zyga, approved, thanks!
[16:08] <zyga> mterry: awesome, thanks
[16:09] <bdmurray> mitya57: okay
[16:16] <rbasak> bdmurray: could you take a look at https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1178245 please? danwest just experienced it. The last comment looks like a good explanation to me; on the surface, anyway.
[16:16] <ubottu> Ubuntu bug 1178245 in ubuntu-release-upgrader (Ubuntu) "missed python-apt dependency" [Undecided,Confirmed]
[16:18] <mitya57> mterry: there are three members ;)
[16:18] <bdmurray> rbasak: ah, okay.  do you know what kind of install (for testing) the upgade was being attempted from?
[16:18] <mitya57> mterry: note that I am subscribed to those packages anyway
[16:19] <rbasak> bdmurray: no, but I'll ask danwest to join this channel.
[16:20] <mterry> mitya57, yeah and that is useful.  But teams provide some long-term security in case you get hit by a bus  :)
[16:24] <danwest> bdmurray: testing upgrade from raring to saucy (armv71)
[16:24] <bdmurray> danwest: what kind of install was the raring system?
[16:25] <danwest> bdmurray: kind? server - is that what you were looking for?
[16:26] <bdmurray> danwest: yes
[16:26] <danwest> k
[16:28] <bdmurray> danwest: so it was a server install?
[16:29] <danwest> bdmurray: yes, I believe so - let me verify
[16:31] <danwest> bdmurray: this was the image -> https://rcn-ee.net/deb/rootfs/raring/ubuntu-13.04-console-armhf-2013-12-17.tar.xz
[16:31] <bdmurray> danwest: okay, thanks
[16:32] <infinity> danwest: Really, a third party image? :P
[16:32] <infinity> (I guess this was on something we don't support, like a BBB?)
[16:32] <danwest> infinity: yup beagle bone black
[16:32] <danwest> nice little MAAS server I hope
[16:34] <mitya57> bdmurray: thanks
[16:34] <mitya57> mterry: better now?
[16:35] <infinity> bdmurray: Seems fairly obviously just a fundamental issue with the py2->py3 transition, where do-release-upgrade and the release-upgrader tarball are of different vintages.
[16:37] <mitya57> doko_: Can you please test if the aarch64 atomics patch can be dropped from qtbase?
[16:38] <mitya57> <hrw> mitya57: you do not need qatomics stuff for 5.2
[16:38] <mitya57> <hrw> mitya57: in other words: 5.2.0 qtbase builds out of box for aarch64
[16:39] <mitya57> Mirv: ^ also FYI
[16:44] <mterry> mitya57, approved, thanks!
[16:45] <mitya57> mterry: thanks!
[16:48] <chiluk> what are the conditions that prevent me from changing a bug to won't fix?
[16:48] <jtaylor> has python3.4 changed something in their shared library extensions again?
[16:50] <xnox> jtaylor: compile flags.
[16:50] <xnox> jtaylor: but i don't know if that was fixed / reversed or not.
[16:50] <jtaylor> you mean the -Wdeclaration-without-statement thing?
[16:50] <jtaylor> I mean file extensions of c libraries
[16:51] <jtaylor> I get a test failure in the source tree but not on install tree (after dh_python3 ran and possibly reverted it?)
[16:51] <jtaylor> 3.4 only
[16:51] <mitya57> Mirv: by the way, any news on Qt transition?
[16:51] <bdmurray> chiluk: probably not being an uploader of the package or not in ubuntu-bugcontrol
[16:52] <chiluk> bdmurray I'll apply now.
[16:55] <xnox> jtaylor: i had some 3.4 failures, where some of my deps were missing 3.4 modules.
[16:55] <xnox> jtaylor: do you have build-log?
[16:56] <jtaylor> no I'm just running the build again thistime with shell hook to look into it
[16:56] <jtaylor> just asking if someone knows something
=== arun is now known as arunpyasi
[17:40] <jtaylor> great it really changed again
[17:40] <jtaylor> ffs
[17:41] <jtaylor> and the interface it provides gives wrong results
[17:51] <jtaylor> might be an ubuntu change
[17:52] <jtaylor> doko_: is the multiarch SOABI accessible somehow?
[17:52] <jtaylor> python3.4 only
[18:09] <mitya57> So... When built against a mix of Qt versions, python3-pyqt5.qt{serialport,sensors} .so files are empty
[18:10] <mitya57> I.e. ldd says they are not linked dynamically to anything
[18:22] <doko_> mitya57, should be SOABI-$(DEB_HOST_MULTIARCH)
[18:29] <mitya57> doko: ENOPARSE, where is the issue?
[18:31] <mitya57> s/doko/doko_/
[18:31] <cjwatson> I think doko_ maybe intended to address that to jtaylor
[18:32] <jtaylor> doko_: from within python
[18:32] <jtaylor> use the _multiarch?
[18:32] <jtaylor> also special case it for 3.4 and not 3.3?
[18:32] <doko_> and it's 3.3 and 3.4
[18:33] <jtaylor> 3.3 works fine
[18:33] <jtaylor> shouldn't python itself be fixed instead of the modules?
[18:33] <jtaylor> by having SOABI not be wrong for what it is used outside of ubuntu
[18:36] <jtaylor> ok 3.3 has the same problem but only after running dh_python3
[18:48] <doko_> jtaylor, well, we still want this as the default for people building extensions not only for the distribution
[18:48] <doko_> the renaming is distro specific. I know, it will break for a handful of packages
[18:48] <doko_> mitya57, ahh, qtbase, yes will start a build
[18:49] <mitya57> Danke!
[18:52] <jtaylor> so what should upstream do if they want the abi tag?
[18:52] <jtaylor> check if running on ubuntu?
[19:02] <tedg> It seems that "ubuntu-bug" doesn't work to file a bug on a package.  What has that changed to?
[19:04] <doko_> jtaylor, get the EXT_SUFFIX, that's the suffix you use without --install-layout=deb
[19:04] <tedg> Seems apport-cli -f -p works
[19:05] <jtaylor> doko_: that doesn't have the multiarch parts
[19:05] <jtaylor> also unreliable, but thats a different story
[19:09] <doko_> jtaylor, yes, that' what I said
[19:09] <jtaylor> what if I want to find packaged modules?
[19:09] <doko_> somewhere there is a list of extensions the interpreter understands
[19:09] <doko_> ?
[19:10] <doko_> anyway, later, have to run
=== jpds_ is now known as jpds
[20:01] <jtaylor> I guess this should work until python3.5 http://paste.ubuntu.com/6686728/
[20:21] <tarpman> hi! while working on bug 937200 I found an odd behaviour wrt fontconfig, ubuntu font, and unfonts: https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/937200/comments/62 Can anyone help me figure out whether that fc-match behaviour is buggy, and if so which package is responsible?
[20:21] <ubottu> Ubuntu bug 937200 in openjdk-7 (Ubuntu) "Fat fonts in Swing applications" [Low,Confirmed]
=== Logan_ is now known as Guest82355
=== Logan__ is now known as Logan_
[21:27] <sbeattie> doko_: do the regular buildds install recommends? I had a daily ppa build just fail on trusty because the split out libtool-bin package didn't get installed from the build dependency on libtool.
[21:40] <stgraber> (trusty-amd64-sbuild)ubuntu@lxc-testing01:/$ grep -ri recommend /etc/apt/
[21:40] <stgraber> /etc/apt/apt.conf.d/99buildd:APT::Install-Recommends "0";
[21:40] <stgraber> sbeattie: ^
[21:52] <sbeattie> stgraber: okay, so are we expected to add an explicit build dependency on libtool-bin?
[21:54] <stgraber> unless libtool can't function without libtool-bin which would then make the Recommends a bug and should have it promoted to a Depends
[22:38] <nemo> heh. you know, I don't know if you guys know this, but, Wine, a thing that is pretty important for noobs trying to transition, breaks pretty badly when installing from ubuntu software centre
[22:39] <nemo> my approximate guess as to what happens, is it is the ms core fonts license dialog
[22:39] <nemo> somehow it is prompty forever for that, just burning CPU, at about the halfway point
[22:40] <nemo> you kill it, and it then requires a dpkg --configure -a to repair, which luckily synaptic informed me of
[22:40] <nemo> installing in synaptic ofc worked perfectly, since it isn't trying to be quite as friendly
[22:40] <nemo> I ran into this on a test VM image of 13.10 where I was going through the effort of setting things up using unity and software centre like my noob friend would
[22:58] <OdyX> tkamppeter: I have just uploaded cups 1.7.0-1 to Debian unstable, which should included all your changes, some of which I implemented differently, plus some Fedora patches that make the package globally better; I trust. Feel free to compare+sync it!
=== salem_ is now known as _salem