[00:02] <ice9> i just built the rhythmbox and gedit sources using make but after the build, i can't find the binary exec file to start the application
[00:31] <pvl1> make install
[00:31] <pvl1> ice9
[00:32] <ice9> pvl1, no i don't want to install it on my system, just want to make a fix and test it
[00:37] <pvl1> is there a bin dir
[00:37] <pvl1> in the project directory
[00:38] <ice9> no
[01:11] <Noskcaj> Can someone please rebuild dx? It should allow it to pass the libtiff5 transition
=== freeflying_away is now known as freeflying
[01:24] <Noskcaj> And feel++ needs a rebuild to pick up openmpi1.6
[01:26] <Noskcaj> Actually just about everything at http://people.canonical.com/~ubuntu-archive/transitions/html/openmpi1.6.html needs a rebuild
[01:28] <xnox> Laney: thanks.
[01:34] <Noskcaj> to rebuild a package should i just submit a branch with a build1 changelog?
[01:45] <xnox> Noskcaj: "everything" is a vague definition, given it's 78% complete, and many things are not accounted for (e.g. fixed packages in proposed)
[01:45] <xnox> Noskcaj: rebuilding feel++ is jumping the ship, since gmsh is not yet fixed across all architectures.
[01:47] <xnox> Laney: not sure about the tracker. E.g. openmpi1.6 didn't get an ppc64el column =/
[01:53] <Noskcaj> xnox, ok. So i do just submit a branch with a build1 revision for the relevant packages?
[02:00] <xnox> ?
[02:00] <xnox> Noskcaj: which package?
[02:01] <xnox> Noskcaj: LoganCloud uploaded all those that didn't FTBFS, the rest seemed to need fixes.
[02:01] <Noskcaj> ok
[02:01] <xnox> Noskcaj: and has the packages deps migrated to openmpi1.6 already?
[02:01] <Noskcaj> idk
[02:02] <xnox> Noskcaj: across all arches... it's easy to get into arch skew =/
[02:02] <xnox> Noskcaj: no change rebuilds is such a low level task, that sponsoring those is, well, a lot of overhead. people with upload rights motu/core-dev usually do those.
[02:03] <Noskcaj> ok, makes sense
[02:03] <xnox> Noskcaj: patches to fix FTBFS for packages in-current transitions is always nice to know =)
[02:03] <xnox> Noskcaj: so again which "the relevant package" that can just be no-change rebuild that you have identified?
[02:05] <Noskcaj> I was going to manually try them, was just checking the process first
[02:13] <xnox> Noskcaj: locally? why a branch merge proposal?
[02:13] <LoganCloud> Did I do something wrong
[02:13] <LoganCloud> I was mentioned in this channel. Not a good sign
[02:14] <Noskcaj> that one i just changed libtiff4-dev to libtiff-dev. Was there something other than building i needed to check?
[02:14] <xnox> Noskcaj: one checks current depends in -proposed/-archive, does a local no-change rebuild to check that new library name is picked up, and if all checks out good prepares no-change upload.
[02:14] <Noskcaj> LoganCloud, you're fine
[02:14] <Noskcaj> ok
[02:14] <xnox> LoganCloud: nah, all good =) just pointing out the good work you did on pushing openmpi transition.
[02:15] <xnox> Noskcaj: as far as I can tell tiff transition is complete, and it has been requested to remove tiff from the archive.
[02:15] <xnox> Noskcaj: unless it's creeping back in?
[02:15] <xnox> Noskcaj: so again, can you tell me which _src_ package you are looking at?
[02:15] <Noskcaj> xnox, Should be done, just a package that still needed libtiff4
[02:15] <LoganCloud> Phew
[02:15] <Noskcaj> And none
[02:16] <xnox> Noskcaj: not the transition name, e.g. tiff4. but the reverse dep in question...
[02:16] <xnox> Noskcaj: i'm confused. =(
[02:16] <Noskcaj> I have no idea what you're talking about
[02:18]  * Noskcaj thinks he needs to find something else to do with his holidays
[02:18] <xnox> Noskcaj: "<Noskcaj> [01:11:51] Can someone please rebuild dx? It should allow it to pass the lib" & "<Noskcaj> And feel++ needs a rebuild to pick up openmpi1.6" & "<Noskcaj> to rebuild a package should i just submit a branch with a build1 changelog?"
[02:19] <xnox> Noskcaj: I got the impression, that you want to help with transitions and believe you have something ready to be uploaded.
[02:19] <xnox> Noskcaj: yet, I still don't know which packages you want to be rebuild.
[02:19] <Noskcaj> 1 and 2: basic guesses, probably wrong. 3. Moure general info
[02:19] <Noskcaj> I want to help, don't really know what to do
[02:20] <xnox> Noskcaj: looking at dx -> whilst it build-depends on libtiff-dev, it doesn't actually result in binary depends on tiff.
[02:20] <xnox> Noskcaj: in the transition tracker feel++ is at the very top of the stack, and typically things feel++ depends on should transition before feel++ itself will.
[02:21] <xnox> Noskcaj: otherwise one may end up in an unfortunate situation of trying to load both ABIs into a single binary =/ which is not good.
[02:21] <Noskcaj> ok, so that's what the dependancy level thing means
[02:21] <xnox> Noskcaj: yeah, roll the mouse over the package name to see it.
[02:21] <Noskcaj> oh
[02:21] <xnox> Not very discovarable, unless one reads the source code of the page ;-)
[02:23] <LoganCloud> xnox: thanks :) it was my first real transition
[02:23] <LoganCloud> The fact that Debian did it already helped, for sure :P
[02:23] <xnox> LoganCloud: there are plenty of FTBFS to fix... left =)
[02:24] <xnox> still though.
[02:24] <xnox> yeah, but it's now different, cause they did it at different timing.
[02:24] <LoganCloud> Yes but they're also FTBFSing in Debian
[02:24] <xnox> LoganCloud: did they remove them from testing?
[02:24] <LoganCloud> At least most of the ones with issues
[02:24] <LoganCloud> I think so
[02:24] <xnox> lazy =)
[02:25] <LoganCloud> Because the ones with problems say "Sid only" I think
[02:25] <LoganCloud> I'm not by my computer right now. On my phone
[02:25] <xnox> fixed openmx, cctools and others now.
[02:25] <LoganCloud> Cool, I'll take a look in like 10 min
[02:25] <Noskcaj> speaking of that, do you guys have any tips for finding what is causing an ftbfs? It's very rare for me to find one i know how to fix
[02:27] <xnox> Noskcaj: read the build-log, that's the only....
[02:28] <Noskcaj> As in working out how to fix what the buildlog says
[02:28] <xnox> one solves a sudoku by solving it.....
[02:29] <xnox> read what it says, and depening on what it says, try to understand why, and resolve the root cause behind it.....
[02:29] <xnox> it's not any different from any other puzzles =)
[02:31] <LoganCloud> Noskcaj: knowing basic stuff about coding and stack traces helps
[02:31] <LoganCloud> Also spotting patterns, and taking note of fixes to common problems
[02:32] <Noskcaj> LoganCloud, There's my issue. I only know basic python, and all the python ftbfses are from test errors, or architectures i don't have.
[02:32] <xnox> Noskcaj: learn C, it's easy.
[02:32] <Noskcaj> sigh. I really should
[02:32] <xnox> http://www.cprogramming.com/
[02:49] <xnox> Laney: looks like my last config change did break the trackers. Revert that commit.
[02:49] <xnox> Laney: can you take a look at how to enable the new arch?
[03:33] <Logan_> xnox: Tsk tsk. You modified hdf5 right after I fixed the default mpi for ppc64el and arm64. :P
[03:36] <xnox> Logan_: really?
[03:36] <xnox> Logan_: where?
[03:36] <Logan_> mpi-defaults
[03:37] <Logan_> I reverse-traced the logic it was using to pick up the default MPI and found it was coming from the depends for that package
[03:37] <Logan_> so I added arm64 and ppc64el as arches for openmpi in that package's build-depends
[03:38] <xnox> Logan_: right. and ppc64el is finished now.
[03:38] <xnox> Logan_: do we need to rebuild everything on top on mpi-defaults on arm64 & ppc64el ?
[03:39] <xnox> Logan_: i'll revert hdf5
[03:39] <xnox> Logan_: actually hdf5 needs a no-change rebuild once, mpi-defaults passes.
[03:39] <xnox> Logan_: and it's still wrong for hdf5 to pick a non-existant package as a depends.
[03:40] <xnox> Logan_: will you submit mpi-defaults patch to debian?
[03:45] <Logan_> xnox: yes
[03:45] <xnox> cool, thx
[05:16] <Logan_> xnox: Ugh. This hdf5 thing is a mess.
[07:18] <Logan_> xnox: just sent you an e-mail
[07:40] <alkisg> Laney: could you please have a look at https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/474392/comments/11 ?
[07:40] <ubottu> Ubuntu bug 474392 in indicator-session (Ubuntu) "indicator-session menus are not policykit aware" [Low,Confirmed]
[08:29] <alkisg>  /dev/sdb1 on /media/alkisg/usb-stick type vfat (rw,nosuid,nodev,uid=1010,gid=1010,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)
[08:29] <alkisg> ...that means that when I copy a file from that stick to my home folder, other users don't have read access to it
[08:30] <alkisg> That was not the case in the past... shouldn't dmask provide read access to others by default, or at least some other way could be found so that I don't need to manually update the rights of the files I copy from usb sticks?
[08:38] <alkisg> Hmm completely hardcoded... :( http://cgit.freedesktop.org/udisks/tree/src/udiskslinuxfilesystem.c?id=aa02e5fc53efdeaf66047d2ad437ed543178965b
[08:43] <alkisg> For example, if they were mounted under /run/user/uid/mounts, they wouldn't need strict permissions because /run/user/uid would block other users
=== doko_ is now known as doko
[10:01] <Laney> xnox: what happened?
[10:07] <Laney> alkisg: I could maybe take a look after the holidays
[10:07] <Laney> If you're able, a patch would be welcome
[10:10] <alkisg> Laney: I could try a patch for https://bugs.launchpad.net/indicator-session/+bug/1263438, but not for https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/474392/comments/11, that's a bit beyond my current knowledge of the libraries involved :-/
[10:10] <ubottu> Ubuntu bug 1263438 in indicator-session (Ubuntu) "Indicator-session assumes there's only one active user" [Undecided,New]
[10:10] <ubottu> Ubuntu bug 474392 in indicator-session (Ubuntu) "indicator-session menus are not policykit aware" [Low,Confirmed]
=== ValicekB_ is now known as ValicekB
[11:09] <alkisg> (12:10:15 μμ) alkisg: Thanks, I wish you happy holidays! (to Laney... pidgin was too lazy in notifying me that I was disconnected :))
=== freeflying is now known as freeflying_away
[16:18] <doko> $ cat test.c
[16:18] <doko> int main(){return(0);}
[16:18] <doko> $ gcc -fPIE -pie -static test.c
[16:18] <doko> *** Error in `/usr/bin/ld': corrupted double-linked list: 0x0a329260 ***
[16:19] <doko> <and ld hangs ...>
[16:19] <doko> infinity, ^^^ seen with glibc-2.18, not 2.17
[16:21] <doko> kees, is the use of hardening-includes in graphicsmagick correct? the above example calls with -pie -static
[16:21] <doko> gold correctly complains about it:
[16:21] <doko> $ gcc -fuse-ld=gold -fPIE -pie -static test.c
[16:21] <doko> /usr/bin/ld.gold: fatal error: -pie and -static are incompatible
[16:21] <doko> collect2: error: ld returned 1 exit status
[16:33] <xnox> LoganCloud: yeah, don't worry about it =) easily to sort out.
[16:33] <xnox> Laney: so all trackers stopped to update after I've commited ;"ppc64el" in the global config + some trackers that list arches explicitely (ghc?) see commit + revert in the config/ branch.
[16:34] <xnox> Laney: try updating config branch to -r-2 and rerun tracker so check where it blows up?
[18:23] <cjwatson> xnox: Based on the previous syntax my guess would be that ";" is only supposed to separate items in a list, rather than terminating items
[18:23] <cjwatson> xnox: That is, you need to not have the semicolons after ppc64el
[18:23] <cjwatson> (global.conf and monitor/permanent/ghc.ben)
=== jono is now known as Guest49214
[22:01] <ice9> does ubuntu plan to continue using GTK or will move to Qt at sometime?
[22:13] <Noskcaj> ice9, Unity is moving to Qt5 with unity 8
[22:27] <ice9> Noskcaj, so no more GTK? when unity 8 is coming?
[22:29] <mdeslaur> ice9: gtk will still be there
[22:29] <ice9> but why Unity to move to Qt instead of GTK?
[22:29] <Noskcaj> ice9, We'l still use gtk, but unity 8 (which should be out for 14.10), should be Qt
[22:30] <mdeslaur> ice9: unity isn't using gtk at the moment, it's using a toolkit called nux
[22:30] <mdeslaur> ice9: it's moving from nux to qt
[23:16] <xnox> cjwatson: ta.