=== cpg is now known as cpg|away
[00:09] <BenC> Laney: I'll check on it
[00:11] <BenC> Laney: hopefully that failure is something stupid like endian issues
[00:48] <darkxst_> jbicha, any idea where I can file a bug against gdm off ricotz ppa?
[00:56] <jbicha> darkxst_: you can go ahead and file against gdm, once we get the bugs worked out, I'd like to upload the newer gdm into ubuntu and filing that bug helps
[00:59] <darkxst_> jbicha, ok
=== cpg|away is now known as cpg
[02:37] <darkxst_> jbicha, with a trivial patch and can now boot into gdm ;)
[02:49] <jbicha> darkxst_: cool!
[02:51] <jbicha> darkxst_: the other two major bugs we have are: broken locale support and the keyring doesn't get auto-unlocked
[02:57] <darkxst_> jbicha, yeh I noticed the keyring thing
[02:59] <jbicha> I'm guessing we should look at the PAM code for that
[03:28] <darkxst> jbicha, looks like it is using the autologin pam profile
[03:30] <darkxst> when it probably should be using /etc/pam.d/gdm (for password login)
=== cpg is now known as cpg|away
[03:52] <pitti> Good morning
[04:13] <darkxst> jbicha, however when I change to the correct pam profile, gdm breaks ;(
[04:17] <jbicha> darkxst: well that might not be it. What I was referring to is that upstream now ships 3 different PAM profiles
[04:17] <jbicha> and the current Ubuntu profile is slightly different than the Debian one but I don't understand the GDM/PAM stuff
[04:17] <jbicha> http://git.gnome.org/browse/gdm/tree/data
[04:18] <darkxst> jbicha, yeh, and the debian packaging is using the gdm-autologin profile
[04:57] <darkxst> jbicha, I think I fixed it
[05:01] <darkxst> jbicha, you need to create another link in gdm.postinst
[05:02] <darkxst> ln -s gdm /etc/pam.d/gdm-password
[05:23] <darkxst> jbicha, I have to run, filed this https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1042052
[05:23] <ubottu> Launchpad bug 1042052 in gdm (Ubuntu) "gnome keyring auto-login failure" [Undecided,New]
=== cpg|away is now known as cpg
=== larsu_ is now known as larsu
=== zumbi is now known as Guest29026
[07:13] <dholbach> good morning
=== jussio1 is now known as jussi
[07:24] <dholbach> ogra_, would it be possible for you to swap with bilal on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable?
[07:38] <tumbleweed> dholbach: can bilal make later on wednesday (ideally, I'd like to swap too, something came up on wednesday evening. an earlier slot or different day would be great)
[07:38] <dholbach> tumbleweed, no bilal can only make Tuesday
[07:38] <tumbleweed> ah, never mind then
[07:39]  * tumbleweed will survive
[07:39] <bilal> I'll be unavailable throughout Wednesday and Thursday
[07:53] <dholbach> ivoks, happy birthday! :)
[07:57] <ogra_> dholbach, i would have answered the mail if i could ... :)
[07:57] <dholbach> ah ok, yes - you were CCed
[07:59] <ogra_> (i got teh same meetings as barry)
[08:00] <dholbach> I'm sure slangasek would understand, if you missed one and gave somebody else your notes :)
[08:01] <ivoks> dholbach: thanks :)
[08:03] <bilal> dholbach: so that leaves us with mterry, right? let's see if he agrees
[08:03] <ogra_> dholbach, apart from the fact that i have to write up a summary of the meeting for the release meeting on friday, yeah :P
[08:06] <dholbach> ogra_, there's always the logs and it'd give you an extra day to prepare your session :)
[08:07] <ogra_> haha, you wont convince me :)
[08:18] <dholbach> can somebody help me reject a few merge proposals?
=== cpg is now known as cpg|away
[08:21] <dholbach> can somebody please reject the following merge proposals? http://paste.ubuntu.com/1169455/
[08:53] <pitti> dholbach: erledigt :)
=== doko__ is now known as doko
[09:14] <dholbach> danke pitti
[09:15] <dholbach> pitti, do we have a tool which tells us if a source package can be safely removed? (check all packages if they're a depends or build-depends somewhere)
[09:18] <hsn> what can i do for help translating ubuntu?
[09:18] <pitti> dholbach: there is checkrdepends in ubuntu-archive-tools, but it needs a mirror to work with
[09:19] <dholbach> ah ok, thanks pitti
[09:19] <pitti> dholbach: there is reverse-depends and reverse-build-depends in ubuntu-dev-tools, but I guess they only check the architecture you are running on, not all of them
[09:20] <dholbach> thanks
[09:24] <dholbach> pitti, updated https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive
[09:24]  * ogra_ curses launchpad 
[09:24] <ogra_> *LOUDLY*
[09:25] <ogra_> thats the third time i file a bug today and end up at the error page ...
[09:25] <ogra_> with all my input lost :(
[09:26] <dholbach> pitti, did you get some bug reports about apport using 100% cpu for an extended period of time?
[09:29] <Sweetshark> ogra_: cursing doesnt help, do the angry-old-man-fistshake!
[09:29] <ogra_> heh
[09:30] <ogra_> well, it helped to file bug 1042151
[09:30] <ubottu> Launchpad bug 1042151 in libdri2 (Ubuntu) "MIR: libdri2 needs to be in main for pvr-omap4 (restricted) to build" [Undecided,New] https://launchpad.net/bugs/1042151
[09:30] <ogra_> pitti, btw, the component-mistmaches tool that sends the reports to ubuntu-release doesnt seem to take restricted build-deps into account, is that on purpose ?
[09:30] <Sweetshark> ogra_: http://www.sherv.net/cm/emo/angry/angry-old-man-smiley-emoticon.gif <- threaten lp with that
[09:31] <ogra_> LOL
[09:37] <pitti> erk, DSL reconnect
[09:37] <pitti> dholbach: wiki> thanks
[09:37] <pitti> dholbach: apport 100% cpu> not recently; can you reproduce it?
[09:39] <pitti> ogra_: it's meant to consider restricted
[09:39] <dholbach> pitti, it's happening right now and happened some days ago too
[09:40] <dholbach> pitti, I can give you the logs and the crash file it's currently working on (at least according to lsof)
[09:40] <pitti> dholbach: which process in particular is using the CPU? (check in top)
[09:40] <pitti> dholbach: something called from a hook, or apport-gtk itself?
[09:41] <dholbach>  /usr/bin/python3 /usr/share/apport/apport 2662 11 0
[09:41] <pitti> oh, that part, it's still crashing
[09:42] <dholbach> what do you want me to do? :)
[09:42] <pitti> most of the activity is usually due to compressing core dumps; what crashed exactly?
[09:42] <pitti> dholbach: can you strace it and check if it's still reading data?
[09:42] <pitti> if it doesn't read anything but burns CPU, attaching gdb to it and seeing where it's currently stuck might help, too
[09:43] <pitti> if the core dump is huge, compressing it will take a bit, but that's the only thing I'm aware of
[09:43] <pitti> if it's stuck somewhere else, I'm interested in fixing that
[09:44] <dholbach> I guess the core dump was huge and it just finished and redirected me to (https://launchpad.net/bugs/929219)
[09:44] <ubottu> Launchpad bug 929219 in gwibber (Ubuntu Precise) "chromium-browser, gvfsd-http and others using eglibc crash with SIGSEGV in __nscd_get_mapping() or gethostbyname2_r()" [Undecided,New]
[09:45] <dholbach> but it took like 10-15 minutes at the very least on a quad-core machine with SSD disk
[09:45] <dholbach> sounds a bit weird
[09:45] <pitti> how big is the .crash?
[09:45] <dholbach> 29M
[09:46] <pitti> ok, that's not exactly small; I'll take a closer look once the bug gets retraced and I can access it
[09:47] <pitti> there might be a way to speed it up somehow, python's zlib might be much slower than calling gzip and piping
[09:48] <dholbach> ok
[09:49] <pitti> dholbach: oh, this bug -- LP timed out
[09:51] <pitti> dholbach: oh, this bug -- LP timed out
[09:51] <pitti> sorry, EFOCUS
[09:52] <tumbleweed> everyhting seems to timeout these days :/
[10:03] <ogra_> micahg, seeing the xubuntu build failures you might want the same seed change lubuntu-meta got recently
[10:03] <ogra_> or mr_pouit ^^^
[10:26] <doko> hmm, any qmake exports online?
[10:43] <Sweetshark> moin all!
[10:45] <Sweetshark> seb128: can you unconfuse me about source package clucene-core? there is a version 2.3.3.4-2 in debian but an autosynced 0.9.21b-2 in quantal. how is that?
[10:46] <seb128> Sweetshark, http://packages.qa.debian.org/c/clucene-core.html
[10:46] <seb128> unstable
[10:46] <seb128>     save 0.9.21b-2
[10:46] <seb128> sorry about the "save", select fail
[10:46] <seb128> Sweetshark, we don't think from experimental by default
[10:48] <Sweetshark> seb128: ah, doh - the debian package pages are even more confusing than lp. I took a wrong turn and got diverted to experimental.
[10:50] <seb128> Sweetshark, I've a bookmark with a keyword on "http://packages.qa.debian.org/%s"
[10:50] <seb128> so I can just "debsrc <source>" in my firefox and get to the summary page
[10:51] <seb128> the pts pages are easy to ready and have most of the infos you need
[10:51] <Sweetshark> seb128: so debian uses system clucene now: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661703 -- shall I continue to use the internal clucence copy (Im doing that now, but it makes the package bigger obviously) or shall we try to FFE clucene from experimental?
[10:51] <ubottu> Debian bug 661703 in clucene-core "clucene-core: upload latest clucene git + contrib-libs to experimental" [Normal,Fixed]
[10:54] <xclaesse> upgrades should *really* remove old kernel images and headers
[10:54] <xclaesse> this weekend I had to fix my mother's computer: a 15G / partition full for a simple ubuntu installation (initial install was some years ago)
[10:56] <xclaesse> reason: kernel images and headers accumulated (since 2.6.24) was taking ~9G
[10:56] <seb128> Sweetshark, go for the ffe I guess
[10:56] <xclaesse> seriously, it still had 2.6.24 kernels on a Precise system...
[10:56] <seb128> xclaesse, yeah, it's a known issue (and surprisingly hard to get resolved) :-(
[10:57] <xclaesse> seb128, it happened exactly 0 times to need an older kernel
[10:57] <xclaesse> in all my ubuntu experience
[10:57] <xclaesse> the package could just replace the previous one
[10:57] <xclaesse> that should be trivial, no?
[10:58] <xclaesse> (well, being a dev as well, I know things that seems trivial aren't :)
[10:59] <ricotz> xclaesse, replacing the previous kernel is a *bad* idea!
[10:59] <seb128> xclaesse, well, if there is a bug for your hardware on the new kernel one day you will be happy to have an old kernel to boot
[11:00] <ricotz> xclaesse, seb128 a simple sweep-tool suggesting to remove *ancient* kernels of previous ubuntu release would be reasonable though
[11:02] <Bluefoxicy> blah.
[11:02] <Bluefoxicy> https://bugs.launchpad.net/ubuntu/+source/libmtp/+bug/1042194
[11:02] <ubottu> Launchpad bug 1042194 in libmtp (Ubuntu) "MTP + Nautilus fails with a lot of files on device" [Undecided,New]
[11:03] <Bluefoxicy> probably a duplicate of something, since there's 10 million MTP bugs listed in launchpad but none look quite like what I'm looking for
[11:03] <Bluefoxicy> they're all like "Cannot use X device" or "cannot write files to Sony walkman"
[11:05] <Sweetshark> seb128: https://bugs.launchpad.net/ubuntu/+source/clucene-core/+bug/1042192
[11:05] <ubottu> Launchpad bug 1042192 in clucene-core (Ubuntu) "[FFE] new clucene version needed for LibreOffice" [Undecided,New]
=== MacSlow is now known as MacSlow|lunch
=== tkamppeter__ is now known as tkamppeter
=== _salem is now known as salem_
[12:16] <micahg> pitti: dholbach: reverse-depends and reverse-build-depends at least in 12.04+ should query ubuntuwire and check all archs AIUI
[12:16] <dholbach> ah cool
=== dendro-afk is now known as dendrobates
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
=== MacSlow|lunch is now known as MacSlow
[12:40] <Laney> excuse me while I repeat my question from #-release yesterday
[12:40] <Laney> to update P-a-s, do we just push to lp:~ubuntu-core-dev/packages-arch-specific/ubuntu?
[12:40] <Laney> is there some workflow to sync it with Debian or something?
[12:42] <jamespage> Laney, I'm pretty sure that is the right branch - P-a-S syncs periodically from it from memory
[12:43] <Laney> I think I remember some weird workflow but I'm not sure
[12:48] <Laney> https://wiki.ubuntu.com/PackagesArchSpecific
[13:21] <mterry> ogra_, hello!  So this dri2 MIR: you mention it's a split out copy from mesa, but it doesn't look like it's the same content as the other dri2.c files in mesa?  (forgive me, I'm not super familiar with graphic drivers)
[13:22] <ogra_> i dont think its a 1:1 code copy, no
[13:23] <mterry> ogra_, OK.  And it's a separate upstream?  Like a fork of the code or something?  Why use this instead of mesa's libs?
[13:24] <ogra_> there are no libs in mesa for dri2 atm, thats the point :)
[13:24] <ogra_> everyone accesses it differently
[13:24] <ogra_> this is an attempt to unify
[13:24] <mterry> ah
[13:25] <mterry> and the hope is that mesa would use it in the future?
[13:25] <mterry> or at least various drivers (like the arm one does apparently) use it
[13:25] <ogra_> mterry, http://paste.ubuntu.com/1169816/
[13:26] <ogra_> rob is the upstream (thats also on irclogs.u.c in the #ubuntu-arm channel from 23rd if you want to see more context)
[13:26]  * mterry reads
[13:28] <mterry> k
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
=== Guest92976 is now known as dpb___
[14:04] <hrw> hi
[14:04] <mterry> mvo, hello!  Btw, that phased-updates branch does still have an error in it on i386 branches.  I had told you that it didn't, but that's only when running nosetests3 directly on it.  If you run nosetests3 on the suite, previous tests that instantiate MyCache, which inits the apt_pkg system seem to mess one of your tests up
[14:05] <hrw> I added debdiff to fix aptitude bug 824708 for precise. Can someone take a look at possible SRU?
[14:05] <ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "aptitude can no longer show changelogs: "Changelog download failed: Download queue destroyed." Please merge the fixed version, 0.6.8, from Debian." [Medium,Fix released] https://launchpad.net/bugs/824708
[14:05] <mterry> mvo, because the apt_pkg system is initialized with i386 and then later you try to use amd64, but it's ignored
=== scott-work is now known as Guest49317
=== zyga is now known as zyga-afk
[14:59] <bdrung> kengyu: have you heard of wrap-and-sort?
[15:00] <kengyu> bdrung, no. (sorry for the author) :-)
[15:01] <bdrung> kengyu: now you have. ;) i recommend to use it :)
[15:03] <kengyu> bdrung, yes, I will definitely try it. :-)
[15:04] <bdrung> kengyu: http://lintian.debian.org/full/kengyu@lexical.tw.html
[15:05]  * bdrung pressed crtl+w in the wrong window.
[15:41] <smoser> cyphermox, around?
[15:42] <cyphermox> smoser: yup
[15:42] <smoser> i've just rebooted this system, logged back in, and busted resolv.conf
[15:42] <smoser> (you helped me before with https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1034946)
[15:42] <ubottu> Launchpad bug 1034946 in network-manager (Ubuntu) "dnsmasq and network manager broken if dnsmasq package has 'enable-dbus'" [Critical,Fix released]
[15:42] <cyphermox> smoser: check if it's the same as https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1042275
[15:42] <ubottu> Launchpad bug 1042275 in dnsmasq (Ubuntu) "dnsmasq updating resolvconf when it's not configured to do DNS" [Medium,Confirmed]
[15:43] <cyphermox> basically, you'd see 127.0.0.1 in /etc/resolv.conf
[15:44] <smoser> yes
[15:44] <smoser> i do have dnsmasq installed
[15:45] <smoser> just a bit of fyi, lxc installs: /etc/dnsmasq.d/lxc
[15:45] <smoser> http://paste.ubuntu.com/1170081/
[15:47] <smoser> anyone else with a second display running current unity in quantal?
[15:49] <smoser> i can' make "auto hide the launcher", "sticky edges" or "launcher placement" work. it wont hide, appears on all displays, and i have that annoying sticky edges.
[15:51] <smoser> cyphermox, so you're telling me "disable" ?
[15:52] <cyphermox> smoser: I can test the dual display in a second (need to take my laptop because if i upgrade this system it might break)
[15:52] <cyphermox> smoser: no, I'm telling you if it's the same thing we need to figure out why dnsmasq writes that file out when it really really shouldn't :)
[15:53] <cyphermox> as a workaround you could disable the system dnsmasq, or the one from network-manager if the system one is properly configured
[15:53]  * cyphermox is starting to dislike dnsmasq
[16:04] <smoser> cyphermox, thanks.
[16:08] <smoser> cyphermox, well, disabling the system dnsmasq makes my current pain point go away.
[16:08] <cyphermox> yeah it's just not optimal if you need it ;)
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
=== Beret- is now known as Beret
[17:19] <ogra_> infinity, did the branch for livecd-rootfs move or did colin actually not commit his changes
[17:20] <infinity> ogra_: Eh?  Looks committed to me.  Or did you just do that?
[17:20]  * infinity checks the log.
[17:21] <infinity> revno: 602
[17:21] <infinity> tags: 2.76
[17:21] <infinity> committer: Colin Watson <cjwatson@canonical.com>
[17:21] <infinity> branch nick: livecd-rootfs
[17:21] <infinity> timestamp: Thu 2012-08-23 11:10:28 +0100
[17:21] <infinity> message:
[17:21] <ogra_> well, do i use the wrong branch ?
[17:21] <infinity>   releasing version 2.76
[17:21] <infinity> ^-- After that is a commit from you, so you clearly know where it lives. :P
[17:21] <infinity>   checkout of branch: bzr+ssh://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/
[17:23] <ogra_> hmm, right, wrong local branch
[17:24] <dobey> is errors.ubuntu.com broken?
[17:25] <ogra_> works here
[17:25] <dobey> ogra_: the list of all the errors loads too?
[17:25] <ogra_> ah, no
[17:25]  * ogra_ tries https://errors.ubuntu.com/?launchpad=false
[17:25] <ogra_> aha
[17:26] <ogra_> that seems to work
[17:26] <ogra_> ev, ^^^
[17:26] <dobey> hrmm
=== mcclurmc_away is now known as mcclurmc
[17:28] <ogra_> evil weather indicator
[17:29] <dobey> evil errors reporting apparently mixing up version information :-/
=== Nafallo_ is now known as Nafallo
=== mlankhorst is now known as ml|vacation
=== tyhicks` is now known as tyhicks
=== pp7 is now known as malkauns
[18:34] <smoser> anyone else using xchat on quantal?
[18:34] <smoser> the scrolling seems screwed up for me after last update
[18:34] <smoser> by scrolling i mean grabbing the overlay scroll bar
=== lifeless_ is now known as lifeless
=== cpg|away is now known as cpg
[20:36] <trism> did the compression options change on the quantal iso squashfs? I'm only getting ~4% complete on an iso from 2 days ago
[20:36] <trism> with zsync that is
[20:40] <trism> oh sorry, must have been a weird build on the weekend, an older iso is ~53%
[20:44] <Laney> yeah, there was some slight bustage there
[20:45] <roaksoax> jdstrand: howdy!! So I'm finishing up the packaging of the cobblerless maas, and I was wondering a few, security related things. 1. MAAS needs to be able to restart a service, so I was thinking to add maas to sudoers, is that a good approach? 2. MAAS needs to write files under both, etc/bind, /etc/dhcp/, What wuold the best approach to do so be? (maas runs as its own user/group)
[20:52] <Laney> dobey: what's the point of those u1 uploads you just did? They don't appear to have any changes ...
[20:54] <dobey> Laney: scheduled releases for beta1 freeze target
=== Logan_ is now known as Fluffer
[20:59] <micahg> dobey: releases for the sake of releasing seems pointless
[21:00] <micahg> at least for a beta
[21:00] <Laney> and it uses buildd time and bandwidth
[21:00] <micahg> ah, I was mistaken then, not pointless, wasteful :)
[21:01] <dobey> it's not releases for the sake of realasing. it's to keep our suite of projects the same version across the board so it's easier to support
[21:06] <micahg> it's still doesn't make sense from the distro side of things (especially for a beta), I could see doing it for a final release though if that's what will be shipping in quantal at release
[21:07]  * micahg isn't saying you can't do it, just that it seems to not make sense
[21:11] <slangasek> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal development | Archive: Feature Freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/  | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ev, slangasek
[21:11] <slangasek> ev: are you still piloting? :)
[21:20] <ia> Hello. Probably this channel not for my question, but I take a chance. Let's say I have a hardware with cpu CPUNAME; If I want to compile C/C++ app for this, then I'm doing something like gcc -march=CPUNAME and it works. But how can I do cross recompilation of some existing deb package [from official ubuntu repo] for such CPUNAME? I guess, that should exist some [auto] tools for this, so when ubuntu dev team preparing packages for arm,x86 and x86-64 from the
[21:20] <ia>  same sources/packages, they probably don't do all those stuff by hands. So I will be very appreciate for pointing me to any relevant direction for solution of this issue. Thanks.
[21:22] <slangasek> ia: DEB_CFLAGS_APPEND=-march=CPUNAME dpkg-buildpackage -uc -us -B
[21:22] <slangasek> this is not guaranteed to work for all packages; but it is the standard interface
[21:22] <slangasek> and if it doesn't work, you can file a bug on the package (preferably in Debian)
[21:23] <slangasek> ia: however, this is entirely unrelated to how packages are prepared for different architectures.  *that* is done by native compilation on the target architecture, using a gcc that outputs binaries for the target machine by default.
=== Fluffer is now known as Logan_
[21:27] <ia> slangasek: right. I forgot about detail - let's say we need not only flag, but another CC value - instead of gcc something like ARCH-gnu-linux-gcc, then what?
[21:28] <slangasek> ia: then for that, you want dpkg-buildpackage -a$arch, where $arch is an architecture name which is known to dpkg and which has a correct mapping to the GNU triplet you need
[21:28] <slangasek> dpkg-buildpackage -a$arch is how you cross-compile.  Support for cross-compilation is much, much less complete in the Ubuntu archive compared with support for DEB_CFLAGS_APPEND
[21:31] <ia> slangasek: very interesting, thank you; one more question - what about automation? let's say I want to do it not only with one package, but with all packages from 'main' part of repository - I guess, that somehow I should use apt-build? Any working recipes for such case?
=== ppetraki_ is now known as ppetraki
[21:32] <slangasek> ia: there are several tools for archive autobuilding; xdeb is one intended specifically for in-place cross-bootstrapping of a port
[21:33] <slangasek> if that doesn't meet your needs, Ubuntu uses sbuild for the building and launchpad for the build scheduling; and Debian uses sbuild+wanna-build.
[21:34] <slangasek> the hard part is figuring out which packages to build in what order for purposes of bootstrapping.  There's been some Google Summer of Code work in Debian around that this year, but the results haven't yet been incorporated into the mainline tools AFAIK
[21:43] <ia> slangasek: interesting and useful information, thanks again. BTW, I think that it will be cool to see some articles (at wiki.ubuntu, for example) with detailed instructions how exactly ubuntu dev team is building packages - from upstream/debian sources to iso generation for misc. arch's, so anybody can repeat it; I think that it will be very interesting and useful for advanced users/developers. Probably somewhere such information is available already, but I
[21:43] <ia> can't google it easily
[21:47] <slangasek> ia: most of the things you're asking about aren't related to how Ubuntu themselves are building packages, and are in such rough form that they're not interesting to document at this stage :)
=== salem_ is now known as _salem
[21:50] <jdstrand> roaksoax: hmm, sorry for the delay. I need to think about that. Can you send an email to security at ubuntu.com for what you are thinking you'd like to do?
[21:51] <roaksoax> jdstrand: will do! Thanks!
[21:51] <roaksoax> :)
=== Ursinha` is now known as Ursinha
=== jelmer_ is now known as jelmer
=== jelmer is now known as Guest90165
=== Guest90165 is now known as jelmer
=== glebihan__ is now known as glebihan