[13:44] <djszapi> jodh: ping
[13:44] <jodh> djszapi: hello
[13:45] <djszapi> jodh: I am not getting my upstart job logged
[13:45] <djszapi> there is certainly issues with it and I have used console log
[13:45] <djszapi> but there is no /var/log/upstart/foobar.log entry.
[13:46] <jodh> does the directory /var/log/upstart/ exist?
[13:46] <djszapi> I do not see anything related: http://paste.kde.org/459902/ this is my upstart job: http://paste.kde.org/459908/
[13:46] <djszapi> nope
[13:46] <djszapi> it does not exist
[13:46] <djszapi> on this pandaboard
[13:46] <djszapi> upstart 1.3-0ubuntu12~linaro2
[13:47] <jodh> djszapi: http://upstart.ubuntu.com/cookbook/#stanzas-by-category
[13:47] <jodh> djszapi: console log didn't get introduced until 1.4.
[13:48] <djszapi> by default or altogether ?
[13:48] <jodh> djszapi: if you run "init-checkconf foo.conf" you should get a msg about invalid stanza as "console log" won't be understood.
[13:48] <jodh> djszapi: the feature was added in Upstart 1.4 and you are running Upstart 1.3
[13:49] <djszapi> init-checkconf cannot be run as root
[13:49] <djszapi> and I am not supposed to have another user for this.
[13:49] <djszapi> at any rate, I trust you.
[13:50] <djszapi> jodh: shall I use console output ?
[13:50] <djszapi> and 2>&1 ?
[13:51] <jodh> djszapi: I suggest you read http://upstart.ubuntu.com/cookbook/#debugging
[13:51] <jodh> djszapi: it's all in there
[13:52] <jodh> djszapi: correct - init-checkconf runs as a normal user.
[13:52] <djszapi> jodh: what is wrong about this: http://upstart.ubuntu.com/cookbook/#console-output
[13:52] <jodh> djszapi: nothing - there are many options. It's your decision :)
[13:52] <djszapi> jodh: what do you recommend ?
[13:52] <djszapi> there is some operational issues with my binary
[13:52] <djszapi> it works if I run manually.
[13:52] <djszapi> but it does not function if it is run by upstart
[13:53] <djszapi> the binary is running and all that jazz, but no proper effect on the functionality.
[13:53] <djszapi> it opens a serial port, and begins to listen to that
[13:53] <jodh> djszapi: I'd recommend reading http://upstart.ubuntu.com/cookbook/#debugging then.
[13:53] <djszapi> and if there is a data, it parses.
[13:53] <djszapi> and act accordingly, that is all. What I now see, it does not act as expected.
[13:53] <djszapi> so needs to be debugged.
[13:54] <jodh> yes - see also http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
[13:54] <jodh> which might be the answer in your case. You'll just have to try it.
[13:54] <djszapi> that is a complete no go
[13:54] <djszapi> I would like to separate the logging out for my stuff
[13:54] <djszapi> I would not like to grep in a bunch of stuff
[13:56] <djszapi> and that is what console output is for, afterwards.
[13:56] <jodh> I think you have misunderstood - the 'grep' is an example in the section above. *You* don't need to grep, you need to test your script with '/bin/sh -e'.
[13:57] <djszapi> I do not understand
[13:58] <djszapi> Please note that I do not use script
[13:58] <djszapi> and there is no "failing" either.
[13:58] <djszapi> what I would actually like to get, is a 2>&1 like operation, and console output seems to be designed for that.
[13:59] <djszapi> as in: exec /usr/bin/foobar-commandline receive > /var/log/foobar.log 2>&1
[14:00] <jodh> djszapi: you can do exactly that if you want to.
[14:01] <djszapi> what happend with Scott ?
[14:01] <djszapi> one or two years ago I had the discussions with him.
[14:01] <djszapi> he stepped down as the upstart maintainer ?
[14:04] <jodh> yes - he is now working at Google.
[14:04] <djszapi> I know that, but I did not know he stepped down from the upstart maintenance.
[14:06] <djszapi> interesting, after the launch: stop foobar; start foobar and the "foobar" binary works just fine...
[14:06] <djszapi> what is the difference ?
[14:07] <djszapi> the serialport is opened by that process after the launch, so I do not really understand.
[14:08] <djszapi> jodh: is the serialport available for writing for such a job ?
[14:23] <djszapi> jodh: the modem is not set up on the serial port :(
[14:23] <djszapi> while the upstart job is running, just later.
[14:23] <djszapi> how can that be ?
[14:24] <djszapi> since the modem does not respond to the commands that time I send out.
[14:24] <djszapi> so I guess the modem is not set up, but why ?
[14:24] <djszapi> I had the impression "start on runlevel [23]" should be just fine
[14:35] <djszapi> jodh: what should trigger the start of my job instead of the initlevel thingie ?
[14:42] <jodh> djszapi: you should probably add 'and X-device-added a=b c=d' for the modem device. See http://upstart.ubuntu.com/cookbook/#upstart-udev-bridge, upstart-events(7) and upstart-udev-bridge(8).
[14:46] <djszapi> jodh: I have honestly no ideas about the subsystem :/
[14:46] <jodh> djszapi: what device does your app open? /dev/ttyS0?
[14:47] <djszapi> /dev/ttyUSB0
[14:47] <djszapi> PL2303 (usb-serial converter)
[14:48] <djszapi> jodh: http://paste.kde.org/459968/
[14:48] <djszapi> perhaps usbdev ?
[14:49] <jodh> so, have your job 'start on tty-device-added DEVPATH=*ttyUSB0'
[14:49] <djszapi> E: SUBSYSTEM=tty
[14:49] <djszapi>  udevadm info --export-db | grep -B 2 -A 2 /dev/ttyUSB0
[14:49] <djszapi> from this output
[14:51] <djszapi> this one then ? start on (tty-device-added)
[14:51] <djszapi> stop on (tty-device-removed)
[14:51] <djszapi> hmm, the documentation does not mention the DEVPATH
[14:52] <djszapi> just inside the log, but not for the "start/stop" lines.
[14:52] <jodh> I've given you the answer above. I'm guessing you either don't have your usb device plugged in or you didn't run udevadm as root?
[14:53] <djszapi> well, the documentation does not mention any DEVPATH examples.
[14:53] <djszapi> the documentation only speaks about the log wrt those.
[14:53] <jodh> ?
[14:54] <djszapi> show me the documentation example for the DEVPATH usage.
[14:55] <djszapi> these are the examples: start on (graphics-device-added or drm-device-added)
[14:55] <djszapi> start on (graphics-device-added or drm-device-added)
[14:55] <djszapi> 1) Both contain brakcets
[14:56] <djszapi> brackets*
[14:56] <djszapi> 2) None of the presents the usage of DEVPATH
[14:57] <djszapi> jodh: did not help
[14:58] <jodh> djszapi: what did not help? Please be specific.
[14:59] <djszapi> jodh: http://paste.kde.org/459974/
[14:59] <djszapi> what I told above
[14:59] <djszapi> same symptom
[14:59] <djszapi> the modem was not able to reply to the message sent out while running the relevant binary from the upstart job.
[15:01] <jodh> djszapi: I suggest you (1) comment out the 'stop on' and make the job 'start onrunlevel [23] and  tty-device-added DEVPATH=*ttyUSB0'.
[15:02] <jodh> djszapi: also, comment out respawn.
[15:02] <djszapi>  init-checkconf /etc/init/piruag.conf
[15:02] <djszapi> ERROR: failed to ask Upstart to check conf file
[15:02] <djszapi> respawm is very important
[15:05] <jodh> djszapi: do this before running init-checkconf as presumably you're running on a console: eval `dbus-launch --auto-syntax`
[15:05] <djszapi> jodh: I am now having only two lines: 1) start onrunlevel [23] and  tty-device-added DEVPATH=*ttyUSB0 2) exec /usr/bin/foobar-commandline receive
[15:06] <jodh> djszapi: ...?
[15:06] <djszapi> File /etc/init/foobar.conf: syntax ok
[15:06] <djszapi> jodh: what is not clear ?
[15:07] <jodh> djszapi: so what happens now? does the job work with the 2 lines or not?
[15:08] <djszapi> testing
[15:09] <djszapi> jodh: I think the point is not ttyUSB0
[15:09] <djszapi> jodh: IMO, the point is that this specific modem is set up at that time.
[15:09] <djszapi> if they are the same, then ok.
[15:11] <djszapi> jodh: that way, it does not even run after the bootup
[15:11] <djszapi> probably no space between on and runlevel
[15:11] <djszapi> and I have just copied and pasted your line. :-)
[15:17] <djszapi> jodh: that line actually broke the initscripts
[15:17] <djszapi> even ssh does not work from outside anymore :(
[15:18] <djszapi> jodh: get it back, sorry but no ... my binary does not even run anymore with that "start on runlevel..." etc line
[15:19] <djszapi> are you sure brackets are not needed or other quirk ?
[15:22] <jodh> djszapi: init-checkconf will tell you if the file is valid.
[15:23] <djszapi> jodh: at any rate, the binary is not even started this way
[15:23] <djszapi> any ideas ?
[15:25] <djszapi> too bad upstart is this hard to use :/
[15:34] <jodh> if your app isn't setting the modem, sounds like you need to find out what is. If it is being configured by an Upstart job, you can make your job 'start on stopped <thing>' since at that stage the modem will presumably be configured. If it's being done by a sysv script, then 'start on stopped rc'.
[15:35] <djszapi> I have no clue what you are talking about.
[15:36] <djszapi> my application does configure the modem, but it should obviously available for commands. As for me, upstart seems to be either broken or quite undocumented.
[15:38] <jodh> djszapi: it is neither.
[15:38] <djszapi> well, it does not work
[15:38] <djszapi> and I do not find in the documentation either how it is supposed to work either.
[15:39] <djszapi> as for me, it is time consuming either way as a "customer".
[15:40] <djszapi> script echo "`env`" > /dev/.initramfs/job-A.log
[15:40] <djszapi> end script
[15:40] <djszapi> this logged nothing, so even this part of the documentation is hilariously broken
[15:41] <jodh> djszapi: incorrect - that tells you the either you have a corrupt .conf file (your paste is incorrect in that 'echo' should be on the line below), or your job never started.
[15:42] <jodh> djszapi: have you tried "start <job>" on a booted system maybe? do you get a log file then?
[15:44] <djszapi> no log, no
[15:44] <djszapi> even after start stuff
[15:45] <djszapi> jodh: ^
[15:45] <djszapi> start on (runlevel [23] and tty-device-added DEVPATH=*ttyUSB0)
[15:45] <djszapi> script echo "`env`" > /dev/.initramfs/job-A.log
[15:45] <djszapi> end script
[15:45] <djszapi> exec /usr/bin/...
[15:47] <jodh> djszapi: as stated above, that is incorrect syntax: the first 'script' should be on a line on it's own, as shown in the cookbook and as documented in init(5).
[15:47] <djszapi> no
[15:47] <djszapi> documentation shows this: start on (graphics-device-added or drm-device-added)
[15:47] <djszapi> script echo "`env`" > /dev/.initramfs/job-A.log
[15:47] <djszapi> end script
[15:47] <djszapi> have you actually checked the documentation ?
[15:48] <djszapi> also: init-checkconf /etc/init/piruag.conf
[15:48] <djszapi> File /etc/init/piruag.conf: syntax ok
[15:48] <djszapi> s/piruag/foobar/
[15:50] <jodh> djszapi: what you have pasted above is therefore *not* what is in piruag.conf as it is invalid. the cookbook is correct. Maybe your web-browser is mis-rendering it. It views perfectly for me in ff and chromium.
[15:50] <djszapi> huh ?
[15:51] <djszapi> your irc client is wrong then
[15:51] <djszapi> since it was a simple copy/paste
[15:51] <djszapi> please do not argue about useless things
[15:51] <djszapi> let us just nicely proceed
[15:51] <djszapi> I would not like to spend yet another few hours with upstart to run a simply binary lol
[15:51] <djszapi> once tty is set up properly.
[15:52] <djszapi> s/simply/simple/
[15:52] <djszapi> I do not understand why this hard to use an initiscript.
[15:53] <djszapi> this is a perfectly valid syntax made according to the documentation (TM): http://paste.kde.org/459992/
[15:58] <jodh> djszapi: right - your problem is that you've specified both a 'script' section and an 'exec'. That's not valid, or rather the last valid entry will be selected (the exec), hence you won't get a log.
[15:58] <djszapi> init check returns /valid/
[15:58] <djszapi> fix the check.
[15:58] <jodh> djszapi: put the call to /usr/bin/foobar-commandline at the end of the script section and comment out the exec section.
[15:59] <jodh> djszapi: it's valid, but not what you want.
[15:59] <djszapi> what is the point of upstart if it is this hard to run a binary once the serial port is set up  ?
[16:00] <jodh> it isn't hard - you just need to read the documentation. If the documentation is unclear or needs more examples, please raise bugs so we can rectify the situation.
[16:00] <djszapi> well, you did not even provide any working solution so far
[16:00] <djszapi> so it seems to be even hard for you.
[16:01] <djszapi> so what can I say as a newcomer...
[16:01] <jodh> djszapi: I don't have a modem and I didn't write your application :)
[16:01] <djszapi> it has nothing to do with my application
[16:01] <djszapi> it expects a modem set up
[16:01] <djszapi> which is obviously a sane thing if you wanna configure it ....
[16:02] <djszapi> http://paste.kde.org/460028/ -> this is the env
[16:02] <djszapi> quite poor from what I can say.
[16:03] <djszapi> anyway, I have no clues...
[16:03] <djszapi> any help is welcome...
[16:03] <djszapi> otherwise I need to admit it is incredibly hard from upstart, and not worth spending the time with.
[16:04] <jodh> djszapi: so your application runs correctly from the command-line on a booted system?
[16:04] <djszapi> like I said in the very beginnig, of course...
[16:04] <djszapi> even from upstart ...
[16:04] <djszapi> not during the boot, but I said it many times really :)
[16:04] <djszapi> so clearly, the modem is not up and running
[16:05] <djszapi> and still, the last line I got for the "start on ..." is broken
[16:05] <djszapi> the binary is not even executed anymore
[16:07] <djszapi> jodh: ^
[16:18] <SpamapS> djszapi: what release of Ubuntu are you on?
[16:19] <djszapi> upstart 1.13
[16:19] <djszapi> (like I said in the beginning)
[16:19] <djszapi> why should the ubuntu version matter ?
[16:19] <SpamapS> djszapi: I wasn't here in the beginning. Please try to be a bit more polite.
[16:20] <SpamapS> djszapi: There is no such thing as 1.13
[16:20] <djszapi> weird, I see you were online.
[16:20] <djszapi> of course there is.
[16:20] <SpamapS> 1.5 is the newest release of upstart
[16:20] <djszapi> 1.3-0ubuntu12~linaro2
[16:20] <djszapi> yes, 1.3
[16:20] <SpamapS> Ok, 1.3 not 1.13 :)
[16:21] <djszapi> it drives me crazy :/
[16:21] <SpamapS> djszapi: so if you add this to your exec line, you can get the error messages from your command logged to syslog:
[16:21] <SpamapS> 2>&1 | logger -t pickatag
[16:21] <djszapi> that is not gonna work without console log IIRC
[16:21] <djszapi> console output
[16:21] <SpamapS> djszapi: you may also want to increase the log priority to 'info' so that you can see upstart events being processed. 'initctl log-priority info'
[16:22] <SpamapS> djszapi: you don't have syslogging?
[16:22] <SpamapS> djszapi: ok, change that to this then:
[16:22] <djszapi> I do have syslog
[16:22] <djszapi> but I would rather prefer a dedicated log just for this.
[16:22] <SpamapS> >> /run/mylog.log 2> /run/myerr.log
[16:23] <djszapi> -> /run ?
[16:23] <djszapi> you mean /var/log/ ?
[16:23] <SpamapS> choose whatever you want
[16:23] <djszapi> -> /run does not really fit the lfsh
[16:24] <SpamapS> ok, you get the idea.
[16:25] <djszapi> http://paste.kde.org/460052/
[16:27] <SpamapS> djszapi: yeah that should work
[16:27] <djszapi> ok, it does not
[16:27] <djszapi> like I said before
[16:28] <djszapi> especially because console output is not there.
[16:28] <djszapi> and even if I was putting there, I would have the same information, I already do have.
[16:28] <djszapi> the modem does not respond.
[16:28] <djszapi> most likely because it is not set up
[16:28] <djszapi> so I do not understand what addition we would gain in here.
[16:28] <djszapi> Any ideas pushing the topic forward ?
[16:29] <djszapi> what I need is not the logging of my application, I already know where it fails.
[16:29] <djszapi> I would need to know what to trigger the application for.
[16:29] <djszapi> the documentation does not just work, period.
[16:29] <djszapi> nor the aforementioned ideas.
[16:30] <djszapi> I do not understand why one needs to spend many hours to run a binary once the serial port and the modem in there are ready. :/
[16:30] <djszapi> it should be this simple: I would like to run my daemon once the system is fully set up: ok, use this.
[16:30] <djszapi> should be just one option.
[16:32] <SpamapS> djszapi: where does it fail then?
[16:32] <djszapi> huh ?
[16:32] <SpamapS> djszapi: is there hardware missing?
[16:32] <djszapi> have you actually read what I wrote ? :-)
[16:32] <SpamapS> djszapi: sounds like the device added event is emitted by udev too soon.
[16:33] <djszapi> sorry, but really getting frustrated. I would not like to spend /enormous/ amount of time to run a binary once the system is fully set up.
[16:33] <SpamapS> djszapi: I'm done. Good luck with upstart. You will get no help until you can be nice.
[16:33] <djszapi> you have not clearly read what I wrote.
[16:33] <djszapi> I wrote that the modem does not respond back then while trying to configure it.
[16:33] <SpamapS> Ok, I typed that while you said sorry.
[16:34] <SpamapS> djszapi: so that tells me that you need an event for when the modem is ready, not when the serial port is added
[16:34] <djszapi> I would need a common event which tells the system is up!
[16:34] <djszapi> now you can run anything.
[16:34] <djszapi> everything is set up.
[16:34] <SpamapS> "system is up" is hard to define.
[16:34] <djszapi> I do not care about low-level stuff, like a certain specific device is run
[16:34] <SpamapS> mobile systems have resources that come and go.
[16:35] <djszapi> with the certain specific vendor and so on ids.
[16:35] <djszapi> this is quite low-level.
[16:35] <djszapi> super low-level
[16:35] <djszapi> "system is set up" -> done
[16:35] <djszapi> run the binary
[16:35] <djszapi> what is so hard about it ?
[16:35] <SpamapS> runlevel 2 should be that the system is ready to run anything statically onfigurable
[16:35] <SpamapS> configurable rather
[16:36] <djszapi> like I said, runlevel 2 did not work.
[16:36] <djszapi> getting no replies from the modem
[16:36] <SpamapS> Right, so there is something not-static that you are dependent on.
[16:36] <djszapi> meanwhile if I make a stop myjob; start myjob, I do get replies
[16:36] <djszapi> either an "OK" or an "ERROR".
[16:36] <SpamapS> djszapi: perhaps try 'stopped udevtrigger and runlevel [23]'
[16:36] <djszapi> it is quite static, trust me :)
[16:37] <SpamapS> djszapi: udevtrigger will flush all events that the kernel knows about at system boot.
[16:37] <djszapi> I am not sure udevtrigger stopping check is a good point for that.
[16:37] <djszapi> Like I wrote: "start on (runlevel [23] and tty-device-added DEVPATH=*ttyUSB0)" does not even run the binary anymore
[16:37] <djszapi> so it is already a broken check.
[16:38] <djszapi> extending a broken check... I do not expect anything working.
[16:38] <djszapi> start on (stopped udevtrigger and runlevel [23] and tty-device-added DEVPATH=*ttyUSB0)
[16:38] <djszapi> I do not expect it to work either.
[16:39] <SpamapS> djszapi: it will delay the start a bit... perhaps until the modem is ready
[16:40] <SpamapS> djszapi: Otherwise, the modem needs to be polled
[16:40] <djszapi> no way
[16:40] <djszapi> if I stop and start, it runs fine
[16:40] <djszapi> without doing that, it does not appear.
[16:40] <djszapi> so no, sorry.
[16:41] <SpamapS> djszapi: let me put it another way. What actual event would you expect to signify that the modem is ready?
[16:41] <djszapi> modem is continously ready
[16:41] <djszapi> since it gets power supply, and not turned off.
[16:41] <djszapi> so I would expect once /dev/ttyUSB0 is available, it should work oob
[16:43] <SpamapS> djszapi: so perhaps there's a bug in the code that emits the event about ttyUSB0 being ready when it isn't
[16:43] <djszapi> I do not understand why I am having these troubles if it is super simple by using SystemV.
[16:45] <SpamapS> djszapi: because systemv takes 5x longer to start
[16:46] <SpamapS> djszapi: its still a race, its just that one car is WAY slower than the other :)
[16:46] <djszapi> I do not feel it funny, sorry for that...
[16:48] <SpamapS> djszapi: you can try putting yourself way after rc runs.. 'start on stopped rc RUNLEVEL=[23]'
[16:48] <SpamapS> djszapi: but thats really just slowing down the race a bit. Not solving the issue.
[16:48] <djszapi> huh ?
[16:49] <SpamapS> djszapi: perhaps also try 'respawn' which will retry a few times
[16:49] <SpamapS> djszapi: you need an event that is reliable. Your ttyUSB0 event is clearly not reliable. :-P
[16:49] <djszapi> jodh said to remove the respawn...
[16:49] <djszapi> you have nothing to prove that saying.
[16:49] <djszapi> really.
[16:49] <SpamapS> I don't, because you won't show me the output of your program
[16:50] <djszapi> ubuntu should drop upstart to the trash :)
[16:51] <djszapi> it is unusable even for simple cases like this.
[16:51] <SpamapS> djszapi: this has nothign to do with upstart.
[16:51] <djszapi> ofc it does.
[16:51] <djszapi> since it works with other systems like aforementioned.
[16:51] <SpamapS> djszapi: upstart is operating properly... as I said, you just don't have an event you can rely on.
[16:51] <djszapi> that makes no sense, sorry.
[16:51] <djszapi> stop/start works fine!
[16:52] <SpamapS> djszapi: so if I tune up my engine and get my car to go 220mph, but that makes the tires melt.. its the engine's fault?
[16:52] <djszapi> huh ?
[16:52] <SpamapS> djszapi: upstart is just the point where you're interfacing with the plumbing of the entire system
[16:52] <SpamapS> djszapi: stop/start works fine because the device has had enough time to initialize
[16:52] <djszapi> I joined this channel more than three hours ago
[16:53] <djszapi> and still not solved
[16:53] <djszapi> like...wtf ?
[16:53] <SpamapS> djszapi: well you've been really difficult. I'm trying to help.
[16:53] <SpamapS> djszapi: lets back up, because I want to make sure I'm as helpful as possible.
[16:53] <djszapi> I have not realized I would have any solution for the issue, really.
[16:54] <SpamapS> djszapi: you have this job which uses 'start on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0  .. right?
[16:54] <djszapi> to run a daemon after the system is fully up takes more than three hours :(
[16:55] <SpamapS> djszapi: and you refuse to try adding 'stopped udevtrigger' right?
[16:55] <djszapi> not right
[16:55] <SpamapS> djszapi: and upstart tries to start the program, but the program fails with some kind of error about the serial port not being ready, right?
[16:55] <djszapi> no, the program does not fail
[16:55] <SpamapS> ahh
[16:55] <SpamapS> <-- misunderstood
[16:56] <SpamapS> djszapi: ok, so the program never starts?
[16:56] <djszapi> and, no, I am now trying this as recommended: start on stopped rc RUNLEVEL=[23]
[16:56] <djszapi> it does start
[16:56] <SpamapS> djszapi: and its in 'stop/waiting' after the system fully boots?
[16:57]  * djszapi ponders how many hours have to wasted yet for upstart :(
[16:57] <djszapi> be*
[16:57] <djszapi> SpamapS: again: the binary runs with start on stopped rc RUNLEVEL=[23], but the modem does not respond with either "OK" or "ERROR" like after running stop/start
[16:58] <djszapi> tart on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0 and stopped udevtrigger -> did not work
[16:58] <djszapi> the daemon did not even run
[16:59] <SpamapS> djszapi: is it possible that the modem doesn't initialize itself until the first time you run the program?
[16:59] <djszapi> huh ?
[16:59] <djszapi> like I said, the modem is fully powered
[17:00] <djszapi> it is configured
[17:00] <djszapi> it is working
[17:00] <djszapi> the running ubuntu stuf makes it not responding
[17:00] <SpamapS> djszapi: what I'm saying is, could it be that the modem won't respond to the first program that talks to it.
[17:00] <djszapi> during the bootup for probably some false bootup sequence.
[17:00] <djszapi> I do not see how that would be possible really.
[17:01] <djszapi> if I do not try to run the program, but I run after the bootup
[17:01] <djszapi> everything is alright.
[17:01] <SpamapS> djszapi: ok so it still is just a race.. and we need to find the event that means "the modem is active"
[17:01] <djszapi> again, again and again: I need to run my program once the system is set up !
[17:01] <SpamapS> I would have expected tty-device-added to be that
[17:01] <djszapi> darn upstart, it is not possible to do such a basic thing...
[17:01] <SpamapS> djszapi: systems are mobile
[17:01] <SpamapS> djszapi: tty devices come and go
[17:02] <SpamapS> djszapi: 'stopped udevtrigger' is "when all the hardware that is plugged in at boot time is initialized"
[17:02] <djszapi> well
[17:02] <SpamapS> djszapi: perhaps take out the tty-device-added part
[17:02] <djszapi> 19:58 < djszapi> tart on runlevel [23] and tty-device-added DEVPATH=*ttyUSB0 and stopped udevtrigger -> did not work
[17:02] <SpamapS> djszapi: so     start on runlevel [23] and stopped udevtrigger
[17:03] <djszapi> I am not sure it is a good thing to base a system on a such a brittle tool.
[17:04] <SpamapS> djszapi: the tool is actually quite strong. the events are just not easy to understand, because parallelism is hard.
[17:04] <djszapi> I do not care about the events
[17:04] <djszapi> have you still not realized ? :)
[17:04] <djszapi> I would like to run my binary once everything is set up!
[17:05] <djszapi> I do not care about premature optimization.
[17:05] <djszapi> which causes -3-4 hours from more people's life.
[17:05] <SpamapS> djszapi: I actually fully understand that. I want there to be more clear, simpler events like 'boot-hardware-initialized'. I created the event 'static-network-up' for this reason.
[17:06] <SpamapS> djszapi: I also think that runlevel 2 should probably be delayed until after 'stopped udevtrigger' .. but people want the boot to proceed without waiting for all the hardware
[17:06] <djszapi> I am not the people.
[17:07] <SpamapS> djszapi: then you must understand the events. :)
[17:07] <djszapi> no
[17:07] <djszapi> Again, I would like to run a binary once everything is set up!
[17:08] <SpamapS> djszapi: that is runlevel [23] and stopped udevtrigger
[17:08] <djszapi> did not work
[17:08] <djszapi> modem does not respond.
[17:08] <SpamapS> hmmm... one thing..
[17:08] <SpamapS> I notice udevtrigger uses post-stop to run 'udevadm settle'
[17:09] <SpamapS> so perhaps the events will still be going after that event
[17:09] <SpamapS> *argh*
[17:09] <djszapi> Upstart, to the trash!
[17:10] <SpamapS> djszapi: I have to go soon.. but I think this is worth a bug. It should be possible to ask for a job which waits for udevadm settle to finish.
[17:10] <SpamapS> djszapi: let me make this clear. This has nothing to do with upstart. It is just a deficiency in the system plumbing available on top of upstart in Ubuntu.
[17:10] <SpamapS> djszapi: upstart is doing everything right. Ubuntu has just failed to expose the events in a way that makes sense.
[17:11] <SpamapS> I am surprised that your tty-device-added doesn't work
[17:11] <djszapi> is there *ANY* workaround ?
[17:11] <djszapi> put a sleep into the script ?
[17:12] <djszapi> but that is blocking.
[17:12] <djszapi> unless the kernel events are async.
[17:12] <djszapi> which is probably the case.
[17:12] <slangasek> if the goal is to delay the startup of the job, sure, you can use a sleep
[17:12] <djszapi> in any case, sleep would be blocking.
[17:12] <slangasek> what do you mean by "async"?
[17:12] <SpamapS> djszapi: a sleep might work. You can also try putting 'udevadm settle' right before it running the program (or in a pre-start)
[17:12] <SpamapS> djszapi: sleep would be blocking, exactly, thats why it might work ;)
[17:13] <djszapi> can you tell me the line exactly?
[17:13] <slangasek> pre-start exec sleep 10?
[17:13] <djszapi> ohh it is just sleep 10
[17:13] <djszapi> pre-start ?
[17:13] <djszapi> why is that ?
[17:13] <SpamapS> slangasek: any ideas on an event for 'when all the hardware currently plugged in is available'
[17:13] <slangasek> djszapi: or you can put it at the top of the 'script'
[17:13] <SpamapS> djszapi: so that when you respawn you don't run it again
[17:14] <slangasek> SpamapS: I was thinking 'stopped udevtrigger' should do this, but I have the same uncertainty you do about whether post-stop scripts are required to complete before starting jobs that are 'stop on'
[17:16] <djszapi> http://paste.kde.org/ -> slt ?
[17:16] <slangasek> I think you missed the last part of that link
[17:17] <djszapi> http://paste.kde.org/460106/
[17:17] <slangasek> I don't think you need both the udevadm settle *and* the sleep... but certainly that should be enough
[17:18] <djszapi> sorry, bruteforce for everything...just work...
[17:19] <slangasek> I would expect that to work
[17:20] <slangasek> btw, the 'console output' is irrelevant there, I think you've misunderstood what that does: that tells where to send stdout/stderr from the job script, but you're redirecting all of that to files anyway
[17:20] <djszapi> so no harm either...
[17:21] <slangasek> yes
[17:22] <djszapi> I guess "udevadm settle" is better to have than random sleep amount ?
[17:22] <slangasek> SpamapS: so if 'on stopped udevtrigger' doesn't catch the udevadm settle, we should probably split the trigger and settle out into separate jobs for dependency purposes
[17:22] <slangasek> djszapi: yes
[17:22] <slangasek> did it work for you when using both?
[17:22] <djszapi> slangasek: yes
[17:22] <djszapi> now cleaning up
[17:23] <SpamapS> slangasek: indeed, I was thinking we might also just emit another event after the udevadmsettle.. 'stopped udevadm' or 'stopped udevtrigger' is very hard to read. :-P
[17:23] <SpamapS> something like boot-devices-ready ?
[17:23] <djszapi> http://paste.kde.org/460112/ -> Anything to improve on this ?
[17:24] <djszapi> can I use exec + pre-script at all ?
[17:24] <djszapi> or just script + pre-script ?
[17:24] <slangasek> djszapi: ok.  then I also suggest dropping the 'runlevel [23] and' from the start condition
[17:24] <slangasek> because a) it should be redundant, and b) it can cause the job to deadlock in certain corner cases involving runlevel changes, so it's best to not have it
[17:24] <slangasek> SpamapS: 'coldplug-finished'?
[17:25] <slangasek> or 'udev-coldplug-finished'
[17:25] <slangasek> which is more explicit about what you get than 'boot-devices'
[17:25] <SpamapS> slangasek: still feels very "I know about plumbing"
[17:25] <djszapi> slangasek: could you please my worry about ?
[17:25] <slangasek> djszapi: yes, 'pre-start exec udevadm settle' would be fine there
[17:25] <djszapi> comment on*
[17:25] <slangasek> and would be more idiomatic
[17:25] <djszapi> that was not my question...
[17:25]  * SpamapS suspends to save battery
[17:26] <djszapi> my question was related to the exec mybinary...
[17:26] <djszapi> + pre-script...
[17:26] <slangasek> djszapi: ah, right - yes, that's also allowed
[17:27] <slangasek> in general, it's preferred to use 'exec' instead of 'script' if you only have one command because it spares you a needless shell execution
[17:27] <slangasek> but you can intermix them freely
[17:27] <djszapi> I have been said above I cannot.
[17:28] <slangasek> must have been a misunderstanding; you can
[17:28] <slangasek> and SpamapS and jodh certainly both know that :)
[17:28] <slangasek> SpamapS: I can see the point that a more generic name would be appropriate... particularly since that means we can adjust the underlying implementation as needed to fulfill that interface contract
[17:31] <djszapi> slangasek: did not work
[17:31] <slangasek> djszapi: pastebin the one that didn't work, please?
[17:31] <djszapi> see above
[17:31] <djszapi> runlevel [23] -> this was removed from that
[17:31] <slangasek> ok
[17:32] <slangasek> well, re-add it then if you must :/  that's not ideal, but it's more important that it work
[17:32] <djszapi> I am not saying that is the culsprit
[17:32] <slangasek> btw, what does your disk partitioning scheme look like?
[17:32] <djszapi> the original working got a decent cleanup
[17:32] <djszapi> my worry is that if it works only with hard coded sleep :(
[17:32] <djszapi> that would be a pity
[17:33] <djszapi> so that would defeat the robust system purpose.
[17:33] <slangasek> true, it would; and we've tried hard to avoid using sleep in our startup scripts because sleep only hides a race, it never fixes it
[17:34] <djszapi> we can agree upon this.
[17:37] <slangasek> this is exactly why you'll find resistance to the idea that SysV is doing anything right - it's not, it's just much, much slower ;)
[17:38] <djszapi> slangasek: only sleep helps
[17:38] <djszapi> I have put back everything except sleep
[17:39] <slangasek> clever
[17:39] <slangasek> that means there's a kernel bug
[17:40] <slangasek> because calling 'udevadm settle' following 'stopped udevtrigger' guarantees that the kernel's queue of coldplug events is empty and udev has processed them all
[17:40] <slangasek> actually, wait, it doesn't guarantee there's a kernel bug either, because USB in particular can have devices show up on the bus for the first time *after* coldplugging
[17:42] <slangasek> djszapi: I would suggest editing /etc/init/udevmonitor.conf to comment out the 'stop' rule, then reboot, then call 'service udevmonitor stop' by hand after boot
[17:42] <slangasek> then post /var/log/udev somewhere
[17:42] <djszapi> I do not have time for that, sorry.
[17:42] <slangasek> ... unless you prefer to stick with the 'sleep' option
[17:42] <slangasek> ok
[17:42] <djszapi> hacking the base system upside down is even worse than any sleep
[17:43] <slangasek> fundamentally, this scores one of the weaknesses of relying on any sort of a static event to tell you the devices are all up... because upstart can't actually be sure they are, because the kernel and udev aren't sure that they are
[17:43] <slangasek> s/scores/underscores/
[17:43] <djszapi> tell me a better way
[17:43] <djszapi> which is working, really.
[17:43] <slangasek> which is why the tty-device-added would have been the better solution, but you ran into problems there
[17:43] <djszapi> that is broken
[17:43] <slangasek> and to understand why it wasn't work, I'd need to see a udev log
[17:44] <djszapi> give me a foobar.conf
[17:44] <djszapi> and command set
[17:44] <djszapi> I can spend half an hour with this
[17:44] <djszapi> not more.
[17:44] <djszapi> if you think that helps you, I can help
[17:44] <djszapi> but I do not have more time, sorry.
[17:44] <slangasek> if you have a solution that works for you, let's not spend any more time on it
[17:45] <djszapi> sleep 30 -> this is the current solution
[17:45] <djszapi> but super fragile.
[17:45] <slangasek> the only way it would help me is to give me the satisfaction of knowing your job was written the Right Way ;)
[17:45] <djszapi> there is no right way
[17:45] <slangasek> but to make any progress I definitely need to see a complete udev log
[17:45] <djszapi> we went through those, none of them worked.
[17:46] <djszapi> give me a start line
[17:46] <djszapi> I can spend half an hour
[17:46] <djszapi> warning: not more
[17:46] <djszapi> /etc/init/udevmonitor.conf -> stop rule: commented
[17:47] <slangasek> right
[17:47] <slangasek> then reboot
[17:47] <djszapi> no matter what start line ?
[17:47] <slangasek> yes
[17:47] <djszapi> in my job ?
[17:47] <djszapi> yes what ?
[17:48] <djszapi> start on runlevel [23] and stopped udevtrigger
[17:48] <djszapi> this is the current start line
[17:48] <slangasek> then, once booted and you can confirm that your tty is present in /dev/, run 'service udevmonitor stop' and post /var/log/udev
[17:48] <slangasek> yes - to give you a better start line for your job, I first need the debugging info from udev
[17:48] <slangasek> which requires a reboot just to get that
[17:49] <slangasek> so ignore your own job for now, we just need the complete udev log
[17:49] <djszapi> I am paid for this job, I cannot ignore ;)
[17:49] <slangasek> the purpose of this reboot is to *just* get the udev log
[17:50] <slangasek> whether the job starts or not on this reboot is irrelevant to this question
[17:50] <djszapi> root@linaro-ubuntu-desktop:~# service udevmonitor stop
[17:50] <djszapi> udevmonitor stop/waiting
[17:50] <djszapi> root@linaro-ubuntu-desktop:~#
[17:50] <djszapi> you got I was joking right ?
[17:50] <slangasek> heh... sorry, sometimes it's hard to get the humor on IRC
[17:51] <djszapi> ->/var/log/udev is HUGE
[17:51]  * djszapi is intalling wgetpaste
[17:51] <djszapi> heh not available, darn...
[17:51] <slangasek> pastebinit :)
[17:51] <djszapi> how ?
[17:52] <djszapi> scrolling over a large file is not possible
[17:52] <djszapi> time and buffer wise
[17:52] <slangasek> there's a "pastebinit" command in the Ubuntu archive
[17:52] <djszapi> here you go anyway: http://paste.pocoo.org/show/584182/
[17:52] <djszapi> done by wgetpaste from the host
[17:52] <djszapi> after scp'ing the file in question
[17:52] <slangasek> ok
[17:53] <djszapi> pastebinit is not a vailable on my linaro ubuntu for the pandaboard, sorry.
[17:53] <slangasek> well, it's in the Ubuntu archive ;)  but ok
[17:53] <slangasek> are you using an initramfs when booting?
[17:54] <djszapi> no clue, sorry.
[17:54] <slangasek> ok
[17:54] <slangasek> I'll assume you are then
[17:56] <slangasek> udev starts at 9.82s after boot.  kernel sees ttyUSB0 at 13.35s after boot.  That may or may not be enough time that coldplugging has missed the event
[17:56] <djszapi> dmesg | grep initramfs
[17:56] <djszapi> [    0.372070] Trying to unpack rootfs image as initramfs...
[17:56]  * slangasek nods
[17:57] <djszapi> what next ?
[17:57] <slangasek> so I would expect 'start on tty-device-added DEVNAME=ttyUSB0' to do the right thing
[17:57] <slangasek> is that one that you tried?
[17:57] <djszapi> nope
[17:58] <djszapi> tty-device-added DEVPATH=*ttyUSB0
[17:58] <djszapi> I tried that one.
[17:58] <djszapi> Note the star.
[17:58] <slangasek> yeah
[17:58] <slangasek> that should *also* have worked
[17:58] <djszapi> then yep, I tried.
[17:58] <djszapi> went nowhere usable.
[17:59] <djszapi> can I restore the stop rule in here: /etc/init/udevmonitor.conf ?
[17:59] <slangasek> yes
[17:59] <djszapi> http://paste.kde.org/460154/ -> this essentially right ?
[18:00] <slangasek> oh, actually, I see that the tty subsystem event comes before the usb-serial subsystem event
[18:00] <djszapi> oh ?
[18:00] <djszapi> PL2303 usb-serial converter
[18:00] <djszapi> that resides between the pandaboard and the modem.
[18:01] <djszapi> because the pandaboard and the modem both have male serialport connection
[18:01] <djszapi> and I have not bothered with fixing that.
[18:01] <djszapi> since I had a usb-serial converter by off-hand.
[18:01] <djszapi> both should work anyway...
[18:02] <djszapi> so what can we do if any ?
[18:02] <slangasek> whoops, no, we don't get a usb-serial udev event anyway, only a kernel event
[18:02] <slangasek> and that udev event is emitted after both the kernel events
[18:03] <djszapi> well
[18:03] <djszapi> I am now trying the start on tty-device-added DEVNAME=ttyUSB0 line
[18:03] <djszapi> let me know if you need any logs.
[18:03] <djszapi> after a boot
[18:03] <slangasek> no logs, though I'm interested to know if that works
[18:03] <djszapi> lol
[18:03] <slangasek> oh wait
[18:03] <slangasek> DEVNAME=/dev/ttyUSB0
[18:03] <djszapi> yeah ?
[18:03] <slangasek> so DEVNAME=ttyUSB0 will definitely fail
[18:04] <slangasek> sorry
[18:04] <djszapi> right, that is why I have been recommended by the stars
[18:04] <djszapi> though hard coding is not that bad in this special case
[18:04] <djszapi> since it is always like that
[18:04] <djszapi> ttyUSB0 is right under /dev
[18:04] <djszapi> if not, many stuff will break in the world :D
[18:04] <slangasek> yeah; either DEVNAME=*/ttyUSB0 or DEVNAME=/dev/ttyUSB0 should work
[18:05] <slangasek> and if those don't work, I think this is a kernel driver bug
[18:05] <djszapi> now: start on tty-device-added DEVNAME=/dev/ttyUSB0
[18:05] <djszapi> phantastic...
[18:05] <slangasek> because we should not be seeing these events before the driver is initialized and ready for use
[18:05] <djszapi> there is already a pl2303 kernel bug
[18:05] <djszapi> I did not even bother to report it
[18:05] <djszapi> since I have no clue where to report that
[18:05] <djszapi> and I do not wanna spend hours for finding where to report
[18:06] <slangasek> I could tell you where based on 'uname -r'
[18:06] <djszapi> 3.1.1-26-linaro-lt-omap
[18:07] <djszapi> linaro just wraps upstream IMO
[18:07] <slangasek> in a manner of speaking
[18:08] <slangasek> in the case of the pl2303 bug, that's probably true
[18:08] <slangasek> this bug may be an omap-specific usb bug though
[18:08] <djszapi> perhaps
[18:08] <djszapi> but the other bug was appearing on my Lenovo Thinkpad 510 laptop
[18:08] <djszapi> two connected usb-serial
[18:08] <djszapi> second did not work
[18:09] <djszapi> not even with stty -F :)
[18:09] <djszapi> in any case
[18:09] <slangasek> https://bugs.launchpad.net/linux-linaro to report issues with the omap kernel
[18:09] <djszapi> my binary is not even run (according to "ps aux | grep foobar") after the start on ... line.
[18:09] <slangasek> hmm, really?
[18:09] <djszapi> really.
[18:10] <djszapi> that is what I said above as well
[18:10] <slangasek> I think you should just revert to the 'sleep' for now then, sorry
[18:10] <djszapi> http://paste.kde.org/460160/
[18:10] <slangasek> hmm
[18:11] <slangasek> I don't know why that's not working
[18:11] <djszapi> I wonder how long sleep I should put in there.
[18:11] <djszapi> not to get a brittle system
[18:12] <slangasek> nor do I
[18:16] <djszapi> start on runlevel [23] and stopped udevtrigger
[18:16] <djszapi> do I need both before a sleep ?
[18:16] <djszapi> or just the second ?
[18:16] <slangasek> probably the second is enough
[18:17] <djszapi> let me try.
[18:17] <djszapi> sleep 20 is now what I do
[18:17] <djszapi> trying atm with 10 secs.
[18:18] <djszapi> I just wonder what the border is. :-)
[18:18] <djszapi> I will not use this low value for sure.
[18:18] <djszapi> (in the end)
[18:27] <djszapi> slangasek: second is enough, yeah.
[18:27] <djszapi> slangasek: what should be the stop line ?
[18:35] <djszapi> jodh, SpamapS and slangasek: thank you for your help
[18:46] <slangasek> stop line> I don't know, when do you want it to stop? :)  'stop on runlevel [016]' would be typical
[22:57] <marcoceppi> I've written an upstart script, and the script requires a HOME environment, I have a user for the daemon to run as, how do I let upstart script know where HOME is and pass that env on to the exec command?
[22:58] <marcoceppi> I tried adding evn HOME="/home/user" to the upstart script with no luck
[22:58] <slangasek> s/evn/env/ ?
[22:59] <marcoceppi> slangasek: yes typo in chat, not a typo in the config
[22:59] <slangasek> ok, just checking
[22:59] <marcoceppi> here is the current upstart script
[22:59] <marcoceppi> (if it helps)
[22:59] <marcoceppi> http://paste.ubuntu.com/937599/
[23:03] <slangasek> it's possible you also need to 'export HOME'
[23:03] <slangasek> I'm not sure what the semantics of env vs. export are, honestly
[23:03] <slangasek> I'm not convinced the manpage describes the current behavior accurately
[23:04] <slangasek> hmm... but I see other jobs on the system that use that just fine
[23:04] <marcoceppi> I'll give export a quick try


[00:58] <broder> hmm...does anybody do processing on lintian.d.o for things like tags over time?
[02:14] <highvoltage> hey broder
[02:15] <highvoltage> do you know if there's a script or site that can show me packages that are in universe but not in debian?
[02:29] <ajmitch> highvoltage: why yes there are scripts :)
[02:29] <ajmitch> http://qa.ubuntuwire.com/mdt/universe.html
[02:29] <highvoltage> thanks, ajmitch
[02:30] <highvoltage> Not in Wheezy : 1135 packages
[02:30] <highvoltage> I honestly didn't expect that number to be so high.
[02:30] <ajmitch> that includes a lot of i18n packages, packages removed from testing, etc
[02:31] <ajmitch> usually the comparison is between sid & the current ubuntu release, but the LTS is special
[02:41] <jbicha> and that's not including main packages
[02:42] <ajmitch> right, there's probably quite a few more in main
[02:44] <highvoltage> yeah, at least the packages in main are probably cared for. I'm wondering about packages that should be dropped/orphaned in universe. (stuff like feisty-session-splashes, potentially)
[02:45] <micahg> highvoltage: we need to do a lot of cleaning before the LTS, so feel free to start now :)
[02:47] <highvoltage> micahg: yep. I'll do my part. If that list of 1135 packages could be halved for 12.04 then that would already be good I think.
[02:47] <highvoltage> so that script just compares between wheezy and precise? I guess some of those packages might be in unstable too
[02:47] <micahg> yep, some are updated in unstable, some removed
[02:48] <ajmitch> highvoltage: I can get you a list of the difference between unstable & precise
[02:48] <ajmitch> just not as pretty as mdt
[02:48] <micahg> well, that's not entirely good either, we don't want everything from unstable
[02:49] <micahg> ah, you mean in precise but missing in unstable
[02:49] <ajmitch> yes
[02:49] <micahg> carry on :)
[02:49] <highvoltage> ajmitch: yeah, I need to learn how that works. Ideally I'd like a column that says when the package was last updated, and how many bugs it has against it
[02:49] <ajmitch> micahg: I have that list somewhere as a byproduct of the rcbugs list
[02:49] <highvoltage> would be nice to have some kind of idea of which packages are bad and kind of abandoned
[02:49] <ajmitch> highvoltage: that's possible, might be best to do that with UDD
[02:50] <broder> highvoltage: i think tumbleweed put a report kind of like that together
[02:50] <broder> something like "packages that have gone the longest without being uploaded"
[02:50] <broder> let me see if i can find it
[02:50] <micahg> well, there's a semi-automated script I think which can remove stuff that's been removed from Debian where we have no diff, maybe we can get that run before we start to file removal requests
[02:51] <highvoltage> broder: that would make sense, tumbleweed is always 2 steps ahead of me :)
[02:51] <ajmitch> http://qa.ubuntuwire.com/oldmerges/
[02:51] <broder> ajmitch: that's the one
[02:52] <broder> also, lintian run is on "z" :)
[02:52] <ajmitch> it doesn't include packages that haven't been touched for years in debian & are unmodified in ubuntu, but that probably wouldn't be hard to get either
[02:52] <ajmitch> broder: nice
[02:52] <broder> though i bet it'll take it a while to generate the html reports after it finishes
[02:52] <broder> ajmitch: i think those packages are definitely a secondary concern for us
[02:53] <ajmitch> broder: I need to sort out stuff on mekaneck with wgrant, so that I can set up a CNAME record for lintian.uw.o
[02:53] <ajmitch> broder: agreed, the oldmerges page should keep us busy enough :)
[02:54] <broder> ajmitch: no worries. i'll keep working on the output some anyway
[02:55] <ajmitch> broder: you plan to push the lintian reports there regularly?
[02:56] <broder> yeah, i was planning to put it on a cron job
[02:56] <ajmitch> fair enough, tell me if you need me to set anything else up
[02:57] <broder> i think all i need is somewhere to throw it
[02:58] <ajmitch> sure, you can put it somewhere in your home dir & I'll point apache to it
[02:58] <broder> ok. sounds good. i guess i'll push it to people.uw.o for the time being until we get the CNAME setup
[02:58] <ajmitch> it's the same host, so whatever works :)
[02:59] <ajmitch> "arkose exists in precise (universe) but not in Debian" - not the most detailed output there per package, I guess
[03:02] <wgrant> ajmitch: What's up?
[03:04] <ajmitch> wgrant: can you check if I have sudo access on mekaneck?
[03:05] <wgrant> ajmitch: You seem to...
[03:06] <StevenK> ajmitch: sudo -l ?
[03:07] <ajmitch> it's more likely that I can't recall which password I'd used at some time in the distant past on that machine, but I've never had a ~/.sudo_as_admin_successful on there
[03:08] <StevenK> ajmitch: That is a slightly seperate problem :-)
[03:09] <ajmitch> StevenK: yeah, a pity that sudo doesn't just trust my ssh key :)
[03:09] <StevenK> Haha
[03:26] <funkyHat> ajmitch: alias sudo="ssh root@localhost"
[03:26] <funkyHat> ;)
[03:30] <ajmitch> funkyHat: /win 28
[03:30] <ajmitch> oops :)
[03:30]  * funkyHat looks in window 28. Huh, that's just #ubuntu-devel. ;)
[03:30] <ajmitch> funkyHat: yeah, that'd work with agent forwarding, and if the public key was allowed for root as well
[03:30] <ajmitch> #ubuntu-devel should be in your top 10 at least
[03:31] <funkyHat> It would break if you tried to use -i or anything else though
[03:31] <funkyHat> ajmitch: I have bindings for windows up to 100
[03:31] <ajmitch> still no excuse :)
[03:32] <funkyHat> And -motu is 8, so -devel being 28 is nice because they have almost the same keybinding ⢁)
[03:32] <funkyHat> (I have a whole bunch like that, -meta sits on top of #u for example)
[03:33] <funkyHat> How sad ❡⢁)
[03:52] <ajmitch> broder: lintian stuff still rsyncing?
[04:49] <broder> ajmitch: uh...it seems to have followed a recursive symlink :)
[04:51] <broder> ajmitch: there
[04:52] <broder> http://people.ubuntuwire.org/~broder/lintian/ (note: for those playing along at home, url not permanent. skinning not permanent. etc.)
[04:55] <ajmitch> broder: right, I was looking at the tags there & found I couldn't access them earlier :)
[04:55] <ajmitch> I'll point lintian.uw.o there
[04:55] <broder> cool :)
[05:12] <wgrant> Hmmm.
[05:12] <wgrant> I wonder if I still have my Ubuntu lintian instance around somewhere.
[05:13] <wgrant> I ran one for a little while years ago, but then liw started one in the DC.
[05:13] <broder> http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ is still the canonical source for "ubuntu policy", in so much as it exists distinct from "debian policy", right?
[05:23] <broder> ok. made a half-hearted effort to ubuntu-ify the output :)
[05:29] <ajmitch> broder: how long did it take to run over the whole archive?
[05:30] <broder> day and a half, i guess?
[05:30] <broder> maybe longer
[05:30] <ajmitch> so I guess you won't be updating it too often
[05:30] <broder> wasn't really paying attention, and had to restart it a couple of times
[05:30] <broder> it does incremental updates
[05:30] <ajmitch> ah good
[05:30] <ajmitch> I was about to ask that :)
[05:55] <broder> ajmitch: ok. lab and sync is on a cron job now
[08:38] <dholbach> good morning
[11:05] <tumbleweed> highvoltage: you are actually looking for http://ubuntu-dev.alioth.debian.org/cgi-bin/neglected-packages.cgi
[13:29] <highvoltage> sladen vs kinect: http://www.youtube.com/watch?feature=player_embedded&v=sxZplO4XPpE
[13:36] <sladen> damn youtube
[15:07] <genjix> tumbleweed: you mentioned before about debian unstable for a library with a constantly changing API/ABI. is there some kind of thing where i can hand over the packages to a maintainer?
[15:08] <genjix> i already made the packages but i have no idea what i'm doing because i'm a lacklustre maintainer
[15:08] <genjix> https://launchpad.net/~genjix/+archive/libbitcoin
[15:36] <jdstrand> dholbach: hey, do you know who owns the ubuntu fridge calendar?
[15:37] <dholbach> jdstrand, you should be able to make modifications if I read https://wiki.ubuntu.com/Fridge/Calendar correctly
[15:38] <jdstrand> dholbach: yes. I was able to add a calendar
[15:38] <jdstrand> dholbach: err, calendar item
[15:38] <jdstrand> dholbach: problem is, I want it to forget about one that is not in a calendar I control
[15:38] <jdstrand> dholbach: ie, kees'
[15:38] <dholbach> good question
[15:39] <jdstrand> dholbach: 'Security Team Catch-up' should be forgotten by the Ubuntu Fridge clendar
[15:39] <dholbach> maybe the guys in #ubuntu-news (or was it #ubuntu-news-team) know?
[15:39] <jdstrand> I'm fairly certain kees can't access that calendar any more too
[15:39]  * jdstrand tries
[15:39] <jdstrand> dholbach: thanks
[15:41] <Quintasan> dholbach: Your air hockey match should be up on internets soon, depending on when my ISP unbreaks my internet :)
[15:42] <dholbach> Quintasan, oh man.............. it's not like I was actually good :)
[15:43] <Quintasan> Well, but the idea of playing with two of those disks was superb
[15:44] <dholbach> ok, let's wait for the video then ;-)
[16:51] <tumbleweed> genjix: Actually, I was talking about experimental. Having libraries like that in ustable isn't easy because you'll have lots of transitions to handle.
[17:10] <genjix> tumbleweed: ok
[17:10] <genjix> but same thing still
[17:26] <highvoltage> +    Has there been a recent scrub to highlight the orphaned packages in Universe? It might be useful to make them visible and put them up for adoption? Failing that, possibly look at removing from the archive?
[17:26] <highvoltage> dholbach: should that perhaps also be a work item? ^^^ (to initiate/drive a scrub?)
[17:28] <dholbach> maybe
[17:28] <dholbach> or bring it up on the mailing list?
[17:33] <highvoltage> ok
[18:04] <LaserJock> so if I have a package in Oneiric that segaults, and an to fix it I need to fix a library and then rebuild, would I need to do 2 separate SRUs?
[18:04] <LaserJock> s/and an/and/
[18:04] <AnAnt> Hello, what was the last sync from Debian testing to precise ?
[18:04] <AnAnt> s/what/when
[18:06] <mewerner_arand> Is it not ongoing still?
[18:06] <geser> AnAnt: try asking an archive admin in #ubuntu-devel
[18:07] <AnAnt> geser: how can I know archive admins ?
[18:07] <geser> simply ask and hopefully someone will answer
[18:08] <micahg> LaserJock: yes, well, 2 uploads, I think 1 bug can track both
[18:09] <LaserJock> if the library is used to build other packages would I have to rebuild those too or is it enough to leave them alone?
[18:09] <LaserJock> there are only a handful, but I'd rather not have to SRU a bunch of packages to fix 1
[18:10] <micahg> LaserJock: are you breaking ABI with the fix?
[18:10] <jtaylor> depends, if the soversion changes yes, else no
[18:10] <LaserJock> there were just headers that failed to be installed via the .install
[18:11] <LaserJock> the broken packages need those headers, the code isn't changing
[18:11] <jtaylor> how did the rdeps build then in the first place?
[18:11] <jtaylor> without the headers
[18:12] <LaserJock> they must not have needed those particular one
[18:12] <LaserJock> s
[18:12] <jtaylor> not needed, or disabled some features?
[18:12] <LaserJock> I don't know yet
[18:13] <AnAnt> is there a reason that the following packages are not sync'ed from Debian testing: xpra & xcb-util-renderutil
[18:13] <jtaylor> should be checked, it would be problematic if yes, as the next update of the rdeps will enable new features not previsously in the release
[18:14] <micahg> AnAnt: there probably hasn't been a sync since before UDS
[18:14] <AnAnt> ok
[18:14] <ajmitch> xpra is version 0.0.6+dfsg-1ubuntu1, so it needs merged or manually synced after explaining why the diff can be dropped
[18:14] <AnAnt> ajmitch: oh
[18:15] <highvoltage> mjeanson: btw, here's the link to the ding-libs source package I last uploaded: http://mentors.debian.net/package/ding-libs
[18:15] <jtaylor> does request-sync also only look in testing?
[18:15] <jtaylor> it always complains that ubuntu version is newer
[18:15] <jtaylor> although its not since 3 days
[18:15] <micahg> AnAnt: the other one is a new package apparently and those are syncd less frequently than what's already in then archive
[18:16] <AnAnt> micahg: ?
[18:16] <AnAnt> micahg: why's that ?
[18:16] <micahg> different set of commands I think?
[18:17] <micahg> AnAnt: if it's needed relatively soon, you can file a sync request (still has to go through NEW though) (idk about syncpackage and new packages)
[18:18] <AnAnt> micahg: ok, thanks
[18:18] <geser> NEW syncing also includes checking if the new binary packages don't "overwrite" other binary packages from existing source packages and also processing of the NEW queue (accept/review the source package)
[18:18] <jtaylor> hm is something wrong with importing new versions from debian?
[18:19] <jtaylor> deleted my lpcache and its still not letting me sync ._.
[18:19] <geser> new versions or NEW source packages?
[18:19] <jtaylor> just version numbers
[18:19] <geser> check what LP knows about the package in Debian and Ubuntu
[18:19] <jtaylor> requestsync thinks python-django-piston is newer in ubuntu than debian
[18:19] <geser> which package btw?
[18:20] <micahg> jtaylor: requestsync should be looking at testing, so that's correct
[18:20] <jtaylor> how do I force it to unstable?
[18:20] <jtaylor> tried setting the base version
[18:20] <micahg> jtaylor: -d unstable
[18:20] <AnAnt> ah, xpra is also a new package !
[18:20] <AnAnt> and parti-all needs to be removed
[18:21] <micahg> AnAnt: ah, yes, new source, binaries are in already
[18:22] <jtaylor> yey changelog not found ._.
[18:22] <tumbleweed> that shouldn't be a blocker
[18:22] <jtaylor> ok then the manual way ._.
[18:23] <jtaylor> or can one already sync via a button in launchpad? if yes can someone do that? its an security update
[18:23] <tumbleweed> we use a script (syncpackage) not a button
[18:24] <AnAnt> micahg: so, should a removal be requested for parti-all (because of the Ubuntu delta), or that isn't needed anyways ?
[18:24] <tumbleweed> a security update probably shouldn't have used urgency=low
[18:24] <rryan`> hi all, i just uploaded a package to REVU (my first) and I was wondering if anybody could spot-check it for me to see if there are any serious issues: http://revu.ubuntuwire.com/p/mixxx
[18:25] <micahg> AnAnt: yeah, if we have a diff, you can file that after the new source is sync'd though
[18:25] <jtaylor> tumbleweed: I agree, it was a bit weirdly handled, debian stable hasn't got the update yet either
[18:25] <tumbleweed> rryan`: we're trying to get rid of REVU, and generally trying to get new packages in via Debian
[18:26] <tumbleweed> rryan`: but in this case, mixx is already in Ubuntu, are you trying to update it?
[18:26] <AnAnt> micahg: shouldn't the removal be requested first before syncing xpra (since both provide the same binary packages) ?
[18:26] <LaserJock> what's the best way to build a package if it requires a package not in the archives? PPA, local repo, some trick with pbuilder?
[18:26] <micahg> AnAnt: no, the new binaries will supersede the old ones
[18:26] <AnAnt> micahg: thanks
[18:26] <rryan`> tumbleweed : yup, we just released a new bugfix release
[18:26] <broder> LaserJock: PPA is probably most straightforward
[18:27] <broder> shouldn't have to do anything special - just upload the out-of-archive dependencies, then the actual package
[18:27] <rryan`> tumbleweed : oneiric onwards has 1.9.0+dfsg0-4, 1.9.2 is our latest version
[18:27] <LaserJock> broder: make sense, thanks
[18:28] <tumbleweed> rryan`: I suggest you contact the debian maintainers of the package. Packages filter through from Debian to Ubuntu (unless there's a good reason for them not to)
[18:28] <tumbleweed> (also in this case, the maintainer is active in Ubuntu too)
[18:28] <tumbleweed> http://packages.qa.debian.org/m/mixxx.html
[18:29] <rryan`> tumbleweed: gotcha, thanks. I did send alessio a note but haven't heard back from him yet
[18:30] <micahg> indeed, also, that team is pretty open, so if you'd like to help maintain in Ubuntu/Debian, I'd suggest joining the team and doing it in the Debian Multimedia git repo
[18:30] <tumbleweed> rryan`: he was at UDS last week, probably still getting home / recovering. Give him a few days...
[18:30] <rryan`> tumbleweed : k, will do
[18:31] <tumbleweed> (assuming you poked him in the last week)
[18:35] <tumbleweed> jtaylor: synced
[18:36] <jtaylor> thx
[18:37] <tumbleweed> jtaylor: need release nominations for the bug?
[18:37] <jtaylor> is already on the security sponsors todolist
[18:37]  * tumbleweed should probably learn more about Ubuntu's security workflows at some point...
[18:37] <jdstrand> jtaylor: I suggest joining #ubuntu-security
[18:38] <jtaylor> not -hardened?
[18:38] <jdstrand> jtaylor: we have a role for processing sponsored patches
[18:38] <jtaylor> thats what I was told last time is the place to go :)
[18:38] <jdstrand> jtaylor: either. -security forwards to -hardened
[18:38] <jdstrand> UDS kinda put last week behind, but I think tyhicks may be looking at it
[18:49] <highvoltage> Laney: I see you got mentioned on bansheegeddon
[18:49] <ajmitch> highvoltage: of course he would be
[18:52] <ajmitch> highvoltage: he's part of the supersecretelite debian team that looks after such packages
[19:03] <micahg> geser: DMB?
[19:07] <geser> now?
[19:16] <micahg> geser: yes
[19:18] <geser> forgot that due to DST change it's now an hour earlier for me
[19:19] <micahg> mdeslaur: ^^ you win :)
[19:19] <ajmitch> heh
[19:20] <mdeslaur> micahg: hehe :)
[19:20] <geser> micahg: what did he win?
[19:20] <micahg> geser: the right to say "I told you so" :)
[19:39] <broder> tumbleweed: have you pushed any of your requestbackport stuff anywhere yet? i want to experiment with writing a backport bugbot
[20:56] <tumbleweed> broder: right, I think I finished that on the plane, let me test it and push it to a branch for you to play with
[21:03] <blair> i wrote commit and pushed it into a bzr branch to update python-rbtools 0.2 to 0.3.4.  the package is also in debian, so does the new ubuntu version number have "ubuntu" in it?
[21:04] <blair> as in 0.3.4-1ubuntu1 or should it be 0.3.4-1?
[21:04] <ajmitch> it would be 0.3.4-0ubuntu1 in that case
[21:04]  * ajmitch saw that the maintainer hadn't replied to the 'new upstream version' bug filed in february
[21:05] <blair> i want to get this into the 12.04 release that i want to move our company to (from fedora13), is doing the work in ubuntu the best way, or having debian get the upgrade and doing a sync to ubuntu?
[21:06] <ajmitch> it'd be best to get it done in debian first & synced - you'd have until feature freeze to get that done
[21:06] <ajmitch> providing an updated package for the debian maintainer to look at can be useful
[21:06] <blair> ok, so take my bzr changes and make the same change to the debian package?
[21:08] <ajmitch> yes, though you'd be basing it off the upstream tarball
[21:08] <blair> right
[21:08] <ajmitch> the debian maintainer may not find a bzr branch useful :)
[21:08] <blair> no, probably not :)
[21:08] <ajmitch> was it much work to update it to the new version?
[21:08] <micahg> mentors.debian.net might be useful
[21:08] <blair> no, not too much work
[21:09] <blair> but i had some questions:
[21:09] <blair> 1) it's one debian policy version behind, does it need to be updated?
[21:09] <blair> 2) in the bzr checkout, there's a .pc directory at the top level that had some patching info in it, it's not in debian's checkout or anywhere else, so i deleted it in my branch since it seemed like cruft
[21:10] <ajmitch> if you've checked that the package follows the policy updates in 3.9.2, then you could update it in debian/control
[21:11] <blair> yeah, i've been doing a few debian packages over the years, but definitely not an expert to know the differences between policy updates
[21:11] <blair> i did a git diff in the debian policy repository, but didn't see anything relevant
[21:11] <ScottK> There's a checklist in the debian-policy package.
[21:11] <ScottK> In general, I wouldn't worry about it.
[21:12] <ajmitch> http://www.debian.org/doc/packaging-manuals/upgrading-checklist.txt also has it
[21:12] <blair> BTW, i'm a MacPorts committer and we have a policy where if a ticket isn't responded to in 3 days a non-maintainer can make a change, is there a similar policy in debian or ubuntu
[21:12] <ScottK> There is actually Ubuntu policy not to update the policy version relative to Debian since it generates meaningless diff.
[21:12] <ajmitch> policy changes in minor version are generally minimal
[21:12] <ajmitch> ScottK: I figured that it'd be ok to update the version in this case when offering it to the debian maintainer
[21:12] <Laney> ScottK: this is about preparing a diff for Debian (iiuc)
[21:12] <ScottK> blair: Debian has a similar policy for severe (release critical) bugs.  For Ubuntu there are no dedicated maintainers so anyone can fix anything.
[21:12] <ScottK> ajmitch: True.
[21:12] <ScottK> Laney: OK.  Nevermind then.
[21:18] <ajmitch> blair: also, we're not going to hold up 0.3.4 from going into ubuntu if you can't get a response from the debian maintainer in a reasonable amount of time
[21:20] <tumbleweed> broder: lp:~stefanor/ubuntu-dev-tools/requestbackport
[21:21] <broder> tumbleweed: cool. i'll check it out tonight
[21:22] <tumbleweed> broder: my demo bug https://bugs.staging.launchpad.net/bugs/860919
[21:22] <tumbleweed> note that all the non-production launchpads don't know that precise is the current dev release, so play along
[21:23]  * broder nods
[21:23] <tumbleweed> dogfood thinks we are on 'rusty robot' :P
[21:23] <broder> looks reasonable
[21:23] <blair> ajmitch, thanks, i'll prepare the patch for upstream and update the ubuntu tickets with the status
[21:24] <ajmitch> alright, thanks
[21:24] <broder> tumbleweed: that seems to have all the information we'd expect to show up in the bug report
[21:24] <broder> as a random thought, it might be cool to have a verification checklist in the "testing" section
[21:24] <tumbleweed> yes, if you will provide one of those
[21:24] <broder> i'll see what i can come up with
[21:25] <broder> ...but not while i'm at work. i'm far enough behind from UDS :)
[21:25] <tumbleweed> it currently has << Mention any build & install tests you've done >>, < List the reverse dependencies that you've tested >
[21:25] <broder> oh right, we got stuck because there's no good way to lookup rdeps for the not-current release in the absence of chdist/chroot/etc. setup, right?
[21:26] <tumbleweed> we decided to solve that with a webservice
[21:26] <tumbleweed> we just need to write it...
[21:27] <ajmitch> broder: unless you went with manually grabbing the Packages files & using grep-dctrl
[21:27] <broder> ajmitch: *good* way :-P
[21:27] <ajmitch> :)
[21:28] <Laney> we should make the ubuntu-dev-tools refuse to proceed if you've left templates in
[21:28]  * ajmitch still has to get that backport tester in a working shape for demo purposes
[21:28] <Laney> especially submittodebian
[21:28] <tumbleweed> Laney: good point, but please file a bug because I'm pretty tired (thankfully, slept until 2pm today...)
[21:29] <Laney> ditto
[21:29] <ajmitch> tumbleweed: it's not like you would have had a long flight? :)
[21:29]  * ajmitch was tired after UDS, but that was more because of getting up at 2AM to listen in on sessions
[21:30] <tumbleweed> ajmitch: no, it was shorter on the way back, only 18 hours total :)
[21:30] <ajmitch> that's nothing
[21:31] <tumbleweed> :)
[21:32] <ajmitch> dunedin->seville was about 36 hours travelling each way, was a fun trip :)
[21:51] <broder> tumbleweed: hmm...looks like the determine_destinations isn't quite working correctly. determine_destinations('precise', 'hardy') -> ['hardy', 'lucid']
[21:51] <broder> but as of right now we'd still need to do maverick/natty/oneiric backports for that as well
[21:59] <tumbleweed> true
[22:00] <broder> it might be sufficient to reset support_gap every time you hit an LTS
[22:01] <tumbleweed> that sounds reasonable
[22:04] <tumbleweed> broder: pushed
[22:12] <micahg> why not just take every supported release between the 2 in question
[22:12] <micahg> ah, nevermind :)


[06:03] <RikMills> adrien: if you look at the test history (e.g. https://autopkgtest.ubuntu.com/packages/e/exim4/noble/amd64) you will see that the test of most architectures has been retried with multiple triggers, including the 4.97-3ubuntu2 in proposed
[06:04] <RikMills> so excuses show that latest version as what was tested
[06:05] <RikMills> for ppc64el no-one has triggered a test against 4.97-3ubuntu2, just 4.97-3ubuntu1 in release pocket
[06:27] <adrien> RikMills: oh, thanks, that's a much simpler reason than I was expecting; I triggered a test with the new exim4 version (the failure in ppc64el is close to the one on other arches, but is different)
[07:25] <RikMills> adrien: yeah. looks like tests are now passing, and only waiting to see if that does the same on arm64
[07:25] <RikMills> a arm64 test is in the queue, but may be some while before that gets done
[09:24] <adrien> RikMills: ah, I hadn't seen your message and I triggered it too :P
[09:24] <adrien> anyway, indeed, it looks like the new runs fixed it; I'm not sure it's due to this specific change however considering how much the archive is changing at the moment
[11:06] <rbasak> @pilot in
[15:22] <kajiya> Can I bribe someone in return for an upload to noble please? :D The LP bug's here: https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/2050956
[15:22] -ubottu:#ubuntu-devel- Launchpad bug 2050956 in google-guest-agent (Ubuntu Noble) "Update d/control file with dependencies" [Undecided, New]
[15:46] <rbasak> @pilot out
[16:32] <athos> @pilot in
[19:26] <sergiodj> dbungert: I'm working on taurus-pyqtgraph
[19:32] <sergiodj> that's done.  now working on r-bioc-savr
[19:35] <ginggs> sergiodj: where did you see r-bioc-savr?
[19:36] <sergiodj> ginggs: ravikant_ mentioned it here yesterday.
[19:36] <sergiodj> I'm seeing that there's an RM request against it on Debian
[19:36] <sergiodj> so I'll leave a comment on the bug and move on
[19:37] <ginggs> sergiodj: ah ok, yes, i was going to mention debian bug #1061114
[19:37] -ubottu:#ubuntu-devel- Debian bug 1061114 in ftp.debian.org "RM: r-bioc-savr -- ROM; Orphaned upstream, removed by Bioconductor" [Normal, Open] https://bugs.debian.org/1061114
[19:37] <sergiodj> yep
[19:40] <sergiodj> I'll go back to update_excuses for now
[19:40] <sergiodj> starting from the bottom
[19:48] <sergiodj> I'm taking a look at tiledarray
[20:01] <athos> @pilot out
[20:20] <hazem-soussi> hi dear collegues
[20:20] <hazem-soussi> i want to share with you my impression after passing one year implemeting k8s
[20:21] <hazem-soussi> that's really an universal technology , not only simple as for deploying apps
[20:21] <hazem-soussi> :-)
[20:37] <dbungert> sergiodj: ACK, thanks
[21:54] <sergiodj> tiledarray is a mess.  I've made progress but stumbled upon another build failure.  moving on
[22:02] <sergiodj> I'm taking a look at celery.  it's been removed from Ubuntu, but if I can fix it in Debian then several packages will be unblocked


[18:30] <Lopi> can someone point me to documentation detailing how to generate an arm initrd?
[23:43] <jraynes> Hi all. trying to load ubuntu on my Beagleboard xM and I'm having a little trouble.  I downloaded ubuntu-11.04-preinstalled-netbook-armel+omap4.img.gz, unzipped it with 7-zip and copied the raw image over to my SD card with win32diskimager. When I put the SD Card in my Beagleboard and turn it on I don't get any video or serial at all. Any ideas as to what I'm doing wrong here?
[23:47] <infinity> jraynes: The Beagleboard is omap3, not omap4 (so, use the "omap" image)
[23:50] <jraynes> Downloading now.. thanks.