[00:47] -queuebot:#ubuntu-release- Unapproved: android-platform-art (groovy-proposed/universe) [8.1.0+r23-3 => 8.1.0+r23-4] (no packageset) (sync)
[00:47] -queuebot:#ubuntu-release- Unapproved: rejected android-platform-art [sync] (groovy-proposed) [8.1.0+r23-4]
[00:47] -queuebot:#ubuntu-release- Unapproved: android-platform-system-extras (groovy-proposed/universe) [8.1.0+r23-2 => 8.1.0+r23-3] (no packageset) (sync)
[00:48] -queuebot:#ubuntu-release- Unapproved: accepted android-platform-system-extras [sync] (groovy-proposed) [8.1.0+r23-3]
[01:00] -queuebot:#ubuntu-release- Unapproved: gimp-help (groovy-proposed/universe) [2.8.2-2ubuntu1 => 2.10.0-1] (no packageset) (sync)
[01:00] -queuebot:#ubuntu-release- Unapproved: accepted gimp-help [sync] (groovy-proposed) [2.10.0-1]
[01:06] -queuebot:#ubuntu-release- Unapproved: symfony (groovy-proposed/universe) [4.4.11+dfsg-1ubuntu1 => 4.4.14+dfsg-1] (no packageset) (sync)
[01:06] -queuebot:#ubuntu-release- Unapproved: accepted symfony [sync] (groovy-proposed) [4.4.14+dfsg-1]
[09:14] <mwhudson> vorlon: http://launchpadlibrarian.net/502306338/casper_1.454_1.455.diff.gz is fairly cursed :)
[10:38] -queuebot:#ubuntu-release- Unapproved: hedgewars (groovy-proposed/universe) [1.0.0-11build1 => 1.0.0-12] (no packageset) (sync)
[10:38] -queuebot:#ubuntu-release- Unapproved: accepted hedgewars [sync] (groovy-proposed) [1.0.0-12]
[11:11] -queuebot:#ubuntu-release- Unapproved: gnome-boxes (groovy-proposed/universe) [3.38.0-1 => 3.38.1-1] (desktop-extra) (sync)
[11:31] -queuebot:#ubuntu-release- Unapproved: phpmyadmin-sql-parser (groovy-proposed/universe) [4.6.1-2ubuntu1 => 5.4.1-1] (no packageset) (sync)
[11:31] -queuebot:#ubuntu-release- Unapproved: accepted phpmyadmin-sql-parser [sync] (groovy-proposed) [5.4.1-1]
[13:00] -queuebot:#ubuntu-release- Unapproved: claws-mail (groovy-proposed/universe) [3.17.6-1 => 3.17.7-1] (no packageset) (sync)
[13:00] -queuebot:#ubuntu-release- Unapproved: accepted claws-mail [sync] (groovy-proposed) [3.17.7-1]
[13:03] -queuebot:#ubuntu-release- Unapproved: gnome-feeds (groovy-proposed/universe) [0.14.1+dfsg1-1 => 0.15+dfsg1-1] (no packageset) (sync)
[13:04] -queuebot:#ubuntu-release- Unapproved: accepted gnome-feeds [sync] (groovy-proposed) [0.15+dfsg1-1]
[13:10] -queuebot:#ubuntu-release- Unapproved: python3.9 (groovy-proposed/universe) [3.9.0-3 => 3.9.0-4] (i386-whitelist)
[13:11] -queuebot:#ubuntu-release- Unapproved: accepted python3.9 [source] (groovy-proposed) [3.9.0-4]
[13:55] -queuebot:#ubuntu-release- New sync: r-cran-cubelyr (groovy-proposed/primary) [1.0.0-2]
[13:56] -queuebot:#ubuntu-release- New sync: r-cran-broom.mixed (groovy-proposed/primary) [0.2.6-2]
[13:56] -queuebot:#ubuntu-release- Unapproved: r-cran-mice (groovy-proposed/universe) [3.10.0-1 => 3.11.0-1] (no packageset) (sync)
[13:57] -queuebot:#ubuntu-release- Unapproved: accepted r-cran-mice [sync] (groovy-proposed) [3.11.0-1]
[14:02] <ginggs> r-cran-cubelyr and r-cran-broom.mixed ^ should fix LP: #1895203
[15:16] -queuebot:#ubuntu-release- Unapproved: cinnamon-session (focal-proposed/universe) [4.4.1-1 => 4.4.1-1ubuntu0.1] (no packageset)
[18:01] -queuebot:#ubuntu-release- Unapproved: gnome-nibbles (groovy-proposed/universe) [1:3.38.0-1 => 1:3.38.1-1] (desktop-extra) (sync)
[21:48] -queuebot:#ubuntu-release- Unapproved: budgie-desktop (groovy-proposed/universe) [10.5.1+git20200824-2 => 10.5.1+git20200824-2.0ubuntu1] (personal-fossfreedom, ubuntu-budgie)
[23:55] -queuebot:#ubuntu-release- Unapproved: gnome-shell-extension-draw-on-your-screen (groovy-proposed/universe) [8.1-1 => 9-1] (no packageset) (sync)
[23:55] -queuebot:#ubuntu-release- Unapproved: accepted gnome-shell-extension-draw-on-your-screen [sync] (groovy-proposed) [9-1]
[23:55] -queuebot:#ubuntu-release- Unapproved: sysprof (groovy-proposed/universe) [3.38.0-2 => 3.38.1-1] (no packageset) (sync)
[23:56] -queuebot:#ubuntu-release- Unapproved: accepted sysprof [sync] (groovy-proposed) [3.38.1-1]


[00:25]  * Batshua has paid the bill.
[00:25] <Batshua> Actually, more pressing problem, I think.
[00:26] <Batshua> I updated to .24-fixes at the behest of mythtv-users, and now my audio has done borked itself
[00:26] <Batshua> i WAS using pulseaudio
[01:59]  * Batshua waves at the channel
[01:59] <Batshua> If you saw me in #mythtv-users, you know what's going on, otherwise, here goes:
[01:59] <Batshua> I am now using mythtv 0.24-fixes on lucid.  In the prior version, audio was fine.
[02:00] <Batshua> Now I have NO AUDIO, but only on mythtv.  Audio is fine on the rest of the system.  I have tried EVERY available audio setting in mythtv to no avail.
[02:00] <Batshua> I do not know where to go from here, and if anyone could assist, I would be extremely grateful.
[04:09] <gregL> Batshua, Did you scan for audio in the frontend?
[04:09] <Batshua> yes
[04:09] <Batshua> i tried every option in there except null
[04:11] <gregL> It works outside of mythtv?
[04:13] <Batshua> yup
[04:13] <Batshua> in 0.23 i was using pulseaudio (which i hear is impossible) and it worked fine
[04:13] <Batshua> since the upgrade, ... no sound in mythtv
[14:04] <James2> any ideas why when i launch mythtv backend setup, all i get is a blank screen?
[14:05] <James2> the terminal window shows no errors, and shows that it connected to the db etc
[14:06] <rileyp> you mean mythtv-setup?
[14:06] <rileyp> or mythbackend
[14:07] <rileyp> if mythbackend you wont see anything as its just a daemon
[14:07] <rileyp> mythtv-setup brings up a gui
[14:08] <James2> mythtv-setup.real
[14:08] <James2> checking on my drivers,
[14:08] <rileyp> you dont need the .real
[14:08] <James2> the nvidia driver is saying
[14:08] <James2> no, thats what teh task bar says
[14:08] <James2> i laucnhed it from the menu
[14:08] <James2> the nvidia driver is saying "this driver is activated but not currently in use"
[14:09] <rileyp> drivers? you dont set drivers in mythtv-setup
[14:09] <James2> ive been googling, and not having the drivers setup proerly was one of the issues that was mentioned
[14:09] <James2> i can seee the background of the mytht-setup prog, but none of the options show up
[14:09] <rileyp> ahh so you want to install nvidia drivers
[14:10] <rileyp> so have you run sudo nvidia-xconfig
[14:10] <James2> ah right
[14:10] <rileyp> to set up xorg.conf for nviida
[14:10] <rileyp> go read how to install nv drivers please
[14:11] <rileyp> then sudo servive gdm restart
[14:11] <rileyp> and nv wil activate if you have the drivers installed
[14:11] <rileyp> esle no screen and you sad
[14:11] <rileyp> sadder
[14:12] <James2> hmm
[14:12] <James2> done ethat now vnc isnt working
[14:12] <rileyp> if your unsure look in synaptic at what nv driver are installed
[14:12] <James2> i used the proprietory drivers gui
[14:13] <James2> 173 is installed
[14:13] <rileyp> lol what version of nv card is it?
[14:13] <rileyp> model sorry
[14:13] <rileyp> a 440
[14:13] <James2> 7300 GS
[14:13] <James2> no its well old
[14:14] <James2> its the newest nvidia card with a working svideo output
[14:14] <rileyp> well thne you wont be running latest nv drivers I know
[14:14] <James2> 8xxx series onwards they removed the svideo capabilities
[14:14] <rileyp> maybe just run stock driver until you find a good guide for your card
[14:14] <James2> as i found out when i tried upgrading the card a couple of years ago lol
[14:15] <James2> no it must be running the nvidia driver for the tvout to work
[14:15] <rileyp> well then find a guide its not a mythbuntu issue its a my nv card wont play cricket issue
[14:16] <James2> well now i have no screen even when it boots
[14:16] <James2> white and black vertical lines is all im getting now lol
[14:16] <James2> and i cant ssh or vnc in lol
[14:17] <rileyp> ctrl alt and f1
[14:17] <James2> s
[14:17] <James2> to skip whatever it was waiting for
[14:17] <rileyp> and then sudo rm /etc/X11/xorg.conf
[14:17] <rileyp> and then sudo service gdm restart
[14:18] <rileyp> and you will have gui but no nv xorg,conf
[14:18] <James2> ok, lets see what it was waiting for on the boot
[14:19] <rileyp> that does not skip anything it simply puts you in a tty screen as apposed to the gnome which driver isnt working
[14:19] <James2> damn i7 quad core with ssd boots fast :P
[14:19] <Zinn> James2: Please watch your language.
[14:19] <James2> and same issue on boot :S
[14:19] <James2> hmm
[14:20] <James2> and the same regardless which tty im looking at
[14:20] <James2> once it boots gfx are fine however
[14:20] <James2> perhaps this card is on its way out lol
[14:21] <rileyp> I doubt you just nendd to set your xorg.conf correctly
[14:21] <rileyp> need sorry
[14:21] <James2> its fine once it boots
[14:21] <James2> its only the "loading mythbuntu" screen which looks fugly
[14:21] <rileyp> did you remove xorg.conf?
[14:21] <James2> yes
[14:21] <James2> this is post having done that
[14:21] <rileyp> so now its not using nv driver ok
[14:22] <James2> it did it before and after
[14:22] <James2> as i ihave a picture on my monitor, yes
[14:22] <James2> whe its set to use the nv driver, the only output goes to the svideo (which i have othing connected to) hence needing to use vnc
[14:24] <rileyp> thats if you have your xorg.conf set that way you should be able to run both vga or dvi and svideo at same time you just need to make xorg.conf right
[14:24] <James2> time to put vga=771 on the boot options
[14:24] <James2> no snag with these cards
[14:24] <James2> you can only use one of the outputs at a time
[14:24] <James2> it cant clone the output as the svideo and monitor cannot display the same res
[14:25] <rileyp> then you know more than I do about it so good luck...
[14:25] <James2> you end up losing half the tv picture if you try cloning it
[14:25] <James2> but why i have screwed  gfx during boot i haave no idea
[14:25] <rileyp> dont clone
[14:25] <James2> once X starts, they sort themselves out
[14:26] <rileyp> run seperate res on each
[14:26] <rileyp> in xorg.conf
[14:27] <James2> where the kernel boot options in ubuntu
[14:27] <James2> grub doesnt have a menu.lst, so where doe it get the list tof boot options from?
[14:27] <rileyp> like this one here 2 diff displays 2 diff setups http://www.mythtv.org/wiki/User_Manual:JudderFree
[14:27] <Zinn> [www.mythtv.org] User Manual:JudderFree - MythTV
[14:28] <rileyp> grub2 is awesome
[14:28] <rileyp> just gotta know its tricks
[14:28] <James2> look i only have 1 screen to be configured on this system, a TV
[14:29] <James2> i will not have a monitor connected once installed
[14:29] <rileyp> Im not looking  :P
[14:29] <James2> it will not even be remotely possible to plug a screen in, so i will not setup X for anything other than what i need
[14:29] <James2> thats what vnc is for lol
[14:29] <rileyp> ok thats good
[14:30] <James2> and fyi, service gdm restart doesnt restart vnc
[14:30] <rileyp> you just said you cant vnc
[14:30] <James2> you have to reboot to have the same effect, while leaving vnc working
[14:30] <rileyp> I know
[14:30] <James2> if you service gdm restart, i then have to ssh in, issue a reboot command, and after the reboot i can vnc back in
[14:31] <James2> yeah i couldnt vnc because you told me to restart gdm lol
[14:31] <rileyp> I dint know you were using vnc you  said you couldnt
[14:33] <rileyp> James this is going nowhere go find a guide on how to setup svideo. I think thoigh support is waneing in the newer kernels
[14:33] <James2> youre really not helping lol
[14:33] <James2> i dont need help setting up svideo
[14:33] <James2> im trying to work out how to change the boot options given to the kernel by grub
[14:34] <James2> so that i can see the screen while it is booting, ie BEFORE x is started
[14:35] <James2> thats edit
[14:35] <James2> /etc/default/grub
[14:35] <James2> and grub-mkconfig btw
[14:37] <rileyp> after you edit /etc/default/grub you need to run sudo update-grub
[14:38] <rileyp> so that the grub menu is updated with your edits
[14:39] <rileyp> grub mk config Im not usre if it even looks at etc/default/grub when making the configuration file
[14:55] <James2> ty
[14:55] <James2> i have a screen now having disable quiet and splash
[14:56] <James2> no idea why splash rendered so wierdly tho
[15:07] <James2> has anyone got any experience of running a DVB-T and DVB-S cards in the same system
[15:07] <James2> mainly to do with listings info, as i can get listing info for both types by EIT,
[15:08] <James2> but they share 90% of the same channels, all of which are updateable by xmltv
[15:08] <James2> but channel numbers (and rarely times) vary between the different sources
[15:10] <James2> also how can i force a particluar card dto be detected as a certain /dev/dvb/adaptorX
[15:10] <James2> atm i have a dual channel nova-t card, and a dual dvb-s card
[15:11] <James2> /dev/dvb/adaptor0/frontend0 and /dev/dvb/adaptor2/frontend0 are the dvb-t card
[15:11] <James2> and
[15:11] <James2> /dev/dvb/adaptor1/frontend0 and ../frontend1 are the dvb-s card
[15:17] <James2> they do seem to be staying the same after reboots
[19:50] <James2^2> h iguys
[19:50] <rhpot1991> !ask
[19:50] <Zinn> Please don't ask if anyone is around or if it is alright to ask a question.  Many people check back periodically and may answer your question when they see it.  IRC is not normally an instant fix so check back often for an answer.
[19:51] <James2^2> ok, with a system where i have DVB-T and DVB-S cards, i have added all the dvb-t channels, ive just added 100+ non conflicting dvb-s channels, but now it is asking me "insert all, insernt manually or ignore all" with 115 conflicting dvb chanels
[19:51] <James2^2> what should i do?
[19:52] <James2^2> i have created different input sources for dvb-t and dvb-s
[19:59] <James2^2> any idea?
[20:01] <James2^2> i know im going to have channels available on multiple inputs
[20:01] <James2^2> eg, bbc1 could come from dvb-t or dvb-s
[20:14] <James2^2> ooh now i have "off air" channels too lol
[20:15] <James2^2> and now "channel xxxxx (xxxx xx) was found to be in conflict with other channels. please enter a unique channel number"
[20:15] <James2^2> this is proving to be a right pita lol
[21:33] <Number6> Any issues with upgrading to Natty?


[02:02] <zerothis> well I got lubuntu installed on my laptop with an Ali/Trident card using the "forcevesa" option. Now, the installed version blank screens, "forcevesa", "nomodeset", "acpi=off", all fail to avoid it. Only the installation option with forcevesa works. Not Live and not installed.
[02:02] <holstein> nomodeset is what i use
[02:02] <holstein> zerothis: i found that with lubuntu, i had to specify them post installation
[02:03] <holstein> i would actually just find an xorg.conf that works, and put it in place, and try it
[02:03] <holstein> http://ubuntuforums.org/showthread.php?t=1270209 for example
[02:05] <zerothis> I have specified them post installation in grub edit and using the liveCD to 'boot from hard disk'. Ineffective. I have tried mounting my installation from terminal after running the installer, but it won't mount.  Nothing else on the LiveCD works, everything but the installer goes to blank screen. The drive was running XP as well as XP can run before I overwrote it.
[02:11] <holstein> zerothis: as i said, if i cant mount the drive, i would test it.. its plausible that the drive is bad, since *all* drives will fail..
[02:11] <holstein> zerothis: if the live CD works, and the installed system doesnt, that could be due to failing hard drive, and nothing to do with the options you are passing
[02:12] <zerothis> "try lubuntu" does not work. How would I test the drive from the installer?
[02:14] <holstein> zerothis: i actually use whatever tool i feel would test the drive best based on the brand.. but, there are tools such as "gmartcontrol" that run tests
[02:14] <holstein> i would run a short test, then, a longer test that may take some time
[02:15] <holstein> or, since i have other drives laying about, i might just pop a new one in, and install, and test.. and if it works ok with a new drive, i woudl test the drive later
[02:15] <phillw> zerothis: when you boot the CD / USB  you will be offerred the option to run a test on the cd
[02:15] <holstein> thats on the installation media, though
[02:16] <zerothis> phillw: yes, the CD checked fine. Then I installed
[02:16] <holstein> i think the actual hard drive is failing.. since, the live environment works, and the installed one fails with a "black screen", though, the error when trying to mount the partition that installed is "unrecongized filesystem"
[02:17] <holstein> i mean, we know the filesystem is ext4, and lubuntu live CD's *can* recognize it.. and, that the live CD supports the grahpical environment on the hard drive
[02:17] <holstein> i feel, testing the actual hard drive will show an error
[02:18] <zerothis> I'm attempting tests now. So why wouldn't the "try lubuntu without installing" work then (since the live environment works)?
[02:18] <holstein> zerothis: not following that
[02:19] <holstein> zerothis: the "try lubuntu without installing" *is* the live environment
[02:19] <holstein> you stated the live CD works, correct?
[02:20] <holstein> id say, dont "attempt" to test the hard drive.. its a good idea to test *all* your drives since *all* drives fail.. but, its time consuming to do so.. you want to be sure you are doing it properly
[02:20] <zerothis> "try lubuntu without installing" boots to blank screen even with "forcevesa". but choosing the install option on the LiveCD menu will boot to the installation environment (same as try environment, right?) with the "forcevesa" option.
[02:20] <holstein> http://www.technibble.com/gsmartcontrol-monitor-test-hard-drive-smart-data/
[02:25] <zerothis> problem, how to run gsmartcontrol while the installer is running. I suppose there's a command-line way to run it in X. Or, how to run things when the installer is the desktop in X
[02:26] <holstein> you cant
[02:26] <holstein> i run all of that *before* the install
[02:26] <holstein> i am assuming you have an install that has failed that you are asking about
[02:26] <holstein> is that the case?
[02:30] <zerothis> I assumed the installation works, I just can't see it. During the boot, before X loads, its happily scrolling plain text linuxy things on the screen like it always does when boot is not quiet, until a few lines after the ALI15x3 errors (my videocard).  I could Alt+F2 and play an audio file to test that theory I suppose. so, now that I have a drive with lubuntu on it, I should format it?
[02:30] <zerothis> I have a terminal up in the installation environment now, gsmart testing now...
[02:30] <holstein> !tty
[02:31] <holstein> thats what i try on black screens.. though, i'll just put a vesa xorg in place
[02:31] <zerothis> nope, gsmartcontrolcrashes. it's requesting GTK things (overlay-scrollbar etc)
[02:32] <holstein> you will have those issue with any desktop components
[02:32] <zerothis> from the blank screen, ctrl + alt + F1-F6 don't do anything visible. Again, I presume it swtched, but I just can't see it.
[02:32] <holstein> zerothis: you cant, though
[02:33] <holstein> zerothis: you cant assume or presume anything
[02:33] <holstein> if you literally see nothing on the screen, it could be kernel panic'd or in any state
[02:34]  * zerothis stubbornly assumes the sun will rise tomorrow
[02:34] <zerothis> but I understand your point
[02:35] <holstein> yeah.. because, one day, it wont rise.. and that hard drive will fail.. and *all* of that hardware will fail
[02:35] <holstein> thats the only reason i say
[02:35] <zerothis> is there a non-gui testing option. the command-line don't scare me none
[02:35] <holstein> on older hardware, i'll just start testing
[02:36] <holstein> zerothis: you can use whatever you like.. i like the gsmartcontrol tool. i use a live CD called "ultimate boot cd" that has vendor specific tools in it
[02:36] <holstein> zerothis: the big thing to remember is, this is *not* a fix.. so, dont waste time on it
[02:36] <holstein> zerothis: i am merely saying, i like to test with i see those "issues" on hardware like that with linux
[02:38] <zerothis> but its knowledge. if the drive is fine, I then know its something else. If its bad, I know what to fix. Older hardware, hmph, I have a 30 year old Commodore 64 that sat totally submerged in water overnight, was dryed with a hair dryer, and continues to work to this day.They don't makem like they used to
[02:39] <holstein> sure.. but, you have a special case here
[02:40] <holstein> you also have older hardware with no promise of linux support from the creators
[02:40] <Ahmuck> zerothis: this is fixable.  i've had the same problem happent to me before on a machine.
[02:41] <holstein> zerothis: i say, just start at the beginning and try and rule issues out. those graphics adapters can be challenging.. i have had via chips in the past that just dont work with linux..
[02:42] <zerothis> again, Commodore 64, Little Unix, I'm just sayin
[02:42] <holstein> zerothis: that hardware *will* fail too, at some point.. if you want to assume its good, that fine
[02:43] <holstein> in that case, i would try an older version of ubuntu.. 12.04 live CD, for example.. i would see how that runs live, and make a note of the graphics driver in use, and the kernel version.. etc
[02:46] <zerothis> ok then
[02:47] <holstein> i also like using the mini iso's...
[02:47] <holstein> !mini
[02:47] <holstein> they give the quickest way to get a text-only system up and running.. small download size..
[02:48] <zerothis> thanks again
[02:48] <holstein> if i can get 14.04 minimal installed text only, then, i can test the drive, or other hardware from there.. and move on to the graphics card support
[02:48] <holstein> Ahmuck may have just the answer for you.. not sure..
[02:49] <holstein> Ahmuck: would you like to share? you have the same graphics card? ALI/trident?
[02:50] <zerothis> he shared, thanks
[02:58] <zerothis> what CLI utilities precisely would you use?
[03:06] <holstein> simple ones, actually ..that test whatever i need to test
[03:06] <zerothis> names?
[03:07] <holstein> http://www.linuxjournal.com/magazine/monitoring-hard-disks-smart for example
[03:07] <holstein> zerothis: the specific names depend on what im trying to test and for what, and in what.. and what my resources are
[03:08] <holstein> zerothis: this is something would spend about 15 minutes with, or just move on
[03:08]  * zerothis turns to the plant on his desk, "Thou art god"
[03:08] <holstein> this is *not* a fix, for anything, as i said, so, if you are not finding your way with getting helpful results, then, just move on
[04:14] <Ahmuck> # lxpanel <profile> config file. Manually editing is not recommended.
[04:14] <Ahmuck> # Use preference dialog in lxpanel to adjust config when you can.
[04:15] <Ahmuck> is there a reason that lubuntu is recommending that a user not manually edit the lxpanel file?
[04:15] <holstein> potential breakage. but, thats from lxde
[04:16] <holstein> the gui is the prefered tool in that case, it seems. might cause inconsistencies to try and use both.. but, i would just make a backup of the file and try settings if i felt i needed to
[04:19] <holstein> Ahmuck: anything in particular you are trying to facilitate in that file?
[04:20] <holstein> i think at some point, i would just strip down to openbox, if i wanted really granular control over everything with config files..
[06:33] <swift110> Hey
[07:27] <swift110> Co
[07:27] <swift110> Cool
[15:07] <malaphus> anyone know where the documentation is for lightdm-gtk-greeter?
[15:32] <firc4975d08c> hi
[15:35] <firc4975d08c> i would like to install some latex editor on lubuntu, but editors i found are KDE or GNOME how will it influence the performence?
[15:42] <phillw> firc4975d08c: https://help.ubuntu.com/community/LaTeX
[15:45] <testdr> firc4975d08c: if you only want to write letters, you should check   tk-brief
[15:57] <Ahmuck> hrm, well i've managed to break my lubuntu login
[15:57] <Ahmuck> on a machine
[15:58] <Ahmuck> The menu option "Default Applications for LXSession"  (aka lxsession) allows you to turn off all autostart applications.
[15:58] <Ahmuck> I suspect this is why I am no longer able to get past the greeter screen?
[15:59] <Ahmuck> I did however find something that may be causing the double icon and hope to test in the next hour, though if somebody wanted to chime in, i'd enjoy that.
[15:59] <Ahmuck> would appreciate that.
[15:59] <Ahmuck>  /etc/lightdm/lightdm-gtk-greeter-ubuntu-conf
[15:59] <Ahmuck> - indicators=~language;~session;~power
[16:00] <Ahmuck> is the lightdm-gtk-greeter placing an icon in the systray as an indicator as well as what is getting placed there by autostart?
[16:02] <testdr> Ahmuck: you are playing around without a fallback (=working) user-account? You have never setup a second admin-user-account?
[16:05] <Ahmuck> testdr: i'm able to access via tty5
[16:05] <Ahmuck> i don't store data or config files on my local user account.  those all get stored to a sd card
[16:06] <Ahmuck> user config files
[16:06] <Ahmuck> btw, did you know that having a password login is a liablity
[16:06] <Ahmuck> ?
[16:07] <phillw> Ahmuck: if they steal your computer, password protection is the least of your worries :P
[16:11] <Ahmuck> no, really.  password accounts, or user control is not for protection of documents.  document protection (and user configuration) can be performed on removable media with encryption with encryption keys held on seperate removable media requiring both removable media to work
[16:12] <Ahmuck> if user A access doc A on the network and user B the same document it creates a record
[16:12] <Ahmuck> of who access the document
[16:12] <Ahmuck> but if user A has his password stolen and then access doc B which he is not supposed to then user A gets the blame
[16:13] <Ahmuck> however, if there is passwordless login, user A is able to claim plausable denability.
[16:13] <Ahmuck> password logins really are there for blame assignment
[16:14] <Ahmuck> and there really is no such thing as security as such
[16:15] <Ahmuck> if your documents are encrypted on removable media then it does not matter what account is used and you become the responsible party for protecting your own documents.  the responsiblity then rests with the user, not the system that blames the user
[16:17] <phillw> Ahmuck: just create user accounts with encryption.. it is an option.
[16:17] <Ahmuck> not an option.  physical or remote access with a comprimised accounts won't make a bit of difference (and it is happening)
[16:18] <phillw> Ahmuck: and this is a discussion better suited to #lubuntu-offtopic and I suggest you move it there
[16:18] <Ahmuck> anywho, back to the login issue.  so lxsession allows you to turn off all autostart functions.  i assume this means PAM, SSH, etc.
[16:19] <Ahmuck> phillw: sorta.  i'm not able to log in because of password requirement, which i realized today should not be a requirement
[16:19] <phillw> none of those are enabled by default on a desktop system, you are thinking about server security, not protecting someone's home computer / laptop.
[16:19] <Ahmuck> a really open system with each person responsible for their own documents prevents such messes
[16:20] <phillw> Ahmuck: Which is not a lubuntu support issue.
[16:20] <Ahmuck> 1. does lxsession really allow you to turn off all autostart functions?
[16:21] <Ahmuck> 2. is it necessary to require lightdm (this is the login screen function, or part of the screen logout/login function) as part of the os?
[16:22] <Ahmuck> 3. is there a way to turn off login authentication and lightdm
[16:23] <phillw> Ahmuck: As I told you yesterday.. Put your views / questions into a document and email it to me. I will ensure the devs get to read it and you will have a detailed answer. This is not thee area to discuss such things.
[16:25] <Ahmuck> how does having a support channel and putting them in a document help me utilize the support channel?
[16:25] <Ahmuck> i need support for the login
[16:25] <Ahmuck> lightdm, etc.
[16:25] <Ahmuck> is lubuntu not a support channel?
[16:27] <phillw> Ahmuck: it works, you are asking for details of functionality.. that is best done on the mailing list or going and hunting down what documentation there is.
[16:27] <Ahmuck> back to the lightdm conf file.  is it placing an icon in the indicator tray?
[16:28] <phillw> no idea.
[16:28] <Ahmuck> i've been combing through documentation and code on lubuntu site
[16:28] <Ahmuck> that is the best answer i've had yet, it's honest
[16:28] <phillw> again you are asking about the innards.. so email is your best route.
[16:29] <Ahmuck> is there no documentation on lightdm?
[16:29] <phillw> Ahmuck: https://wiki.ubuntu.com/LightDM ?
[16:30] <Ahmuck> yes, found it.
[16:30] <Ahmuck> was looking at ubuntu site
[16:30] <Ahmuck> er, lubuntu site
[16:30] <phillw> I'm sure you can use a search engine ? Coz I found that as answer #1 with http://en.wikipedia.org/wiki/LightDM as #2
[16:30] <phillw> Ahmuck: LightDM is not lubuntu specific
[16:31] <phillw> if an application starts as lx it is specific to lxde, otherwise it is an application that we use...
[16:32] <Ahmuck> k, back to lxsession.  on the other computer i've turned the mousepad off as a startup option but it does not recognize it
[16:34] <phillw> Ahmuck: that could be an ACPI issue, have a search for the model and trackpad via your favourite search engine
[16:34] <firc4975d08c> hi
[16:35] <phillw> wb firc4975d08c
[16:36] <firc4975d08c> i use lubuntu and i would like to install some latex enviroment, but i found KDE and Gnome only. how it will influence the performence?
[16:36] <phillw> firc4975d08c: please read the earlier replies :)
[16:37] <firc4975d08c> sorry, but i reconected. may i anyhow gain acces to them?
[16:38] <phillw> (16:42:53) phillw: firc4975d08c: https://help.ubuntu.com/community/LaTeX
[16:38] <phillw> (16:45:55) testdr: firc4975d08c: if you only want to write letters, you should check   tk-brief
[16:40] <firc4975d08c> thx
[16:40] <firc4975d08c> one more question
[16:41] <firc4975d08c> what is wb? :)
[16:41] <firc4975d08c> welcome bro? :)
[16:41] <phillw> wb = welcome back
[16:42] <firc4975d08c> fair enough
[16:50] <firc4975d08c> but is this a problem to install KDE application on lubuntu, will it work, what impact wil it make on computer performence will it impact be permanent or exist only while application is running?
[16:50] <firc4975d08c> ass well with GNOME apps
[16:52] <phillw> firc4975d08c: when you go to install the kde one, it will tell you how much extra stuff it needs. As a general rule kde is lighter than GNOME libraries.
[16:53] <phillw> you can say 'N' to install the kde one once it says how much disk space., applications it needs and then do the same with the GNOME on.
[16:53] <Ahmuck> @syndaemon -d -t
[16:53] <Ahmuck> https://help.ubuntu.com/community/Lubuntu/Mouse#Disable_touchpad_while_typing
[16:53] <Ahmuck> i need the @ sign?
[16:54] <phillw> Ahmuck: evidently, as that is in the code line
[16:55] <firc4975d08c> ok, but not the disc space is what i worry about, but ram and cpu
[16:56] <Ahmuck> http://pastebin.com/aTYzVXY9
[16:57] <phillw> firc4975d08c: try both, and see which is better
[16:57] <firc4975d08c> will KDE run permanently, will i need to controll it manually, or maybe it gonna run only with my KDE app?
[16:59] <phillw> firc4975d08c: kde is very well behaved, you should not see any nasty things running in the background. Same actually goes for GNOME, just that kde libraries tend to be smaller
[16:59] <firc4975d08c> ok. thx verry much
[16:59] <Ahmuck> firc4975d08c: i use kexi on lubuntu
[17:03] <firc4975d08c> and how is it connected with the topic? :)
[17:04] <firc4975d08c> cause i don't follow
[17:05] <firc4975d08c> is it KDE app?
[17:05] <firc4975d08c> oh right, it is
[17:06] <phillw> firc4975d08c: http://www.kde.org/applications/office/
[17:06] <phillw> I can go dig :D .. We are all the same family and share stuff.
[17:07] <firc4975d08c> so this all KDE stuff are libraries only, and aren't gonna run while not being in use by other program?
[17:09] <phillw> firc4975d08c: they should not, we share the same base
[17:10] <firc4975d08c> :)
[17:12] <firc4975d08c> ok, kile is loading dowh :)
[17:12] <firc4975d08c> *down
[17:14] <phillw> good, sorry for delays, but I'm busy getting a padawan area created and have both a senior dev for moin (wiki system that, e.g., ubuntu uses) and the TL from our artwork team together.
[17:38] <ianorlin> yeah LaTeX pulls in lots of dependencies
[17:39] <ianorlin> but has lots of useful stuff
[17:46] <phillw> firc4975d08c:  ^^ read what ian said
[21:50] <dim78> hello
[22:00] <phillw> !ask | dim78
[22:08] <dim78> hello
[22:08] <dim78> can boot my lubuntu partition
[22:21] <phillw> dim78: can you please tell us what the error message is that you get when you try
[22:22] <phillw> dim78:  "it does not work" will not grab people to help you.
[22:24] <dim78> hello Phillw, I have this pc with win7 and lubuntu partition ... everything was ok and now lit and the pc does not boot lubuntu, the screen goes black
[22:26] <phillw> dim78: are using lubuntu to boot win7  or using win 7 to start lubuntu?
[22:26] <dim78> dual boot
[22:29] <phillw> dim78: I'm not skilled at dual boot... ask on #ubuntu there should be some people who can help. (The boot system is same for all flavours).
[22:30] <dim78> thanks
[22:30] <dim78> ;)


[00:00] <jelmer> hi *!
[00:00] <beuno> OMG, jelmer is back
[00:01] <jelmer> hey beuno :-)
[00:01] <BrianRice> hi. is there a way to run, say, the update command and have it only indicate what it *would* do rather than take action?
[00:01] <jelmer> beuno, Do I have you to blame for the bzr-search upload? If so, thanks !
[00:02] <beuno> jelmer, yeah, I took advantage of debcamp  :)  welcome'
[00:02] <beuno> now, I'm about to release loggerhead 1.6.1, which would be nice to have in debian/ubuntu too  :)
[00:02] <beuno> even PPA meanwhile
[00:03] <beuno> BrianRice, I don't think there's a --dry-run option. Feel free to file a bug requesting it
[00:03] <BrianRice> ok
[00:03] <lifeless> 08:46 < mwhudson> "Port Loggerhead should listen on (default 8080 is the default."
[00:03] <jelmer> beuno, ah, cool
[00:03] <BrianRice> "bzr log" comparison seems to do well enough in the mean-time
[00:04] <jelmer> beuno, will see what I can do to get into debian once I'm rested
[00:04] <lifeless> mwhudson: perhaps
[00:04] <lifeless> "Port Loggerhead should listen on (8080 is the default)."
[00:04] <beuno> jelmer, where were you, btw?  vacation?
[00:04] <mwhudson> lifeless: that was a typo, yes
[00:04] <jelmer> beuno, yep, went cycling in the alpes for ~10 days
[00:05] <lifeless> jelmer: wow back already
[00:05] <pickscrape> Bet you're knackered now :)
[00:06] <beuno> jelmer, cool.  I'm sucking at getting to stuff quickly lately
[00:06] <jelmer> lifeless, yeah, bad weather so came back one day early
[00:06] <jelmer> lifeless, thanks for the bzr-gtk pqm update
[00:09] <pickscrape> beuno: no rush at all
[00:13] <jam> lifeless: Some interesting results when tweaking the knobs on ChunkWriter for the btree index
[00:13] <jam> http://rafb.net/p/owGbxj90.html
[00:13] <jam> This is with the artificial nodes from the test suite.
[00:13] <jam> But still interesting.
[00:13] <jam> I'm planning on putting something together with real data tomorrow.
[00:14] <jam> The only problem with using copy() is that it will change the page sizes if it is/isn't available
[00:14] <jam> which means the test suite will become very brittle.
[00:15] <jam> The "current" algorithm creates 490 pages, the "best" creates 390
[00:15] <jam> So there may be some room to either be a bit faster, or compress a bit better in the same time
[00:16] <jam> Anyway, I'm done for the evening.
[00:19] <lifeless> jam: gnight
[00:19] <lifeless> jam: perhaps we should do the zlib interface ourselves
[01:03] <jelmer> hmm, rc5!?
[01:04] <beuno> jelmer, don't ask
[01:07] <AfC> It's ok. It's called "quality". That's a good thing.
[01:15] <LarstiQ> AfC: what is this "quality" thing you speak of?
[01:23] <AfC> It's what happens when you take the time to polish a release after you've decided to make one in the first place. There is a point of diminishing returns, but I've long felt that being shackled to particular dates and thereby shipping arbitrary bugs does not result in a better user experience.
[01:24] <beuno> thumper, working on the gnome theme, progress so far: lp:~beuno/loggerhead/gnome_theme   (still have to fix quite a few things)
[01:24] <lifeless> beuno: cool
[01:25] <LarstiQ> AfC: a hard shackling to a specific date, no. But I feel it's better to not ship it if it needs too much polish.
[01:25] <beuno> lifeless, you have access to gnome to push this once it's finished, don't you?
[01:26] <lifeless> beuno: maybe:)
[01:26] <beuno> :)
[01:26]  * beuno -> dinner
[01:46] <lifeless> LarstiQ: so if something needs too much polish, what - you give up on the project?
[01:47] <LarstiQ> lifeless: include it in the next release
[01:48] <lifeless> LarstiQ: well, thats what we're doing :)
[01:50] <LarstiQ> lifeless: I was disagreeing with AfC's general statement, I think :)
[02:05] <lifeless> oh suck
[02:05] <lifeless> some plugin is making TestOutsideWT.test_url_log fail hard
[02:06] <jelmer> lifeless, have you updated bzr-svn recently?
[02:06] <lifeless> jelmer: FSVO recent
[02:06] <lifeless> jelmer: remember it segfaults for me
[02:07] <jelmer> lifeless, ahh
[02:07] <jelmer> lifeless, it should no longer segfault
[02:07] <jelmer> lifeless, if it does, please let me know
[02:07] <lifeless> 0.4 still ?
[02:07] <jelmer> it also contained a bug that made test_url_log hang
[02:07] <jelmer> yep
[02:08] <jelmer> I worked on a fix for this with Mark Hammond, which made it into the 0.4.11 rc
[02:08] <lifeless> pullink
[02:11] <lifeless> eek
[02:11] <lifeless> I'm in install-revisions, in fetch :(
[02:12] <lifeless> EFREAKINGSLOW
[02:15] <lifeless> jelmer: editor.c: In function 'py_dir_editor_change_prop':
[02:15] <lifeless> editor.c:358: warning: unused variable 'p_c_value'
[02:16] <jelmer> lifeless, thanks, fixed
[02:16] <lifeless> also,
[02:16] <lifeless> ra.c:1141: warning: 'py_revstart_cb' defined but not used
[02:16] <lifeless> ra.c:1161: warning: 'py_revfinish_cb' defined but not used
[02:18] <lifeless> meh,
[02:18]  * lifeless disables Werror
[02:19] <jelmer> ah, looks like that happens when you build against svn 1.4
[02:19] <jelmer> fixed as well
[02:20] <lifeless> hmm, build_ext -i is broken
[02:20] <lifeless> actually, no, its fine
[02:20] <lifeless> ok, that test isn't hanging now, thanks
[02:20]  * lifeless returns to log hacking
[03:55] <lamont>  'No handlers cound be found for logger "bzr"'
[03:55] <lamont> ^^ wassat?
[03:55] <lamont> 1.6~rc3-1~ bzr and 1.6.0-1~ bzrtools
[04:30] <lifeless> lamont: a race?
[04:30] <lifeless> lamont: from pqm or something?
[04:30] <lifeless> lamont: also, bzr-playground?
[04:31] <mneptok> that'll teach him to unidle.
[05:38] <jml> lifeless: testresources?
[05:38] <lifeless> jml: yes, high on my queue
[05:39] <lifeless> jml: or are you wanting to chat about it right now?
[05:39] <jml> lifeless: no, just thought I'd take the opportunity to pester :)
[05:46] <lifeless> can I review-by-mail?
[05:48] <lifeless> jml: I see why you wanted the review; you went rather critical.
[05:48] <lifeless> unfortunately, some of what you did isn't suitable
[05:48] <jml> lifeless: that's ok. I figured that would be the case.
[05:49] <lifeless> in particular the licence changes are incorrect
[05:50] <jml> lifeless: review by mail is fine by me.
[05:55] <lifeless> we'll see if lp forwards it to you
[06:27] <chmac> beuno: I'm loving bzr upload, it works like a charm. :)
[08:05] <lifeless> later all
[08:38] <sadleder> hi, i've a question regarding launchpad-cscvs, is this the right place to ask?
[08:42] <siretart> beuno: jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14)
[08:42] <siretart> beuno: jelmer: is this something to worry about or shall I continue uploading it?
[08:42] <thumper> sadleder: probably #launchpad is better
[08:44] <sadleder> thumper: thanks
[10:27] <luks> is it intentional that http://bazaar-vcs.org/releases/src/ doesn't have the latest 1.6 RCs?
[10:27] <luks> oh
[10:27]  * luks is blind
[11:28] <awilkins> Since MarkH is producing .exe installers, would you like my builds of the Python-flavoured ones?
[11:32]  * awilkins finds the python ones to be easier to hack/dogfood on
[11:33] <luks> jam: (when you are here, and if you are interested) http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1
[12:09]  * luks wonder why https://launchpad.net/~bzr/+archive has 1.6rc5 for hardy
[12:11] <luks> +s
[12:11] <awilkins> Is everyone dead at their desk?
[12:13] <bob2> yes!
[12:13] <awilkins> Arrgh, 'tis zombie bob2
[12:25] <bazaar> hi. is it possible to change commit metadata (message, commiter etc)?
[12:31] <bob2> no
[12:31] <bob2> unless you count "bzr uncommit"
[12:31] <bob2> or merging them and giving better information in the merge revision
[12:42] <jelmer> siretart, hi
[12:43] <siretart> hey jelmer
[12:44] <siretart> jelmer: I've prepared an upload for bzr1.6rc3 to experimental, I've compiled it locally on hardy, and a bzr selftest tells me this: FAILED (errors=32, known_failure_count=14). is this something to worry about or shall I continue uploading it?
[12:45] <jelmer> what are the errors exactly?
[12:45] <AfC> jam: did you cut bzr-1.6-rc5 yet?
[12:46] <jelmer> AfC, yep, according to the website :-)
[12:48] <siretart> jelmer: I can mail you the full log if you want to know
[12:48] <siretart> jelmer: where should I mail it to?
[12:49] <jelmer> siretart<EMAIL_ADDRESS>[12:49] <jelmer> siretart, It's probably nothing, but let's check just in case
[12:50] <siretart> jelmer: should be in your inbox now
[12:50] <AfC> jelmer: ah. Nice. Someone should change channel topic then.
[12:51] <siretart> AfC: this channel is -t
[12:56] <lifeless> bazaar: please choose a different nickname; you will confuse people with the nickname you have :)
[13:05] <lamont> lifeless: in my case, it was a root owned ~/.bzr.log
[13:05] <lamont> the other person seeing it doesn't have such a simple explanation
[13:06] <jelmer> siretart, thanks
[13:11] <siretart> jelmer: is that expected breakage, local breakage or is there something really wrong?
[13:14] <jelmer> siretart, I haven't received your email yet
[13:15] <jelmer> ah, got it
[13:17] <siretart> the file has been created with this command: env -i bzr --no-plugins selftest -v | tee selftest.log
[13:25] <jelmer> ah, it's all poll errors from pycurl
[13:25] <jelmer> lifeless/jam: ping
[13:30] <AfC> Oh dear. I got the error at https://bugs.launchpad.net/bzr-svn/+bug/229419 / https://bugs.launchpad.net/bzr-svn/+bug/234010 and, upon upgrading to bzr-1.6-rc5 and bzr-svn trunk, trying to bzr pull in a (from Subversion) checkout seg faults
[13:32]  * AfC is not even sure where to turn next
[13:32] <fullermd> Is bzr-svn trunk something runnable?
[13:32] <fullermd> I thought jelmer was doing all his stuff in the 0.4 branch or something...
[13:33] <AfC> Oh?
[13:33]  * AfC tries that...
[13:34]  * fullermd doesn't really know, just vaguely remembers conversations here.
[13:34] <AfC> fullermd: sure. Thanks
[13:34] <fullermd> He must be dead, though.  It's been two minutes since I said 'jelmer' out loud, and he hasn't shown up.
[13:34] <AfC> I'm not entirely sure he is required to come running just because someone says his name.
[13:37] <jelmer> AfC, did you rebuild bzr-svn after updating it?
[13:37] <jelmer> fullermd, coffee brake :-)
[13:37] <jelmer> *break
[13:37] <Peng_> Is it safe to have another web server serve Loggerhead's static files, instead of passing them back to Paste?
[13:38] <fullermd> Oh, good.  I was getting worried about you   ;)
[13:39] <jelmer> (-:
[13:40] <AfC> jelmer: so I just did a fresh branch of 0.4 (ok, branch + pull --overwrite --remember, whatever)
[13:40] <AfC> jelmer: and then ran `make` there.
[13:40] <AfC> jelmer: and it too segfaults
[13:41] <AfC> jelmer: .bzr.log shows it getting as far as "opening SVN RA connection to<EMAIL_ADDRESS>[13:41] <AfC> jelmer: and then that's it
[13:41] <jelmer> AfC, any chance you can run it inside gdb and paste the backtrace?
[13:41] <AfC> Sure, I can try
[13:42] <AfC> gdb bzr pull ?
[13:42]  * AfC doubts
[13:42] <luks> `gdb python` and inside gdb `run /path/to/bzr pull`
[13:42] <AfC> k
[13:45] <AfC> jelmer: http://rafb.net/p/2Gm5ck59.html I hope
[13:45]  * AfC has never tried Python inside gdb before, but has plenty of scars from trying to debug segfaults in Java code reaching to a native library. Pain.
[13:46] <jelmer> AfC, thanks
[13:46] <jelmer> AfC, It's not too bad with Python
[13:46] <jelmer> AfC, there's even gdb macros that allow you to inspect the python stack
[13:46] <AfC> jelmer: single threaded :)
[13:46] <AfC> jelmer: oh yeah? Nice.
[13:46] <AfC> jelmer: [now that Java is finally free, we're starting to see some progress along those lines]
[13:46] <jelmer> AfC, Ah, of course. Multiple threads would make things more complex in java
[13:54] <rocky> hrm, if i bzr merge something but don't commit it, what's the standard way to revert the merge?
[13:54] <fullermd> revert?
[13:55] <rocky> i bzr revert'ed each of the individual file changes but when i run bzr stat it still says i have a pending merge
[13:55] <jelmer> rocky, just revert without any arguments
[13:55] <fullermd> revert <file> doesn't touch the merges, just the full version.
[13:55] <jelmer> rocky, (which will revert all changes in the working tree)
[13:55] <rocky> ah thanks ;)
[13:55] <jelmer> rocky, or revert --forget-merges
[13:55] <fullermd> (there's an arg to touch ONLY the pending merges too, but if you're blowing away the merge, you don't care about that)
[13:56] <rocky> jelmer: btw... i've troubleshooted the speed issue with bzr-svn 0.4.10 a bit again... and i'm seeing that everytime i commit, it basically checks properties on every folder in the remote svn repo (100's of svn requests)
[13:56] <jelmer> siretart, seems fine to me to upload
[13:56] <jelmer> siretart, there's an issue with pycurl, but I think that's known
[13:56] <jelmer> rocky, even with 0.4.11~rc1?
[13:57] <rocky> jelmer: 0.4.11-rc1 only works with bzr 1.6rcX right?
[13:57] <jelmer> rocky, yep
[13:57] <rocky> jelmer: i tried playing with that in a sandbox the other day and got tracebacks all the time
[13:58] <rocky> jelmer: does that mean you won't be trying to fix this in the 0.4.10 branch?
[13:58] <jelmer> rocky, what backtraces exactly?
[13:58] <jelmer> rocky, yes, 0.4.10 won't see any further development
[13:58] <rocky> jelmer: i'll have to try again (i didn't at the time because you weren't around) to see the tracebacks
[13:59] <AfC> jelmer: (am I in error to be working from your 0.4 branch? Should I grab the 0.4.11-rc1 tarball instead?)
[14:00] <AfC> (or trying to bludgeon Subversion, or...?)
[14:00] <fullermd> Wouldn't you be doing that anyway, just on GP?   :p
[14:01] <AfC> fullermd: I was thinking more a rapier missile battery on fully-automatic, but yes
[14:01] <jelmer> AfC, no, the 0.4 branch should work just fine (atm it's the same code as 0.4.11~rc1)
[14:01] <jelmer> AfC, I'm not sure what's causing your backtrace, still looking into it
[14:01] <AfC> jelmer: (that's what I figured)
[14:02] <rocky> jelmer: what version of svn does bzr-svn 0.4.11 require?
[14:02] <AfC> jelmer: Most kind. I hope it's not something stupid I'm doing (or with my environment).
[14:02] <jelmer> rocky, 1.4
[14:02] <rocky> jelmer: will it work with svn 1.5.x ?
[14:03] <jelmer> AfC, even then it shouldn't be segfaulting
[14:03] <jelmer> rocky, yes
[14:03] <rocky> jelmer: atm i'm testing with http://bazaar.launchpad.net/%7Ejelmer/bzr-svn/0.4/  ... should i keep testing with that or switch to your tarball or?
[14:04] <jelmer> rocky, that seems fine, though you may want to use the original location (http://people.samba.org/bzr/jelmer/bzr-svn/0.4 instead since the lp mirror may be out of date)
[14:04] <AfC> (I would automatically blame Subversion, except that I was able to do an `svn checkout` of a different project whereas that URL segfaulted for bzr-svn trying to do a checkout)
[14:04] <rocky> jelmer: gotcha
[14:22] <rocky> jelmer: here's a traceback just trying to check out a svn branch...  http://cluebin.appspot.com/pasted/601
[14:23] <jelmer> rocky, was this in a clean sandbox?
[14:24] <rocky> jelmer: that toplevel "repo" dir was a fresh repo i just created with "bzr init --rich-root-pack repo" if that's what you mean
[14:25] <rocky> jelmer: but... the remote svn repo it's connecting to has lots of bzr props set from other versions of bzr-svn
[14:29] <rocky> jelmer: and, the remote svn repo i'm connecting to is publically available so you can play with it if you'd like
[14:36] <jelmer> rocky, thanks, will give it a try
[14:53] <ktenney> for a while my prompt (Ubuntu) included the version of the current tree, now it doesn't
[14:53] <ktenney> where is that set?
[14:56] <james_w> ktenney: I think there may be something in /usr/share/doc/bzr/examples , but I'm not sure
[14:59] <jelmer> beuno, ping
[15:00] <beuno> jelmer, pong
[15:00] <jelmer> beuno, any chance you can set a tag for the loggerhead release?
[15:01] <beuno> jelmer, I've never used tags. Do I have to change the repo format?
[15:01] <jelmer> beuno, if the branch is in a packs format, you should already be able to use tags
[15:02] <jelmer> beuno, e.g. "bzr tag -r213 loggerhead-1.6"
[15:02] <beuno> jelmer, sure then. Tag && push?  IIRC, they don't propagate automatically?
[15:02] <beuno> although I have a checkout, that may do it
[15:03] <jelmer> beuno, yep, a checkout should do it
[15:03] <jelmer> beuno, they should propagate automatically
[15:03] <beuno> beuno@beuno-laptop:~/bzr_devel/loggerhead/trunk$ bzr tag -r213 loggerhead-1.6
[15:03] <beuno> Created tag loggerhead-1.6.
[15:04] <beuno> AKA, done  :)
[15:04] <beuno> we should have 1.6.1 out tomorrow, the code is up for review
[15:04] <LarstiQ> don't you need to commit it though?
[15:05] <jelmer> beuno, I see it here, thanks!
[15:05] <ktenney> james_w .. no examples, I'll poke around. Odd how it appeared and disappeared ...
[15:05] <beuno> LarstiQ, it seems not. I never quite got my head around how tags propagate
[15:06] <jelmer> rocky, thanks, I can reproduce that
[15:07] <rocky> jelmer: excellent :)
[15:07] <rocky> jelmer: if you can get this issue fixed i'll try again and if everything's ok i'll start using bzr-svn 0.4.11 for all my stuff ;)
[15:08] <rocky> since i'm using a bzr branch of your bzr-svn 0.4 i should be able to test quickly
[15:12] <jelmer> rocky, cool
[15:12] <rocky> jelmer: if it wasn't for the fact that i love bzr so much i would have given up by now due to the speed issues with 0.4.10 :(
[15:14] <jelmer> siretart, while you're at it, any chance you can sponsor an upload of loggerhead to debian and ubuntu?
[15:14] <jelmer> rocky, 0.4.11 should really be a lot better in that regard
[15:14] <rocky> excellent :)
[15:20] <awilkins> Does anyone want my rc5 Python/Win32 installer builds?
[15:27] <jelmer> awilkins, somebody asked me about them
[15:27] <jelmer> awilkins, perhaps just add them to the releases wiki page?
[15:28] <awilkins> jelmer: As attachments?
[15:28] <jelmer> awilkins, Just pointing at the URLs if you have uploaded them somewhere
[15:29] <jelmer> awilkins, alternatively, maybe you can upload them to the bzr launchpad project?
[15:29] <jelmer> awilkins, It may be useful to talk with John or Mark about that
[15:30] <awilkins> jelmer: The "exe" version is convenient but I prefer the Python version which is more hackable
[15:31] <awilkins> jelmer: I have no inkling of how to upload a file to the launchpad project (I feel certain that I have no rights to do so)
[15:31] <jelmer> awilkins, I think it makes sense to have both available for users to download
[15:31] <jelmer> awilkins, John, Mark or Martin should be able to help there
[15:32] <awilkins> markh: Ping? jam: ping?
[15:32] <awilkins> jam: Ping?
[15:33] <jam> jelmer: pong
[15:33] <jam> awilkins: pong
[15:34] <jelmer> jam, siretart is seeing select/poll errors in the testsuite from pycurl
[15:34] <jelmer> jam, is that a known issue?
[15:34] <awilkins> jam: Hello, I have a build of the python-installer packages for windows if you want them
[15:34] <jam> jelmer: there is a known issue with newer versions of pycurl giving select/poll errors, yes
[15:34] <jam> I don't know that anyone has really dug into it
[15:34] <jelmer> jam, ah, ok
[15:34] <jelmer> jam, So this occurs with older versions of bzr as well?
[15:34] <jam> I thought vila poked at it a bit, but has been gone the last 3 weeks, and doesn't really start up again for about 24hrs
[15:35] <jam> jelmer: it has to do with the new pycurl, not so much bzr
[15:35] <jam> As I understand
[15:35] <jam> so <hardy works
[15:35] <jelmer> jam: Ah, cool - thanks
[15:35] <jelmer> siretart, ^^
[15:36] <jelmer> jam, well, not *cool* but good it's not a new issue introduced by bzr :-)
[15:37] <siretart> jelmer: sec
[15:38] <siretart> jelmer: okay, I'll upload then rc5 in a minute then
[15:38] <siretart> jelmer: where to find the loggerhead packaging branch?
[15:39] <jelmer> siretart, http://bzr.debian.org/pkg-bazaar/loggerhead/unstable
[15:39] <jam> awilkins: thanks, I would guess it is easier to just have me reboot and build them, or have markh do it when he does the full installer. Mostly because someone needs to upload them, and sending 5MB email attachments isn't great :)
[15:39] <timnik> when doing a "bzr pull" is it possible to tell bzr to not overwrite a particular file? (ever?)
[15:40] <timnik> i.e. one of the files under version control
[15:41] <timnik> I'm guessing it's not, but if I'm wrong would be cool :-)
[15:44] <Peng_> beuno: ping
[15:44] <beuno> Peng_, pong
[15:45] <Peng_> beuno: Just to make sure, is it safe to have Loggerhead's /static/ directory served by another web server instead of LH itself?
[15:45] <jam> timnik: generally not
[15:46] <beuno> Peng_, sure, I don't see why that would blow up at all
[15:46] <awilkins> jam: Fair enough
[15:46] <Peng_> Yeah, it seems to be working fine.
[15:46] <beuno> it accesses everything through the URL, so you should be fine
[15:46] <Peng_> Thanks. :)
[15:47] <awilkins> timnik: A pull will never overwrite a file. It may move it, but not destroy it
[15:47] <beuno> Peng_, anything for our star tester  :)
[15:47] <timnik> jam, thanks
[15:47] <Peng_> :)
[15:47] <timnik> awilkins, would it not attempt to update it, if it's contents had changed?
[15:47] <awilkins> timnik: Unless that's part of the revisions pulled of course....
[15:48] <timnik> awilkins, well, yes
[15:48] <timnik> awilkins, not to worry. It's more a matter of me being lazy than any real problem.
[15:48] <timnik> thanks!
[15:52] <awilkins> timnik: You could write a post-pull hook that restored your file I suppose
[15:53] <timnik> awilkins, Thanks for the hints. What I should really do is fix my program to use a custom settings file not under version control. :-D
[15:54] <timnik> awilkins, admittedly I was looking for the lazy way out
[15:54] <awilkins> timnik: I like a versioned template that you copy, but it's on the ignore list in it's "active" position
[15:55] <timnik> awilkins, hmm, that's an idea
[15:55] <luks> the problem with this is that you have to manually copy any change to the real config
[15:55]  * timnik runs to try it
[15:55] <luks> I'd really like to see a proper solution to that problem
[15:55] <luks> but I can't think of anything
[15:55] <awilkins> Primary file is versioned but secondary ignored file overrides it?
[15:55] <timnik> luks, it should really ever be a problem. If it's needed, the developer is doing something wrong, imho.
[15:56] <timnik> In this case it's me, and I'm too lazy to fix it.
[15:56] <luks> timnik: well, software evolves and you need to add some configuration options
[15:56] <timnik> *never
[15:56] <timnik> luks, well, have a default file, and use it, unless a custom file exists. The settings in the custom file override that of the default.
[15:57] <timnik> default is under version control, custom is not, and is only ever used if it exists.
[15:57] <luks> hmm, yeah, that works for some cases
[15:57] <luks> but it's still not as flexible as I'd like
[15:57] <timnik> heh, now you sound like me :-P
[15:58] <timnik> is in possible to undo a "bzr ignore" other than edit the ignore file?
[15:58] <luks> I don't think so
[15:58] <timnik> oh, ok. Almost had it.  Unfortunately Thunderbird doesn't deal with it particularly well :(
[16:12] <Peng_> The only issue I ever have is having to log in frequently.
[16:12] <Peng_> Is that what you meant?
[16:16] <awilkins> Peng_: Yes, that's what I mean
[16:16] <Peng_> That is a pain, but I've gotten used to it. :\
[16:17] <Peng_> That shows how much it happens.
[16:17] <beuno> awilkins, FWIW, I'm having problems with gmail through the web interface
[16:17] <beuno> it's doing odd things
[16:18] <Leonidas> What does hgext.convert.common.getchanges mean by "where id is the source revision id of the file."
[16:19] <siretart> jelmer: oh, loggerhead is a completely NEW package, isn't it?
[16:19] <Leonidas> I thought it was the revision id where the file was last modified.
[16:19] <jelmer> siretart, yes
[16:19] <Leonidas> oops, sorry, wrong channel ;)
[16:19] <Leonidas> (although the question is bzr-related, too)
[16:19] <awilkins>  Leonidas Filthy mercurial user! Begone!
[16:20] <siretart> jelmer: oh, that meas I have to do a more thourough license check and such, I won't get to it today, will try tomorrow. If I fail to manage it until saturday, please ping me again
[16:20] <jelmer> siretart,
[16:20] <siretart> jelmer: btw, did you run 'licensecheck -r .' on the source?
[16:20] <Leonidas> awilkins: hey, when i implement the bzr_sink, you'll be able to convert hg repositories to bzr ;)
[16:20] <jelmer> siretart, thanks!
[16:20] <jelmer> siretart, no, wasn't aware of that tool yet
[16:20] <jelmer> siretart, I will, now :-)
[16:21] <siretart> jelmer: it is a rather simple tool using regex to determine the license of each file. of course not bulletproof, but a great asset for ftpmasters ;)
[16:21] <siretart> it is in the 'devscripts' package
[16:22] <jelmer> siretart, yep, found it
[16:22] <jelmer> siretart, I did a recursive grep for Copyright, that seemed to've covered everything
[16:23] <jelmer> siretart, I'll keep this in mind for next time though, very useful
[16:24] <jam> Leonidas: my understanding was that with hg fast-export | bzr fast-import you already *can*
[16:24] <jam> Or with the bzr-hg plugin, though I don't know if it has received any polish in a while.
[16:24] <jam> Leonidas: I don't really understand that sentence, in the context of hg or bzr
[16:25] <jam> "source revision id of the file" sounds like the revision id that initially added the file?
[16:25] <Laney> Is this bug known and/or fixed? http://paste.ubuntu.com/39425/
[16:26] <Leonidas> jam: Yeah, but as far as I have seen it should be the "current" revision.
[16:27] <Leonidas> jam: I haven't tried fast-(im/ex)port, need to give it a try. I am currently hacking up hg convert so there is support for continous integration of new changesets into repositories.
[16:27] <jam> Laney: sounds like you have the bzr-dbus plugin installed
[16:27] <jam> I don't know why it would need X11
[16:27] <jam> you could do "bzr pull  --no-plugins" and have it work
[16:27] <jelmer> siretart, any chance you can commit your changes for rc5 in the bzr branch on alioth?
[16:27] <Laney> I have no idea what that is jam
[16:28] <Laney> I'll file the bug
[16:28] <jelmer> Laney, that's a known issue in bzr-dbus
[16:28] <Laney> Oh!
[16:28] <jam> Laney: I don't know who did your setup then :) But you seem to have the bzr-dbus package installed. If you don't use it, you could "apt-get remove" it
[16:28] <Laney> jam: Maybe it was pulled in as a dep of something?
[16:29] <Laney> "Automatically installed: yes"
[16:29] <Laney> Well if it's known then I will wait
[16:29] <jelmer> Laney, https://bugs.edge.launchpad.net/bzr-dbus/+bug/107169
[16:30] <jelmer> bzr-gtk suggests or recommends bzr-dbus these days, I think apt may automatically install it when you install bzr-gtk by default
[16:31] <Laney> Probably. But I don't know why bzr-gtk would be involved at all - I'm invoking this over SSH
[16:32] <Leonidas> To read a file from a repo I just need to lock_write it, right? Because lock_read 8which is unfortunately undocumented) would lock it also for reading, as far as I can guess. Am I right?
[16:32] <jelmer> Laney, If you install bzr-gtk, apt may also install bzr-dbus for you
[16:33] <jelmer> Laney, bzr-gtk isn't involved here, but bzr-dbus probably came along with it if you installed it
[16:33] <siretart> jelmer: err, I already did?
[16:33] <Laney> jelmer: Right, I get that. But shouldn't bzr-dbus be disabled if calling over SSH too, or?
[16:33] <siretart> >> bzr missing sftp://bzr.debian.org/bzr/pkg-bazaar/bzr/unstable/                                                          :0.0
[16:33] <siretart> Branches are up to date.
[16:34] <Laney> jelmer: Anyway, removing bzr-dbus has fixed it. Many thanks
[16:34] <jelmer> siretart, sorry, my bad
[16:34] <jelmer> siretart, my mail is just very slow today
[16:34] <jelmer> pulling manually does indeed work
[16:36] <siretart> jelmer: I work with checkouts, my local branch is bound to alioth
[16:38] <jelmer> siretart, I was checking for a commit email from alioth, but for some reason are not seeing any
[16:39] <siretart> ok, heading home now, cu later!
[16:40] <jelmer> see you!
[17:32] <jam> beuno: did you see luks: http://bazaar.launchpad.net/~luks/bzr/packaging-tools/annotate/3?file_id=ppa.txt-20080821102811-jhoajulm56uo6vgm-1
[17:33] <jam> vila: I submitted my patch (with test) for bug #259855 so I closed that bug, but opened a new one about FTP transport and assigned it to you. It is priority low, so you are welcome to ignore it, unassign it
[17:34] <beuno> jam, oh, open source rocks!  :)
[17:34] <jam> beuno: I haven't tried it
[17:34]  * beuno branches
[17:34] <jam> but it looks like he set up a few packaging branches
[17:34] <jam> and has the whole thing fairly scripted
[17:34] <jam> I noticed he left out "intrepid"
[17:35] <jam> and he hosted the packaging branches as "bzr" project branches, which isn't quite correct.
[17:35] <jam> but in general, it could make things a lot easier.
[17:35] <luks> jam: they already were under bzr
[17:35] <jam> I would probably create a "bzr-packaging" project, and migrate things over to ~bzr/bzr-packaging etc.
[17:35] <jam> luks: ah, well, that doesn't make it *right* :)
[17:35] <jam> Probably martin did that
[17:36] <luks> I think it's common on launchpad to have debian/ubuntu packages under the product
[17:36] <beuno> luks, very cool. I'll poke at it in a bit
[17:36] <luks> beuno: the main advantage is that it uses bzr-builddeb
[17:36] <luks> so you don't have to mess with tarballs
[17:37] <luks> the scripting is just extra bonus (yes, I was bored :))
[17:37] <beuno> luks, so you worked around the .c/pyrex problem?
[17:37] <luks> there is no .c/pyrex problem
[17:37]  * LarstiQ waves a spoon about.
[17:38]  * pickscrape watches the spoon bend
[17:39]  * timnik thinks there is no spoon
[17:39] <beuno> luks, didn't jam mention something yesterday?
[17:39] <luks> yes, and he was wrong
[17:39] <luks> sorry :)
[17:39] <beuno> that's great news!
[17:39] <jam> luks: so how do you get the .c files into the output?
[17:39] <jam> if you aren't using tarballs?
[17:40] <luks> jam: *you* put them there
[17:40] <luks> it does use tarballs
[17:40] <luks> but bzr-builddeb takes care of it, not the packager
[17:40] <jam> luks: ok, you just said: (11:36:52 AM) luks: so you don't have to mess with tarballs
[17:40] <jam> Just a bit confused
[17:40] <jam> but as long as it works :)
[17:40] <luks> sorry
[17:41] <beuno> jam, can you release a rc6, so I can test this?
[17:41]  * beuno ducks
[17:42] <jam> beuno: You'll get a 1.6-final in a few days
[17:42] <jam> is that sufficient :)?
[17:42] <jam> You could do everything but upload
[17:42] <beuno> sure, let's alpha-test with 1.6 final  :p
[17:42] <beuno> I'm kidding, yes
[17:42] <beuno> I can upload to my own PPA n' stuff
[17:42] <fullermd> 1.6-final is a RC for 1.7   :p
[17:42] <luks> heh
[17:43]  * beuno slowly moves away from jam
[17:44] <jam> beuno: isn't that what 1.6.1 is for? :)
[17:44] <jam> actually 1.6~bazaar2
[17:45] <jam> since the tarball doesn't change
[17:45] <jam> just the packaging
[17:45] <teratorn> beuno: back away, slow. don't take your eyes off of it
[17:45] <jam> or maybe 1.6~bazaar1~hardy2 ?
[17:45] <beuno> yeah, as of today, I can upload all bzr packages with "control + r" and changing 4 or 5 characters
[17:45] <jam> I don't strictly understand all the numbering ideas
[17:46] <fullermd> Yeah.  Like "1.6i+5".  It gets so complex.
[18:16] <Odd_Bloke> I checked out part of a Subversion repo using bzr-svn.  I did some local commits and then tried to do a non-local commit (which I was expecting to sync up all the commits).  I was told that the local branch was out of date with the SVN branch.  Nothing has changed in that part of the repo (though I don't know about the repo as a whole).
[18:16] <jelmer> Odd_Bloke, you need to "bzr up" first
[18:17] <jelmer> Odd_Bloke, and you may have to push the changes to svn first
[18:17] <Odd_Bloke> I'm now trying to push my changes into there and bzr-svn seems to be browsing the ~245 branches (as per the branching scheme) on the server, without any actual pushing seeming to happen.
[18:18] <vila> fullermd: ROFL
[18:18] <jelmer> Odd_Bloke, it is checking whether the revisions are already there somewhere in one of the other branches
[18:18] <Odd_Bloke> OK, I'm now pulling from my branch into a pristine checkout of the SVN.  Which seems to be working...
[18:18] <vila> jam: ok, I'll look into it in 12.5 hours 8-)
[18:19]  * fullermd clicks off a stopwatch.
[18:20]  * vila tweaks fullermd's watch to adjust it: 12h40m
[18:40] <kek2> hi
[18:45] <kek2> hi everybody. i'am using bzr first time. I Committed revision 1. How can i push the commit to a server over ssh?
[18:47] <Odd_Bloke> kek2: 'bzr push sftp://<user>@<server>/<path>'.
[18:47] <jelmer> Odd_Bloke, "bzr push <svn-url>" would've also worked
[18:47] <kek2> ok, i will test
[18:47] <Odd_Bloke> jelmer: Yeah, I realised this just now (when it did work :D).
[18:47] <Odd_Bloke> But the pulling option is actually quicker, because it doesn't feel the need to scan for the revision in every branch.
[18:47] <kek2> kekz@firefly:~$ bzr push sftp://kekz@kekzkbook/home/kekz/test
[18:47] <kek2> bzr: ERROR: Not a branch: "/home/kekz/".
[18:48] <kek2> whats the mistake?
[18:48] <Odd_Bloke> kek2: Well, '/home/kekz/' is not a branch.
[18:48] <kek2> the same error when i use bzr push bzr+ssh: ... usw.
[18:48] <Odd_Bloke> kek2: So you can't use bzr to push it anywhere.
[18:48] <Odd_Bloke> Which directory were you in when you committed revision 1?
[18:49] <kek2> oh ... so i must initalize an empty commit on server?
[18:49] <Odd_Bloke> kek2: No, locally.
[18:49] <Odd_Bloke> kek2: What directory were you in when you committed revision 1?
[18:50] <kek2> /media/daten/devcenter
[18:50] <kek2> no .. the last time i try from /home/kekz
[18:50] <kek2> aah :)
[18:51] <kek2> ssh: kekzkbook: Name or service not known
[18:51] <kek2> bzr: ERROR: Unable to connect to SSH host kekzkbook; EOF during negotiation
[18:51] <kek2> ok, i think i have an dns problem
[18:51] <kek2> wrong hostname
[18:51] <kek2> ok, it works
[18:51] <kek2> Odd_Bloke: Thank you
[18:52] <kek2> its pushing =)
[18:53] <Odd_Bloke> kek2: No worries, glad I could help. :)
[18:57] <kek2> i have a pc and a notebook and a server (in vmware on the notebook). Sometimes i work on my pc, sometimes i work on my notebook. What is the best practice .... to push and pull from server      OR    to push and pull between pc and notebook directly?
[18:58] <Odd_Bloke> Argh, I'm having to commit for the third time because I forget that bzr-svn will prompt for passwords multiple times.
[19:04] <uws> Odd_Bloke: ssh keys to the rescue?
[19:10] <jelmer> Odd_Bloke, bzr-svn doesn't prompt multiple times, bzr does :-)
[19:17] <jelmer> kek2, either will work fine I think
[19:17] <jelmer> hmm, bb down again?
[19:17] <jelmer> james_w, hi
[19:19] <beuno> jelmer, it's been down for a while, and abently is on vacation
[19:25] <jelmer> beuno: ah, ok
[19:28] <Odd_Bloke> jelmer: Hmm, I've only noticed it when using bzr-svn.
[19:28] <jelmer> Odd_Bloke, the checkout logic is all inside of bzr
[19:29] <jelmer> Odd_Bloke, have you used local commits with checkouts and native bzr branches?
[19:29] <Odd_Bloke> No, I suppose not.
[19:31] <kek2> bye
[19:31] <kek2> and thanks for help
[19:33] <vila> jam: I agree 60% with your analysis and 100% with your patch for #259855, I'll address the remaining 40% while fixing #260131, so BB:approve
[19:33] <mwhudson> jelmer: i was trying to help a guy the other week who (it turned out) was doing 'bzr ci' in a svn working tree when the svn server was inaccessible
[19:33] <mwhudson> jelmer: the error was not very clear :)
[19:34] <vila> ubottu: grrr, bug #259855
[19:34] <jelmer> mwhudson, did you file a bug ? :-)
[19:34] <jelmer> mwhudson, or, do you perhaps remember what the error message was?
[19:34] <jam> vila: shame on you for harassing the ubottu :)
[19:35] <vila> ubottu: grrr, bug #260131, yeah, mister bot, but come on #226131 is *obvious* !!!
[19:35] <mwhudson> jelmer: oh, it was https://bugs.edge.launchpad.net/bzr-svn/+bug/211683, you commented already
[19:35] <vila> jam:  :-P 23.5 hours to go :)
[19:35] <mwhudson> jelmer: that's what the comment from chris perkins was about
[19:36] <fullermd> What?  It was 12.5 an hour and a quarter ago!
[20:30] <beuno> mwhudson, hi. Want to see something weird?  bug #260190
[20:31] <mwhudson> beuno: !?
[20:33] <beuno> mwhudson, I have *no* idea how different tabs can be show on different places
[20:37] <jam> vila: wouldn't that mean you start late in the evening on Friday? I should get your TZ sometime so I can keep track of your offset.
[20:37] <jam> Though I guess knowing your working hours is just as important :)
[20:38] <beuno> vila should be UTC +2
[20:38] <jam> beuno: so basically your template is der-broken?
[20:38] <jam> That is kind of odd
[20:38] <jam> But I certainly see the same thing
[20:39] <jam> the help tab disappears when you are under changes
[20:39] <beuno> jam, well, the tabs are generated from one place only, so this kinda throws me off  :)
[20:45] <james_w> hey jelmer
[20:45] <jelmer> james_w, Have you had any time to look into my debian directory service patch for bzr-builddeb yet?
[20:46] <james_w> jelmer: I put it on hold, sorry.
[20:46] <jelmer> james_w, No hurry, just making sure it's not forgotten
[20:46] <james_w> ah, ok.
[20:46] <jelmer> james_w, How's the bzrification of the archive going?
[20:46] <james_w> I may try and fold it in this week, but I'm wondering how it interacts with my other work
[20:47] <james_w> I haven't started another conversion run since the sprint as I have been focusing on other things, but it's hopefully on track
[20:52] <jelmer> james_w, ah, cool
[20:53] <jelmer> james_w, you've probably already seen it, but just in case: https://wiki.ubuntu.com/BzrMaintainedPackages
[20:53] <james_w> ah, great, thanks
[20:53] <james_w> that's probably going to be useful
[21:16]  * mwhudson hmms
[21:16] <mwhudson> lifeless: awake yet?
[21:27] <rocky> anyone here using TracBzr ?
[21:28] <rocky> curious what it's "status" is
[21:29] <pickscrape> I am
[21:29] <pickscrape> Though I'm not sure of its status
[21:29] <rocky> pickscrape: is there a released version to use or is using a snapshot from bzr the best bet or?
[21:29] <pickscrape> It seems to have some problems with bzr 1.6.
[21:29] <pickscrape> We're using a snapshot from bzr
[21:29] <rocky> this branch seems to be working on bzr 1.6 compat
[21:29] <rocky> https://code.launchpad.net/~scott-idealist/trac-bzr/bzr-1.6
[21:30] <pickscrape> ooh, I hadn't seen that...
[21:30] <pickscrape> Thanks for pointing me at that :)
[21:30] <rocky> np :)
[21:30] <rocky> i'm not so interested in 1.6 support yet ... what i'm more curious about is just how fast it is compared to trac's native svn support and being sure it won't blow up my server ;)
[21:32] <pickscrape> Our experience is that it seems to be slower, though that could be because we have it pointing at a directory containing multiple shared repositories that contain multiple branches
[21:32] <rocky> hm
[21:33] <rocky> does it have any kind of support for cross-referencing revision links in wiki formatting? (ie with svn support, if in a ticket you reference r23 it automatically links to svn/browser r23 changeset url)
[21:34] <pickscrape> Yes
[21:34] <pickscrape> It looks like [branch_name,revno]
[21:34] <pickscrape> e.g. [trunk,34]
[21:35] <rocky> oh cool
[21:35] <rocky> i'ven ever hosted an actual bzr repo before so that's something i'll have to play with anyhow
[21:35] <pickscrape> Though there is an annoyance in that if the branch name contains a slash, it gets escaped and looks awful. Not sure if that's a problem with trac core or trac-bzr though.
[21:41] <brl4n> just installed and started playing with bzr an hour ago. Trying to do a push via sftp but I'm getting an "Connection abandoned.
[21:41] <brl4n> bzr: ERROR: Unable to connect to SSH host localhost; EOF during negotiation
[21:42] <brl4n> not exactly sure if it is an ssh problem or bzr problem
[21:42] <mwhudson> brl4n: sounds like an sftp problem
[21:43] <brl4n> well I am able to connect through a sftp client.
[21:43] <mwhudson> hmm
[21:43] <mwhudson> what platform?
[21:44] <brl4n> winXP using openshh
[21:44] <brl4n> bzr returns the rsa2 key finger print
[21:45] <brl4n> "Connection abandoned" then the Error: Unable ... etc
[21:45] <brl4n> i've googled around but wasn't able to come up with anything
[21:46] <mwhudson> oh windows
[21:46] <mwhudson> i know things can be a bit hard to set up there, don't know the details though :/
[21:47] <mwhudson> markh probably does, but i guess he's asleep
[21:47] <brl4n> yah that is what I'm thinking
[21:47] <brl4n> okie
[21:47] <brl4n> i'll idle around then.
[21:47] <brl4n> thanks
[21:47] <mwhudson> jam, vila: maybe you can advise brl4n ^ ?
[22:12] <lifeless> jam: ping
[22:12] <jam> lifeless: pong
[22:12] <lifeless> that log patch was against bzr.dev
[22:12] <lifeless> no missing revisions
[22:13] <lifeless> if you'll note it was started on rev 3642 of trunk -   (jam) Merge in 1.6rc5 and revert disabling default stack on policy
[22:14] <lifeless> also, good morning
[22:14] <jam> lifeless: well, the patch I see includes the NEWS entry for 1.6rc4 and 1.6rc5
[22:14] <jam> Are you sure it was against bzr.dev proper?
[22:14] <jam> (are you sure your bzr.dev copy is up-to-date)
[22:15] <lifeless> oh wrong parent,
[22:15] <lifeless> its got integration as my parent for some retarded reason
[22:15] <jam> aha
[22:15] <jam> good morning to you, too :)
[22:15] <lifeless> resent
[22:17] <rockstar> Is there a way you can put a plugin in the plugins directory, and blacklist it so it doesn't load in bzr?
[22:17] <lifeless> yes, don't put it in there
[22:17] <lifeless> rockstar: why do you want to do that?
[22:24] <rockstar> lifeless, because we need the functionality of the plugin, but don't want bzr actually trying to use it
[22:24] <lifeless> rockstar: 'we' ?
[22:24] <rockstar> All the imports are 'from bzrlib.plugins.foo'
[22:24] <rockstar> lifeless, lp-code
[22:24] <lifeless> rockstar: a little more detail and I can probably be really clear and helpful :)
[22:25] <rockstar> lifeless, sorry
[22:25] <lifeless> if you have python code you want to use froma python program that also uses bzrlib
[22:25] <lifeless> you can just import it
[22:25]  * rockstar winds up
[22:25] <lifeless> if its not a bzrlib plugin, don't put it in plugins
[22:25] <lifeless> if it is a plugin, put it in plugins
[22:26] <rockstar> So, I'm trying to implement a new layer into cscvs which will use the work jelmer did for svn.
[22:26] <rockstar> So, we need the bzr-svn code, but we don't actually want it used by bzr
[22:26] <lifeless> well
[22:26] <lifeless> you'll need to restructure bzr-svn then
[22:26] <lifeless> or
[22:27] <lifeless> only have it in the bzrlib plugins path when cscvs is running
[22:27] <lifeless> BZR_PLUGINS_PATH
[22:27] <rockstar> Yea, that's what I had figured, and that's what mwhudson and I decided would be a good idea
[22:28] <lifeless> though I'd just install it normally and use it
[22:28] <lifeless> (where normal is probably in the lp rollout system)
[22:28] <lifeless> unless you have a specific reason /not/ to have it available
[22:29] <lifeless> bzr.dev is looking at shipping bzr-svn by default
[22:30] <mwhudson> lifeless: it seems like it would be a bad idea to have bzr-svn active when running the supermirror-pull.py mirror script
[22:30] <mwhudson> unless we want to start supporting imports via bzr-svn essentially by accident
[22:30] <lifeless> mwhudson: doesn't the pull check the branch type already?
[22:31] <lifeless> mwhudson: seems like the 'manually create an identical format in the target' step will fail epicly with bzr-svn branches and repositories :)
[22:31] <mwhudson> lifeless: that's true i guess, but a bit of a detail
[22:31] <mwhudson> lifeless: also, we use clone() for the initial branch creation now
[22:32] <mwhudson> lifeless: which relates to something else really i want to talk to you about...
[22:33] <mwhudson> ('manually create an identical format in the target' is also broken for bzr+http of course)
[22:34] <lifeless> mwhudson: indeed
[22:34] <lifeless> so, what I'd do is to integrate and test bzr-svn carefully
[22:35] <lifeless> rather than doing something complex and hoping noone says 'this is too complex' and 'fixes' it later
[22:35] <lifeless> without thinking of the things you have thought of
[22:35] <mwhudson> though oh god, we'll probably completely re-mirror a bzr+http branch each time the puller runs now :(
[22:36]  * mwhudson biles a fug
[22:38] <lifeless> better than buggering a file
[22:53] <mwhudson> bug 45277
[23:22] <AfC> So revision specs can be used with -r arguments, all good; is there a way to use them with commands that just take a branch URL (ie, I'd like to do `bzr missing push:` but that doesn't fly)
[23:22] <mwhudson> well
[23:22] <mwhudson> i think you mean bzr missing :push
[23:23] <mwhudson> that works and isn't a revisionspec
[23:25] <AfC> ooooh
[23:25] <AfC> nifty
[23:25]  * AfC wonders where he could have learned that himself
[23:25] <AfC> mwhudson: (but I was referring to forms like `bzr diff -r parent:` )
[23:37] <mwhudson> AfC: it's not documented yet
[23:43] <james_w> AfC: I think parent is also :parent
[23:43] <AfC> Interesting
[23:43] <jonnyde1> hi, I've got a question regarding bundles: is it possible to backup a bazaar branch and all its revisions using a bundle? if so, how would it look like?
[23:43] <james_w> AfC: but if you mean e.g. "branch:" then I think "branch:29:wherever" is the way
[23:44] <AfC> I'm going to observe that it seems a bit strange that the thing: pattern was inverted to :thing
[23:44] <james_w> the :thing things are not revision specs, they are location specifiers
[23:45] <AfC> (if it's meant as a suffix, then fine, it makes sense, but it is rather glaring as using the same names in an inconsistent way. That tends to be a UI foible)
[23:45] <james_w> I'm not sure that they are the same names
[23:45] <AfC> james_w: parent, branch?
[23:45] <mwhudson> it's not really the same class of thing, even
[23:45] <AfC> same
[23:45] <mwhudson> though i agree it's a bit confusing
[23:45] <james_w> I'm not that keen on :parent et. al., but I don't think they conflict
[23:45] <james_w> AfC: it's branch: and :parent, they are two different words
[23:46] <AfC> james_w: bzr command -r branch:path
[23:46] <AfC> james_w: bzr command  path:branch
[23:46] <james_w> you can say using very similar things is a problem, but I don;t think they are the same
[23:46] <james_w> AfC: the second doesn't make any sense as far as I am aware
[23:46] <jonnyde1> (I would like to have a backup which is independent of the repository format)
[23:46] <james_w> or is that one I'm not familiar with?
[23:46] <AfC> ok
[23:47] <AfC> james_w: bzr command -r parent:
[23:47] <AfC> james_w: bzr command :parent
[23:47] <james_w> I could imagine it as "the branch of this tree wherever it is"
[23:47] <AfC> you're trying to tell me that people aren't going to go out of their minds trying to remember when to use which?
[23:47] <james_w> I don't think parent: is recognised
[23:48] <james_w> oh, I don't dispute that, but you said "same words", and I don't think there are any actually replicated
[23:48] <AfC> james_w: as may be.
[23:48] <AfC> james_w: were I a betting man, I'd be wagering heavily on this one.
[23:49] <james_w> AfC: is the very nature of these things a problem, or is it just the presentation?
[23:49] <james_w> would e.g. branch: and @parent be easier?
[23:50] <jonnyde1> I think somehow creating a diff (bundle) between an empty branch and the branch to be backed up should do it, shoudn't it?
[23:51] <james_w> jonnyde1: I think so
[23:52] <jonnyde1> so this should also be a way to convert a format into another format where no direct upgrade/downgrade is available...?
[23:52] <james_w> direct upgrade is available from every format since 0.4 or something as I understand
[23:53] <james_w> (so long as you don't try and go rich-root->non-rich-root or similar)
[23:53] <jonnyde1> well, but as I figured out this is not true for downgrading
[23:53] <james_w> and as a bundle contains the revision data you won't be gaining anything
[23:54] <bob2> going via bundles won't let you downgrade repository formats
[23:54] <jonnyde1> why not? is the bundle format specific to a repository format?
[23:55] <james_w> I think it just serialises the source repository format
[23:55] <jonnyde1> ok, I see. So a cannot apply a bundle to a repository where the formats are incompatible...
[23:57] <bob2> well, pretty sure it works upwardly
[23:58] <bob2> but you can't go back (from rich-root to plain)
[23:58] <jonnyde1> I wonder why there is no way to just export a series of commits. This way, I could just replay the commits, no matter what format the repository has...
[23:58] <james_w> you can fast-export, but it's lossy
[23:59] <jonnyde1> bob2: btw, thanks for your feedback
[23:59] <bob2> you can, as diffs or fast-export, but that doesn't help you


[02:12] <lamont> gcc-opt: forcing -O1
[03:03] <jbailey> lamont: Can you tell me if hppa has succesfully built klibc?
[03:05] <lamont> on debian?
[03:05] <lamont> or ubuntu?
[03:05] <lamont> latest, or ever?
[03:06] <lamont> make[1] : Entering directory `/build/buildd/klibc-1.0.14'
[03:06] <lamont> MCONFIG:90: klibc/arch/parisc64/MCONFIG: No such file or directory
[03:06] <lamont> make[1] : *** No rule to make target `klibc/arch/parisc64/MCONFIG'.  Stop.
[03:07] <lamont> fix your uname -m crap to strip the 64...
[03:09] <jbailey> Okay.
[03:10] <jbailey> Just that initramfs-tools 0.11 works for booting off of a harddrive, software raid1 and nfsroot now.
[03:11] <jbailey> Is 2.6.13 really does drop devfs, then this will be it from then on. =)
[03:11] <jbailey> s/Is/If/
[03:14] <jbailey> Should I map hppa* to hppa, or just hppa64 ?
[03:16] <lamont> parisc* -> hppa
[03:16] <lamont> jbailey: way cool.
[03:17] <jbailey> Hmm.
[03:17] <lamont> and yeah, good that it's working that well.
[03:17] <lamont> well, let me rephrase that...
[03:17] <jbailey> No, the kernel considers your arch to be "parisc"
[03:17] <lamont> kernel knows it as parisc or parisc64, depending on which kernel is running
[03:17] <lamont> and in fact, has an ifdef that appends the 64...
[03:17] <lamont> user space knows it as hppa
[03:18] <lamont> so whichever is appropriate for your environment...
[03:18] <jbailey> klibc is using this to grab the kernel headers.
[03:18] <jbailey> for syscalls and such.
[03:18] <lamont> hrm...
[03:18] <lamont> package names have hppa{,64}{,-smp} versions, iirc
[03:18] <jbailey> But it looks like there isn't really a separate parisc64 header set.
[03:19] <lamont> there isn't - it's purely config diffs
[03:19] <jbailey> I'm going to go with s/parisc*/parisc/ then.
[03:19] <lamont> sounds correct for kernel space.
[03:19] <jbailey> Have a good one, I'll push this to upload now.
[06:12] <lamont> hrmpf.  hppa is at 56.5%, sparc at 57.9% (installed)
[06:27] <fabbione> morning
[06:27] <fabbione> lamont: :)
[06:42] <lamont> fabbione: but my builds go faster now, since I'm forcing -O1 for a max optimization level in g{cc,++}-4.0.
[06:43] <lamont> otoh, ccache is slowly flushing
[06:43] <fabbione> i am not using ccache on the external buildd
[06:44] <fabbione> and i leave standard opts
[06:44] <fabbione> but well.. i am ok at this speed :)
[06:45] <lamont> dpkg: error processing tetex-bin (--configure):
[06:45] <lamont>  subprocess post-installation script returned error exit status 30
[06:45] <lamont> stupid tetex
[06:46] <lamont> gonna have to fix that tomorrow
[06:46] <fabbione> eh good idea :)
[06:47] <lamont> already done, it appears
[06:47] <lamont> tex/tetex-bin_2.0.2-30ubuntu3: Needs-Build [optional:out-of-date]
[06:49] <lamont> and depwait gtk+2.0 and linux-source-2.6.12 on the newer tetex-bin.  sigh
[06:50] <fabbione> oh l-s-2.6.12 is FTBFS on sparc :)
[06:50] <fabbione> i need to fix that ;)
[06:50] <lamont> eventually, at least, eh?
[06:50] <fabbione> probably, maybe, mostlikely :)
[06:51] <lamont> the -O1 is a workaround for a g*-4.0 regression in the optimizer.  annoying
[06:51] <fabbione> ah
[06:52] <lamont> I'd rather be able to leave it at 0..3
[06:52] <fabbione> i wonder if that also fixes some of my FTBFS
[06:52] <lamont> might... although it's an hppa-specific regression
[06:52] <fabbione> ah ok
[06:53] <lamont> it would appear that some code misbehaves when it compares two function pointers for equality and gets told 'not equal', when in fact they are.
[06:53] <fabbione> ah
[06:56] <fabbione> YEAH
[06:56] <fabbione> .12 is out
[06:58] <lamont> so how soon will we upload 2.6.12-1.1?
[06:59] <fabbione> that will be mostlikely 2.6.12-2.1
[06:59] <fabbione> or do you truely believe that from rc6 to final they did not break the ABI?
[07:00] <lamont> ah, we started being good and tracking, eh?
[07:00] <fabbione> yes.. because we moved .12 in main yesterday :(
[07:00] <lamont> we really should deliver the abi files as part of one (or each) of the kernel packages
[07:00] <lamont> rather than scaping them from the log files
[07:00] <fabbione> yeah that's in the spec..
[07:01] <fabbione> we need to think deeper about it :)
[07:02] <lamont> yeah - the proper place to put it would be linux-source, but that's arch: all --> no can do
[07:03] <lamont> maybe add a package that is nothing but the abi spec files?  then you can install that and linux-source-2.6.NN, and have everything you need to build a kernel properly
[07:05] <lamont> g'night
[07:05] <fabbione> re
[07:05] <fabbione> there is the b-d problem to do that
[07:05] <lamont> hrm.. /me needs to deal with gcc-opt it appears.
[07:06] <fabbione> good night
[07:06] <fabbione> what's wrong with it?
[07:06] <fabbione> it's a global problem or local?
[07:06] <lamont> -O gets misparsed
[07:06] <lamont> only if you restrict to < 2
[07:06] <lamont> is it a problem, that is
[07:06] <fabbione> ah ok
[07:07] <lamont>                     else if (c=='\0')
[07:07] <lamont>                         OptLevel=1;
[07:07] <lamont> DOH!!!
[07:07] <lamont> -O is == -O2, yes?"
[07:07] <fabbione> whoops
[07:08] <lamont> that hurts
[07:14] <lamont> gcc -O
[07:14] <lamont> gcc-opt: forcing -O1
[07:14] <lamont> gcc-4.0.gcc-opt: no input files
[07:14] <lamont> much better
[07:58] <fabbione> r/sc
[07:58] <fabbione> meh jb is not around
[02:43] <fabbione> Total 1594 package(s)
[02:43] <fabbione> Needs-Build :)
[02:44] <fabbione> Total 621 package(s)
[02:44] <fabbione> Building
[02:44] <fabbione> -20 in the buildd
[02:44] <fabbione> 601 in DepWait/FTBFS
[02:44] <fabbione> not really encouraging
[02:44] <fabbione> but most of them are missing B-D on X and DepWait
[03:10] <fabbione> hey jbailey
[03:17] <jbailey> Fabio!
[03:17] <fabbione> jbailey !
[03:17] <jbailey> Tell me about klibc on sparc.
[03:17] <fabbione> i did prepare a chroot with the new libc on sparc
[03:18] <jbailey> I want it working on sparc and hppa today. =)
[03:18] <jbailey> Ooo ooo ooo!
[03:18] <fabbione> klibc is FTBFS
[03:18] <fabbione> i think i told you already
[03:18] <fabbione> now.. i have the chroot.. what do you want me to test with it?
[03:20] <jbailey> Assume since you can get into it that shell and ls and friends work.
[03:21] <jbailey> +I
[03:21] <fabbione> yeah they do
[03:22] <jbailey> *lol* alright then. =)
[03:22] <jbailey> I've only been awake for 6 or 7 minutes. =)
[03:22] <fabbione> that's fine :)
[03:22] <jbailey> Did you seriously just upload?
[03:23] <fabbione> no.. i moved it to the upload dir...
[03:23] <doko> s/g/k/
[03:23] <fabbione> jbailey: i did test apt and such
[03:23] <jbailey> t would be nice if you could test something that uses getpid
[03:23] <jbailey> Like top
[03:23] <fabbione> hmm
[03:23] <fabbione> sure
[03:23] <jbailey> REmember that this instance has the known clone bug in it.
[03:24] <jbailey> Next upload will have that fixed (and hopefully some langpack love for pitti)
[03:24] <fabbione> i trash langpacks
[03:24] <fabbione> there is no way LP can access external buildds
[03:24] <jbailey> Sounds like a bug.
[03:25] <fabbione> doko: what are you going to upload?
[03:25] <fabbione> jbailey: LP is designed to access only DC buildds
[03:25] <jbailey> Then it's broken.
[03:25] <jbailey> Becuase ports will never be DC.
[03:26] <fabbione> jbailey: rule is: given port foo with a community, Mark will buy buildds to put at the datacenter
[03:26] <fabbione> sparc and hppa are 2 exceptions
[03:26] <fabbione> very special cased because it's lamont and me running them
[03:27] <jbailey> How big does the community need to be? =)
[03:27] <fabbione> jbailey: at least 50/100 users?
[03:27] <jbailey> Oh, that's easy enough.
[03:27] <jbailey> Hell, we have that many Hurd users. =)
[03:27] <fabbione> we can start faking email addresses and domains to mail bomb Mark asking for them :)
[03:28] <doko> fabbione: 4.0.1
[03:28] <fabbione> but hounestly.. i did stop Mark from buying sparc buildd's
[03:28] <fabbione> doko: dude.. get it right or i might knock on your door this evening
[03:29] <jbailey> AH did 4.0.1 release?  I'm a couple days behind on the toolchain lists.
[03:29] <doko> RC2
[03:29] <jbailey> BUt initramfs now works for the three cases that I claim it should.
[03:29] <jbailey> head is in stage 3 now, right?
[03:30] <fabbione> jbailey: top seems to work fine
[03:30] <fabbione> anything fancy you want me to test?
[03:31] <jbailey> You don't have a spare machine, right?
[03:31] <fabbione> nope
[03:31] <jbailey> Oh well.  I would suggest booting with it usually.
[03:31] <jbailey> Just because the change is so drastic.
[03:32] <jbailey> GA and upload then. =)
[03:32] <fabbione> yeah who cares :)
[03:32] <fabbione> there are probably 4 sparc users out there
[03:34] <fabbione> jbailey: in case it works.. you have to add a changelog entry for libc in debian:
[03:34] <fabbione> "NTPL on sparc is dedicated to that Kamikaze of fabbione"
[03:35] <fabbione> ;)
[03:35] <jbailey> It won't happen in Debian until the sparc porters say clearly that they want it to happen.
[03:35] <fabbione> ahaha
[03:35] <fabbione> that will never happen
[03:35] <fabbione> no.. really..
[03:35] <jbailey> Exactly.
[03:35] <fabbione> they can't even agree on what kind of toilet papers to use...
[03:35] <fabbione> generally speaking i mean
[03:35] <jbailey> Right.
[03:36] <fabbione> Benc and davem are pretty sane tho
[03:36] <jbailey> benc's last directive was 'don't to nptl'
[03:36] <jbailey> A quick poll of the other Debian glibc folks say that they are not in a rush to move away from LinuxThreads.
[03:36] <jbailey> So I do not expect to roll out nptl in Debian the way I have in Ubuntu.
[03:37] <fabbione> you can still use a very good argument
[03:37] <fabbione> "I overabused my Ubuntu powers to get it tested on 6 arches and it works...."
[03:37] <jbailey> 5.  Hppa isn't there yet. =)
[03:37] <fabbione> ".. but it's your call to decide"
[03:37] <fabbione> ah right.. hppa is even behind on the buildd!
[03:37] <jbailey> Right, and drow said "No.  Ubuntu may be able to get away with it, but Debian has a different situation"
[03:38] <fabbione> for once i am satisfied for not being the slowest arch :)))
[03:38] <jbailey> LOL
[03:40] <doko> ohh, I didn't know that infinity did join the porting team ;-P
[03:41] <fabbione> doko: no. i got the second buildd running
[03:41] <doko> no m68buntu :-/
[03:42] <fabbione> probably.. if we start m68buntu i will add 2 buildds here :)
[03:42] <fabbione> anyway it's saturday.. the sun is shining.. my wife has backed a cake
[03:42] <fabbione> cya later fellas
[03:43] <fabbione> Uploading via ftp glibc_2.3.5-1ubuntu7_sparc.changes: done.
[03:43] <fabbione> Successfully uploaded packages.
[03:43] <fabbione> ENJOY THE RIDE
[03:43] <jbailey> fabbione: Lovely.  Unblock glibc from the buildd then, please? =)
[03:43] <fabbione> i did already
[03:43] <fabbione> ;)
[03:43] <fabbione> i am off
[03:44] <jbailey> c'ya Fabio!
[10:24] <doko> lamont, infinity: please could you look at the build failure of db4.2 on i386? gij-4.0 is supposed to install the /usr/bin/java symlink as an alternative