[00:28] hefe_bia__: cat /etc/lsb-release will clue you in to the version in the chroot [03:36] emgent: is UTU manually updated? [03:38] nellery: auto-updated. [03:39] is there any way to see what packages were installed recently? [03:39] check every 10 min [03:39] no, to my computer [03:39] my compiz skydome broke and I have no clue what broke it; I need to see what packages have been updated [03:39] coppro: please use #ubuntu [03:39] emgent: okay, thanks [03:39] nellery: np. [03:39] ok [03:41] also, the dhcp3 packages are in main and universe, yet display an "All rights reserved" message. This doesn't seem right. [04:13] hello! guys, i have a question on debhelper compability: I want to use some v7 features, like dh_lintian - but will the package build on ubuntu 8.04 with those? [04:14] artfwo: Yes; debhelper has been backported. [04:14] artfwo: And the only way for new packages to get to Hardy is through backports, so... [04:14] then PPA build system includes v7 as well? [04:15] artfwo: I don't think so [04:15] Good question. I don't think the PPAs do build against backports.- === ApOgEE-_ is now known as ApOgEE-- [04:19] sadly, but true. just checked the build logs - it only uses -updates and -security [04:19] no they don't build against backports :) [04:19] I would have a lot more people screaming at me if it did [04:19] why? [04:19] jdong: for sure [04:20] 1) building against things that not a everybody is likely to have is not a good idea [04:21] 2) -backports has potential to have real changes that would affect packages, different cmake and Qt4 version for instance [04:21] hmm... ah [04:22] okay, I guess I'll stick with manual installation of lintian_overrides then [04:23] thanks everyone for your help! [04:24] so, anyone know why a main/universe package is displaying an "all rights reserved" message? [04:25] where is it displaying it? [04:26] yes, there is quite a number of such notices - in libicu for instance [04:26] :0:> less /usr/share/common-licenses/BSD [04:26] Copyright (c) The Regents of the University of California. [04:26] All rights reserved. [04:26] that's the license though [04:27] not the program [04:27] (any dhcp3 program in this case) [04:29] just run it and it says "Copyright 2004-2008 Internet Systems Consortium" [04:29] "All rights reserved" [04:30] I have another question on sourcepkg compability: Lintian on Intrepid gives the warning "out-of-date-standards-version 3.7.3 (current is 3.8.0)" - is it okay to update the policy to 3.8.0 if I'm going to build the package on Hardy as well? [04:31] why is the "All rights reserved" an issue? [04:31] from what I can see, it used to be required or at least expected in order to assert copyright [04:32] anyway, I have to run [04:32] it's no longer required according to wikipedia, but is still seen regularly [04:34] all rights are clearly not reserved; there's a license [04:34] that allows me to distribute it [04:34] but I think they are saying they are reserving their rights to say how it is licensed, not sure about that though [04:35] i.e. the default is full copyright with all rights reserved, *then* you poke holes in it with the license [04:35] well, I wouldn't expect any program to say that I can't copy it if it's in main [04:37] coppro: I don't think it *is* saying that [04:37] the program, as run, provides no exception [04:37] which at least implies that I can't copy it [04:37] artfwo: First, don't update the standards version unless you actually update the package to meet that standard. Generally if it's a package we get from Debian, you shouldn't change it. [04:38] There's really no point in updating it for Hardy in any case. [04:38] Often you can just ignore that warning. [04:38] coppro: it's MIT licensed [04:38] ScottK-laptop: okay, thanks [04:39] LaserJock: the program implies the exact opposite [04:39] coppro: The way I think we are supposed to interpret "All Rights Reserved" is All rights not explicitly given away. [04:39] It's any implicit rights. Not the ones enumerated. [04:39] ok, fair enough. Then it should enumerate the rights when run, if it says All rights reserved [04:40] There is no implicit right to say you can't run it (except AGPL explicitly says you need to meet certain conditions). [04:40] to run, yes [04:40] but I think, personally, that the text is misleading [04:41] it's maybe not the clearest, but I don't think it's necessarily wrong [04:45] coppro: I'm not a fan of it, I agree it's confusing, but it's quite common. It used to be required (it's not anymore) and the practice lingers through inertia and folklore. [04:46] well, removing it or adding another line about the license is a simple patch [04:46] but part of it is in main, so I guess it's up to canonical [04:47] coppro: just because it's in Main doesn't mean Canonical has to do it [04:48] it means a Core Dev needs to sponsor a patch [04:48] ok. [04:49] Note that both the people you are discussing this with are core-dev and neither works for Canonical. [04:50] Both of those can be fixed. :-P [04:51] * coppro is not very familiar with the system, then [04:52] coppro: that's ok, we're all here to learn [04:52] some more than others, clearly [04:52] oh right, I have an important question [04:53] is a copyright notice really required in every source file if the package is distributed with such a notice? [04:54] usually there is a "header" for each file [04:54] yeah, the package I'm packaging doesn't have such a thing [04:54] a quite common occurance is for somebody to say license the program as GPL and forget the a couple files are actually Academic-only or something [04:54] none of the files have any such license [04:55] so having it in every file helps us to make sure the license is correct [04:56] coppro: My experience is that as long as there is a LICENSE or COPYING file in the source tarball that has the full license in it, the archive admins will hold their nose and accept it. It MUST have the full license in it though and it should be in every file. [04:57] there's a file license.terms with an MIT license in it; I've been told by some sources that isn't enough [05:00] Erm, do any of you geniouses know where I could get help on hostname resolution with avahi? I seem to be stumping everyone I find (or just confusing them). [05:02] It's supposed to just magically work. [05:02] well, it works, just not the way I want it to [05:03] Does anything at http://avahi.org/wiki/Avah4users help? [05:03] jmarsden: perhaps - hadn't seen that yet [05:03] A quick Google found it for me... hopefulyl it will help. [05:09] <\sh> so...it's 6am in germany...and we are finished with our nightshift...time for a beer... [05:28] Can someone help me debug something? [05:29] ls [05:29] quentusrex: ls works, it does not generally need debugging? [05:29] haha, [05:30] no. I'm trying to install munin with mysql plugin. it's a default plugin in the munin-node package. [05:30] but it can't connect to mysql... :( [05:30] but I can easily connect manually... [05:31] quentusrex: Then most likely it is looking in the wrong place (IP address and port) or using the wrong username/pw for auth. [05:31] I've got the user and password correct I'm really sure... [05:32] my $MYSQLADMIN = $ENV{mysqladmin} || "mysqladmin"; [05:32] my $COMMAND = "$MYSQLADMIN $ENV{mysqlopts} extended-status"; [05:32] that is part of the mysql plugin (in perl) that is creating the command [05:32] but I run the command manually: [05:32] /usr/bin/mysqladmin -u debian-sys-maint -p********* status [05:32] and it works. [05:33] So what is the env var mysqlopts being set to? [05:33] it's on a test lan mysql server so here: [05:33] [mysql*] [05:33] user root [05:33] env.mysqladmin /usr/bin/mysqladmin [05:33] env.mysqlopts -u debian-sys-maint -pk3f4nIlErsLzJq8B [05:34] OK. If you change the my $COMMAND line to say my $COMMAND = "echo $MYSQLADMIN $ENV{mysqlopts} extended-status"; [05:34] does it do what you expect? [05:38] it prints 'yes' [05:39] Here is the contents of $COMMAND: mysqladmin extended-statusn [05:39] quentusrex: That's not what I would have expected...! I'll try munin out here, let me install it and see what I find... [05:40] it's missing the entire opts part. [05:40] That would explain the inability to work... [05:40] yup, $ENV{mysqlopts} is blank... [05:42] so.... I don't know how to 'fix' that... [05:47] alright, found the problem. [05:47] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408452 [05:47] Debian bug 408452 in munin-node "munin-node: mysql plugins don't get any data" [Normal,Open] === YokoZar1 is now known as YokoZar [10:06] http://revu.ubuntuwire.com/details.py?package=lensfun if somebody has a little time to look at it? [10:48] i'm trying to package libsigx, but it doesn't seem to have a SONAME. what should i do? [10:56] hyperair: why do you need the SONAME? [10:56] pmjdebruijn: because i'm packaging a library? [10:56] hyperair: I ment why do you need it explicitly? [10:57] hmm i don't? [10:57] @_@ [10:57] the lib file is /usr/lib/libsigx-2.0.so [10:57] hyperair: does build fail? does lintian complain? [10:57] i'm trying to build [10:58] lintian.. [10:58] wait [10:58] what error do you get while building? [10:58] W: sigx source: substvar-source-version-is-deprecated libsigx-dev [10:58] that's unrelated [10:58] sorry, i meant the build isn't complete [10:58] okay, so what does that lintian warning mean? [10:58] hyperair: lintian explains it, if you read further [10:59] gimme a moment [11:00] aah [11:00] i see [11:00] thanks [11:00] =D [11:13] someone knows if there is an open bug about linux not supporting fat32 (properly)? [11:15] what's wrong with linux's fat32 support? [11:16] I had to copy some files from a pendrive on to my home directory. and the whole system stops working [11:16] define stops working [11:17] I removed the stick and after 1-2 minutes the system works again... [11:17] eh? [11:17] hyperair: Well the panel stops working, the windows are frozen [11:17] hmm [11:17] pastebin your dmesg log [11:18] it's probably an issue that's not related to vfat [11:18] have to see if I can find it ... this was 2 days ago [11:18] I had to reboot to vista in order to copy the data on my disk :( [11:21] http://paste.ubuntu.com/83931/ [11:23] elmargol: there's something wrong with your pendrive [11:23] get it checked [11:23] it is not my pendrive and it works 100% on windows [11:23] try formatting it again [11:24] it said Buffer I/O error [11:24] that means there's a hardware error with your pendrive [11:24] NOT my pendrive. and I don't have it here. The bug is that it works on windows [11:37] i'm very sure that if format it in ntfs, it'll have the same issue [11:37] and in any other file system [11:53] elmargol: seriously... high changes are you pendrive is broken somehow... [11:54] pmjdebruijn: ok explain to my why it works perfect on windows [11:58] elmargol: explain to me why I have a hunderd pendrives which work great with Ubuntu [11:58] elmargol: maarja, the flash memory itself is fine, the the usb controller in the stick is quasi-broken [11:58] as in broken by design [11:58] but everything gets tested with Windows (even if it's broken), when it works with Windows it gets a seal of approval, and goes to market [12:00] thats no excuse [12:00] elmargol: huh? [12:00] a) you unmount the drive and give an error message (and don't freeze the system) [12:00] elmargol: I have a hunderd pendrives that just work [12:01] elmargol: well that's weird indeed [12:01] or b) you have some debug mode where it tries to work [12:01] You can't just leave a user with a frozen system and say well your hardware is shit go away and die [12:01] elmargol: it should crash linux, that's true [12:01] elmargol: shouldn't [12:02] elmargol: but the hardware is probably the root cause [12:02] elmargol: linux' fault is just handling is badly [12:02] well i have this bugs not only on pendrives... if you mount a cifs share and loose your wlan the system hangs too [12:02] this is a common issue on linux [12:02] elmargol: cifs never has been very reliable [12:03] elmargol: that why gnome has gnome-vfs... which is not kernel side, and thus can't crash your kernel [12:03] the kernel does not crash... the applications just wait... and wait and wait... [12:03] elmargol: the question is, this usb pendrive issue, did you test with other ubuntu releases [12:03] and after 20-30 seconds it times out [12:04] elmargol: that seems like sane behaviour... [12:04] the timeout is way to long [12:06] elmargol: well file a bug on gnome-vfs [12:06] pmjdebruijn: I'm using kde [12:07] elmargol: then file a bug on the kde counterpart... [12:07] and this is not kde or gnome specific if you cd to the path it hangs too [12:07] elmargol: I don't know how KDE does it mounting [12:07] elmargol: what path? [12:07] elmargol: how did you mount it? [12:08] pmjdebruijn: i just plug it in... i guess hal mounts it? [12:08] elmargol: how does the mount command list the mount [12:08] elmargol: huh? [12:08] elmargol: hal mounts cifs? [12:09] pmjdebruijn: ahh you mean cifs.. mom [12:09] elmargol: anyway, this probably isn't the proper channel for that [12:09] elmargol: motu is primarily for universe packages [12:09] ok... i give up [12:10] elmargol: you should probably ask on #ubuntu [12:10] there are a ton of open bug reports... noone cores... and i have this issues 2,5 years now [12:10] elmargol: did you file the bug on the proper package? [12:11] elmargol: filing good accurate bugs is very important in getting them fixed [12:11] roflmao [12:11] huh? [12:12] You don't believe that do you? [12:13] elmargol: seriously, what do you expect [12:13] elmargol: developer will prioritize... [12:13] if a bug takes more than 10 minutes developers just ignore it :D [12:13] * pmjdebruijn is just another user, btw [12:14] elmargol: You don't believe that do you? [12:14] I believe that 100% [12:15] elmargol: well, I can't help you with that... please check if you properly filed your bugs... and ask help on an appropriate channel... like I said, #ubuntu-motu isn't the best place for the bugs you're talking about... [12:18] * directhex thinks there's a pinkware error alongside the hardware error [12:58] directhex: pinkware? [13:13] pmjdebruijn: I think he means brains :) [13:31] does anybody know what I have to do when I get the following error after uploading an update of a package? [13:31] http://revu.ubuntuwire.com/?archive=4208 [13:40] mgdm: oh === LucidFox is now known as Jack_Harkness [13:56] hmmmm. Brainzzzz. [14:07] * mgdm shuffles away from ScottK [14:11] If it's going to take you that long to shuffle, it's probably too late already. === Jack_Harkness is now known as LucidFox === SWAT___ is now known as SWAT === ma101_ is now known as ma10 [15:02] unfortunately my client crashed, and possibly lost any answers on my question about: [15:02] http://revu.ubuntuwire.com/?archive=4208 [15:05] logari81: No one answered you, but I've asked a REVU hacker to take a look at it. [15:05] * ScottK-laptop waves to NCommander. [15:08] Would someone be able to have a look at the diff in https://bugs.edge.launchpad.net/hardy-backports/+bug/306280/ ? (Despite appearances, this is nothing to do with Hardy Backports...) [15:08] Launchpad bug 306280 in libdmtx "Update libdmtx to 0.6.0" [Undecided,New] [15:09] bug 307020 [15:09] Launchpad bug 307020 in swt-gtk "Please merge swt-gtk 3.4-2 (universe) from Debian unstable (main)." [Undecided,Confirmed] https://launchpad.net/bugs/307020 [15:10] ScottK-laptop: do you think I should try to upload the package again or is it already correctly uploaded despite of that error? [15:10] this is the link to the package [15:10] http://revu.ubuntuwire.com/details.py?upid=4208 === Kmos_ is now known as Kmos [15:11] logari81: I suspect it is correctly uploaded, but don't know for certain. [15:13] Heya gang [15:15] heya bd. [15:15] Urgh. Not enough coffee for proper tab completion yet. [15:16] heya bddebian. [15:16] meeh [15:16] reminding me of my lack of coffee isn't fair :-P [15:18] blah [15:19] * jdong has a 2.5lb bag to finish in the coming week [15:19] Heya ScottK [15:19] I don't want it to go stale over my winter break [15:19] nor do I want to take the bag home through the airport because then I seem like some crack dealer [15:20] Odd. [15:20] * ScottK measures coffee staleness in months and years, not days and weeks. [15:20] Hi bddebian [15:20] winter break is ~1.5mo [15:21] and I don't have a really great airtight container [15:21] Heya geser [15:21] that's going to be on my christmas shopping list. [15:21] Freezer? [15:21] I suppose that works too [15:29] scottK hello ! do you know why bug 271546 are not yet fixed on dapper and gutsy ?? [15:29] Launchpad bug 271546 in clamav "[hardy] Multiple unfixed CVEs" [Undecided,Fix released] https://launchpad.net/bugs/271546 [15:30] leonel: No. [15:30] jdstrand_ or kees ^^ [15:30] leonel: Go have a look at r4550 in the clamav svn. [15:35] https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <--- in the Method section of that, should dget -xu URL be dget -x URL? [15:36] rjune: -u allows unsigned extraction right? [15:36] yes [15:36] so that is correct [15:36] otherwise if you don't have the package's signing key in your GPG keyring, newer dget refuses to extract [15:36] jdong, when I do dget -xu, I get an error that -u is not known. [15:37] ok, it's a recent change then [15:37] I'm pretty sure it works Hardy+ [15:37] scottK to enable the chm ?? [15:37] leonel: Yes. Then you can test if the vulnerability is real or not. [15:38] jdong, doesn't work in hardy, might work in intrepid [15:39] jdong: Personally, I consider unsigned extraction failure a feature. It reminds me to go fetch their GPG key and check if I'm going to do anything with the code. [15:39] ScottK, nobody is complaining about it. just trying to verify the behaviour is correct [15:40] well .. I guess is real since the module is disabled and clamav fixed the bug [15:40] leonel: It's real for 0.94, but is it real for 0.92? [15:41] rjune: I wouldn't recommend -xu to people myself. [15:42] But then I do crazy stuff like make sure md5sums match before I upload a tarball too. [15:42] * rjune shrugs. not my wiki. [15:42] ScottK: I mostly agree when human intervention is there [15:42] ScottK: for prevu it was more of an annoyance that dget started failing in Hardy for unsigned packages [15:42] s/unsigned/unknownly signed/ [15:42] it wouldn't make any sense to automatically fetch and trust a GPG key either [15:43] True. [15:43] My main concern is DNS cache poisoning and so if you're fetching the GPG key from a different domain than the code, then at least your odds are better. [15:44] i.e. they have to successfully poison both of them. [15:59] does fakeroot depend on cdbs? [16:00] do you mean to ask the other way around? [16:01] ScottK: well my secondary concern is it takes a human to verify whether or not a package is signed by the right person and whether I got the right key for the person... IMO automating that and giving a false sense of security is worse than just plain assuming the data can be compromise. [16:01] jdong, no [16:01] jdong, I installed fakeroot and went to run it [16:01] it's always been my belief that security done wrong is worse than nothing done at all [16:01] it failed because cdbs was not installed [16:01] rjune: fakeroot has nothing to do with cdbs or Debian at all. [16:02] fakeroot is a standard Linux command that can be used on any distribution to give the appearance of root access. [16:02] what you're seeing is probably your package's build scripts being run with fakeroot that need cdbs. [16:08] jdong, https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <-- working through that [16:08] which allows for using fakeroot or as roo [16:08] as root [16:08] so I installed fakeroot [16:08] which failed because it didn't install cdbs as a dependancy. [16:09] which gets back to my initial question. does fakeroot depend(require, need) cdbs. your answer seems to be yes it does. [16:23] rjune: NO, fakeroot does not depend on cdbs. [16:23] rjune: fakeroot doesn't do anything but change your user to look like it's root. [16:23] but if you run something under fakeroot, it can require other things like cdbs. [16:23] that's like me running sudo firefox [16:23] and concluding sudo requires X, GTK, Mozilla, XulRunner, etc. [16:24] ok, so cdbs is required by the build scripts [16:24] that's correct [16:24] for your particular package you're working with, yes :) [16:25] then the web page should be updated to indicate you need to install cdbs [16:25] which it does. [16:25] dammit, missed that line [16:26] whoops :) [16:26] I hate it when I do that. [16:31] jdong, is cdbs a standard requirement for building packages? [16:32] rjune: no [16:32] rjune: No. Some use it. Some don't. [16:32] do debs have such a concept as build requires? [16:32] yes. [16:32] Build-Depends [16:33] generally only a small subset of them is required to build the source target with debuild -S [16:33] so then cdbs should be in the build-depends for anything that requires cdbs? [16:33] yes [16:33] otherwise the package would not build [16:34] https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageUpdate <-- I'm still here. [16:34] it says to install cdbs at the beginning, but I'm wondering if updating the dsc file is a better solution [16:36] look in debian/control [16:36] cdbs is absolutely listed in the build depends [16:36] otherwise the package would not build in the Ubuntu build system [16:37] then why does it not error immediately when I try to build it with cdbs not installed? [16:37] Instead I got an error these files are missing [16:38] because to evaluate the build conditions cdbs is used. [16:38] the makefile debian/rules will immediately die a horrible death trying to find the cdbs scripts [16:40] so upon attempting to build something with deb, it does not first verify all the build-requires are installed? [16:40] or does cdbs do that verification? [16:40] in the case of cdbs, cdbs does that verification. [16:41] the actual rule for reading the build requirements is a part of the build script. [16:41] and in the case of cdbs, the build script (debian/rules) is surprisingly empty except for a bunch of cdbs includes. [16:42] so if I do debuild -S -sa, then cdbs is responsible for looking at Build-Depends and making sure everything is installed? [16:42] the build system used in debian/rules is [16:42] correct [16:42] which in this case is cdbs [16:43] it might be something different, in theory [16:43] ok, then just install cdbs because it's effectively required to do package building. even if it isn't a strict technical one. [16:43] for your package, yes. [16:43] because it was made with cdbs [16:43] not all packages are made with cdbs. [16:44] it is one of several build systems that are available for use === gouki_ is now known as gouki [16:44] dh7! [16:45] jdong, right, not everything uses cdbs, it's not a technical requirement. but a fair number of packages do, and when they do, there's no way to verify it before hand. so just install it so you have it [16:46] well, I suppose. [16:46] it doesn't hurt to have cdbs around. [16:46] * directhex hurts jdong [16:47] eewww proposal 8! [16:47] *ducks* [16:47] what other require engines should I have installed? [16:48] Wait, what? [16:48] The build system gets build-deps? [16:49] Laney: the buildsystem usually calls a standard debhelper mechanism that checks them yes [16:49] I thought that dpkg-buildpackage did that [16:49] parsing of control [16:51] Laney: yes, but before doing so: [16:51] unless ($noclean) { withecho(@rootcommand, @debian_rules, 'clean'); [16:51] } [16:51] which runs the debian/rules target [16:51] which you're screwed on if one of the included makefiles isn't available :) [16:52] which is why it's helpful to use an internal variant of pdebuild to even buidl source packages [16:52] jdong, any other engines besides cdbs Ishould have installed? [16:52] But that doesn't actually install anything itself [16:52] rjune: get them when they come. [16:52] You have to have stuff used in the clean target installed to build source packages [16:52] don't waste time now trying to foresee every build dependency you might need in the future. [16:52] there's a few packages that are evil enough to require a substantial amount of stuff to execute their clean target [16:52] But I don't think anything actually check that - building will just bomb out? [16:53] but seeing as I won't know what they are until I get an error about them. which may or may not provide information as to what I actually need. I figured I would ask. [16:53] Laney: yeah... [16:53] ok [16:53] I guess I was confused as to what you were saying [16:53] depending on how you clean. [16:53] right [16:53] if you are doing a fakeroot debian/rules clean, yeah it'll bomb out. [16:53] but if cleaning is a part of a debuild/dpkg-buildpackage sequence, you're okay [16:54] those check build deps before cleaning === ma101 is now known as ma10 [17:11] I just fixed the amd64 issue with my package, can someone review the corrected version ( http://revu.ubuntuwire.com/details.py?package=lensfun )? [17:31] crimsun, I've not tested that snapshot. i've tested the stuff in intrepid and hardy at this point [17:44] sebner, I checked the amd64 cifer binary from the packages before adding the chrpath --delete and after, and chrpath reports that neither of them contain rpath tags [17:44] DRebellion: how that? O_o [17:44] sebner, i'm not sure [17:45] sebner, perhaps there wasn't a problem after all? [17:45] DRebellion: I'll recheck that today or tomorrow. Besides this issue your package could be advocated so I'll try to solve that [17:45] sebner, ok thanks. === dickydoo2 is now known as WelshDragon === fta2 is now known as fta [19:16] <`Chris> Hello #ubuntu-motu! Can anyone direct me to some beginner tutorials for packing and maintaining packages in Ubuntu? [19:16] `Chris, dive in: https://wiki.ubuntu.com/PackagingGuide/Complete [19:17] <`Chris> Thanks a bunch DRebellion [19:18] `Chris, you could also look at https://wiki.ubuntu.com/MOTU/GettingStarted (it has some references to Ubuntu development) and http://www.debian.org/doc/debian-policy/ (for packaging rules in general). [19:22] ogra, You get your package? [19:22] jdong: are you on motu-sru? === RainCT changed the topic of #ubuntu-motu to: Masters of the Universe - https://wiki.ubuntu.com/MOTU | Want to get involved with the MOTUs? https://wiki.ubuntu.com/MOTU/Contributing | Grab a merge: http://dad.dunnewind.net http://merges.ubuntu.com | http://qa.ubuntuwire.com/uehs | Go REVU! :) [19:23] I urgently need to get bug 263173 approved for SRU [19:23] Launchpad bug 263173 in sugar-hulahop "Sugar Browse fails on startup" [Undecided,Confirmed] https://launchpad.net/bugs/263173 [19:24] jdong, nxvl, cody-somerville ^ please? [19:25] rjune, yeah, we'll try it tonight ;) [19:31]