[01:40] <ScottK> slangasek: Since usplash is no longer built on ia64, what would you think of removing all the binaries on ia64.  Then I can do a new kubuntu kubuntu-meta update and germinate won't try to put usplash on ia64?
[01:45] <slangasek> ScottK: acceptable
[01:45] <ScottK> slangasek: Do you want a bug for the usplach binary removal?
[01:45] <ScottK> ch/sh
[01:45] <slangasek> I don't think so
[01:46] <ScottK> slangasek: OK.  Just let me know when it's done and I'll give it a couple of publisher cycles.
[01:46] <slangasek> will do
[01:50] <slangasek> ScottK: done
[01:50] <ScottK> slangasek: Thanks.
[02:32] <slangasek> ArneGoetje: translation full export for RC starts tomorrow(today), right?
[03:00] <ArneGoetje> slangasek: Friday 22:00 UTC
[03:02] <ArneGoetje> slangasek: export will take about 24 hours, the langpack prep another 5 hours or so.
[03:22] <ice-nine> Is there a website / bug tracker listing current bugs in 9.04, and possibly status of bugs?  Reason being, I'd like to take a look at what requires fixing, and may be lend a helping hand....
[03:25] <slangasek> ArneGoetje: ok
[03:28] <slangasek> ice-nine: the list of bugs that are known targets for Ubuntu 9.04 are found at https://launchpad.net/ubuntu/jaunty/+bugs
[03:29] <ice-nine> thanks slangasek.  I'll check out that url.  Is it possible for just anyone getting involved in committing bug fixes in common apps?
[03:30] <slangasek> ice-nine: to commit fixes, you generally have to be a member of ubuntu-dev already; but we happily accept patches via Launchpad
[03:30] <persia> ice-nine, You might find https://wiki.ubuntu.com/SponsorshipProcess useful
[03:32] <ice-nine> Thanks.  I'll look into this.
[03:46] <gopogo> ubuntu jaunty jackass is  not detecting windows during installation
[03:46] <gopogo> it says no windows instaled
[03:49] <Hobbsee> gopogo: and again, #ubuntu+1
[03:52] <jdong> wow...
[04:33] <gopogo> http://www.linuxloop.com/news/2009/04/08/why-virtualbox-should-be-included-in-ubuntu/
[04:34] <persia> apt-cache show virtualbox-ose ?
[06:08] <gopogo> Jaunty -> its saying connected to wifi netework but not pigging default gateway
[06:10] <slangasek> gopogo: this is not a support channel.  I gather that you've already been directed to #ubuntu+1 several times already.
[06:13] <YokoZar> A user submitted a bug report with this failure on Wine's --configure step: Error: contents of '/etc/mailcap.new' do not match what was written -- abort
[06:13] <YokoZar> Could this possibly be the package's fault, or is something else going on here?
[06:21] <gopogo> slangasek: no body is answering ubuntu +1
[06:23] <Hobbsee> gopogo: then perhaps you shouldn't ask when it's the European & US night, and a public holiday in a lot of countries.
[06:23] <gopogo> Ohk
[06:23] <Hobbsee> channels are always quieter then ;)
[06:24] <gopogo> is there any issue in wep in jaunty jackass ?
[06:24] <gopogo> opps jackolope
[06:25] <Hobbsee> ...but the bit about support not being here still applies, i'm afraid...
[06:25] <infinity> gopogo: Rephrasing the question doesn't make it any less a support question.
[06:25] <gopogo> WEP IS NOT WORKING LOOKS LIKE BUG
[06:25] <gopogo> ;-)
[06:26] <gopogo> its was working in 8.04
[06:26] <infinity> gopogo: If you need answers RIGHT NOW, Canonical (among other companies) offer paid support.  Otherwise, please respect the (rather small set of) rules that our community support runs by, and ask in the proper channel, browse bugs to see if you find something similar, check forums, etc.
[06:27] <gopogo> i cant pay connanical
[06:27] <gopogo> i am a student
[06:28] <infinity> gopogo: Then feel free to make use of the free support that the community offers.  Just keep in mind that said free support doesn't happen here.  Please.
[06:46] <gopogo> oks
[06:46] <gopogo> where should i report this bug
[06:47] <YokoZar> ubuntu-bug (packagename) on a terminal is best
[07:09] <slangasek> superm1: is /etc/apache2/sites-available/default-mythbuntu not a conffile?  you shouldn't need to rm -f it in the maintainer script, should you?
[07:09] <superm1> slangasek, it's not a conffile, it's generated by the postinst
[07:09] <slangasek> ok
[07:24] <dschulz> hi
[07:26] <dschulz> anyone bitten by #358915  "init crashed with SIGSEGV in event_poll()"   ?
[07:26] <dschulz> running jaunty/amd64
[07:27] <dschulz> i'm looking for clues on this
[07:42] <slangasek> not that I'm aware of
[07:42] <slangasek> I'm way impressed with apport now, though
[07:51] <dschulz> slangasek: i thought the same when I first saw the bug report finished
[09:46] <deepspring> I found a bug in Python 2.6 on Ubuntu 9.04... do I discuss it here?
[09:46] <deepspring> http://ubuntuforums.org/showthread.php?p=7046504
[09:50] <persia> deepspring, #ubuntu-bugs is a better place for discussion of bugs.
[09:50] <deepspring> ok
[09:50] <deepspring> gone
[13:11] <bigon> hi, is reloading dbus after installing a .service file still necessairy in the postinst script?
[13:44] <t325> Hello, is OpenSSL considered a part of Ubuntu? If it is, where are its linkable libraries installed?
[13:45] <t325> (coming from a FreeBSD perspective -> don't know very well the "separation of powers" here)
[13:46] <persia> t325, Do you have libssl-dev installed?  dpkg -L libssl-dev would show you the relevant files in this case.
[13:47] <persia> But this isn't a support channel: for asking about aspects of packaging (like that), #ubutnu-motu is better.  For asking more general questions about Ubuntu, #ubuntu is better.
[13:47] <t325> it wasn't installed, thanks!
[13:49] <lool> slangasek: Bug #359049 > could you have a RM look and comment?  cjwatson mentionned consistency between subarches is desirable
[14:16] <lifeless> pop quiz; is there a C url library (and not 'libcurl, its an http library, not a  URL library)
[14:16] <lifeless> I want something with urljoin, urlparse etc
[14:17] <lifeless> clearly mozilla etc etc etc have to _do_ this, but I don't want to even think about linking in those monsters
[14:17] <elmo> lifeless: I think the gnome folks have a library that does that, but I forget it's name
[14:17] <lifeless> jamesh: ^
[14:17] <elmo> lifeless: oh, maybe neon?
[14:18] <elmo> lifeless: and libsoup is the gnome one
[14:18] <lifeless> ah, blink, I remmeber that from tla; libneon changed api more often than... /me stops
[14:18] <persia> And it also is an http library, rather than a URL/URI library.
[14:18] <lifeless> yah
[14:19] <lifeless> I don't mind that so much, but the focus leads to some odd apis
[14:19] <elmo> persia: well, i assumed a http library would have URL/URI functions
[14:19] <lifeless> elmo: libcurl has exactly one - 'escape' :P
[14:19] <persia> elmo, It does: it's just that the form of the request disqualified something else for supporting http :)
[14:20] <lifeless> persia: not strictly; libcurl I've already ruled out but neon may have what I want
[14:20] <lifeless> I don't want to start a liburl project for the hell of it
[14:21]  * persia finds annoying unlicensed public code that implements URL parsing functions
[14:22] <lifeless> the ne_uri_* functions are what I need. Thanks elmo, I really should have remembered this
[14:22] <lifeless> though dragging in a full http library to get it - fail
[14:23] <lifeless> bah actually no
[14:23]  * lifeless implements
[15:01] <jamesh> lifeless: there is some basic URL parsing functions in glib, but they are really basic.
[15:03] <tedg> jamesh: Is there more in gio?
[15:03] <jamesh> tedg: perhaps.  I haven't explored it much.
[15:03] <jamesh> maybe in the GFile interface
[15:04] <lifeless> tedg: I saw that it uses dbus to access backends and cried while running
[15:04] <tedg> I figured there'd have to be, but I haven't played with it either.
[15:04]  * tedg thinks bazaar should use dbus for backed support.
[15:07] <lifeless> tedg: heh. no
[15:07] <lifeless> its not that I don't like DBus, I like it fine
[15:07] <lifeless> but its IPC/RPC.
[15:07] <lifeless> not everything needs to be hit with that particular hammer.
[15:07] <tedg> lifeless: Yes, choosing the right tool for the job.
[15:08] <tedg> lifeless: BTW, were you able to get the appropriately corrupt repository downloading it from LP?
[15:08] <lifeless> now, if you have a core implementation that allows a backend to be 'I get stuff from dbus', then you can mix and match
[15:08] <tedg> lifeless: Or should I start a tarball upload for the next couple days :)
[15:09] <lifeless> tedg: To make sure I don't waste time debugging something differnet I really want a tarball of what you have on your disk
[15:09] <tedg> lifeless: Okay, do you know if there is an attachment limit in LP?  Perhaps it should go on people.u.c
[15:09] <lifeless> past midnight here, gnight
[15:09] <lifeless> whereever is fine
[15:10] <tedg> Cool, will do.  Thanks lifeless
[16:40] <crik91> hi
[16:54] <bluefoxicy> anyone know why trackerd constantly uses 100% CPU?
[17:01] <bluefoxicy> actually you know what.
[17:01] <bluefoxicy> I can find out why it uses so much CPU.
[17:01]  * bluefoxicy bash script.
[17:03] <jdong> bluefoxicy: for me right after the upgrade it required a complete rebuild of the DB which was pretty thrashy and spinny at times, after that initial chug things settled down for the most part....
[17:03] <bluefoxicy> jdong this has been happening since I upgraded, 3 days before beta.
[17:03] <bluefoxicy> and it's not playing with my hard disk a lot.
[17:03] <bluefoxicy> % time     seconds  usecs/call     calls      function
[17:03] <bluefoxicy> ------ ----------- ----------- --------- --------------------
[17:03] <bluefoxicy>  60.34   80.164781         672    119149 g_main_context_iteration
[17:03] <bluefoxicy>  24.21   32.168548         269    119150 g_main_context_pending
[17:03] <jdong> odd; sounds like an indexer is getting stuck on some sort of file type then
[17:04] <bluefoxicy> this is where most of the work is occurring but this is pretty useless
[17:04] <jdong> lol that sounds like a main event loop or something
[17:04] <bluefoxicy> yeah.
[17:04] <jdong> hmm a profiler, then?
[17:05] <bluefoxicy> what I need is an encapsulated graph
[17:05] <bluefoxicy> like, g_main_context_iteration() takes 60%.  45% of its time is in function call to some_other_function(), which spend 80% of its time in yet_another_function()...
[17:06] <bluefoxicy> and draw pretty, space-filling boxes
[17:06] <jdong> lol is it technically feasible for strace to do that?
[17:06] <bluefoxicy> (actually ltrace could be modified to do this)
[17:06] <jdong> well it probably can
[17:06] <bluefoxicy> yes, because it can say "You are in function X" "function call to Y... we were in function X.  X called Y."
[17:06] <bluefoxicy> and trace the return path.
[17:07] <jdong> well when A() waits 1s, calls B() which takes 1s, what does strace report as the time for A(), 1s or 2s?
[17:07] <bluefoxicy> it's also feasible to output a trace to a log and write a parser to process it
[17:07] <bluefoxicy> that's a good question
[17:08] <bluefoxicy> as main() doesn't encapsulate the entire life of the program, and all times add up to 100%, I'd say it counts only the time literally spent in the function body and not in sub-calls
[17:08] <sbeattie> strace is strictly syscalls, ltrace might do it, oprofile might be useful here as well.
[17:08] <jdong> yeah it makes more sense from a "useful output" point of view if it does not double-count time in encapsulated calls
[17:09] <bluefoxicy> well, regardless
[17:09] <bluefoxicy> this is a lot of useless.
[17:23] <cjwatson> robbiew,slangasek: 339898 is actually fixed, evand just forgot to close the bug
[17:23] <cjwatson> I'll close it out
[17:23] <robbiew> cjwatson: ah, ok
[17:23] <robbiew> thnx
[17:30] <davmor2> robbiew: I can confirm it is fixed :)
[17:30] <robbiew> :D
[17:31] <davmor2> robbiew: infact only outstanding obvious bug is bug 358519
[17:32] <robbiew> davmor2: ok, thanks
[17:32] <cjwatson> I'll target that, but I'm not sure we have time to fix it for jaunty
[17:32] <robbiew> agreed
[17:33] <davmor2> cjwatson: weird thing is it was working and now isn't
[17:35] <cjwatson> davmor2: in that case, it might help a bit if you could give a rough estimate of when it last worked
[17:35] <cjwatson> but I'm not working until Tuesday, so it's a bit of a stretch
[17:35] <cjwatson> (nor, I think, is Evan)
[17:36] <davmor2> cjwatson: It didn't appear in beta so after that I think I check on Monday and it was in so maybe the week before
[17:37] <davmor2> I really should learn to use grammar
[17:37] <cjwatson> punctuation too
[17:38] <davmor2> cjwatson: I am dyslexic it's hard enough to spell with out remembering other things :)
[17:38] <cjwatson> hmm, so we're talking somewhere between 26th and 30th March?
[17:38] <cjwatson> if you could put that in the bug that'd be good
[17:38] <cjwatson> davmor2: ah, fair enough :)
[17:38] <davmor2> cjwatson: will do
[17:39]  * cjwatson eyes the enormous changelog for 1.12.0, uploaded on Mon 30th Mar
[17:39] <cjwatson> sigh
[17:39] <cjwatson> could lose a goat in there, no trouble
[17:39] <davmor2> cjwatson: it would of happened before monday as it was on monday's cd
[17:40] <davmor2> ah sorry 30th
[17:40] <cjwatson> davmor2: but there were no changes between 26th and 30th
[17:41] <davmor2> just saw mon and not the 30th
[17:41] <cjwatson> I think 1.12.0 is a good guess for the version that introduced this, as that included a merge of a branch that made reasonably non-trivial changes to the KDE partitioning page
[17:42] <cjwatson> shtylman: ^- don't suppose you could look into this, as it was your branch? see bug 358519
[17:43] <davmor2> cjwatson: can you set a status on the bug so it doesn't get missed,  because currently you can't change the partition size in side by side install.
[17:44] <cjwatson> it's targeted, it won't get forgotten
[17:44] <davmor2> ah cool :)
[17:47] <ion_> All udev’s changelog entry says is “New upstream release.  LP: #358013”. It would be interesting to see that bug report, since it appears to be closed. :-)
[17:48] <jdong> haha magic words of doom :)
[17:53] <davmor2> cjwatson: I'm going to grab a copy of beta just to confirm that it wasn't in then.  I'm pretty certain I would of logged it though. But that will at least mean that you can definitely rule out pre-beta
[18:14] <shtylman> cjwatson: will do
[18:16] <cjwatson> shtylman: thanks, give me a shout if/when you have a branch for us to merge
[18:20] <jcole> didrocks: as you already may know, calendar still doesnt work in evolution-mapi and the Authentication button still crashes evo even after your latest patch...
[18:21] <jcole> didrocks: i compiled the latest openchange, samba4 and evolution-mapi from svn and everything works :)
[18:21] <didrocks> jcole: I tried to contact you
[18:21] <didrocks> jcole: evolution-mapi is the last version, contrary to what you told previously
[18:21] <jcole> didrocks: oh, im sorry, i get busy here at work sometimes
[18:22] <didrocks> I followed upstream who told me to package the last version :)
[18:22] <jcole> didrocks: you have an old libmapi0 in jaunty
[18:23] <didrocks> jcole: yes, comming from openchange
[18:23] <didrocks> not evolution-mapi :)
[18:23] <jcole> didrocks: the libmapi0 in jaunty doesnt work with the calendar
[18:23] <didrocks> jcole: as I said in the bug report, we are waiting for debian upstream packager who is working on the update and then sync
[18:23] <didrocks> jcole: I already know that ^^
[18:24] <jcole> didrocks: oh ok
[18:24] <didrocks> jcole: that's why we wait for openchange ^^
[18:24] <jcole> didrocks: do you think it will be ready before jaunty release?
[18:24] <didrocks> jcole: if it's not packaged Tuesday, can you ping me please ?
[18:24] <jcole> didrocks: you bet :)
[18:25] <didrocks> jcole: Tuesday is the deadline seb128 and I convinced to wait for debian :)
[18:25] <didrocks> (I didn't check today if they have the new version)
[18:26] <jcole> didrocks: remind you, it takes the latest samba4 to compile the latest openchange.. the samba4 currently in jaunty wont work
[18:27] <didrocks> jcole: do you have the version for the 2 packages?
[18:27] <jcole> didrocks: thanks alot for all the hard work on this, its very appreciated
[18:27] <didrocks> it will be quicker for me to check on debian ^^
[18:27] <didrocks> jcole: I know it's a waited feature, try to have it for jaunty :)
[18:27] <didrocks> s/waited/wanted
[18:27]  * jcole looks
[18:29] <jcole> didrocks: for openchange -> http://websvn.openchange.org/filedetails.php?repname=openchange&path=%2Ftrunk%2FChangeLog
[18:29] <jcole> didrocks: yesterday was last update
[18:29] <didrocks> jcole: ok, I just wondered about last official released
[18:30] <jcole> didrocks: i think they are planning to have an official release very soon
[18:30]  * jcole pings the evo devs
[18:31] <didrocks> jcole: openchange and evolution dev are the same people?
[18:31] <davmor2> cjwatson: definitely not happening in beta
[18:32] <jcole> didrocks: the openchange devs hang out in #evolution on irc gnome
[18:33] <didrocks> jcole: ok, and if you downgrade to last samba4 version, it doesn't work. Did you test it?
[18:40] <didrocks> jcole: just give a look there
[18:41] <jcole> didrocks: ill try to downgrade and see what happens
[18:41] <didrocks> jcole: thanks a lot :)
[18:41]  * didrocks hopes that jcole used /usr/local so that it will not be an headake :)
[18:42] <jcole> didrocks: /usr/local/samba
[18:43] <didrocks> jcole: perfect :)
[18:50] <lamont> gah.  how in the hell do I get firefox to STOP stealing focus when it thinks it's a good idea?
[18:51] <ion_> A window manager shouldn’t permit such behavior.
[18:52] <lamont> ion_: yeah, and then there is metacity.
[18:52] <lamont> and compiz
[18:52] <davmor2> lamont: use epiphany
[18:52] <lamont> davmor2: and this will help me how?
[18:53] <davmor2> firefox won't steal anything any more :D
[18:53] <jcole> lamont: compiz has a "Utility" called "Windows Rules" that lets you manage annoyances like that... look in compiz settings manager and scroll to the bottom
[18:55] <lamont> jcole: true.  OTOH, metacity has focus-policy == strict, which I'd really like to migrate into compiz but haven't managed to locate where, in the 10 minutes I've spent researching it over the last year
[18:55] <jcole> lamont: looks like its called "No focus"
[18:56] <lamont> srsly?
[18:56] <lamont> because upstream was completely against == strict... which has been there since I, um, coaxed.  yeah lets use that word, seb128 into adding it for me
[18:57] <jcole> lamont: http://wiki.compiz-fusion.org/WindowMatching#Window_Rules
[18:57] <jcole> lamont: heh, looks like a firefox example there
[18:58] <lamont> huh.  what do you know.  this machine actually does have an nVidia display
[18:58] <lamont> 01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0640 (rev a1)
[18:58] <lamont> though it'd be nicer if it knew what it had
[18:58] <jcole> lamont: System->Administration->Hardware Drivers
[18:59] <jcole> lamont: ubuntu auto installs the nvidia driver :)
[19:01] <lamont> yeah
[19:01] <lamont> but only if you let it
[19:01] <lamont> "no proprietary drivers are in use on this system"
[19:20] <jcole> lamont: i think your modaliases might be out of date
[19:20] <jcole> $ apt-cache show nvidia-180-modaliases | grep -E '^D|^ '
[19:20] <jcole> Description: Modaliases for the NVIDIA binary X.Org driver
[19:20] <jcole>  The modaliases provide a list of pci id's which makes it possible to
[19:20] <jcole>  detect the model of a graphic card.
[19:23] <lamont> W: Unable to locate package nvidia-180-modaliases
[19:23] <lamont> so that'd be a "yes"
[19:24] <lamont> though to be fair, the machine is stuck on hardy for other reasons
[19:25] <jcole> lamont: install envy and get the latest then
[19:27] <jcole> lamont: https://wiki.edubuntu.org/EnvyNG
[19:30] <lamont> jcole: I'm still working on figuring out why I even care if I have the latest restricted driver
[19:30] <lamont> since I'm, you know, not using it.
[19:30] <ion_> keybuk: Since you wrote the udev changelog entry “New upstream release.  LP: #358013”, perhaps you could consider making LP: #358013 open for the curious public (since the bug appears to be fixed). :-)
[19:44] <jdstrand> slangasek: fyi-- uploaded new vm-builder to fix bug #342359 and bug #354849
[20:12] <calc> anyone know what happened to the coreutils info pages?
[20:13] <calc> eg info cut just gives me the manpage that has no information and tells me to use info cut for more information
[20:14] <calc> hmm info coreutils works but not info cut
[20:44]  * calc was just made aware the dictionary issue was much bigger than he thought :\
[20:45] <calc> every dictionary package has to be manually checked and updated if out of date for new OOo (gag)
[20:45]  * calc kicks OOo hard
[20:46] <calc> i thought it was a short list of ~ 5 packages i had already fixed from reading the debian bug report
[20:47] <calc> i guess i know what i will be doing this weekend :\
[21:26] <Milosz> hey people, I am packaging an application that I want to submit and I have a question regarding the control file
[21:26] <Milosz> for libcurl, there exist 2 different -dev packages, one with openssl and one with gnutls
[21:26] <Milosz> how can I specify in the control file that either is fine?
[21:27] <geofft> put a | between them
[21:28] <geofft> but it looks like both of those Provide: libcurl-dev
[21:49] <slangasek> jdstrand: "to give the loopback a devices a chance to settle down" - why is this not a call to udevadm settle?
[21:51] <jdstrand> slangasek: I was not aware of that command
[21:51] <slangasek> ah; I don't have enough context from the diff to know if it's appropriate here, but the comment suggests it might be the Right Thing
[21:52] <ScottK-palm> slangasek: I just read the release team meeting logs. AFAIK, all the Python 2.6 bugs from last week's list are still open.
[21:53] <jdstrand> slangasek: this is a simple workaround the fact that kpartx sometimes dies. it doesn't seem to with the sleep(3), and the extra tries are just to give a sporting chance at it working
[21:53] <jdstrand> slangasek: bottom line, this was a workaround that I was told to upload until soren works out the problem and the correct solution
[21:54] <slangasek> hmm, ok
[21:55] <Keybuk> settle sounds like the right workaround
[21:55] <Keybuk> "wait for /dev to catch up"
[21:55] <ScottK-palm> jdstrand: cemc found a new apparmor issue with clamav 0.95.1. I asked him to get a hold of you. It is probably the long pole in the tent for having 0.95.1 ready to upload.
[21:55] <jdstrand> ScottK-palm: yeah, already talked to him
[21:55] <ScottK-palm> jdstrand: Great. Thanks.
[21:55] <Keybuk> he eventual plan, of course, is just to have these ioctl()s block in the kernel until /dev has caught up
[21:57] <directhex> hm. /me prepares some notes on a topic he expects to hear mentioned at UDS
[21:57]  * ScottK-palm remembers he didn't say he was going yet and goes off to write a mail ...
[22:00] <jdstrand> Keybuk: your saying 'udevadm settle' is the correct thing to do for bug #342359?
[22:00] <jdstrand> Keybuk: this is the relevant errorL:
[22:00] <jdstrand> VMBuilder.exception.VMBuilderException: Process (['kpartx', '-d', '/tmp/vmbuilderID1u60/disk0.img']) returned 1. stdout: , stderr: device-mapper: remove ioctl failed: Device or resource busy
[22:02] <jdstrand> ioctl: LOOP_CLR_FD: Device or resource busy
[22:03] <Keybuk> I can't read the bug
[22:04] <Keybuk> but if you get EBUSY, that sounds like you need a settle
[22:08] <jdstrand> slangasek: honestly I'm not sure what to do wrt the bug. vm-builder is not my code and I don't know what soren wants to do long-term (ie, maybe he wants to run it on systems without udev... I have no idea)
[22:10] <slangasek> there are no Ubuntu systems without udevz
[22:10] <jdstrand> of course, but python-vm-builder is an upstream
[22:11] <jdstrand> uhhh, vm-builder
[22:11] <slangasek> fine, but the package should still be properly integrated in Ubuntu :)
[22:11] <jdstrand> I am not arguing with that :)
[22:12] <slangasek> anyway, the diff here is, I think, wrong, but it mostly addresses the symptom and shouldn't cause regressions (aside from slowing down the process), so I'll accept it
[22:13] <slangasek> please follow up with soren about doing this with udevadm settle in the future, though
[22:13] <jdstrand> ok
[22:14] <jdstrand> btw, that is 3 seconds on an (at least) 5 minute long command
[22:14] <jdstrand> but I'll follow up with him
[22:37] <slangasek> ogra: if/when you're around, I think you should go ahead with an upload for bug #358762
[23:04] <Keybuk> DRAIIIIEEEEEE
[23:06] <jdstrand> ScottK: fyi the klamav apparmor fix is in bug #359301
[23:06] <jdstrand> ScottK: due t the pending 0.95.1 upload, I have assigned it to you
[23:09] <aaronator_>  ./fwupdate.ini: line 1: syntax error near unexpected token `newline'
[23:09] <aaronator_>  ./fwupdate.ini: line 1: `<?xml version="1.0" encoding="ISO-8859-1"?>'
[23:09] <aaronator_> what is the error?
[23:24] <slangasek> aaronator_: this isn't a support channel; please see #ubuntu
[23:25] <aaronator_> thanks
[23:46] <dcomxx> hi! is it possible to somehow add the current date to the ping result and also print the errors on timeouts or not reachables to a different text file ?
[23:50] <savvas> dcomxx: date; ping www.example.com | grep -i 'string to match here'
[23:51] <savvas> dcomxx: but you might want to ask that or future questions at #ubuntu :)
[23:53] <dcomxx> what is string to match ? the error ?
[23:54] <dcomxx> and i need it to print the date for every ping not only once
[23:54] <dcomxx> or only for the errors .. so that i know when the error happened
[23:55] <dcomxx> oh yea .. grep .. but how i know what error it will be ...
[23:58] <dcomxx> can i write like this -> ping ip | grep 'error msg' | date > file.txt
[23:58] <dcomxx> ?