| mikodo | Can feature requests be made here | 01:54 |
|---|---|---|
| mikodo | I would like to see Mir be developed with it's own feature of inversing the color display. (Independant of X or Xmir with "Xcalib" or by using compositors like Compiz and Kwin). | 02:10 |
| cyphermox | @pilot out | 02:16 |
| === udevbot changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> utopic | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| cyphermox | mikodo: you might want to ask that in #ubuntu-mir; but if you know exactly what needs to be done and can develop the patches yourself, it's likely it would get done faster :) | 02:18 |
| mikodo | cyphermox, Thanks, no I can't do it. I will ask there. | 02:19 |
| cyphermox | np | 02:19 |
| === ScottK is now known as kitterma | ||
| === kitterma is now known as ScottK | ||
| LocutusOfBorg1 | good morning developerz :) | 08:43 |
| === doko__ is now known as doko | ||
| rbasak | bdmurray: is ~ubuntu-reviewers actually active? I've never seen anything come out of an automatic bug subscription. Are we setting false expectations with the automatic comment? | 09:05 |
| sil2100 | didrocks: hey! :) Could I use your archive admin powers and ask for removal of 2 packages from 14.09-proposed in ubuntu-rtm? | 09:18 |
| sil2100 | didrocks: they're part of an invalid transition that we need to re-do | 09:18 |
| didrocks | sil2100: hum, I can try, but I'm unsure how this work for ubuntu-rtm | 09:18 |
| sil2100 | didrocks: ubuntu-system-settings and upower | 09:19 |
| sil2100 | didrocks: thanks o/ | 09:19 |
| didrocks | sil2100: why don't you push new packages with new versions rather? | 09:20 |
| sil2100 | didrocks: that's the plan, but in the meantime I don't want those to cause chaos in other packages building against -proposed | 09:20 |
| didrocks | sil2100: do you know the suite name for ubuntu-rtm? | 09:21 |
| sil2100 | didrocks: suite name? | 09:22 |
| sil2100 | didrocks: the distro is ubuntu-rtm and series 14.09, not sure about the other names | 09:22 |
| didrocks | sil2100: 14.09 is -proposed? | 09:23 |
| didrocks | hum, no, there is a 14.09-proposed apparently | 09:24 |
| sil2100 | didrocks: there's 14.09-proposed as well | 09:24 |
| didrocks | sil2100: fine with you? http://paste.ubuntu.com/9439167/ | 09:24 |
| * sil2100 looks at the list while sweating | 09:25 | |
| willcooke | cking, howdy! Do you know about BGRT? | 09:25 |
| sil2100 | didrocks: I think yes :) | 09:25 |
| * didrocks flushes | 09:25 | |
| didrocks | sil2100: done | 09:26 |
| cking | willcooke, the ACPI table for logos? | 09:26 |
| willcooke | cking, AIUI, yes | 09:26 |
| willcooke | cking, do you know if Grub(?) can support getting it and displaying it during boot? | 09:26 |
| sil2100 | didrocks: thanks again! | 09:27 |
| cking | willcooke, afraid I don't know about that | 09:27 |
| willcooke | cking, no worries. | 09:27 |
| didrocks | sil2100: yw ;) | 09:28 |
| cking | willcooke, maybe worth asking the grub mailing list | 09:28 |
| willcooke | cking, plan - thx | 09:28 |
| mlankhorst | infinity: I've uploaded the pre-requisites, bug 1400626 | 09:30 |
| ubottu | bug 1400626 in xtrans (Ubuntu) "Please backport xtrans, libdrm, x11proto-{fonts,core} packages for 14.04.2" [High,In progress] https://launchpad.net/bugs/1400626 | 09:30 |
| sil2100 | pitti: ping o/ | 09:46 |
| seb128 | sil2100, he's one of the people travelling that might not be on IRC, maybe better to give some context/others might be able to help you? | 09:49 |
| seb128 | willcooke, cjwatson might know about that | 09:49 |
| cjwatson | pitti: Yes, I did the systemd integration for openssh. Please see the end of README.Debian, which explains various caveats with it. | 09:50 |
| cjwatson | seb128,willcooke: GRUB knows how to parse ACPI tables for things like figuring out how to shut down properly, but as far as I know it doesn't use it for anything graphical. You'd have to ask upstream. | 09:54 |
| cjwatson | seb128,willcooke: I mean, if you want anything implemented. Upstream will also tell you that the answer to the question you actually asked is no :-) | 09:55 |
| === vrruiz_ is now known as rvr | ||
| rbasak | Do I need do declare Depends on packages that have Priority: required? Eg. passwd. | 09:55 |
| cjwatson | rbasak: Yes. You may only omit dependencies on packages that are Essential: yes. | 09:55 |
| rbasak | I don't see anything relevant in policy. I get the feeling there's something that says I don't need to do it, but I don't see where. | 09:55 |
| rbasak | Aha. Thanks :) | 09:56 |
| cjwatson | Nothing tells you that you may omit them, therefore you must include them. :-) | 09:56 |
| rbasak | :) | 09:56 |
| willcooke | cjwatson, thanks | 09:56 |
| cjwatson | But people get confused because a lot of required packages are essential. (Counterexample: libc6.) | 09:56 |
| cjwatson | Obviously libc6 is transitively essential, but it's not Essential: yes in its own right. | 09:57 |
| seb128 | cjwatson, thanks | 09:58 |
| seb128 | hallyn, hey, why are cgmanager systemd job disabled by default? | 10:10 |
| === tsimpson_ is now known as tsimpson | ||
| seb128 | cjwatson, do you know what set up the console keyboard layout? it looks like console-setup used to ship an upstart job to do that but that it doesn't do it anymore, what that replaced by something else? | 10:29 |
| ogra_ | there is a hool in the initrd as well ... in case you have fs encryption it is executed | 10:30 |
| ogra_ | *hook | 10:30 |
| seb128 | ogra_, context is that my test laptop has the correct keymap when init is upstart but not when init is systemd, trying to figure out why | 10:31 |
| ogra_ | ah | 10:31 |
| seb128 | /etc/default/keyboard has the correct "fr" config | 10:31 |
| cjwatson | seb128: It has to be done before plymouth starts, so the way it works is that there's an initramfs script that does it if it can, and otherwise /etc/init.d/console-setup should take care of it if plymouth isn't running. | 10:37 |
| cjwatson | seb128: My guess would be that systemd is doing some keyboard handling itself and needs to be adjusted to match up, but I haven't looked. | 10:37 |
| seb128 | cjwatson, k, thanks, I'm going to have a look to console-setup | 10:39 |
| seb128 | cjwatson, systemd is built without vconsole which is the job that handle that | 10:39 |
| seb128 | one #debian-systemd comment suggests that console-common does the config on a Debian systems | 10:40 |
| ogra_ | seb128, i *think* the real thing is not handled by upstart but by udev | 10:40 |
| seb128 | ogra_, udev doesn't change depending of what is pid1 though... | 10:40 |
| alexbligh1 | https://security-tracker.debian.org/tracker/CVE-2014-8106 was I think previously restricted but is now in the open. Reasonably serious qemu vulnerability. I can't find an equivalent LP bug. Would it be appropriate to open one or is there likely a restricted one that I can't see? It's a one line fix. | 10:40 |
| ubottu | ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-8106) | 10:40 |
| seb128 | but could be that something in systemd override the value | 10:40 |
| seb128 | though that should be vconsole which is disabled | 10:40 |
| cjwatson | ogra_: No, that's the font. | 10:41 |
| cjwatson | seb128: Well, yeah, it's probably some other similar component in Debian but that shouldn't matter ... | 10:41 |
| cjwatson | seb128: Maybe check "systemctl status console-setup"? | 10:41 |
| seb128 | cjwatson, that job is loaded/activated with status=0/SUCCESS | 10:45 |
| cjwatson | seb128: Maybe stick strace -f in there and see what it actually ends up doing ... naturally this stuff is an utter pain to debug | 10:46 |
| didrocks | seb128: ok, I'm available now, it seems you want to enable this keyboard thing yourself? (I'm happy to, I'll finish/upload xdiagnose then) | 10:48 |
| flexiondotorg | How do I go about merging the Ubuntu MATE seeds to the official location? | 10:48 |
| flexiondotorg | cjwatson, Can you point me in the right direction? | 10:49 |
| seb128 | cjwatson, ok, I'm going to have a look to that, thanks for the hint | 10:52 |
| seb128 | didrocks, yeah, I started looking at it, doesn't seem really systemd itself | 10:53 |
| seb128 | but lunch first, then back to that | 10:53 |
| cjwatson | flexiondotorg: No, sorry. | 10:54 |
| cjwatson | Hopefully somebody else can help. | 10:54 |
| didrocks | seb128: enjoy! | 10:54 |
| flexiondotorg | Got a name I can contact? I realise your role has changed. | 10:55 |
| === _salem is now known as salem_ | ||
| cjwatson | flexiondotorg: No, but this is the right channel to ask. | 10:55 |
| cjwatson | flexiondotorg: I'd advise starting by being more specific. | 10:55 |
| rbasak | Is there any mounted tmpfs on a buildd that I can rely on to be present for faster tests during the mysql build? | 10:57 |
| rbasak | It'd be too hacky to use /dev/shm I presume? | 10:57 |
| mitya57 | sil2100: hi, have you seen my three appmenu-qt5 fixes? Please review them, as I am also going to submit two more :) | 11:09 |
| mitya57 | (two more will be new features, rather than fixes, and that will be later, maybe next week) | 11:10 |
| flexiondotorg | dholbach, Are you available for a quick chat via PM? | 12:09 |
| === henrix_ is now known as henrix | ||
| dholbach | flexiondotorg, sure | 13:12 |
| dholbach | hey seb128, who could take a look at https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116 and https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-sound-gtk2/+merge/244120? | 13:16 |
| seb128 | dholbach, not sure, anyone in the xubuntu or mate teams I guess? | 13:17 |
| seb128 | ochosi might know who to recommend | 13:17 |
| dholbach | ah... so it's them who maintain indicators-gtk2? | 13:17 |
| seb128 | dholbach, well, see https://launchpad.net/ubuntu/+source/indicator-application-gtk2/+changelog | 13:18 |
| seb128 | dholbach, basically it's for xubuntu/lubuntu and it seems mate | 13:18 |
| seb128 | dholbach, the sound one is fine to upload | 13:18 |
| seb128 | the indicator-application one looks fine to me as well | 13:18 |
| dholbach | mr_pouit, ^ are you fine with me uploading them? | 13:18 |
| seb128 | in fact maybe not | 13:19 |
| ochosi | right, well actually in xubuntu we don't use the gtk2 indicators anymore | 13:19 |
| ochosi | we use gtk3 since 14.04 | 13:19 |
| seb128 | great | 13:19 |
| seb128 | dholbach, I'm unsure about the indicator-application one | 13:20 |
| ochosi | so i don't think any of our devs would really want to maintain that | 13:20 |
| dholbach | seb128, why unsure? | 13:20 |
| seb128 | dholbach, because I wonder if having the dbus activation put it back could lead to have the gtk2 service loading under e.g unity when you don't want it, because it uses the same name on the bus | 13:20 |
| seb128 | ideally the service would be renamed | 13:21 |
| seb128 | let me comment on the mp to ask about that | 13:21 |
| seb128 | dholbach, the other one is fine to upload | 13:21 |
| dholbach | flexiondotorg, ^ | 13:22 |
| flexiondotorg | dholbach, Thanks. | 13:23 |
| flexiondotorg | seb128, The indicator-application-gtk2 has been tested. There are no conflicts. | 13:24 |
| Unit193 | dholbach, seb128: Xubuntu uses GTK3 indicators. | 13:24 |
| Unit193 | Oh, dowh. | 13:24 |
| seb128 | flexiondotorg, how tested? are you sure it's never ever going to start under e.g xfce or unity? | 13:25 |
| flexiondotorg | seb128, Yes. See the reference bug reports. It was tested with MATE installed over Xubuntu. | 13:25 |
| flexiondotorg | https://bugs.launchpad.net/ubuntu/+source/indicator-application-gtk2/+bug/1319352 | 13:26 |
| ubottu | Launchpad bug 1319352 in indicator-application-gtk2 (Ubuntu) "indicator-application does not work in MATE 1.8" [Undecided,Confirmed] | 13:26 |
| flexiondotorg | https://bugs.launchpad.net/ubuntu/+source/indicator-application-gtk2/+bug/1319352/comments/10 | 13:27 |
| flexiondotorg | seb128, Also see https://bugs.launchpad.net/ubuntu/+source/indicator-sound-gtk2/+bug/1208204 | 13:28 |
| ubottu | Launchpad bug 1208204 in Ubuntu Studio "[SRU]Update indicator-sound-gtk2 with patch" [Undecided,New] | 13:28 |
| flexiondotorg | seb128, That patch made the Gtk2 indicator use a different DBus name, so that the indicator-sound-service from this package is loaded instead of the Gtk3 one which is incompatible. | 13:29 |
| === eliasps_ is now known as eliasps | ||
| seb128 | flexiondotorg, what patch makes it use a different dbus name? | 13:29 |
| seb128 | flexiondotorg, https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116 doesn't for sure | 13:29 |
| flexiondotorg | seb128, indicator-application-gtk2 (which the changes I've proposed) has been tested on Xubuntu which which use GTK3 indicators. No conflicts were encountered, | 13:44 |
| seb128 | flexiondotorg, how do you define conflict? if indicator-application-gtk3 is not installed and some client try to use the dbus name it's not going to activate the gtk2 version? | 13:45 |
| flexiondotorg | I'll install stock Ubuntu and Xubuntu and install my patched version of indicator-application-gtk2 and indicator-sound-gtk2 on both to be double sure. | 13:45 |
| seb128 | flexiondotorg, thanks, but as said the case might be more "if indicators are not running and something call to the dbus name" | 13:47 |
| seb128 | but I guess it's a corner case | 13:47 |
| seb128 | in any case I was just pointing it out as a potential issue, feel free to upload as it is as far as I'm concerned | 13:47 |
| flexiondotorg | seb128, I understand your concern. I'll test it now. | 13:47 |
| seb128 | thanks | 13:48 |
| flexiondotorg | seb128, I don't have upload rights. | 13:48 |
| flexiondotorg | dholbach is my sponsor. | 13:48 |
| seb128 | flexiondotorg, well, "you" being your sponsor then | 13:48 |
| flexiondotorg | dholbach, ^^^^ | 13:51 |
| dholbach | flexiondotorg, "sponsor" means somebody who uploads packages for you | 13:52 |
| dholbach | I'd really like to keep sponsorship "free for all" | 13:52 |
| dholbach | that's why we have this approach where folks who need patches or packages uploaded can subscribe a team to bug reports, so a number of folks can go and help out | 13:53 |
| dholbach | and things don't get blocked on a single person | 13:53 |
| dholbach | but yes, I (as many others) am happy to help out :) | 13:53 |
| sil2100 | mitya57: thanks! :) Will look into those tomorrow probably | 14:25 |
| sil2100 | mitya57: today I'm trying to have a take on a bigger package transition in ubuntu-rtm | 14:25 |
| sil2100 | So I won't have time for this probably | 14:26 |
| caribou | I have a question regarding bug #1387594 | 14:48 |
| ubottu | bug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/1387594 | 14:48 |
| caribou | this bug is critical only if the package is rebuilt; the libnss-ldap packages in Utopic and Trusty do work atm | 14:48 |
| caribou | but they will fail if it is rebuilt against the current source. Is it possible to upload a fixed source only to the archive ? | 14:49 |
| xnox | caribou: no, in launchpad we have a strict sources->binaries 1:1 relationship. | 14:50 |
| xnox | caribou: well, you can upload a source which forces a FTBFS if it detects that the built binary has particular problem. | 14:51 |
| caribou | xnox: well, not at the moment, as the binary for libnss-ldap for Utopic and Trusty have not been rebuilt since 2012 | 14:51 |
| xnox | caribou: it seems that fixing that bug is important. | 14:51 |
| xnox | caribou: what do you mean "not at the moment"? | 14:51 |
| caribou | xnox: rebuilding libnss-ldap for Utopic and Trusty will make it fail. The version in the archive works | 14:52 |
| xnox | caribou: each new release forks the previous one, but it's a matching set of binaries for each source, as they were built at the initial upload. | 14:52 |
| xnox | caribou: given that ppc64el binaries were built much later, I presume that bug is in the archive for ppc64el and arm64. | 14:53 |
| xnox | caribou: because those binaries where built much later than regular i386/amd64/etc. | 14:53 |
| caribou | xnox: nope; look at the [TEST] section of the SRU template for that bug | 14:54 |
| caribou | xnox: I understand that it should not be the case, but it is | 14:54 |
| xnox | caribou: can you explain what you believe is currently the case? | 14:54 |
| * xnox sees no inconsistencies at the moment. | 14:54 | |
| xnox | there may ever be a single binary for a given source package on one arch, through the life-time of ubuntu. Thus amd64/i386 were built in 2012, ppc64el in 2014, etc. | 14:55 |
| caribou | xnox: the archive package has libnss_ldap-2.15.so and this version uses _pthread_mutex_lock symbol | 14:55 |
| xnox | the same i386 binary from 2012 is in preice, trusty, utopic, vivid etc. | 14:56 |
| caribou | xnox: rebuilding with the current source will bring libnss-ldap to libnss_ldap-2.19.so and this one uses __libc_lock_lock which is no longer in glibc | 14:56 |
| caribou | xnox: look at the SRU test case for the bug, I ran this a few minutes ago | 14:57 |
| xnox | ... yes, becuase in 2012 we used eglibc 2.15 and didn't rebuild libnss-ldap against eglibc 2.19, yet. | 14:57 |
| xnox | caribou: "Is it possible to upload a fixed source only to the archive ?" the answer is no. | 14:58 |
| xnox | caribou: the source upload, will rebuild and publish updated binaries. | 14:58 |
| xnox | in the SRU. | 14:58 |
| caribou | xnox: ok, I was just wondering if it was possible | 14:59 |
| caribou | xnox: I was just worried of unexpected regressions cause by such a rebuild | 14:59 |
| xnox | caribou: i'm not sure why you started talking about inconsistencies and pointing to the bug test case.... when my answer was only about your question alone. | 15:00 |
| caribou | xnox: because you talk about a 1:1 relationship b/w source & binary which is clearly _not_ the case in this situation | 15:00 |
| xnox | caribou: there should be no regressions as nothing directly links with libnss plugins, they are dlopened at runtime. Thus if a basic test $ getent passwd root works with libnss-ldap installed and configured | 15:01 |
| xnox | you should know that things works. | 15:01 |
| caribou | xnox: and the bug clearly shows that | 15:01 |
| xnox | caribou: there is a 1:1 relationship /in the archive/ between source .dsc & binary .deb. | 15:01 |
| xnox | caribou: it's not possible to publish a new .dsc / .deb with a different checksum for the same version number for the same arch. | 15:02 |
| caribou | xnox: ok, I see what you mean : archive != src pkg in LP; my mistake | 15:02 |
| xnox | caribou: yeah, one has to bump the version number (sru version number) which is a new source + new set of binaries that superseed the previous one. | 15:03 |
| xnox | caribou: you can experiment in a PPA e.g. generate two different packages with the same name and version number, only first one will be accepted. | 15:04 |
| caribou | xnox: I was wrong to assume that pulling the source from LP would give me the same source as what is in the archive | 15:04 |
| xnox | caribou: it does give you the same source... | 15:04 |
| caribou | xnox:s already | 15:04 |
| xnox | caribou: but to get the same binary you need a chroot from 2012 of the release used to build the original binary. | 15:05 |
| xnox | which subsequently was copied from one release to the next. | 15:05 |
| xnox | caribou: we do not rebuild all binaries when we open new series, we keep them. | 15:05 |
| cjwatson | xnox: that's a one-to-many relationship, not a one-to-one relationship :-) | 15:06 |
| xnox | look: https://launchpad.net/ubuntu/+source/libnss-ldap/264-2.2ubuntu4 | 15:06 |
| cjwatson | </twitchy maths geek> | 15:06 |
| xnox | caribou: https://launchpad.net/ubuntu/+source/libnss-ldap/264-2.2ubuntu4 from here amd64, armel, armhf, i386, powerpc were built on quantal to produce _i386.deb etc. and those are copied and were published in quantal, raring, saucy, trusty, utopic. | 15:06 |
| caribou | xnox: ok, I'm going to run a new set of tests just to be safer (even if I already did test each one) | 15:07 |
| xnox | caribou: arm64 deb was build in published in saucy and up. | 15:07 |
| xnox | caribou: ppc64el deb was build & published in trusty and up. | 15:08 |
| xnox | cjwatson: well, my defence is that i said 1:1 per arch, which is 1 to many. | 15:08 |
| xnox | caribou: now, you are claiming that identical source produces a differen tresult when built in trusty chroot. | 15:08 |
| xnox | caribou: that is correct because the comparison is with a binary build in quantal's chroot. | 15:08 |
| caribou | xnox: I'm not too bothered about what I claim, just about the fact that if, for some reason gets rebuilt, it will trigger segfaults & unbootable systems | 15:10 |
| xnox | caribou: cjwatson can tell you a story of unbootable ISOs with an icon changed from one picture to another. | 15:10 |
| xnox | caribou: i'm certain if you rebuild that source in quantal's chroot it will remain bootable without segfaults. | 15:11 |
| rbasak | Is there any mounted tmpfs on a buildd that I can rely on to be present for faster tests during the mysql build? | 15:11 |
| rbasak | It'd be too hacky to use /dev/shm I presume? | 15:11 |
| rbasak | We're wondering about /run | 15:11 |
| xnox | rbasak: is that for out of archive rebuilds, or the official builds for archive.ubuntu.com? | 15:12 |
| xnox | rbasak: tmpfs can cause miscompiles, thus should not be used for official builds. | 15:12 |
| cjwatson | xnox: It's still not one-to-one per arch, since one source produces one *or more* binaries per architecture. | 15:13 |
| xnox | cjwatson: true. | 15:13 |
| caribou | xnox: Am I correct to think that if some other SRU for this library comes in, libnss-ldap will not be rebuilt in a quantal's chroot but a more recent one ? | 15:14 |
| rbasak | xnox: it's for running a test suite quicker, both in official builds and developers test building locally | 15:14 |
| rbasak | xnox: I don't see why it'd cause any miscompiles. It's true use of a RAM-based filesystem for stuff that needs to use a filesystem quickly. No overlayfs or anything like that. | 15:14 |
| caribou | xnox: TL;DR : I don't want to break things that are not broken atm | 15:15 |
| cjwatson | caribou: I'd stop agonising about it and just release a build fix if I were you :-) | 15:15 |
| xnox | caribou: correct. it will be rebuild in the target's chroot and thus a harmless typo fix SRU will cause "crashes & segfaults" | 15:15 |
| caribou | cjwatson: :-D correct. | 15:15 |
| cjwatson | A package that can't be rebuilt safely is bad news | 15:15 |
| caribou | cjwatson: I know, that why slangasek asked me to mark the bug critical & fix it | 15:16 |
| cjwatson | Right, so JFDI rather than worrying about all this :-) | 15:16 |
| cjwatson | You'll get rebuilt binaries, verify that they still work, mark bug accordingly, move on | 15:16 |
| caribou | cjwatson: oh, the SRU is done; just need a sponsor. I only had afterthoughts | 15:16 |
| cjwatson | ok :) | 15:17 |
| caribou | cjwatson: it'll be even worse when I get to upload it myself :-) | 15:17 |
| caribou | xnox: thanks for the clarifications; was good learning | 15:17 |
| bdmurray | pitti: Could you have a look at https://code.launchpad.net/~brian-murray/apport/check-contents-server-age/+merge/244071? | 15:19 |
| xnox | caribou: it would have been even scarier to "upload a fixed source only to the archive ?" cause then you add an extra hop of possible exploadadge which has not been sru verified, sru+2 will not have common/known previous version of neither source or binaries. | 15:19 |
| xnox | s/will not have/ would not have had/ | 15:19 |
| caribou | xnox: yes, indeed | 15:20 |
| xnox | caribou: at lest with this fix, we can verify new binaries and either accept them as good, or fall back to known binaries - which we know are precious, since we can't rebuild them. | 15:20 |
| xnox | caribou: and they will be frozen / accessible if one forces installation from release pocket, without -updates/-proposed/-security enabled. | 15:21 |
| xnox | caribou: oh, and you do want this fix to be published in security pocket and copied into -updates probably. | 15:21 |
| xnox | jdstrand: could you sponsor bug #1387594 into -security? any no-change rebuild of that package will explode at runtime into glitter | 15:22 |
| ubottu | bug 1387594 in libnss-ldap (Ubuntu Utopic) "init: symbol lookup error: /lib/powerpc64le-linux-gnu/libnss_ldap.so.2: undefined symbol: __libc_lock_lock" [Critical,In progress] https://launchpad.net/bugs/1387594 | 15:22 |
| jdstrand | mdeslaur, sarnold: can one of you help xnox with ^ | 15:24 |
| mdeslaur | jdstrand: sure | 15:25 |
| cjwatson | xnox: That's not necessary; the next -security upload, if any, will be based on what's in -updates. https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation | 15:25 |
| xnox | cjwatson: i did not know that. | 15:25 |
| mdeslaur | xnox: yeah, we always rebase on -updates | 15:25 |
| * xnox though -updates are rebased on top of -security | 15:25 | |
| cjwatson | xnox: That is also true. https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories | 15:25 |
| jdstrand | oh yeah, I didn't read that closely enough | 15:25 |
| mdeslaur | both ways :) | 15:25 |
| jdstrand | yeah, we're good already | 15:26 |
| xnox | caribou: right, so just need normal SRU into -updates. | 15:27 |
| mitya57 | sil2100: no problem | 15:38 |
| roadmr | hello folks, anybody from the ~xorg-edgers team in here? | 15:45 |
| caribou | xnox: ok, thanks for checking | 15:47 |
| caribou | now anyone can sponsor :) | 15:48 |
| === jpds is now known as Guest86457 | ||
| pitti | slangasek, mdeslaur, kees, infinity: hi! I try to attend the TB meeting today, but I'm at the snappy sprint so I might get pulled away on short notice | 16:34 |
| mdeslaur | pitti: ack! | 16:34 |
| pitti | kees, infinity, slangasek: TB meeting poke? | 17:02 |
| mitya57 | sil2100: can I reuse LGPL code written by mgraesslin (KDE guy) in appmenu-qt5 code, or it is not possible because he hasn't signed the CLA? | 17:17 |
| * mitya57 wanted to steal QPlatformMenu{,Item} implementations from KDE | 17:17 | |
| stm | Hi there. I have two problems I want to discuss with some experts about building Ubuntu packages on launchpad. | 17:22 |
| stm | It is especially about 64 bit packages. | 17:23 |
| stm | First thing is that most of the time the compiler hangs on the server - maybe due to limited memory. I had the same problem with by virtulized Ubuntu. | 17:24 |
| stm | Ist there any "switch" to force launchpad to use a server with 2 GB memory? | 17:24 |
| teward | stm: "building Ubuntu packages on launchpad" with respect to PPAs, or the main repository builders? | 17:28 |
| stm | I have a PPA on launchpad. | 17:31 |
| stm | What do you mean by main repository builders? Though these are any way the same computers - just a pool for the Ubuntu distro and "private" projects. | 17:33 |
| teward | i meant the builders in the build farm (https://launchpad.net/builders) | 17:33 |
| teward | just clarifying so the true experts can know what you're specifically referring to :) | 17:34 |
| stm | Yes it is packed there - looks someone offers his private computer to do the packaging | 17:34 |
| stm | My problem is that compiling the projects needs a real big memory - also the final program is just 20 MB. | 17:34 |
| stm | Do not ask me why - I am just the package maintainer! | 17:35 |
| teward | stm: i might be willing to dump your stuff into sbuild locally after i update my chroots, and then dump the built binaries onto one of my servers so you can then download them and use them via manual dpkg install, but the ppa builders, I think, are identical and take time to compile large projects | 17:35 |
| stm | I tried to compile the program (gxsm.sf.net) on my virtual machine with 1 GB ram but did not succeed. | 17:36 |
| teward | (you'd also have to define 'hangs' in better detail, because 'hangs' is ambiguous) | 17:36 |
| teward | first, lunch. *disappears for foods* | 17:36 |
| cjwatson | stm: All the virtualised build nodes used for PPAs on Launchpad have a uniform setup with 4GiB of RAM. | 17:43 |
| stm | \query cjwatson | 17:43 |
| === roadmr is now known as roadmr_afk | ||
| stm | I figured out that there are certain differences while building a package on my computer and via launchpad. | 17:46 |
| cjwatson | stm: I'd need to see an example of the build that's hanging. When you use debuild locally, though, you aren't working in a clean environment, so there could be any number of subtle differences. | 17:47 |
| cjwatson | sbuild is a much better test. | 17:47 |
| stm | One problem is also the path to the plugins being /usr/lib/gxsm-plugins on my computer and /usr/lib/x86-64-gnu/gxsm-plugins if compiled and packed on launchpad. | 17:47 |
| cjwatson | stm: You're building on a different Ubuntu release, then, I expect. | 17:48 |
| cjwatson | Launchpad is not doing anything special there itself. | 17:48 |
| cjwatson | I'm pretty confident you'd see the same thing in sbuild locally, if you pointed it at the correct Ubuntu release. | 17:48 |
| stm | I have Ubuntu 14.04 LTS running - 64 bit on a virtual machine | 17:48 |
| cjwatson | The fix is likely to pass an appropriate plugin directory to the upstream configure script. | 17:48 |
| cjwatson | (in debian/rules) | 17:49 |
| stm | The upstream configure sets it to /usr/share/gxsm-plugins for both i386 and AMD64. | 17:49 |
| cjwatson | /usr/lib/x86_64-gnu/ almost certainly comes from debhelper's standard behaviour of passing --libdir=${prefix}/lib/$(DEB_HOST_MULTIARCH) to configure. | 17:50 |
| cjwatson | You can and should override that. | 17:50 |
| stm | I did not want to maintain even different configure scripts. | 17:50 |
| cjwatson | (Possibly --libexecdir.) | 17:50 |
| cjwatson | You don't have to. | 17:50 |
| cjwatson | But you still haven't told us where to find the offending build ... | 17:50 |
| stm | Sorry - not as a quick writer than you: https://launchpad.net/~totto/+archive/ubuntu/gxsm/+build/6628573/+files/buildlog_ubuntu-trusty-amd64.gxsm_3.10.4-0ubuntu11_FAILEDTOBUILD.txt.gz | 17:51 |
| cjwatson | That build appears to be failing with a compiler error, not hanging? | 17:52 |
| stm | It is not hanging with I386 and not an my computer! | 17:53 |
| cjwatson | But it's not a hang. | 17:53 |
| cjwatson | It's just failing to compile. | 17:53 |
| cjwatson | pyremote.C: In function 'PyObject* remote_move_delta_xyz(PyObject*, PyObject*)': | 17:54 |
| stm | I had this on my computer as the memory (1GB) was too low. | 17:54 |
| cjwatson | pyremote.C:766:23: error: 'class XSM_Hardware' has no member named 'Move_delta_XYZ' | 17:54 |
| cjwatson | gapp->xsm->hardware->Move_delta_XYZ (dx, dy, dz, NULL); | 17:54 |
| cjwatson | ^ | 17:54 |
| cjwatson | I do not believe that that is a problem with insufficient memory. | 17:54 |
| stm | The "search path" for the plugins is the in configure.ac as AC_DEFINE_UNQUOTED(PACKAGE_PLUGIN_DIR, "${ac_default_prefix}/lib/gxsm-plugins" or AC_DEFINE_UNQUOTED(PACKAGE_PLUGIN_DIR, "${prefix}/lib/gxsm-plugins", depending if "prefix" exists or not. | 17:56 |
| cjwatson | There are two definitions of "class XSM_Hardware" in this project, and only one of them has a "Move_delta_XYZ" member. | 17:57 |
| cjwatson | stm: debian/rules is constructed very strangely and really ought to be rewritten entirely or else you're going to get very confused in other ways. | 17:57 |
| stm | There is an abstract class XSM_hardware and the final implementation. | 17:57 |
| cjwatson | stm: Specifically it is extremely strange to use a %: dh $@ rule and then also manually write out clean, install, build, binary-indep, binary-arch. | 17:58 |
| cjwatson | And DEB_BUILD_OPTIONS should not be set there. | 17:58 |
| stm | I was happy to get it running any way. I know you can have the packaging just by a one line rule file but that did not work here. | 17:59 |
| cjwatson | Oh, and DEB_CONFIGURE_EXTRA_FLAGS is ineffective. That comes from cdbs, which you are not using here. | 17:59 |
| cjwatson | None of this is a problem with Launchpad - you could reproduce the exact same problem with sbuild. https://wiki.ubuntu.com/SimpleSbuild | 18:00 |
| cjwatson | I recommend investing time in setting that up | 18:00 |
| cjwatson | But let me see if I can give you a sketch of a better-constructed rules file | 18:00 |
| cjwatson | I see no evidence of the /usr/lib/$(DEB_HOST_MULTIARCH)/gsxm-plugins/ problem you mention in the working i386 build, by the way ... | 18:01 |
| cjwatson | Anyway, since this package doesn't install any libraries of its own, it's safe to override dh_auto_configure and pass --libdir; though the upstream should really be modified to use libexecdir for that. | 18:02 |
| stm | The sbuild looks a little like the pebuilder enviroment, doesn't it? | 18:02 |
| cjwatson | More or less, yes. | 18:02 |
| cjwatson | (You mean pbuilder, I think.) | 18:03 |
| stm | yes | 18:03 |
| cjwatson | The upstream configure.ac is inconsistent in other ways. It defines PACKAGE_PLUGIN_DIR, but then defines plugindir differently. It should be revised upstream. | 18:04 |
| stm | okay - guess that part was introduced 10 years ago. Certainly one would do better. Everyone is learning! | 18:06 |
| cjwatson | stm: I would start by reducing debian/rules to http://paste.ubuntu.com/9444836/, with an added Build-Depends on dh-autoreconf (in debian/control). | 18:09 |
| stm | see the point about the two definitions - thanks for pointing this out. | 18:09 |
| cjwatson | stm: And then it will be much easier to follow if you put an upstream tarball in the parent directory as gxsm_3.10.4.orig.tar.gz, so that the source package is constructed with all the packaging bits in a separate file. | 18:10 |
| cjwatson | stm: I see that you have a build rule that copies src to gxsm. I suspect that what's happening here is that the conflict between your catch-all % rule and the manual "build" rule is resolved differently on amd64 vs. i386 - on trusty, i386 will go via "build" and all other architectures will go via "build-arch". That's why you'll have a better time sticking to one syntax. | 18:11 |
| cjwatson | stm: So the effect of that is that you end up with a stale copy of src used for other architectures. | 18:11 |
| cjwatson | stm: You should make sure to clean up the gxsm directory at some point, if you need to do it that way at all (it's an odd way to do things, though occasionally necessary); in my rewritten rules file you'd use an override_dh_auto_clean rule to do that. | 18:12 |
| cjwatson | stm: (Oh, you do clean it up at the start of build, I see. Still, I'd recommend doing that in clean instead.) | 18:13 |
| stm | @cjwatson - let me try that shortened rules files and have a look. | 18:17 |
| udevbot | Error: "cjwatson" is not a valid command. | 18:17 |
| stm | I will try tonight to modify - right now I have just a hand on a windows machine - need my laptop at home. | 18:18 |
| cjwatson | So to explain it a little differently, the conflict between two entirely different styles in debian/rules meant that, without realising it, you had one build rule which was run on i386 and one build rule which was run on all other architectures (for your PPA, that's just amd64). | 18:19 |
| cjwatson | And those two build rules had nothing in common ... | 18:19 |
| stm | see the problem now a little by more clear. | 18:21 |
| cjwatson | I haven't actually tested my rewritten file, of course :) | 18:21 |
| stm | Now problem - I will do that! | 18:22 |
| stm | You mind if I contact you again - for some progress report? | 18:22 |
| stm | I will have to go home now - I am for 12 h at the university and need urgently food and my girl friend. | 18:23 |
| stm | I have also the alias stm at sourceforge.net - so in case you have another briliant idea. | 18:24 |
| stm | But your input was already helping me to get a new view on may problem. | 18:24 |
| stm | So thank you very much, cj | 18:25 |
| cjwatson | stm: I don't mind, but in general I'm only around in UK working hours. | 18:26 |
| cjwatson | stm: No need to contact me if it works. | 18:26 |
| stm | Thanks and bye. | 18:26 |
| === roadmr_afk is now known as roadmr | ||
| dannf | what's the appropriate list to discuss enabling 64K pages on arm64? ubuntu-devel-discuss? | 20:09 |
| stm | <cjwatson> Are you stil online? | 20:46 |
| stm | Got it mostly working, but now it hangs during the install. | 20:47 |
| stm | cp -a debian/tmp/usr/bin/gxsm2 debian/gxsm//usr/bin/ cp: cannot stat ‘debian/tmp/usr/bin/gxsm2’: No such file or directory | 20:47 |
| stm | Guess the error is in the gxsm.install | 20:47 |
| stm | Here I have just the line "usr/bin/gxsm2" | 20:48 |
| === dpm is now known as dpm-afk | ||
| TheNumb | o/ | 21:23 |
| sarnold | doko: are you sure intel-microcode can go to main? it does include intel-provided binary blobs. https://bugs.launchpad.net/bugs/1388889 | 21:29 |
| ubottu | Launchpad bug 1388889 in intel "[MIR] intel-microcode & iucode-tool (multiverse -> restricted)" [Undecided,New] | 21:29 |
| === roadmr is now known as roadmr_afk | ||
| === salem_ is now known as _salem | ||
| === roadmr_afk is now known as roadmr | ||
| doko | sarnold, my mistake, now fixed | 22:21 |
| sarnold | doko: thanks | 22:21 |
| brainwash | pitti: will you package systemd 218 (once available) or will 15.04 ship with 217? | 22:50 |
| brainwash | I'm not sure if I should request to pick a commit from git | 22:51 |
| brainwash | http://cgit.freedesktop.org/systemd/systemd/commit/src/libudev/libudev-hwdb.c?id=8232e39e7cf32071e11b3b04839e6c98fbc81d0f | 22:52 |
| brainwash | :) | 22:52 |
| shadeslayer | kirkland: do you know where I can get the source for the snappy tool? | 23:45 |
| shadeslayer | or maybe even design docs or whatever to get a idea of what magic is going on underneath | 23:45 |
| kirkland | shadeslayer: https://code.launchpad.net/~snappy-dev | 23:46 |
| shadeslayer | cheers | 23:47 |
| kirkland | shadeslayer: snappy is built on click (the package system for the ubuntu phone) | 23:47 |
| shadeslayer | ah ok | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!