[12:11] <adeleon> Someboy knows something about the XKB error a start P?????
[12:12] <adeleon> Hellooooooooo
[12:14] <amu> lamont: did you start another test.iso ?
[12:33] <jdub> hey amu!
[12:33] <jdub> nice, hoary announce was on LWN
[01:27] <jdub> thom: around?
[01:35] <mdz> jdub: too late for the weekly edition, though
[01:35] <jdub> yeah
[01:35] <jdub> nice though
[01:35] <jdub> means jon probably likes it
[01:35] <mdz> ubuntu gets lots of LWN love
[01:38] <jdub> i was very happy to see ubuntu security updates in lwn
[01:38] <jdub> it's like hearing your song on the radio or something ;)
[01:40] <T-Bone> hehe
[01:49] <jdub> $ ./universe
[01:49] <jdub> libhowl0
[01:49] <jdub> libreadline5
[01:49] <jdub> ^ on hoary
[01:49] <mdz> yeah, we have some seed changing to do
[01:49] <jdub> what do you think we should do about mdnsresponder?
[01:50] <mdz> cry
[01:50] <jdub> heh
[01:50] <mdz> it needs to listen by default, right?
[01:50] <jdub> to be useful, yeah
[01:51] <mdz> I think the best we could do without compromising safety would be to provide a knob to switch it on
[01:51] <jdub> we need a sensible services editor
[02:06] <jdub> mdz: mdnsresponder == 5353 udp externally, 5335 tcp localhost
[02:09] <jdub> hrm
[02:09] <jdub> doesn't seem to use tcpwrappers
[02:09] <mdz> written in C?
[02:09] <jdub> but of course :)
[02:11] <jdub> there are options to run it only on a particular interface or addr
[02:11] <jdub> which is good
[02:12] <mdz> but pointless if it needs to listen on an external interface in order to be useful
[02:12] <jdub> yeah
[02:17] <jdub> hrm
[02:17] <jdub> i am an idiot
[02:17] <jdub> libhowl0 should be libhowl1
[02:30] <jdub> hrrrrmmm
[02:30] <jdub> so if i have a package with two libraries
[02:31] <jdub> hrm
[02:47] <mojo_> hi all
[02:48] <mojo_> I'm working on somehack for Ubuntu About, I actually hacked the GNOME about, i'm wondering is it OK to do so? If so, I need a list of developers, and some info that Ubuntu want to put in
[02:49] <jdub> mojo_: atm, we'd prefer to use a webpage for the 'about' information
[02:50] <jdub> that icon should really be loading the on-disk page
[02:50] <mojo_> i c, i just find it looks so simple, the icon in the applet is scaled up very blur,
[02:50] <mojo_> ok then
[02:50] <jdub> the icon in the menu?
[02:50] <jdub> depends which icon theme you're using ;)
[02:51] <mojo_> the icon in the Main Menu is OK
[02:51] <mojo_> but the icon in Add to Panel..(GApplet) is blur
[02:51] <jdub> oh, the 'add to panel' thing?
[02:51] <mojo_> yeah
[02:51] <jdub> yeah, well, who wants to add that to their panel? :)
[02:51] <mojo_> it used same icon
[02:51] <jdub> those icons are only there due to a bug
[02:51] <mojo_> true
[02:51] <mojo_> hope artwork team fix it soon
[02:51] <jdub> well
[02:51] <jdub> it's not an artwork issue
[02:51] <jdub> it's a panel issue
[02:52] <mojo_> true
[02:52] <jdub> those things shouldn't be available as applets
[02:52] <mojo_> yeah
[02:52] <mojo_> then y that applet existed there? lol
[02:52] <jdub> if you have any suggestions of the on-disk page, let us know :)
[02:52] <mojo_> ok
[02:52] <mojo_> I will
[02:52] <mojo_> oh yeah
[02:53] <mojo_> about the Trash Applet
[02:53] <mojo_> do u know who's responsible for it in Ubuntu team?
[02:53] <jdub> well, Mitario is the upstream author
[02:53] <jdub> but seb128 and jamesh did most of the hacking on it for warty
[02:53] <mojo_> his nick is the same??
[02:54] <mojo_> ok then
[02:54] <mojo_> I will contact them
[03:13] <herzi_lap> amu, ping
[03:19] <mojo_> hey
[03:19] <mojo_> herzi
[03:19] <jdub> mojo_: where in vic are you?
[03:20] <mojo_> I'm in Flemington rite now
[03:20] <jdub> ahr
[03:20] <mojo_> Derby day mate
[03:20] <jdub> heh
[03:20] <mojo_> u know Melb Cup rite?
[03:20] <jdub> race that stops the nation
[03:20] <jdub> :)
[03:20] <mojo_> yeah
[03:20] <mojo_> my house is 100m away from Flemington RaceCourse
[03:20] <jdub> ouch
[03:21] <mojo_> next yr
[03:21] <mojo_> I will travel to Syd
[03:22] <mojo_> yawn...
[03:51] <lamont> moo
[04:51] <jdub> mdz: what were the problems with the user-mode-linux package?
[04:51] <mdz> jdub: lots of bugs which just caused it to fail to boot in various situations
[04:51] <mdz> 2.4 vs. 2.6 host kernels, skas vs. tt
[04:53] <jdub> ahr
[04:53] <jdub> it would be totally rad to have a uml package built from our default kernel
[04:54] <jdub> when was that new version of skas due?
[04:57] <sladen> it would be enourmously sane and fairly useful
[05:04] <mdz> jdub: make-kpkg can build UML papckages now
[05:05] <mdz> jdub: the new version of skas has never had a due date, and has been under development in secrecy for years now
[05:06] <mdz> jdub: there has been talk on the UML list of creating a UML-oriented Linux distribution :-)
[05:06] <mdz> would make a fantastic ubuntu derivative
[05:07] <jdub> mmmmm!
[05:11] <mojo_> hey jdub
[05:12] <mojo_> do u know how to enable Java coloring syntax for vim?
[05:12] <mojo_> I never used Vim with Java
[05:12] <mdz> mojo_: same as enabling every other kind of syntax in vim
[05:12] <mojo_> show me the syntax
[05:12] <tseng> show me the google
[05:12] <mdz> :syntax on
[05:12] <tseng> :)
[05:13] <mojo_> man,, too lazy,,any done it?
[05:13] <tseng> ...
[05:14] <srbaker> WHAT?!?!?
[05:14] <mojo_> are there any good IDE for Java on Linux???
[05:14] <srbaker> britis women don't give oral sex?!?
[05:15] <srbaker> mojo_, emacs.  eclipse isn't bad
[05:15] <mojo_> srbaker: cause they get bored with xxx, they can't moan any more!
[05:15] <jdub> mojo_: (probably best for these questions in #ubuntu, #ubuntu-devel is for ubuntu development discussion)
[05:15] <srbaker> whoops, british.
[05:15] <srbaker> man.  i always wanted to travel to the UK.  not anymore!
[05:17] <srbaker> mojo_, if you want an ide in the sense of a windows ide, try eclipse.  but emacs should be all you need
[05:17] <srbaker> mojo_, hell, i'm an emacs bigot, and i'm even attracted to vim these days :P
[05:17] <srbaker> mojo_, so either choice is good
[05:45] <bluefoxicy> can someone give me a quick start guide to rebuilding ubuntu packages and the software involved?
[05:45] <tseng> uh
[05:45] <tseng> google debian new maint
[05:45] <bluefoxicy> or do I actually have to do work and read docs, then try to pull the pieces I need out of them
[05:46] <tseng> yes go read, its not immediately obvious
[05:46] <tseng> its not a single task
[05:46] <bluefoxicy> blah.
[05:46] <tseng> its understanding the packaging format and several related tools
[05:46] <bluefoxicy> tseng:  emerge -eB universe?  :)
[05:46] <tseng> no?
[05:47] <tseng> spoiled? i wouldnt say that
[05:47] <bluefoxicy> megaverse?
[05:47] <bluefoxicy> err, negaverse, megaverse, what the hell was it on sailor moon
[05:47] <tseng> you get busted ass gcc and glibc-cvs-du-jour
[05:47] <bluefoxicy> so?
[05:47] <tseng> so, it sucks. ubuntu is solid
[05:47] <tseng> so rtfm and join the fun :)
[05:48] <bluefoxicy> I play well with gcc 3.4.2-alpha3-beta9-cvs200410nextweek
[05:48] <bluefoxicy> gives me something to do
[05:48] <tseng> meh.
[05:48] <bluefoxicy> it'd be boring if it worked all the time; if I wanted everything to work, I'd be running stable :)
[05:48] <bluefoxicy> that's what stable is for, having stuff that works.  :)
[05:49] <bluefoxicy> wtf
[05:49] <bluefoxicy> I just went to google.ow
[05:49] <bluefoxicy> what a painful typo.
[05:50] <bluefoxicy> tseng:  http://www.debian.org/doc/manuals/maint-guide/ch-dreq.en.html
[05:51] <bluefoxicy>        8  Package: gentoo  <
[05:51] <bluefoxicy> ^-- There's a package that installs Gentoo?  wtf?
[05:54] <lifeless> gentoo is a type of penguin
[05:54] <bluefoxicy> yes
[05:54] <lifeless> that documentation predates the 'Gentoo Linux' project.
[05:54] <bluefoxicy> ah
[05:54] <bluefoxicy> it's still funny; there's a program that converts another distro to debian, yes?
[05:54] <tseng> gentoo is a file manager
[05:54] <lifeless> yes, there is
[05:55] <bluefoxicy> mmm.
[06:00] <fabbione> morning guys
[06:05] <fabbione> mdz: you around?
[06:14] <lamont> not all automated merges are created equally.
[06:14] <lamont> 41 build failures in main right now...
[06:14] <lamont> many of them thought they succeeded in the automerge..  well, that gives me something to work on next week..
[06:16] <tuo2> hosaka: cafsoc?
[06:18] <jdub> there was a phoenix.rpm a while bck
[06:19] <jdub> that converted a red hat install to debian
[06:20] <jdub> oh man
[06:21] <jdub> there are even two herberts in bugzilla
[06:23] <jdub> whoa!
[06:24] <jdub> b0rkage in a hoary upgrade :)
[06:24] <jdub> gnomemeeting uninstallable
[06:24] <jdub> excitement!
[06:33] <lamont> evolution-data-server-dev: Depends: libgnome2-dev but it is not going to be installed
[06:34] <lamont> jdub: you want b0rkage??? "Get your b0rkage here!  just AU$5!!"
[06:34] <lamont> hrm... maybe I'm getting a bit punchy.
[06:34] <jdub> AU$5 is pretty cheap
[06:35] <lamont> b0rkage is pretty easy to come by right now, that's all.....
[06:35] <jdub> lamont: usual place for hoary build logs?
[06:36] <jdub> http://people.ubuntulinux.org/~lamont/buildLogs/g/gnomemeeting/1.0.2-5/gnomemeeting_1.0.2-5_20041029-0057-i386-failed
[06:36] <jdub> ahr
[06:36] <jdub> After installing, the following source dependencies are still unsatisfied:
[06:36] <jdub> libpt-dev(inst 1.6.5-3ubuntu1 ! >= wanted <IP_ADDRESS>-1) libopenh323-dev(inst 1.13.4-3 ! >= wanted <IP_ADDRESS>-1)
[06:38] <jdub> hmm, gotta plan for a new ubuntu-calendar :)
[06:39] <lamont> yep
[06:40] <lamont> ah, that explains something else.  hrm... to read, perchance to fix.
[06:41] <pasc> woohoo
[06:41] <pasc> jdub: I was going to stop at every pub on the way home, but then realised what that entailed
[06:43] <lamont> jdub: thanks, I think I fixed the stupid auto-depwaiter :-(
[06:44] <jdub> pasc: hahaha
[06:45] <lamont> jdub: gnomemeeting building
[06:45] <jdub> oh, rad!
[06:45] <jdub> thanks :)
[06:46] <lamont> the auto-depwaiter turned that failure into a d-w libpt-dev (>= <IP_ADDRESS>-1), which would be, um, wrong.
[06:46] <jdub> hrm
[06:46] <jdub> bongy
[06:46] <jdub> how are the buildds holding up?
[06:46] <lamont> .+ instead of [^ ] +
[06:47] <jdub> hope we get cricket graphs some time
[06:47] <jdub> so we can watch the pain ;)
[06:47] <lamont> kinda like this...
[06:47] <lamont>  05:47:27 up 9 days, 13:52,  1 user,  load average: 0.00, 0.00, 0.00
[06:48] <jdub> haha
[06:49] <lamont> jdub: I need to roll out a new buildd that knows to only take N% of the needs-build packages, otherwise one buildd gets stingy
[06:49] <lamont> code's done, just been waiting for both the buildd's and I to be idle at the same time.
[06:50] <plovs_work> any wiki-dev here, site gives zope-errors logging in
[06:51] <jdub> ahr
[06:51] <jdub> plovs_work: use site-edit.ubuntulinux.org
[06:51] <plovs_work> jdub, thanks
[06:53] <plovs_work> jdub, same error Error Type: AttributeError Error Value: setProperties
[06:53] <jdub> not sure then
[06:57] <plovs_work> started 9 hours ago, at this site of the ocean :(
[07:09] <plovs_work> jdub, Alt-e helped logging in, then it works (a bit) better
[07:21] <jdub> hrm
[07:21] <jdub> we should do a howto for reinstalling grub to the bootblock
[07:21] <jdub> anyone know grub well>
[07:21] <jdub> ?
[07:30] <jdub> night lamont
[07:30] <fabbione> night
[07:33] <tuo2> b/topic
[08:57] <daniels> Kamion: do we support booting from a usb ms / ?
[10:53] <sivang> Morning all.
[11:02] <SuperLag> any of you guys dual boot Ubuntu with another Linux distro?
[11:03] <jdub> SuperLag: best to ask user questions on #ubuntu
[11:03] <sivang> SuperLag : Yes, with debian sid. But if you're interested in help, I believe that would be better served in #ubuntu
[11:57] <mdz> fabbione: here now
[12:02] <Kamion> elmo: please revert partman-md to Debian
[12:02] <Kamion> daniels: "usb ms"?
[12:04] <fabbione> mdz: does the bug sync from Debian work?
[12:07] <fabbione> 278781 hasn't been synced
[12:07] <fabbione> and i expect others too
[12:08] <mdz> fabbione: I will check
[12:08] <fabbione> mdz: i did check the rsync and it works fine
[12:09] <fabbione> there were no updates in the queue since last run
[12:09] <mdz> it's failing trying to download the germinate output
[12:10] <fabbione> argh
[12:10] <mdz> broke 3 days ago
[12:10] <fabbione> ok
[12:10] <fabbione> not too bad
[12:11] <Kamion> from where is it trying to download the germinate output?
[12:12] <mdz> Kamion: it was pointing at chinstrap/~scott/
[12:13] <mdz> I redirected it to /~cjwatson/
[12:13] <fabbione> with all this white dust i look like bdale :-)
[12:13] <fabbione> (i was sandpapering walls ;))
[12:13] <Kamion> mdz: you might want germinate-warty-output rather than germinate-output, too?
[12:13] <mdz> Kamion: what is the difference?
[12:13] <Kamion> mdz: the former is computed against sid
[12:14] <jdub> hey dudes
[12:14] <fabbione> hey lady
[12:14] <mdz> Kamion: perhaps, now that we have a functional distribution, it should just point at Packages/Sources instead
[12:14] <Kamion> mdz: yeah, probably
[12:15] <fabbione> YEAH SPANK ME SPANK ME! I LOVE THAT YEAHHH!

[12:15] <Kamion> mdz: noting that you don't have all the seeds in there at the moment, either ...
[12:15] <mdz> Kamion: I would be positively thrilled if you wanted to take responsibility for debzilla :-)
[12:15] <Kamion> mdz: I wouldn't :-)
[12:16] <jdub> fabbione: i don't think we should be doing this at the office
[12:16] <Kamion> mdz: but, ok, ask me on Monday - I need to go into town now
[12:16] <fabbione> jdub: no no... only in pvt :D
[12:16] <Kamion> mother's birthday tomorrow, no present yet, WHOOPS
[12:17] <fabbione> Kamion: better run
[12:17] <mdz> 0800-SORRYMOM
[12:27] <Keybuk> *sigh*  I wish there was a decent gnomeish IDE
[12:34] <Mithrandir> fabbione: why have you marked 3032 as a duplicate of 3037 which in turn is a duplicate of 3032?
[12:35] <jdub> Keybuk: tried anjuta? what do you think?
[12:37] <mdz> anjuta of "I can't get anjuta to work" fame?
[12:37] <mdz> Mithrandir: I think fabbione was rushing ahead of debzilla
[12:37] <Mithrandir> mdz: debzilla marked it as a dupe twice.
[12:37] <Mithrandir> once before, once after fabbione
[12:38] <mdz>                 Marking 3037 as a duplicate of 3032
[12:38] <mdz> that one was debzilla
[12:38] <mdz> debzilla marked 3037 as a duplicate of 3032
[12:39] <mdz> fabbione marked 3032 as a duplicate of 3037
[12:39] <Mithrandir> yes, nine minutes later.
[12:39] <mdz> debzilla can't read :-)
[12:39] <mdz> reopening 3032
[12:40] <Mithrandir> ok :)
[12:40] <Keybuk> jdub: yeah, was just playing with it ... it's ok, but not great
[12:42] <Keybuk> it lacks too many little features that I use all the time
[12:43] <Keybuk> copy buffers and add-to-changelog being the top two
[12:44] <Keybuk> mdz: I use emacs now, but it'd be nice to have something a little more GUI :)
[12:44] <Keybuk> something which I could use the mouse with, for example
[12:45] <mdz> you can use the mouse with emacs
[12:45] <mdz> it just punishes you for it
[12:45] <Keybuk> can't when it's in a terminal
[12:45] <Keybuk> the X variant is just terrible
[12:45] <mdz> I don't find it to be so
[12:45] <Keybuk> the font rendering is abysmal
[12:46] <mdz> works fine for me
[12:46] <mdz> and how could it possibly be worse than gnome-terminal anyway? :-P
[12:46] <Keybuk> gnome-terminal's cute ... properly sized anti-aliased fonts
[12:46] <Mithrandir> g-t is sloooow
[12:47] <jdub> slooooooooow
[12:47] <Keybuk> heh, I find that a *feature* ... I can do compiles and just about see what scrolls past
[12:49] <mdz> it's like having a turbo button again
[12:49] <jdub> haha
[12:49] <jdub> man
[12:52] <jdub> i have to lay the smack down on nalin
[12:52] <Keybuk> nalin?
[12:52] <jdub> vte "maintainer"
[12:53] <Keybuk> heh
[12:54] <moyogo> there has been some interesting discussion on why g-t is so slow lately, i hope it goes somewhere
[12:55] <jdub> mmm, and i hope some of the patches go in
[12:56] <Keybuk> any particular reason why we don't trial them?
[12:56] <jdub> oh yeah
[12:56] <jdub> dude
[12:56] <jdub> we have a distro
[12:56] <jdub> HAND ME THE BUG SPRAY!
[12:57] <Keybuk> was that a "yeah there is a reason" or "omg! I forgot I have the power" ?
[12:57] <jdub> the latter :)
[12:57] <amu> jdub: ;)
[12:59] <jdub> i was spun out earlier tonight
[12:59] <jdub> there was an ad for HE-MAN figures and CASTLE GREYSKULL
[01:00] <mdz> BY THE POWER OF GREYSKULL
[01:00] <jdub> only, way modern
[01:00] <mdz> FIX THAT UNIVERSE BUG
[01:00] <jdub> haha
[01:01] <Micksa> half of me was hoping you'd do a he-man rip-off just now
[01:01] <Micksa> the other half of me was going to leave if you did
[01:01] <mdz> who were the masters of the universe, anyway?  was he-man one of them?
[01:01] <jdub> i think we're more galaxy quest than masters of the universe
[01:01] <Keybuk> http://en.wikipedia.org/wiki/Masters_Of_The_Universe
[01:01] <jdub> Keybuk: addict
[01:01] <mdz> we're more Zork
[01:02] <mdz> or Adventure
[01:02] <mdz> you are in a maze of twisty packages, all alike
[01:02] <jdub> mmm
[01:05] <jdub> just wait until we in grumpy
[01:05] <jdub> or perky
[01:05] <Micksa> I'm imagining jdub doing the scene where captain whatsisname shows off his new crew
[01:05] <jdub> warty at 12 months support
[01:05] <jdub> hoary at 6 months support
[01:05] <jdub> grumpy released
[01:05] <jdub> perky in development
[01:06] <Micksa> if every linux user gave $10 to a linux developer
[01:06] <Micksa> how much would we each get?
[01:06] <Micksa> (let's pretend I am one for a sec)
[01:06] <martin_> ?
[01:07] <mdz> martin_: !
[01:07] <pitti> mdz: still awake?
[01:07] <mdz> yes
[01:07] <pitti> mdz: I just tried to use irssi the first time
[01:07] <pitti> I'm at the Debian boot and these guys somehow block the IRC port, so I have to ssh to my server
[01:08] <pitti> s/boot/booth/
[01:09] <mdz> hello, booth
[01:09] <jdub> GOOD MORNING FREEDOM LOVERS!
[01:09] <jdub> ^ message for booth
[01:09] <amu> hi pitti
[01:10] <pitti> jdub: thanks! This was necessary
[01:11] <mdz> also counted among things which are necessary:
[01:11] <mdz> sleep
[01:11] <mdz> night, all
[01:11] <pitti> mdz: night!
[01:13] <Keybuk> I swear, someone was having fun here
[01:14] <Keybuk> descent linux-source-<IP_ADDRESS>% cat /sys/bus/usb/devices/1-2/version
[01:14] <Keybuk>  1.10
[01:14] <Keybuk> of course, that's 0x0110 ... *huh*?!
[01:24] <Keybuk> return sprintf (buf, "%2x.%02x\n", udev->descriptor.bcdUSB >> 8,
[01:24] <Keybuk>                 udev->descriptor.bcdUSB & 0xff);
[01:24] <Keybuk> yeah, let's pull apart a BCD hex value and pretend it's a float, that'll confuse 'em
[01:27] <Micksa> heh
[01:27] <Micksa> is that something out of the USB spec maybe?
[01:33] <Keybuk> probably
[01:34] <Keybuk> BCD is actually a reasonably sensible way to do it; but it's still evil
[01:34] <Keybuk> abusing hex to look like decimal
[01:34] <Micksa> one of USB's major goals is that devices (and maybe hosts) could be made cheaply
[01:35] <Micksa> it's slightly cheaper to throw BCD right at a numerical display than it is to put in decoding logic :)
[01:36] <Keybuk> indeed
[01:37] <Micksa> which is good if you ever have to make a USB device that needs to display its own dev ids :)
[01:37] <Keybuk> http://searchvb.techtarget.com/originalContent/0,289142,sid8_gci1019210,00.html
[01:38] <Keybuk> ^ ouch, you seen that one jdub?
[01:39] <Keybuk> while not particularly anti-Mono, "Mono is an attempt by Novell to reverse engineer parts of Microsoft's .NET Framework." is a bit strong
[01:41] <Micksa> *sigh*, every question is turned into a pretext to flog windows and bash linux
[01:42] <Micksa> "multiple conflicting distributions with multiple infterfaces"... how about windows 3.1/95/98/me/nt/2000/xp
[01:42] <Micksa> and all the fun developers have trying to make stuff that works on all of them
[01:42] <Micksa> okay, I'm done
[01:42] <Keybuk> heh, nah, MS have it even better
[01:42] <Keybuk> they have multiple conflicting interfaces in each Windows release
[01:43] <cenerentola> hey how can i install hoary?
[01:43] <Keybuk> cenerentola: change warty in /etc/apt/sources.list to hoary and aptitude dist-upgrade -- but beware, in hoary be dragons at the moment
[01:44] <cenerentola> keybuk: ill be there...
[01:44] <jdub> Keybuk: yeah
[01:44] <jdub> Keybuk: and the news about novell making it public that they're doing a patent review...
[01:51] <Micksa> sun sure are being dumbfucks lately
[01:51] <Keybuk> why you say that?
[01:54] <jdub> seb128: around?
[01:54] <Micksa> not as such
[01:54] <seb128> yes
[01:54] <Micksa> grah, ww
[01:54] <jdub> hey hey
[01:54] <seb128> hello jdub :)
[01:54] <jdub> seb128: i just did the tarballs due announec for 2.9.1
[01:54] <seb128> I've got the mail yes
[01:54] <jdub> seb128: so, um, you will be having fun early next week ;)
[01:54] <seb128> he he, I know :)
[01:54] <Micksa> Keybuk: bending over for kodak, mcnealy saying he'll attack redhat over java because he doesn't like them
[01:54] <jdub> seb128: what do you think about making all the gnome packages create -dbg packages?
[01:54] <Micksa> sputing crap about "the cost of free"
[01:55] <seb128> jdub: even the applications ?
[01:55] <jdub> seb128: yeah, so when things go wrong, users can install -dbg packages and we can get good backtraces for us and upstream
[01:56] <cenerentola> who's wearing the belt in here? who should i talk to for opening a ml & related thing [public relations]
[01:56] <jdub> cenerentola: what do you need?
[01:56] <seb128> jdub: I don't really like the idea to have so many -dbg packages ...
[01:56] <jdub> seb128: what do you think? is that a ton of packaging work, or is it pretty easy?
[01:57] <seb128> packaging is not the problem, but that make huge packages
[01:57] <Mitario> lo veryone!
[01:57] <seb128> waste of mirror space, bandwidth, etc ...
[01:57] <jdub> hey Mitario
[01:57] <jdub> seb128: hmm
[01:57] <seb128> hi Mitario
[01:57] <cenerentola> jdub: wait a sec... mummy's calling
[01:57] <jdub> seb128: pretty useful though
[01:57] <jdub> seb128: kinda painful shipping 2.9 if we can't get good backtraces
[01:58] <azeem> you could put the -dbg packages in a seperate, non-mirrored archive
[01:58] <seb128> yes, but I would rather make a system to build packages with "nostrip noopt" somewhere
[01:58] <azeem> or just automatically rebuild GNOME packages with DEB_BUILD_OPTIONS=nostrip and put them somewhere else for people to install
[01:58] <jdub> if you guys want to come up with a cool way of doing it
[01:58] <jdub> and ping lamont, mdz and i
[01:58] <jdub> that would be sweet :)
[01:59] <azeem> jdub: hey, it was *your* idea :)
[01:59] <jdub> haha
[01:59] <seb128> yes, we really need debugging packages
[01:59] <cenerentola> jdub: im back...
[01:59] <cenerentola> in black
[02:00] <Micksa> jdub: do you have an alternative viewpoint on novell, so to speak? or do you just generally wanting to blog "novell are joining us! woo!"?
[02:01] <seb128> jdub: the problem is ... what happen if we add -dbg for all the packages ? That's definitively not good for the debian side (too big, not really that useful), so we will definitively get out of sync for GNOME since we don't even have the same binary packages for a same source package
[02:01] <azeem> I guess the CPU cycles for the buildds don't matter too much, so just building the package twice is acceptable? (as opposed to, say, hack debhelper/cdbs to spit out unstripped packages as well)
[02:01] <jdub> Micksa: hard to explain
[02:01] <jdub> seb128: hmm
[02:02] <Micksa> jdub: how many blogs do you have? :)
[02:02] <jdub> seb128: maybe lamont will have some clever ideas
[02:02] <jdub> Micksa: one
[02:02] <seb128> I'll take to lamont, the best option would be to get a "noopt nostrip" build for GNOME packages and a repository for these packages
[02:02] <jdub> cool
[02:41] <Mitario> anyone seen mvo_ around?
[02:47] <cenerentola> jdub: here i am
[02:48] <cenerentola> so let's talk
[02:49] <cenerentola> 1) who should i ask to request an italian ml
[02:49] <jdub> me
[02:49] <cenerentola> so...
[02:49] <jdub> mail<EMAIL_ADDRESS>[02:49] <cenerentola> jdub: can you set up.. ahh
[02:52] <cenerentola> can i query you?
[02:56] <jdub> cenerentola: can you please mail me at the above address?
[02:56] <jdub> Keybuk: http://bugzilla.gnome.org/show_bug.cgi?id=122656
[02:56] <jdub> Keybuk: see elijah's comments at the end
[02:58] <cenerentola> jdub: done
[03:01] <Mitario> yay, runnin hoary now.. :)
[03:01] <jdub> woo :)
[03:01] <Mitario> ^^
[03:02] <Keybuk> jdub: a nice collection of swats to apply there then
[03:02] <Mitario> hmm, have to discuss with michael to get the upgrade-notifier and update-manager in :)
[03:02] <Mitario> probably with mdz too
[03:05] <Keybuk> jdub: Nalin's comments on all those bugs are the most interesting <g>
[03:06] <jdub> mmm
[03:12] <Keybuk> (through their lack :p)
[03:12] <Micksa> is he alive?
[03:12] <cenerentola> jdub: have got the mail?
[03:12] <cenerentola> jdub: or better how long should i wait?
[03:12] <Micksa> maybe he's using lynx in g-t
[03:13] <jdub> cenerentola: i'll sort it out on monday :)
[03:13] <Micksa> and he's going to get back to us eventually
[03:13] <Micksa> ho ho ho
[03:13] <Keybuk> Kamion: (catching up) there's a patch on #184635 to fix the Replaces bugs
[03:13] <Keybuk> or, at least, so aj claims <g>
[03:13] <Kamion> Keybuk: hah, awesome, I hadn't even got round to looking at the code yet
[03:14] <cenerentola> jdub: next week ill be at the university and i wont be able to answer until.. friday
[03:14] <Keybuk> I might stick that in 1.13~ and see what happens :p
[03:17] <Keybuk> oh, and 1.10.24 is available for your consideration for sarge ... it's only been in unstable a few days, so you'll probably want to wait; but there's been no "aiieeee!" from it (and those usually show up *very* quickly :p)
[03:21] <Kamion> Keybuk: ah, ok, can you remind me on Monday?
[03:21] <Kamion> I'll push it through then
[03:22] <Keybuk> yup, sure
[03:22] <Kamion> ta
[03:22] <Keybuk> unless my brain has melted from the stupidities of inputmap
[03:32] <Mitario> Keybuk, did you draw that nice little update-config dialog some days ago?
[03:42] <Kamion> elmo: please sync newt from Debian
[03:50] <lamont> morning
[04:13] <Keybuk> Mitario: yeah, http://people.ubuntu.com/~scott/software.png
[04:13] <Keybuk> though it's not HIG-perfect  (a few spacings are wrong, and that line at the bottom shouldn't be there)
[04:25] <trulux> hi
[04:25] <trulux> hey bluefoxicy
[04:26] <trulux> has anybody get informed about the proactive security thread on ubuntu-devel list?
[04:26] <trulux> i'm the head developer of Hardened Debian and bluefoxicy was commenting that maybe it would be a good idea to have me here explaining it, so, here i am
[04:31] <Keybuk> I read that the other day ... my main concern is that I've never seen those types of changes work properly
[04:31] <Keybuk> we've used one of them on our servers, and it just resulted in processes core dumping all the time
[04:33] <trulux> Keybuk, it depends on how you know to do it
[04:33] <trulux> and also on how you have been using it
[04:34] <trulux> hardened debian has been severally tested on produciton environments (software-libre.org , ourproject.org , libre-projects.org)
[04:34] <Keybuk> I guess the best way to demonstrate it's doable for Ubuntu is to do it, and demonstrate how well it works
[04:34] <trulux> and that environments have an average of more than 50 users per hour in the minimal case
[04:35] <trulux> Keybuk, what do you mean with that? letting ubuntu people to test it? sure
[04:36] <Keybuk> I wasn't quite sure, personally, what the intent of John's mail was
[04:39] <Keybuk> it kinda read as "I'd like to discuss doing this" ... but then never really raised anything to discuss *shrug*
[04:40] <trulux> then let me to discuss about it ;-)
[04:40] <trulux> i'm replying his email, but he has tested many implementations that i have already did
[04:41] <trulux> the only thing lefts is the one related with performance and what one to choose
[04:41] <trulux> the less painful, and the less harmful :)
[04:41] <Keybuk> that's not really something you can decide by discussion, but by actually trying them out, isn't it?
[04:41] <trulux> yes
[04:44] <Keybuk> so it's not really anything anybody can take a technical decision on until there's working example
[04:46] <Keybuk> stuff like that (and MAC too) is quite shiney though ... I know almost nothing about it all though
[04:59] <nictuku> hi. is there a known bug about DMA being used on old cd-rom drives during installation?
[05:00] <nictuku> I had problems with that. It errored with "cannot find install media". After burning another CD media, I tried disabling DMA in the CD-ROM drive, and it was fine.
[05:01] <fabbione> mdz: why did you swap again 3037 and 3032?
[06:17] <mdz> fabbione: they are merged in Debian, so debzilla marks the duplicate automatically
[06:22] <elmo> Kamion: done
[06:24] <Keybuk> heh, I appear to have discovered colin-separated arrays
[06:24] <trulux> Keybuk, working examples are already did and also regresion tests
[06:25] <trulux> Keybuk, https://sourceforge.net/project/showfiles.php?group_id=118309&package_id=132536&release_id=274754
[06:28] <Keybuk> trulux-away: I'm slightly amused by the "Better performance" -> PIE line on that ...
[06:28] <Keybuk> PIE is slower
[06:33] <mvo_> Keybuk: is Mithario working on http://people.ubuntu.com/~scott/software.png? or was he just interessted in your mock-up?
[06:34] <Keybuk> mvo_: unsure, you'd have to ask him
[06:34] <mvo_> Keybuk: will do, thanks.
[06:35] <Keybuk> yeah, it'd be nice to have a source-selection UI that doesn't scare the crap out of people <g>
[06:35] <mvo_> Keybuk: that's it! and I like the idea to integrate the "auto-update" feature into it
[06:35] <mvo_> the button to control it that is
[06:41] <Keybuk> I might improve that UI slightly once I've got this evil inputmap parser out of the way
[06:41] <Keybuk> (whoever designed this stuff needs murdering)
[06:48] <bluefoxicy> o.o
 I read that the other day ... my main concern is that I've never seen those types of changes work properly <Keybuk> I guess the best way to demonstrate it's doable for Ubuntu is to do it, and demonstrate how well it works
[06:49] <bluefoxicy> Keybuk:  Runs on Gentoo, I've used PaX/PIE/SSP for a while yet, though it takes some blood and sweat to get it working the first time.
[06:49] <Keybuk> I'm not sure which elmo used on our servers, but it was causing things like Python, ls and tar to randomly segfault
[06:50] <bluefoxicy> Keybuk:  The idea is that the distribution figures out what breaks, and handles that.  Once you've found what blows what apart, it pretty much works.
[06:50] <bluefoxicy> This works because a minimal set of things break.
[06:50] <bluefoxicy> Keybuk:  GrSecurity?
[06:50] <Keybuk> PaX I *think* ... but don't quite me on it
[06:50] <Keybuk> or quote me
[06:50] <bluefoxicy> I've heard some people set up Gr improperly and have basic applications smack straight into their rate limit.
[06:50] <bluefoxicy> err, resource limit . . rlimit, whatever that is.
[06:51] <trulux> rlimit
[06:53] <mdz> Keybuk: exec-shield
[06:54] <Keybuk> ah, thankyou matt
[06:56] <bluefoxicy> http://rafb.net/paste/results/jlO4K230.html
[06:57] <bluefoxicy> :)
[06:57] <bluefoxicy> on amd64; normally I'm using S (segmexec) instead of P (pageexec) on x86
[06:57] <bluefoxicy> ET_DYN executables are executables built with -fPIE or -fPIC
[06:58] <Keybuk> why would you build an executable -fPIC ?  other than as a dare
[06:58] <bluefoxicy> so it can be quickly and safely loaded anywhere in memory.
[06:58] <Keybuk> that's -fPIE ... not -fPIC
[06:58] <Keybuk> PIC executables still have a fixed load-address
[06:59] <bluefoxicy> -fPIE does not exist in gcc <3.4
[06:59] <bluefoxicy> 3.3 uses -fPIC -pie
[06:59] <Keybuk> indeed, but -fPIC doesn't have the same effect
[06:59] <bluefoxicy> -pie is a linker flag.  :)
[06:59] <bluefoxicy> http://lwn.net/Articles/106214/
[06:59] <Keybuk> yeah, that'd make more sense
[06:59] <Keybuk> just building PIC executables without making them PIE is a bit of an odd thing to do
[06:59] <bluefoxicy> yeah
[06:59] <Keybuk> "hey, let's make this executable slower for no reason <g>"
[07:00] <bluefoxicy> even then they have a fixed load address though; but using PaX, PIE binaries will be loaded at random offsets automagically
[07:00] <bluefoxicy> a normal system will still just jam them at an easily determined and repetable address
[07:00] <Keybuk> well, it's not fixed in the sense that the application can't be loaded anywhere else
[07:00] <Keybuk> the link-loader just doesn't load them anywhere else
[07:00] <bluefoxicy> right.
[07:01] <Keybuk> PIE is a bit security-through-obscenity though :p
[07:01] <bluefoxicy> not really
[07:01] <bluefoxicy> security through obscurity is the concept that a system has known flaws, but the attacker doesn't know what they are, and won't find out
[07:02] <bluefoxicy> if the attacker finds out what said flaws are, he can easily exploit them.
[07:02] <Keybuk> the basic security gain is that your application is loaded in a random place, so is harder to exploit
[07:02] <Keybuk> which is up there with putting your PHP webserver on a random port :)
[07:02] <bluefoxicy> In the absence of an information leak, the attacker may know that he can RET2LIBC, but he won't know where the heck LIBC is
[07:02] <Keybuk> hmm... that's about 5 lines of assembler to find that out
[07:03] <bluefoxicy> so even though he knows the system has a flaw, he can never guarantee that he can use that flaw
[07:03] <bluefoxicy> and how do you find that out?
[07:03] <bluefoxicy> remember that you can't execute code you've injected onto the stack.
[07:03] <Keybuk> just look up a known libc symbol (open is a good one :p) in the GOT
[07:03] <Keybuk> ah, no, see you can :)  unless you combine it with SSP/PaX or something aiui
[07:03] <bluefoxicy> ah, no, you can't.
[07:03] <bluefoxicy> the stack is made non-executable
[07:03] <Keybuk> by what?
[07:04] <bluefoxicy> by pax >:)
 ah, no, see you can :)  unless you combine it with SSP/PaX or something aiui
[07:04] <bluefoxicy> ah
[07:04] <Keybuk>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[07:04] <bluefoxicy> sorry, I just read SSP :)
[07:04] <bluefoxicy> I just woke up
[07:04] <bluefoxicy> anyway.
[07:04] <Keybuk> heh :p
[07:04] <bluefoxicy> PaX is what's doing the randomization, I'd figure you'd have it doing ESP too.
[07:04] <Keybuk> but once you've made the stack non-executable, why do you need to have your applications playing musical chairs in memory?
[07:05] <bluefoxicy> the stack may be nonexecutable, but the stack frame pointer and return address can eb fucked with
[07:05] <bluefoxicy> and that can allow an attacker to set up a complex pipeline of attacks i.e. fopen()->fwrite()->fclose()->mmap()->some_newly_mapped_code()
[07:06] <Keybuk> I guess
[07:06] <Keybuk> PIE is slow as hell though :-(
[07:06] <bluefoxicy> no it's not :)
[07:06] <Keybuk> (unless you own an AMD64, anyway)
[07:06] <bluefoxicy> I've seen a .99% slowdown on PIE on x86
[07:06] <bluefoxicy> there's one caveat
[07:06] <Keybuk> you have to do about 5 instructions instead of 1 for every jmp
[07:07] <Keybuk> that's a pretty nasty slowdown
[07:07] <Keybuk> though it doesn't hugely affect apps that rely on shared libs a lot
[07:07] <bluefoxicy> if you use -fomit-frame-pointer without PIE, you gain about 5% performance; but if you use PIE (or pic) you don't get that performance boost, PLUS you lose the 1%
[07:07] <bluefoxicy> so if you rely on -fomit-frame-pointer for a performance boost on x86, you lose ~6% total
[07:08] <bluefoxicy> I used nbyte benchmark to do these tests
[07:08] <Keybuk> heh, I always have a giggle when I see "-O2 -fomit-frame-pointer"
[07:08] <bluefoxicy> and most apps basically live in shared libs.
[07:08] <daniels> Kamion: mass storage
[07:08] <bluefoxicy> -fomit-frame-pointer can do neat things I hear
[07:08] <bluefoxicy> remember above I said you could fuck with the stack frame pointer
[07:08] <bluefoxicy> well it's not there with -fomit
[07:08] <Keybuk> bluefoxicy: sure, but doing that kind of thing in a link line just shows people don't really know what they're up to :)  (-O implies it)
[07:09] <bluefoxicy> -O2 implies it on amd64, not on x86
[07:09] <trulux> Keybuk, PIE does not provide obscurity as you said
[07:09] <bluefoxicy> but again, most apps live in shared libs
[07:09] <trulux> Keybuk, PIE provides a non agressive way to make the pax aslr working without so much brainstorming
[07:09] <Keybuk> bluefoxicy: depends on whether you use -g or not, etc.
[07:09] <mdz> Keybuk: that's only true for architectures which can debug without a frame pointer
[07:10] <mdz> of which i386 is not one
[07:10] <trulux> Keybuk, and also PIE is NOT slower at all
[07:10] <Keybuk> trulux: of course it is
[07:10] <mdz> it is on i386
[07:10] <bluefoxicy> think xmms and beep (all those decoding and vis plugins); lame and oggenc (libogg, libvorbisfile, libmad); abiword (the entire set of filters are all plug-ins); anything doing compression (zlib bzip2lib etc)
[07:10] <Keybuk> mdz: sure, I may be wrong, but I'm sure gcc only omits it if you use -g
[07:11] <Keybuk> we don't all have the luxury of amd64 and their fancy-schmancy pic-in-processor addressing mode :o)
[07:11] <bluefoxicy> doesn't gcc even use libraries to house the code doing most of the work during compilation?
[07:11] <mdz> Keybuk: I don't think -O is that smart
[07:12] <bluefoxicy> mdz, trulux:  PIC is slower than fixed position code; however, all libs are PIC, and a lot of shit hangs out in libs a lot, so PIE is not noticably slower
[07:12] <Keybuk> mdz: dunno, I'd have to grep the source ... it's been a while since I last looked
[07:12] <bluefoxicy> it IS a bit . . well
[07:12] <bluefoxicy> let's say it has some overhead.
[07:12] <bluefoxicy> as for slower, I touch 100% CPU when I'm compiling and encoding shit.
[07:12] <mdz> #ifdef CAN_DEBUG_WITHOUT_FP
[07:12] <mdz>       flag_omit_frame_pointer = 1;
[07:12] <mdz> #endif
[07:12] <Keybuk> ah, not that smart then :)
[07:12] <bluefoxicy> you see 0 slowdown no matter what if you're not touching the ceiling of your CPU :)
[07:13] <mdz> you'll always max the CPU out, at least for short periods
[07:13] <bluefoxicy> yeah
[07:13] <bluefoxicy> but for realtime tasks, nobody cares
[07:14] <bluefoxicy> they have to get their job done in intervals of X time constituting Y work
[07:14] <bluefoxicy> as long as they can do that, there's no problem.
[07:15] <bluefoxicy> hrr, switch X and Y, and that's about what the CPU graph is:  work done over time
[07:15] <mdz> I don't see your point
[07:15] <mdz> in realtime scenarios, it's either fast enough, or it isn't.  If you make it slower, it will sometimes not be fast enough anymore :-)
[07:16] <bluefoxicy> my point is that a 1% performance hit in some fraction of a program's run-time, probably the most lightweight fraction, is in most cases essentially nothing
[07:16] <mdz> a valid point, but I don't think it applies to the issue at hand
[07:17] <bluefoxicy> the issue at hand being. . . I seem to have been lost.
[07:17] <bluefoxicy> sorry I only talk about one thing at a time, and tend to not notice the rest of the world while i talk to myself
[07:20] <bluefoxicy> ar, hey trulux did you see my post to the dh-hackers list
[07:21] <trulux> none yet
[07:21] <bluefoxicy> http://sourceforge.net/mailarchive/message.php?msg_id=9923072
[07:22] <bluefoxicy> that was after a 30 second glance at some documentation
[07:22] <bluefoxicy> so i don't know if it's relavent at all
[07:23] <trulux> ok, i'm reading it
[07:23] <bluefoxicy> that'll require modifying debian/rules in the source tree, but only for packages that break.  also I didn't cover anything to handle PaX markings on the package
[07:23] <trulux> ok
[07:23] <trulux> that should be did by an independant package
[07:24] <bluefoxicy> heh
[07:26] <Keybuk> why would packages break, out of interest?
[07:29] <bluefoxicy> Keybuk:  They may expect various behavior which is no longer true under PaX; or they may be buggy and collide with SSP; or they may not be PIC-aware
[07:30] <bluefoxicy> for example, JIT compilers and realtime machine emulators (Qemu) will not like PaX.  They will need either to be written to be aware of PaX and use mprotect() properly, plus have the mprotect() restrictions removed (paxctl -m); or they will need PaX disabled (paxctl -psem).  If they die from ASLR (java does this), that needs to be disabled for them (paxctl -rx)
[07:30] <Keybuk> see, this is the bit about all of these things that worries me -- it's very in-your-face when it goes wrong
[07:31] <bluefoxicy> JIT compilers can actually function under full PaX, if written properly-- http://www.kaffe.org/pipermail/kaffe/2004-October/099938.html
[07:31] <bluefoxicy> Keybuk:  The distribution maintainers can handle marking the binaries; it's a 30 second job to figure out what breaks and why, and fix it.
[07:31] <bluefoxicy> I know because I used to do it.
[07:31] <Keybuk> yeah, but then you're disabling the security for a particular binary or more
[07:32] <Keybuk> and at that point, you have a path of attack
[07:32] <bluefoxicy> yes
[07:32] <Keybuk> so you may as well not apply it to any binaries
[07:32] <bluefoxicy> wrong
[07:32] <bluefoxicy> maybe I disable the security for something like Java
[07:32] <bluefoxicy> but not for Firefox
[07:32] <Keybuk> so a Java Applet viewed in Firefox can exploit your machine?
[07:32] <bluefoxicy> I can be exploited by a java applet that's written to damage my JIT, but I can't be exploited by malformed HTML
[07:33] <bluefoxicy> nor by libpng exploits (which are umbrellad under the PaX proteciton; java runs in a separate binary)
[07:34] <bluefoxicy> so I've narrowed down the potential exploit paths
[07:34] <Keybuk> my attitude to security stuff is kinda like firewalls ... I'm entirely happy all the time it sits there, stops other people from using my machine; but the second it stops me from using it, it gets switched off completely
[07:34] <bluefoxicy> yes
[07:34] <bluefoxicy> that's the idea here.
[07:34] <bluefoxicy> I want these things to work comfortably without the user or administrator having to care.
[07:34] <Keybuk> and my worry with this stuff is that everything I've seen of it suggests to me that it's going to get in a user's way
[07:34] <bluefoxicy> no
[07:35] <bluefoxicy> it'll provide a small consideration to the maintainers, but not to the users
[07:35] <bluefoxicy> you only have to handle this stuff once
[07:36] <bluefoxicy> if some program overflows a buffer by itself in normal operation, and SSP kills it, then the program gets built without SSP.  The user doesn't have to worry about it, although he may see a note made in the description about it
[07:36] <bluefoxicy> (or maybe you fix the program, although that's a job for the upstream maintainers)
[07:37] <bluefoxicy> If it can't build PIE, then it's built ET_EXEC, or whatever prevents it from building PIE can be disabled.  Gimp for example won't build PIE with --enable-mmx; in general, pre-optimized assembly should be avoided.
[07:39] <trulux> bluefoxicy, sorry , at the point of having the jit without protection i must explain the following scenario that will make the whle heck having sense:
[07:39] <trulux> by that way you should also say tha unprotected libraries loaded inside protected binaries will harm the binary as they can overrride the protections of the areas that they accomply to
[07:39] <trulux> and that's false
[07:40] <bluefoxicy> wha?
[07:40] <trulux> so, running a jave applet, first takes care inside the java sandbox
[07:40] <trulux> bluefoxicy, that the binary loading the sahred object which is unprotected will be affected by the object overrided protections
[07:40] <bluefoxicy> if the java bytecode is malformed, and the JIT is buggy, the bytecode may damage the JIT's internal state and allow an attacker to inject malicious code.
[07:40] <trulux> yes
[07:41] <trulux> but inside the memory areas under the jit control
[07:41] <Keybuk> hmm, a library isn't in a separate address space
[07:41] <Keybuk> if a library can't work with ssp/pax then no application that linked with it could use it either
[07:41] <trulux> false
[07:41] <bluefoxicy> SSP yes it can.
[07:41] <Keybuk> the java_vm is run as a separate process, so in a separate address space
[07:41] <bluefoxicy> PaX no
[07:41] <Keybuk> bluefoxicy: how?
[07:42] <bluefoxicy> SSP checks are done inline
[07:42] <Keybuk> ah, so the library code simply doesn't have ssp in it?
[07:42] <trulux> it depends, PaX used with bind9 will need to have an un protected lib_*_dns
[07:42] <bluefoxicy> the changes don't have a global affect; they're bits of code injected into the binary
[07:42] <bluefoxicy> Keybuk:  exactly.
[07:42] <Keybuk> so an ssp-less library could be used to exploit a binary which used ssp?
[07:43] <trulux> not
[07:43] <Keybuk> why not?
[07:43] <Keybuk> the library lacks ssp, so that code isn't secure
[07:43] <bluefoxicy> trulux:  if libraries in the same address space need different protections, then the relieved protections must be combined to find out everything that needs to be disabled.
[07:43] <bluefoxicy> Keybuk:  Yes, and vice versa
[07:43] <trulux> blueYEAH
[07:43] <trulux> ops
[07:43] <bluefoxicy> if Mozilla is SSP, and libpng is not, then libpng can be exploited via one of those nasty buffer overflows from 2 months ago (if you haven't upgraded yet)
[07:43] <bluefoxicy> and this can happen via loading a malicious web page in mozilla
[07:44] <trulux> yes
[07:44] <Keybuk> bluefoxicy: thus code in libpng can write over all of Mozilla's address space
[07:44] <bluefoxicy> On the other hand, if libpng has SSP, and Mozilla does not, then the libpng exploits are effectively useless
[07:44] <bluefoxicy> Keybuk:  correct.
[07:44] <bluefoxicy> Keybuk:  do not think of programs in terms of libraries and executables
[07:44] <Keybuk> bluefoxicy: but they are :p
[07:44] <bluefoxicy> that's as frivilous as thinking of a library in terms of the object files used to build it
[07:45] <trulux> Keybuk, just btw, what version of glibc is ubuntu running on?
[07:45] <bluefoxicy> once the program is in memory, all those libraries are effectively a part of the program
[07:45] <Keybuk> trulux: same as Debian
[07:45] <bluefoxicy> they might as well have been compiled straight in.
[07:45] <Keybuk> bluefoxicy: they're actually not
[07:45] <Keybuk> they're quite separate
[07:45] <trulux> Keybuk, you mean the fscking old 2.3.2-ds1 ?
[07:45] <Keybuk> trulux: yup
[07:45] <bluefoxicy> Keybuk:  how?
[07:45] <bluefoxicy> trulux:  uh oh :)
[07:45] <bluefoxicy> Keybuk:  DO NOT enable PAGEEXEC in PaX, do NOT disable the vsyscall page :)
[07:46] <Keybuk> bluefoxicy: the memory image of a shared library is shared ... it's just mapped in to each app's address space at some arbitrary point
[07:46] <bluefoxicy> Keybuk:  Do you understand virtual memory?
[07:46] <Keybuk> bluefoxicy: yes
[07:46] <trulux> Keybuk, i pray for your ass then :) take a look on our glibc , you can find it useful for looking on how we implemented some things
[07:46] <Keybuk> (at least, one would hope so <g>)
[07:46] <trulux> bluefoxicy, where is pspax code? (i was out some time due to school , you know...:P)
[07:47] <bluefoxicy> each application is run in what looks like its own machine.  Whether the code is in a library or in the executable, shared between VM spaces or not, it's run the same way.
[07:47] <trulux> bluefoxicy, it was fixed, vsyscall now works without kissing our ass so on
[07:47] <bluefoxicy> trulux:  yes, in ds14 IIRC
[07:48] <trulux> ok
[07:48] <bluefoxicy> http://pageexec.virtualave.net/pax-utils-0.0.4.tar.gz
[07:48] <bluefoxicy> ack
[07:49] <bluefoxicy> not found heh
[07:49] <bluefoxicy> http://dev.gentoo.org/~solar/pax/
[07:49] <bluefoxicy> there ya go
[07:50] <bluefoxicy> trulux:  pax-utils-0.0.4.tar.gz in that folder
[07:52] <Keybuk> trulux: upgrading glibc has been discussed, but we've nobody on team who really follows it
[07:53] <Keybuk> also Debian's isn't really as old as it sounds, it's been heavily patched without the version being incremented
[07:57] <trulux> ok, thanks
[07:57] <trulux> Keybuk, yes
[07:58] <trulux> Keybuk, i can do it
[07:58] <Keybuk> there's also the issue of it being a heavy fork from Debian
[07:58] <trulux> just give me up to it and i will work on it , as i have a ready glibc
[07:58] <trulux> Keybuk, hardened debian?
[07:58] <Keybuk> ordinary Debian
[07:59] <Keybuk> do you know why Debian still runs an older version ?
[07:59] <trulux> yes, for stability
[07:59] <Keybuk> are later versions buggier?
[08:05] <trulux> Keybuk, not
[08:05] <Keybuk> then why do Debian stick?
[08:06] <trulux> because they think that them do, i mean, they suppose that later versions are later problems
[08:07] <Keybuk> most of our guys are upstream too, fwir ... so surely their concerns are justified
[08:07] <trulux> that's nice
[08:08] <trulux> Keybuk, do you want us collaborating together? collaboration for security maybe ;-) ?
[08:08] <Keybuk> define "us" ?  Personally it's not really something that excites me
[08:08] <azeem> as I said before, jbailey was working on updating glibc, and he told me at least gotom was doing it at some point, too
[08:09] <trulux> so?
[08:09] <trulux> Keybuk, us means hardened debian people and ubuntu developers
[08:09] <trulux> i have wroten some documentation on that
[08:09] <Keybuk> it's not really a group I can speak for
[08:10] <Keybuk> from a personal pov. I'd like to see it working to play with, as I haven't yet
[08:10] <trulux> what you haven't yet?
[08:11] <Keybuk> seen a *working* system with any of the "hardened" toys on it -- including SELinux
[08:11] <trulux> bluefoxicy, btw, can you submit a comment to the hardened-dev-tools issue and keep in in the tracker please?
[08:12] <trulux> Keybuk, i have no available boxes, i mean, opened to anybody
[08:12] <trulux> but i have one that could be open for that
[08:12] <Keybuk> trulux: to be honest, I'd rather it were something I had on my machine
[08:13] <trulux> ok
[08:13] <trulux> then i will you in that way
[08:13] <trulux> sorry , help missed in the msg :P
[08:13] <trulux> first you need to get the last 2.6.7 sources from our repository
[08:14] <trulux> make a kernel pkg and install it , it's easy
[08:14] <trulux> i haven't time do it but i can try it now, jus give me 20 minutes
[08:14] <Keybuk> isn't there an APT repository?
[08:14] <Keybuk> and I thought you'd said that stuff had to be recompiled?
[08:15] <trulux> Keybuk, yes, but not upgraded to the last revisions of sarge's gcc
[08:15] <bluefoxicy> trulux: ?
[08:15] <trulux> http://d-sbd.alioth.debian.org/apt/sarge/
[08:16] <Keybuk> what about for Ubuntu ?
[08:16] <trulux> which gcc uses it?
[08:16] <bluefoxicy> what gcc does ubuntu use?
[08:16] <bluefoxicy> you should use one to compile your whole distro, not two :)
[08:16] <Keybuk> 4:3.3.4-1
[08:16] <Keybuk> uh, that's gcc-defaults, heh
[08:16] <Keybuk> 1:3.3.4-9ubuntu5
[08:17] <trulux> Keybuk, http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/system-dh/x86/sarge/devel/gcc/3.3.4-6/
[08:17] <trulux> get them, install them and try to recompile
[08:17] <trulux> tell me if you get any error
[08:18] <trulux> Keybuk, then? install the already did pkgs , but it will make you downgrade to deb's 3.3.4-6
[08:18] <trulux> i think i've already said that the heck is already done :P
[08:20] <Keybuk> if the gain-to-impact ratio is good, they'd make nice grumpy goals I guess
[08:20] <Keybuk> I don't think we've overloaded that yet <g>
[08:20] <trulux> :)
[08:21] <Keybuk> do you know much about MAC as well?
[08:23] <trulux> not really, i'm 15 not so time to spend , just my effort
[08:24] <Keybuk> bluefoxicy: any particular reason?
[08:24] <trulux> MAC systems can be agressive to implement transparently
[08:24] <bluefoxicy> added layer of complexity
[08:24] <trulux> that's the point
[08:24] <Keybuk> heh, isn't that the same argument against ssp/pax/pie. etc? :p
[08:24] <bluefoxicy> no
[08:24] <bluefoxicy> ssp/pax/pie won't cause logins as root to be inable to do anything
[08:24] <bluefoxicy> mac systems normally cause root to drop caps
[08:25] <trulux> yeah
[08:25] <Keybuk> sure, they drop the concept of a superuser entirely in favour of giving privilege where needed
[08:25] <bluefoxicy> so to get sysadmin, it's normally something like log in as sysadmin-user, activate sysadmin-role, su root
[08:25] <trulux> Keybuk, DH minds in usability
[08:25] <trulux> transparently....etc
[08:25] <Keybuk> bluefoxicy: that's actually a pretty good UI
[08:25] <trulux> Keybuk, listen
[08:25] <Keybuk> "activate sysadmin role"
[08:25] <trulux> DH minds in providing the following:
[08:26] <bluefoxicy> Keybuk:  it would change the way the system functions though; people expect root to be able to install programs without jumping through 2 or 3 hoops first.
[08:26] <trulux> a soft system , the default: PaX+PIE+file system enhanced security+other patches such as tcp stealth, etc
[08:26] <Keybuk> bluefoxicy: *shrug* we've pretty much buried root on Ubuntu
[08:26] <trulux> a complete system: same but using rsbac and other mac implementations such as SELinux
[08:27] <bluefoxicy> s/and/or/
[08:27] <trulux> bluefoxicy, and also thinking in what consists on ;-)
[08:27] <trulux> yeah
[08:27] <trulux> sorry :)
[08:27] <bluefoxicy> implementing a proper MAC policy would also be a load on the maintainers ;)
[08:27] <trulux> ;-) lol
[08:27] <bluefoxicy> a serious load, not "Oh, X broke because of Y, let's not do that then"
[08:28] <Keybuk> SELinux in ... SELinux out ... SELinux in ... SELinux out ... shake it all about
[08:28] <trulux> shake usability in the mix
[08:28] <bluefoxicy> Microhat Fedora :)
[08:28] <Keybuk> trulux: but that's exactly what I'm concerned about if added security-related patches
[08:28] <trulux> same as putting tabasco on your coke
[08:28] <bluefoxicy> I've heard that at least some of Fedora's "Security" is smoke-and-mirrors that just does nothing
[08:29] <bluefoxicy> but I don't know
[08:29] <Keybuk> I'm admittedly entirely biased and tainted by a bad experience of exec-shield
[08:29] <trulux> me too
[08:29] <trulux> Keybuk, exec shield is not the whole heck AFAIK
[08:29] <bluefoxicy> ES is crap
[08:29] <trulux> there are many NOEXEC implementations, btw
[08:29] <trulux> ES is deprecated
[08:30] <trulux> http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/
[08:30] <bluefoxicy> ES is immature and the author doesn't like giving people administrative control
[08:30] <trulux> so, deprecated for use, obsolete by the moment
[08:30] <bluefoxicy> Ingo Molnar thinks restricting mprotect() the way PaX does (which is btw an option, and disablable per-binary) is a bad idea :O
[08:31] <bluefoxicy> besides, ES is from May, 2003; PaX came from October, 2000, and has been continuously actively developed since :)
[08:31] <Keybuk> so if you PaX-enable everything, nothing fails and everything still runs?
[08:31] <Keybuk> no strange core dumps/bus errors ?
[08:31] <bluefoxicy> the developer knows his stuff, so it's pretty much mature
[08:31] <bluefoxicy> Keybuk:  not everything
[08:31] <bluefoxicy> but you can easily individually protect things
[08:31] <Keybuk> now you see the source of my unease ... I think "why not?  something wrong there then"
[08:32] <bluefoxicy> http://d-sbd.alioth.debian.org/www/pax/pax.conf
[08:32] <bluefoxicy> Keybuk:  Remember PaX changes the behavior of the system, and applications may not expect that
[08:32] <Keybuk> bluefoxicy: thus something that's supposed to be entirely hidden has now become in-your-face
[08:32] <Keybuk> then I argue that it's broken the system
[08:33] <bluefoxicy> the user doesn't need to see that.
[08:33] <trulux> yeah
[08:33] <Keybuk> sure they do, they install something and it breaks
[08:33] <bluefoxicy> actually
[08:33] <trulux> how they install something....does not root which must do that? :P
[08:34] <bluefoxicy> it's possible to configure it so that third party apps can't break
[08:34] <bluefoxicy> but it's less secure
[08:34] <trulux> yep
[08:34] <trulux> Keybuk, think that users must NOT write executable elfs on their homes
[08:34] <bluefoxicy> and requires a few more lines in the developer script.  :)
[08:34] <trulux> TPE...
[08:34] <trulux> ;-)
[08:34] <Keybuk> hmm?  most users download shit all the time and run it
[08:34] <bluefoxicy> you'd have to paxctl -PSEMR everything by default
[08:34] <Keybuk> cf. the proliferation of Ubuntu installs with mplayer on them
[08:35] <bluefoxicy> Keybuk:  and?
[08:35] <bluefoxicy> doesn't ubuntu supply mplayer?
[08:35] <Keybuk> nope
[08:35] <bluefoxicy> o.O
[08:35] <bluefoxicy> anyway.
[08:35] <Keybuk> it's a viable package for universe, but those are still unsupported
[08:36] <Keybuk> so wouldn't get the love that main does
[08:36] <bluefoxicy> to ensure no third party breakage, packages would have to {paxctl,chpax} -PSEMR everything they build, except for those which break; and set PaX into softmode.
[08:36] <Keybuk> "packages" ?
[08:36] <bluefoxicy> but third party binaries would get no protection by default
[08:37] <bluefoxicy> whatever
[08:37] <Keybuk> ah, sorry, I get you
[08:37] <bluefoxicy> :)
[08:37] <Keybuk> so now we're at a point where to stop the system being generally unstable, we only security-enable particular binaries
[08:37] <Keybuk> which is pretty much the backpedal Fedora had to do with SELinux
[08:38] <bluefoxicy> Keybuk:  another issue is that once the ball gets rolling, upstream should start supporting PaX and marking things in their own debs :)
[08:38] <azeem> just have a trigger in dpkg which does it for all and then blacklist the failures =)
[08:38] <bluefoxicy> Keybuk:  Different.
[08:38] <Keybuk> azeem: was that you volunteering to write the code? <g>
[08:38] <trulux> Keybuk, one resides on role-basis protections and the other on file-basis protections
[08:38] <trulux> one is transparent
[08:38] <trulux> the other not
[08:38] <trulux> that's the diff
[08:38] <bluefoxicy> Keybuk:  It's not "certain packages," it's that all of Ubuntu's standard distribution is handled with least privileges, and third party crap is just fully privileged
[08:38] <Keybuk> but it's not transparent if it causes things to break
[08:39] <trulux> bluefoxicy, quote that please :d
[08:39] <Keybuk> on the first core dump, it goes from transparent to totally opaque
[08:39] <trulux> Keybuk, I've wroten some stuff about that
[08:39] <trulux> and believe me , it's known what it breaks
[08:39] <trulux> and known how to solve it
[08:39] <Keybuk> so why aren't those things fixed already?
[08:40] <trulux> that's an upstream q
[08:40] <trulux> make it to them
[08:40] <Keybuk> have the patches been sent upstream ?
[08:40] <trulux> i can't be responsible of why somebody decided to make use of odd mprotect and so on calls
[08:40] <trulux> Keybuk, is that our task or ours is to test it, make it and work it?
[08:41] <trulux> Keybuk, i call it collaboration -smile-
[08:41] <Keybuk> sure, but you can't expect upstream to know what you've done to the system
[08:41] <bluefoxicy> http://d-sbd.alioth.debian.org/www/secpaper.txt  down about 4/5 of the way you'll see "A.  Manual Control", try that
[08:41] <bluefoxicy> Keybuk:  the changes are very defined :)
[08:42] <Keybuk> bluefoxicy: but are they defined in a mail to the upstreams of what breaks?
[08:42] <bluefoxicy> Keybuk:  I think upstream would notice what major distributions have done to their systems
[08:42] <Keybuk> bluefoxicy: no, they'd only notice the change whatever distribution they run made
[08:42] <bluefoxicy> even when the bug reports start coming in?  :>
[08:42] <Keybuk> they're just ordinary developers, they can only test and fix the systems they have immediate access to
[08:42] <Keybuk> sure
[08:42] <Keybuk> I get bug reports all the time
[08:42] <Keybuk> they're all tagged moreinfo or worksforme
[08:43] <bluefoxicy> heh
[08:43] <trulux> Keybuk, stop one moment, figure this:
[08:43] <bluefoxicy> Keybuk:  Well you have to start somewhere
[08:43] <bluefoxicy> PaX is 4 years old
[08:43] <Keybuk> usually you start asking them for intimate details of their system, to send you example files, etc. and after a few days of tennis they loose interest in helping you fix the bug
[08:43] <bluefoxicy> ssp is like 6
[08:44] <bluefoxicy> and people still don't consider them
[08:44] <trulux> Keybuk, i don't know how to make you figuring out what *we* want to say
[08:44] <trulux> they key thing is that, the problems coming forwrd when using our stuff are minimal and only related with special scenarios
[08:44] <trulux> specific errors related to upstream tasks
[08:44] <Keybuk> I don't believe that
[08:44] <Keybuk> as I said, I'm prejudiced by bad experience
[08:45] <bluefoxicy> Keybuk:  The distribution can be managed so that things don't explode along the way; but it is a crucial first step that has to be taken by *someone* before the upstream devs will start chiming in.
[08:45] <trulux> i mean , modifiyng the mprotect calls to something secure and reliable under restrictive environments
[08:46] <Keybuk> sure, and you're taking those steps, no?
[08:46] <bluefoxicy> I'm one person, I can't get any attention.
[08:46] <bluefoxicy> people just roll their eyes at me
[08:46] <Keybuk> stamp on them :)
[08:46] <bluefoxicy> that's what I'm trying to do
[08:46] <bluefoxicy> Often physics mimic eachother in different contexts
[08:47] <bluefoxicy> The greater the mass, the greater the force needed to stop it
[08:47] <bluefoxicy> A handfull of users on the side won't get any attention; a major distribution will.
[08:48] <Keybuk> but to get a major distribution's attention, you need more than a handful of users :p
[08:48] <bluefoxicy> Yes
[08:48] <Keybuk> chicken, meet egg
[08:48] <bluefoxicy> I actually tried that too
[08:48] <bluefoxicy> did you see my article?
[08:48] <Keybuk> possibly
[08:48] <bluefoxicy> http://lwn.net/Articles/106214/
[08:48] <Keybuk> ah yes, that was an interesting read
[08:49] <bluefoxicy> Power play:  when the masses are ignorant, they're easily controlled; when they're informed, they begin to ask questions, and begin to control you
[08:49] <bluefoxicy> It's easy for a few users to get ignored; but as you pointed out, more than a handful of users will get a major distro's attention :)
[08:49] <Keybuk> sure, but there's one key point you've actually forgotten
[08:50] <Keybuk> let's use Debian as an example here
[08:50] <bluefoxicy> That the masses don't care
[08:50] <bluefoxicy> :)
[08:50] <Keybuk> why do you think Debian haven't started applying these patches?
[08:50] <bluefoxicy> lethargy.
[08:50] <Keybuk> whose lethargy?
[08:50] <bluefoxicy> it means they'd rather sleep than get work done.
[08:50] <Keybuk> no, I asked *whose* lethargy ... not what is it :p
[08:51] <bluefoxicy> the maintainers'
[08:51] <Keybuk> ah, so this is something the Debian maintainers should do?
[08:51] <bluefoxicy> sure, why not?
[08:51] <Keybuk> but they know nothing about it
[08:52] <trulux> false! :P
[08:52] <bluefoxicy> Trulux, solar, who was that other guy
[08:52] <bluefoxicy> steve kemp?
[08:52] <trulux> yes
[08:52] <trulux> skx
[08:52] <Keybuk> if they knew something about it, and believed in it, they'd do it
[08:52] <Keybuk> to use a very bad, but simple example:
[08:52] <trulux> bluefoxicy, steve is on a pub
[08:52] <bluefoxicy> solar offered to be a cross-distro developer and help get this stuff in debian
[08:52] <bluefoxicy> trulux:  an irish pub?
[08:52] <Keybuk> mail debian-devel and ask them to package a piece of software
[08:52] <trulux> bluefoxicy, lol, dunno
[08:52] <Keybuk> generally, the answer (unless someone likes it) will be "do it yourself"
[08:53] <bluefoxicy> heh
[08:53] <Keybuk> Debian pretty much operates on the basis of people doing stuff because it gives them a woody
[08:53] <azeem> I thought the generally the answer is just silence :)
[08:53] <bluefoxicy> XD
[08:53] <Keybuk> if they've not done something, it's not because they're asleep, it's just that they're limp about it
[08:53] <Keybuk> azeem: that's because everyone's bored of saying "do it yourself" mostly :)
[08:54] <Keybuk> personally I find shared libraries, compilation and build systems and package management rather interesting
[08:54] <Keybuk> the packages I maintain reflects that pretty well
[08:55] <bluefoxicy> no one even offered up mirror space :)
[08:56] <bluefoxicy> how big is ubuntu's main distribution? (not universe)
[08:56] <trulux> :)
[08:56] <Keybuk> I find (e.g.) kernels a bit dull; sure, they're vaguely interesting and have to be there, but I don't get excited about it enough to contribute
[08:56] <Keybuk> bluefoxicy: that's somewhat assuming people *had* mirror space
[08:56] <Keybuk> bluefoxicy: not huge, the desktop set is designed to fit on a single CD ... the whole main set is probably no more than twice that size in total
[08:56] <bluefoxicy> it comes from somewhere; debian has 13 binary distributions scattered on how many mirrors?  Are they all at max quota?
[08:57] <Keybuk> bluefoxicy: Debian is always under-hardwared
[08:57] <trulux> Keybuk, http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/HARDENING?rev=1.2&content-type=text/vnd.viewcvs-markup
[08:57] <bluefoxicy> heh
[08:57] <trulux> :)
[08:57] <Keybuk> there's several machines down, the primary webserver is massively overloaded, the security mirror is out of disk space, etc.
[08:57] <bluefoxicy> lol
[08:57] <bluefoxicy> screw max quota
[08:57] <Keybuk> trulux: what's that to show?
[08:57] <bluefoxicy> the disk just can't take it anymore
[08:58] <bluefoxicy> ye cannae change the laws of physics
[08:58] <trulux> Keybuk, http://ecate.tuxedo-es.org/ runs a some-old stuff of hardened debian
[08:59] <lamont> bluefoxicy: ubuntu main/restricted with source was around 4GB, I believe
[08:59] <lamont> with hoary bits there, I'm stting at about 8GB
[08:59] <lamont> but there's a bit of universe and multiverse on that mirror
[08:59] <lamont> actually, just the pool is ~5GB
[09:00] <Keybuk> if you're really interested in getting Debian to accept things, you simply do them
[09:00] <trulux> Keybuk, talking to me?
[09:00] <bluefoxicy> lamont: no source
[09:00] <Keybuk> get the patches in as a kernel-patch-blah thing, join the kernel team and help get them integrated into the kernel; join the gcc/glibc team, etc.
[09:01] <bluefoxicy> anything beyond talking and thinking and playing sonic the hedgehog is beyond my skills
[09:01] <bluefoxicy> *cough*lazy*cough*
[09:02] <lamont> bluefoxicy: the sum of the sizes for everything in warty/main (i386 only) is<PHONE_NUMBER> bytes
[09:03] <bluefoxicy> 1.8G of debs o.o
[09:03] <lamont> bluefoxicy: in warty/main.
[09:03] <lamont> i386
[09:03] <lamont> *~3 for all 3 architectures, of course.
[09:05] <T-Bone> lamont: dude, stage 2.2 on the go :)
[09:07] <Keybuk> nite dudes
[09:29] <lamont> T-Bone: I finally wrote a script called 'iterate'. :-)
[09:31] <T-Bone> lamont: sweet! Am i a valid beta-tester? :^)
[09:32] <lamont> T-Bone: it's not much of a script, truthfully
[09:32] <T-Bone> lol
[09:38] <lamont> 17 lines...
[09:41] <lamont> the arch-all pain is that you need them there once the arch-dep packages are there, but not before.
[10:07] <grok> hello all, the usb drivers don't seem to work/get loaded on warty+ G4. any ideas how to get installation going?
[10:08] <grok> (usb is kinda needed for keyboard :)
[10:08] <grok> wakey wakey, eggs and bakey!
[10:11] <grok> well, see you later then.
[10:32] <T-Bone> mdz: ping?
[10:46] <Mitario> hihi
[11:06] <mdz> T-Bone: pong


[00:03] <blackboxsw> SRU uploads queued for 23.3 into Focal, Jammy and Lunar -proposed. Thanks falcojr for the PRs and uploads there. We will probably start an SRU verification this week then
[00:04] <blackboxsw> dbungert: as a heads up, this is the cloud-init SRU that we know will require a livecd-rootfs set of changes to drop the After=snapd.seeded.service systemd dependency ordering for Jammy
[00:04] <dbungert> blackboxsw: ack, I started the livecd-rootfs side today
[00:04] <blackboxsw> falcojr is going to manage the SRU release for 23.3. I'll assist w/ subiquity-specific testing where needed.
[01:10] <blackboxsw> ppa:cloud-init-dev/proposed has cloud-init 23.3 uploaded and built for focal, jammy, lunar and mantic if that helps anyone for testing.
[16:59] <senzilla> Hello 👋 Any OpenBSD people here? 😊 I have run into some issues related to dhcp and network bring-up on OpenBSD
[17:00] <senzilla> I chatted to minimal yesterday, and I will open an issue on GitHub tomorrow and describe the issues in more detail
[17:02] <minimal> meena: ping!
[17:14] <senzilla> meena: Thanks for all the FreeBSD improvements to cloud-init! I think it's brought OpenBSD a lot closer as well! 🙂
[17:59] <meena> senzilla: hi
[18:00] <meena> minimal has relayed your issues, but i haven't had much time to do stuff today
[18:00] <meena> kiddo is back to school on Friday…
[18:03] <meena> So, essentially, we need to split this into a base class, and one for each divergent BSD
[18:15] <senzilla> meena: Right. We might also need a new Dhcp class. IscDhclient might not cut it for OpenBSD since it's based on dhclient which is being phased out in OpenBSD. It would be better to use dhcpleasectl instead
[18:16] <inflatador> minimal thanks for the heads-up on that
[18:16] <minimal> senzilla: dhcpcd and udhcpc support was added recently as part of catering for dhclient EOL
[18:16] <senzilla> meena: dhclient is still in OpenBSD base, but it's not working well with assumptions in cloud-init (pid files and lease files are not compatible I think)
[18:18] <senzilla> Yesterday, I started stubbing out a new Dhcp class for dhcpleased/dhcpleasectl . I won't find much time in the next couple of days, but I think it'll be pretty straight forward
[18:20] <minimal> senzilla: is that IPv4 only?
[18:22] <senzilla> Yeah, unfortunately I think so
[18:37] <senzilla> I think the OpenBSD distro class could set preferred dhcp class priority based on ipv6 setting
[18:41] <meena> senzilla: how well would dhcplease(d|ctl) work for the net_ops class?
[18:42]  * meena is trying to update her dev VM to 14.0 ALPHA
[18:48] <senzilla> meena: I need to dive into the code base a bit more to answer that. Don't have it in front of me right now
[18:51] <senzilla> meena: and, good luck with the VM update :)
[18:51] <meena> https://github.com/canonical/cloud-init/blob/main/cloudinit/net/dhcp.py#L199
[18:51] <meena> not netops, netops should work.
[18:51] <meena> already ran out of memory twice on compiling LLVM.
[18:51] <senzilla> Yes, I think netops will work. But I don't think IscDhclient will work
[18:52] <holmanb> senzilla: hi o/
[18:53] <senzilla> I think we need a new class, something like Dhcpleased(DhcpClient) which works entirely with dhcpleased and dhcpleasectl
[18:53] <senzilla> holmanb: 👋
[18:53] <holmanb> senzilla: thanks for digging into this, your help on this is welcome and appreciated :D
[18:53] <holmanb> senzilla: sounds like you're on the right track
[18:54] <senzilla> I'm not super
[18:55] <senzilla> ...familiar with python
[18:55] <meena> senzilla: do you have any sysvinit files for OpenBSD you can contribute?
[18:55] <senzilla> is it only the @classmethod methods that count as the actual "public" Dhcp class interface?
[18:56] <meena> senzilla: we'll happily help… but, i wasn't super familiar with Python before starting to work on cloud-init (and iocage)
[18:56] <holmanb> senzilla: fyi, the Udhcpc class is incomplete and won't fully function on azure (and maybe others, would need to check), but it's a really good starting place to get a dhcp_discovery() implimented for whichever class is needed for OpenBSD
[18:57] <holmanb> senzilla: no classmethod just means that the method can be called with the class without instansiating an object instance
[18:58] <senzilla> meena: I do not have any sysvinit files. I actually think the best way to integrate cloud-init is to patch /etc/rc. I don't like patching base, but I think it makes sense here. Because OpenBSD have intentionally hard coded a lot of the init and service startup procedures. And getting cloud-init inserted early enough would require patching /etc/rc
[18:59] <meena> oy
[18:59] <meena> i didn't realize
[18:59] <meena> but i think goneri does it similarly
[18:59] <senzilla> Alternatively, a cleanly packaged version could create a couple of sysvinit files. But cloud-init will only come in right at the end after all base services
[19:00] <meena> https://goneri.lebouder.net/2022/11/11/bsd-cloud-image-org-new-images/
[19:00] <senzilla> meena: goneri is writing the cloud-init boot stages to /etc/rc.local which is only just before user defined services. Still way after base services start up
[19:01] <senzilla> meena: Yeah, I have studied goneri's work a fair bit
[19:02] <meena> on FreeBSD we're very early. basically, after network is up (including ntpd, i think) and after the critical part of the filesystems is mounted.
[19:03] <senzilla> Yeah, one have to patch /etc/rc to get inserted that early in OpenBSD. The hard coded and fully predictable start up order in BSD is great for robustness, predictability and security guarantees
[19:03] <senzilla> It's less good for integration :P
[19:04] <senzilla> s/BSD/OpenBSD/
[19:04] <meena> *nod* *nod*
[19:05] <senzilla>  But hey, rc is placed in /etc... It's free for all right :P
[19:09] <meena> are there any other ports that modify /etc/rc?
[19:16] <senzilla> Don't think so. I think the port should *not* patch /etc/rc . I doubt that would get accepted. It's probably best to leave that as a documented manual intervention
[19:17] <senzilla> I have got a set of Packer templates for building cloud-init OpenBSD VMs. Similar to what goneri is doing.
[19:19] <senzilla> I haven't reached out to goneri yet, but it would make sense to collaborate with him on a standard pre-patched cloud-init OpenBSD image


[07:17] <bzoltan_> jibel: brendand is not online, but I think somebody from the Mir team should know about this http://pastebin.ubuntu.com/13245871/
[07:18] <bzoltan_> Mirv:  do you know anybody early bird from the MIr team?
[07:23] <Mirv> bzoltan_: RAOF is a late bird
[07:29] <bzoltan_> Mirv:  I wonder if it is related to the testtools problem brendad was talking about
[08:36] <jibel> robru, hey, I tried to trigger an autopkgtest run with https://ci-train.ubuntu.com/job/ubuntu-landing-057-2.5-autopkgtests/build but it does nothing
[08:36] <jibel> robru, any clue?
[08:37] <jibel> it returns immediately, no job in the queue
[09:05] <robru> jibel: doesn't look like you triggered the job... Did you click "build" on that page?
[09:06] <jibel> robru, I did :)
[09:06] <jibel> robru, several times
[09:06] <jibel> robru, I did it again and it worked
[09:06] <jibel> weird
[09:07] <robru> jibel: it's the same as all the rest of the Jenkins jobs, you have to click once to log in then click again to actually trigger it
[09:08] <jibel> robru, yeah I know jenkins a little bit, but pressing the button did nothing
[09:08] <jibel> anyway now it's running
[09:09] <robru> jibel: yeah "did nothing" means "redirected through sso then redirected back to the same form you were looking at before".
[09:09] <robru> jibel: looks like it exploded pretty bad
[09:10] <jibel> robru, nothing nothing, and I pressed several times. but it okay now it's running
[09:11] <jibel> robru, heh, I picked the wrong package apparently :)
[09:11] <robru> jibel: you may have better results if you run it on a silo that exists :-P
[09:11] <jibel> robru, man, it existed half an hour ago
[09:12] <jibel> does it mean it is not the day to test autopkgtest on silos and I should do something else?
[09:16] <robru> jibel: you can test it, it just has to be a request that isn't already landed
[09:17] <jibel> robru, so after requesting an autopkgtest I wait 15 min for the result?
[09:18] <robru> jibel: I'm not sure how long it takes but the train will poll for results every 15 minutes
[09:18] <jibel> robru, ack
[09:20] <robru> jibel: i expect the current code will be plagued with false negatives (failures that aren't real failures) because it doesn't distinguish between regressions and "always failed" the way proposed migration currently does. We're working out how to get that up to par for the next iteration
[09:20] <jibel> sil2100, apparently silos 3, 57 and 0 landed but I don't see any message in vivid overlay's changelist, is change bot dead?
[09:21] <sil2100> jibel: hm, let me check what happened
[09:21] <jibel> robru, yeah we need that, triggering a test must be automated not manual and we also need to test rdeps
[09:21] <sil2100> jibel: by silo 0 you mean the libphonenumber thing?
[09:22] <jibel> but it is a start
[09:22] <jibel> sil2100, yes
[09:22] <jibel> no
[09:22] <sil2100> jibel: I see a message about it from 2 days ago
[09:22] <jibel> sil2100, I mean dialler-app
[09:22] <jibel> sil2100, https://requests.ci-train.ubuntu.com/#/ticket/648
[09:22] <jibel> sil2100, https://requests.ci-train.ubuntu.com/#/ticket/647
[09:23] <robru> jibel: we decided not to do automatic tests in case it would overburden the test infra, but i think ultimately the plan is to have landers submit autopkgtests prior to submitting for qa so it at least doesn't waste your time.
[09:23] <jibel> sil2100, and https://requests.ci-train.ubuntu.com/#/ticket/644
[09:23] <sil2100> Ok, need to check
[09:23] <sil2100> Aww come ooon, looks like my instance died
[09:24] <jibel> robru, if it triggers a test when it's marked ready for qa it won't overburden the infra
[09:25] <jibel> robru, on average it's less than 20 silos a week with peaks at 30
[09:25] <jibel> that won't kill the infra
[09:25] <jibel> even if you run them 3 times per silo
[09:25] <robru> jibel: i was envisioning the other way, landers must get passing autopkgtest before at cab be marked ready for qa. Like bileto would only mark it ready after successful testing
[09:26] <robru> jibel: the concern was from pitti, if we auto test after every build it's too much, the test infra is quite weak and overburdened already
[09:27] <jibel> robru, I agree with pitti and it's why I think running once when the lander thinks it's ready for QA is a good compromise
[09:27] <jibel> it's what we'll do manually anyway
[09:27] <jibel> so if we can save this button pressing task it's all good
[09:28] <robru> jibel: yeah it's in the plans, lots of rough edges need to be polished up still
[09:29] <robru> jibel: for now though the feature is there, you can poke at the autopkgtest and see what happens. Hopefully we'll get it smoother soon and landers can start doing it
[09:30] <jibel> robru, although what we really need is reverse dependencies testing. not all packages have autopkgtest but frequently rdeps do have tests and proposed-migration finds lot of regressions this way
[09:33] <robru> jibel: yeah the next step is to enable full britney, it will do rdeps and everything just like proposed migration. But that's a big task to enable in the train, will be some time for that to go live.
[09:50] <robru> jibel: oh for silo 51 it looks like it didn't have any tests, the log shows it skipped submitting anything
[09:51] <jibel> robru, right, I just picked a random silo to see if the build was working
[09:56] <robru> jibel: yeah it seems i need to rework this quite a bit, the silo status makes it sound like it's doing something. I'm working on a major overhaul of the silo status reporting that should clarify what is actually going on, but could be a few days before i finish
[10:05] <xavigarcia> sil2100: ping
[10:05] <sil2100> xavigarcia: pong
[10:06] <xavigarcia> sil2100: hi! I have a question... I would need to move libuntiy-api-dev to main repository, as it is a dependency for a new project we are planning to land and that will be a dependency of the sound indicator
[10:06] <xavigarcia> sil2100: can you help me with that?
[10:07] <sil2100> xavigarcia: it's already handled :)
[10:07] <sil2100> xavigarcia: I did that last week actually
[10:07] <xavigarcia> sil2100: ah, ok...cool!
[10:07] <sil2100> https://bugs.launchpad.net/ubuntu/+source/unity-api/+bug/1512784
[10:07] <xavigarcia> sil2100: great!, then I guess silo 51 should be good to go
[10:08] <xavigarcia> sil2100: and now a second question. I need to add the project gmenuharness to the repository
[10:08] <xavigarcia> sil2100: it's a new project, and contains the base to implement integration tests for all indicators
[10:09] <xavigarcia> sil2100: this is the url: https://launchpad.net/gmenuharness
[10:10] <xavigarcia> sil2100: we'd need to land this asap to avoid having the issues we've got for ota-8 and the indicator-sound silo
[10:10] <sil2100> xavigarcia: ok, in that case you'll need to prepare the packaging and go through the normal landing procedures, after which the package will need to be preNEWed and then NEWed by someone from the archive team
[10:11] <sil2100> xavigarcia: a preNEW procedure is getting some archive admin review your silo after it passes QA
[10:11] <sil2100> To check the packaging etc.
[10:11] <jibel> sil2100, I forgot to ask during the meeting, can you 'enable' the OTA version in the RC channel so we can test before the image is promoted to stable?
[10:11] <xavigarcia> sil2100: ok... the packaging should be ready, so I will create a silo for it
[10:11] <xavigarcia> sil2100: thanks!
[10:11] <sil2100> Normally we wouldn't need a preNEW procedure, but since overlay landings go directly to the overlay PPA I would prefer someone to check it early
[10:12] <xavigarcia> sil2100: sure
[10:12] <sil2100> jibel: ok, yeah, that's my priority today, will give you a sign once it's done
[10:13] <jibel> sil2100, thanks
[11:07] <jibel> sil2100, can you check if you can restart your instance, it should be fixed
[11:07] <sil2100> jibel: yeah, the e-mails got sent, the instance restarted
[11:18] <brendand> sil2100, hey dude
[11:20] <sil2100> brendand: hey
[11:21] <brendand> sil2100, do you know what happens to old version of e.g. messaging-app when a new one lands in the overlay ppa?
[11:21] <brendand> sil2100, is it just 'disappeared'
[11:21] <sil2100> brendand: no, it's still there, you can download it if needed but it's not super trivial - it's superseeded by the new version but still there
[11:22] <sil2100> I have a script that downloads selected versions from the overlay
[11:23] <brendand> sil2100, but in terms of being available for install using apt etc?
[11:23] <sil2100> brendand: bzr branch lp:landing-team-tools and use the overlay-ppa-dl-package script - you can download either .deb binaries (by default), or grab the source by giving the -s options
[11:23] <sil2100> apt also should be able to install it if you explicitly give it a version number
[11:24] <sil2100> hm, or let me think
[11:24] <sil2100> Actually hm, no, apt won't see it I think
[11:25] <sil2100> brendand: I suppose the only option is to download the .deb's directly and installing with dpkg I think
[11:25] <sil2100> brendand: but I would have to check if apt won't find the package if you give the version number directly
[11:29] <sil2100> brendand: ok, so as I thought, it seems that apt just wont see it
[11:32] <brendand> sil2100, ok
[11:35] <brendand> sil2100, makes it a bit more difficult but at least its possible
[13:08] <xavigarcia> sil2100: ping again :)
[13:08] <xavigarcia> sil2100: could you please take a quick look to this build? https://ci-train.ubuntu.com/job/ubuntu-landing-000-1-build/540/console
[13:09] <xavigarcia> sil2100: I think something is wrong in the project configuration
[13:09] <xavigarcia> sil2100: for example: https://launchpad.net/ubuntu/+source/libgmenuharness does not exist
[13:11] <sil2100> xavigarcia: is the branch configured as bzr split?
[13:12] <sil2100> xavigarcia: yeah, so I don't see the .bzr-builddeb directory
[13:12] <sil2100> xavigarcia: check how other projects are done and be sure to include the same things in .bzr-builddeb of your bzr branch, since otherwise it won't generate the tarball from the source tree
[13:13] <xavigarcia> sil2100: oh, ok... will do that
[13:13] <xavigarcia> sil2100: thanks!
[14:44] <sil2100> rvr: ping
[15:05] <rvr> sil2100: pong
[15:06] <sil2100> rvr: hey! Is your krillin free right now?
[15:06] <rvr> sil2100: Yes
[15:32] <AlbertA> trainguards: so this says landed, but I only see the packages released into stable-phone-overlay
[15:32] <AlbertA> https://requests.ci-train.ubuntu.com/#/ticket/604
[15:32] <AlbertA> and not in xenial or xenial proposed
[15:32] <AlbertA> did I not configure the entry properly for dual landing?
[15:41] <greyback> trainguards: hey, this is to fix a ftbfs on armhf xenial: https://requests.ci-train.ubuntu.com/#/ticket/646 can someone hit merge please?
[15:52] <Mirv> greyback: publish? it's not set to "Publish without QA"?
[15:53] <greyback> Mirv: ah boo, I chose the wrong option
[15:54] <greyback> Mirv: okay, now I can press buttons
[16:10] <AlbertA> Mirv: any idea why this didn't make it to xenial ? https://requests.ci-train.ubuntu.com/#/ticket/604
[16:27] <Mirv> AlbertA: the silo was configured to use overlay PPA (dual landings should have the field empty - vivid will go to overlay anyway), so the mir is in... overlay PPA also for xenial dput ppa:ci-train-ppa-service/landing-012 ../build-area/qtpim-opensource-src_5.0~git20140515~29475884-0ubuntu16~xenial1~test1_source.changes
[16:27] <Mirv> AlbertA: s/wrongcopypaste/https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[16:27] <Mirv> also some unity-scopes-shell it seems :P
[16:30] <Mirv> as I'm MOTU I was able to copy the unity-scopes-shell to archives, but the mir is in main so needs core-dev
[16:31] <greyback> Mirv: hey, I've a qtmir bug fix I want to land fairly soon (https://requests.ci-train.ubuntu.com/#/ticket/654) - think I should wait for https://requests.ci-train.ubuntu.com/#/ticket/646 to migrate? Will a dual landing work after a xenial-only landing?
[16:39] <Mirv> greyback: OTA8 blocker is good enough reason, so I'll merge&clean 646. it has at least built so it will probably migrate. dual landing should work fine since the trunk is always xenial/dev anyway. and if not we'll just do some manual publishing once.
[16:39] <Mirv> noting to myself I shouldn't be here, but it seems no other trainguards are here either right at the moment
[16:41] <greyback> Mirv: nice , thank you for the help
[16:42] <Mirv> greyback: ok go ahead in building 654
[16:42] <greyback> Mirv: just kicked off
[16:43] <AlbertA> Mirv: thanks, so should I just make a sync from overlay entry to get it into xenial?
[16:45] <Mirv> AlbertA: either that or just get some core dev like RAOF to copy-package it to xenial-proposed
[16:47] <AlbertA> Mirv: cool thanks
[17:23] <robru> AlbertA: that is strange
[17:25] <robru> Oh I see, hmm I should make the train just ignore that field for dual silos
[17:29] <AlbertA> robru: yeah sorry, I didn't catch that you are not to supposed to use that field anymore...
[17:33] <robru> AlbertA: I recommend just getting a core dev to copy manually. If you make a sync request you still need a core dev anyway so it's a bit pointless for you
[17:33] <AlbertA> robru: yeah I'll ask RAOF on his monday


 Check out Boss Rush by Do a Barrel Roll! … https://play.google.com/music/m/Bdhcfueyifohkf5qmmjfcpvvxde?t=Boss_Rush_-_Do_a_Barrel_Roll
 This album is amazing!
 @KMyers Ransomware simulator https://www.knowbe4.com/press/knowbe4-launches-industrys-first-ransomware-simulator
 Will relay that to a few people
 Anything going on today/tonight?
 I know someone selling a 500 GB Samsung 850 EVO for $180. Anyone looking for a new SSD. It is unopened
 Damn, really tempting
 https://www.youtube.com/shared?ci=bSioHCRN2IM
 That video should be enough to make you reconsider Samsung
 I have the EVO 840 in my laptop and have not had issues with it
 That video is rediculous though..
 Especially when the chick is handed the SSD, then when she picks up the screw driver
 "Uh... What?"
 But, seriously, if your friend could drop the price to $100, I might jump on it
 I think that may be asking too much though
 That's msata, though
 I'll ask
 Okay