=== JackyAlcine_ is now known as JackyAlcine === sagaci_ is now known as sagaci === almaisan` is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [08:19] With this http://paste.ubuntu.com/838760/, I still get the hardening flags in $CFLAGS. According to dpkg-buildflags' man-page, "export DEB_BUILD_MAINT_OPTIONS = hardening=-all" should disable hardening. What am I doing wrong? [08:20] we have some default hardening in our toolchain, I wonder if that's supposed to be removed in this case [08:22] micahg: If I call 'DEB_BUILD_MAINT_OPTIONS=hardening=-all dpkg-buildpackage' CFLAGS is set correctly so I guess it should. [08:23] you have extra space around the first = in the paste, idk if that would make a difference though [08:24] It's a makefile so that shouldn't matter. [08:24] It doesn't. [08:25] Ampelbein: to get the effect of DEB_BUILD_MAINT_OPTIONS you need to export CFLAGS et al yourself [08:27] tumbleweed: Ah, ok. I was under the impression that dpkg-buildflags handles that for me. [08:27] debian bug 644412 sounds related [08:27] Debian bug 644412 in dpkg-dev "dpkg-buildflags: use DEB_BUILD_MAINT_OPTIONS when including buildflags.mk" [Normal,Fixed] http://bugs.debian.org/644412 [08:28] Ampelbein: it handles it for you, if you use it [08:28] sure, you can use buildflags.mk [08:28] or just do it by hand (I do that in pypy) [08:29] What I don't get is: It works correctly if I do 'DEB_BUILD_MAINT_OPTIONS=hardening=-all dpkg-buildpackage' [08:37] that's because dpkg-buildpackage runs dpkg-buildflags [08:38] (although that behavior has been dropped in Debian) [08:38] we'll presumably follow suit in q [08:48] Ampelbein: don't forget to document the disabling of hardening flags on the security wiki page (I assume you trying disabling some of them before all) [08:49] micahg: It's about a fpc using package (gearhead), which should not have hardening enabled in the first place as the programming language is pascal. [08:52] Ampelbein: hmm, if that's true, then we probably need a more generalized solution for this that disabling on a per package basis [08:53] micahg: The build failure in question: https://launchpadlibrarian.net/92025261/buildlog_ubuntu-precise-i386.gearhead_1.100-2_FAILEDTOBUILD.txt.gz [08:54] That's another thing I don't understand. According to the manpage of dpkg-buildflags, only in dh compat level 9 should the flags be exported. The package uses compat level 5... [08:55] we have -fstack-protector in our toolchain by default amongst other things [08:55] did you try just without that? [08:55] Yes, fpc doesn't understand any -format, -format-security, -fstack-protector [08:55] Ampelbein: we export the build flags in dpkg-buildpackage [08:55] * tumbleweed digs out the e-mail announcing that [08:57] still, there are about a dozen packages that use fpc, I'm wondering how any of them built befre [08:57] Ampelbein: https://lists.ubuntu.com/archives/ubuntu-devel/2011-November/034351.html [08:58] micahg: In the case of gearhead, the last build was october 2010 [08:59] Where CFLAGS didn't include any of the hardening flags (https://launchpadlibrarian.net/48191679/buildlog_ubuntu-maverick-i386.gearhead_1.100-2_FULLYBUILT.txt.gz) [08:59] tumbleweed: thanks, reading. [08:59] ah, ok [09:00] our gcc also does hardening flags by default, doesn't it [09:00] * tumbleweed forgets [09:00] yeah, but this is fpc which is why it worked before, now the hardening has moved [09:01] micahg: thanks for reminding me tha tI should document the lack of hardening in pypy [10:42] hmm, so what's the proper version for a lucid-backport? (heading to the wiki to check herself …) [10:44] hmm, either I missed it, or https://wiki.ubuntu.com/UbuntuBackports doesn't state so … [10:49] duh [10:49] Make people more aware of backports, and make the backport request process less transparent [10:49] shouldn't that read MORE transparent instead of LESS transparent?!? [10:49] * Rhonda . o O ( from https://wiki.ubuntu.com/BackportsPromotion ) [10:50] … not that the page looks in any sense relevant, or current. :) [11:00] oh hai Rhonda -- want to do some syncs for me again? :) https://bugs.launchpad.net/ubuntu/+source/pokerth/+bug/930906 https://bugs.launchpad.net/ubuntu/+source/monkeystudio/+bug/930907 [11:00] Ubuntu bug 930906 in pokerth (Ubuntu) "Sync pokerth 0.9.3-1 (universe) from Debian sid (main)" [Undecided,New] [11:00] Ubuntu bug 930907 in monkeystudio (Ubuntu) "Sync monkeystudio 1.9.0.1-2 (universe) from Debian sid (main)" [Undecided,New] [11:00] (yes, yet another pokerth update, sorry, upstream is active) === yofel_ is now known as yofel [11:02] hmmm, start to wonder what the build1 of monkeystudio was for [11:02] Rhonda, libqscintilla 2.6.0 i guess [11:02] it bumped soname some month or two ago [11:03] ah, that build1 was also available in debian, and not only in ubuntu? [11:03] yepp [11:03] +b1 there of course, but you get the point [11:04] subject: [ubuntu/precise] monkeystudio 1.9.0.1-2 (Accepted) [11:04] subject: [ubuntu/precise] pokerth 0.9.3-1 (Accepted) [11:04] thanks a lot [11:05] de nada [11:05] now tell me what version I need to use :) [11:05] ~bpo60+1 [11:05] :P [11:06] does 1:1.10-1~lucid1 look proper? [11:06] Zhenech: ~bpo60+1 is done already ;) [11:07] Rhonda: looks right for the official version, backportpackage can help though with an unofficial version to be superseded if backported in the archive [11:08] Rhonda: why didn't you sponsor the syncs? (syncpackage -s) [11:08] oh [11:08] erm, because I forgot about that :) [11:09] heh, ok :) [11:09] I would have thought that is done implied when I have the rights to [11:09] Because it does use launchpad anyway? [11:10] well, you have rights to upload, but -s gives whoever you pass to it the credit for the sync [11:10] ah, so -s zhench? [11:11] or rather, sargentd [11:11] will try to remember [11:11] yep [11:12] mh, reminds me I wanted to get ~evgeni on launchpad some time… [11:13] but that means i have to kill my ppas [11:13] cant you transition them? [11:14] creating a new user and then moving around? yeah could work [11:14] lp is able to rename users though, they just cannot have ppas [11:14] no, get the accounts merged [11:14] ah [11:14] only recently started with ppas [11:17] mh, the only really used ppa is the monkeystudio one and we could just move it to the monkeystudio group… [12:06] would make it more official looking, yes === tsimpson_ is now known as tsimpson [20:11] Still ok to do sync requests ? [20:13] dupondje: Feature Freeze is on thursday, so yes. [20:16] ok :) lets do some [21:10] to be clear, FeatureFreeze doesn't mean we can't do syncs/merges anymore. it just means that either they have to only contain bugfixes (no new features) or they have to be approved by the release team (which isn't that hard, especially immediately after FF) [21:11] but its better to do it asap ofc ;) [21:12] as long as you don't break enerything, sure [21:12] everything [21:13] 'break everything' would be starting a new major library transition this week, without serious coordination [21:37] new packages also allowed? http://packages.qa.debian.org/d/daq.html [21:37] would like to get the prehistoric snort gone :) [21:41] dupondje: nothing wrong with new packages (in moderation) [23:33] Hello [23:34] Anyone there [23:34] no [23:34] Nobody is chatting so I was just wondering [23:35] Whats up with you Mr Webb? [23:37] Grammys is on tonight === ripps_ is now known as ripps